הגדרת חיבור בין עננים ל-Databricks Unity Catalog

חיבור חוצה-עננים ל-Databricks Unity Catalog מאפשר לשלוח שאילתות על נתונים מהקטלוג הזה ישירות ב- Google Cloud. היכולת הזו מאחדת את ניתוח הנתונים שלכם על ידי שילוב של מקורות הנתונים החיצוניים עם הסביבה הקיימת שלGoogle Cloud .

אחרי שמגדירים את החיבור, אפשר לנהל את הגישה לנתונים המאוגדים ב-Lakehouse ללא גבולות.

לפני שמתחילים

  1. בסקירה הכללית על Lakehouse מוסבר איך מנוהלת הגישה לנתונים ב-Lakehouse.
  2. כדי להבין איך זה עובד, קראו את המאמר גישה לנתונים חוצי-עננים.
  3. בודקים את הקטלוגים הנתמכים כדי לוודא שההגדרות נתמכות.
  4. להבין איך משתמשים בסודות אזוריים ב-Secret Manager. ההרשאה הזו נדרשת כדי להגדיר Lakehouse עם Databricks Unity Catalog באמצעות אימות מבוסס-סוד.
  5. אופציונלי: אם אתם מתכננים לנתב שאילתות דרך חיבור פרטי בין ה-VPC Google Cloud שלכם לבין ה-VPC של ספק שירותי הענן המרוחק (לדוגמה, AWS), ודאו שיש לכם חשבון פעיל אצל הספק המרוחק, הקצו Dedicated Cross-Cloud Interconnect או Partner Cross-Cloud Interconnect, הגדירו סשנים של BGP עם Cloud Router וודאו שיש לכם את הרשאות ה-IAM הנדרשות בשתי סביבות הענן.
  6. אופציונלי: אם אתם מתכננים להשתמש באיחוד זהויות של משתמשים כדי להפיץ זהויות של משתמשי קצה בשאילתות, ודאו ש:
  7. נכנסים לחשבון Google Cloud . אנחנו ממליצים למשתמשים חדשים ב- Google Cloud ליצור חשבון כדי שיוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

  8. Verify that billing is enabled for your Google Cloud project.

  9. Enable the BigLake, Secret Manager APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  10. Verify that billing is enabled for your Google Cloud project.

  11. Enable the BigLake, Secret Manager APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

    12.

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות להגדרת גישה חוצת-עננים, בקשו מהאדמין להקצות לכם את התפקידים הבאים ב-IAM בפרויקט:

להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.

מגבלות ושיקולים

בקטע הזה מפורטות המגבלות והשיקולים שצריך להביא בחשבון כשניגשים לנתונים חוצי-עננים.

  • ספקי שירותי ענן שנתמכים ב-Cross-Cloud Interconnect: אפשר להשתמש בחיבור פרטי כדי לגשת לנתונים חוצי-עננים (cross-cloud) בספקי שירותי הענן המרוחקים הבאים: Amazon Web Services ‏(AWS). אפשר להשתמש ב-Dedicated Cross-Cloud Interconnect או ב-Partner Cross-Cloud Interconnect.
  • ניתוב ברשת: אם לא מוגדר חיבור פרטי (כמו Dedicated CCI או Partner CCI), השאילתות מנותבות דרך האינטרנט הציבורי. זה עלול לגרום לעלייה בעמלות על תעבורת נתונים יוצאת מספק שירותי הענן המרוחק, ולביצועים פחות צפויים.
  • הגדרת Databricks Unity Catalog:
  • לקריאה בלבד: קטלוגים מאוחדים ב-Lakehouse הם תצוגות לקריאה בלבד של הקטלוג המרוחק. אי אפשר לבצע שינויים במשאבים (כמו יצירה, עדכון או מחיקה של משאבים), וצריך לבצע אותם ישירות בקטלוג המרוחק.
  • עדכניות הנתונים: הדגל --refresh-interval בקטלוג מאוחד קובע את תדירות הסנכרון של המטא-נתונים. הערך צריך להיות 0s (מושבת) או לפחות 300s (5 דקות). ככל שיש יותר משאבים של מרחבי שמות וטבלאות, יכול להיות שייקח יותר זמן לרענן את המטא-נתונים ברקע של הקטלוג. אם הרענון הקודם חורג מהזמן, הרענון הנוכחי ידלג, אבל הרענון הבא יתוזמן במרווח הזמן הבא. השאילתות משתמשות במטא-נתונים של הקטלוג שסונכרנו לאחרונה, כך ששינויים שבוצעו בקטלוג המרוחק, כמו טבלאות חדשות, עדכוני סכימה או נתונים חדשים, לא גלויים ב-Lakehouse עד להשלמת הרענון הבא של המטא-נתונים ברקע.
  • שמירה במטמון של Lakehouse: השמירה במטמון של Lakehouse מופעלת באופן אוטומטי בכל השאילתות חוצות-העננים, כדי לחסוך בעלויות של תעבורת נתונים יוצאת על ידי אחסון מקומי של בלוקים של נתונים ב- Google Cloud. אי אפשר להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) לשמירה במטמון. הנתונים שנשמרים במטמון מוצפנים באמצעות Google-owned and Google-managed encryption keys. אם אילוץ מדיניות הארגון constraints/gcp.restrictNonCmekServices נאכף על טבלה כלשהי בשאילתה, השמירה במטמון מושבתת באופן אוטומטי בשאילתה הזו. מידע נוסף זמין במאמר שמירה חכמה במטמון.
  • מיקום אחסון הנתונים ותאימות: כשיוצרים קטלוג מאוחד או חיבור באזור Google Cloud , הנתונים במטמון נשמרים באחסון באזור היעד הזה. אם נתוני הענן המרוחקים נמצאים בסמכות שיפוט אחרת, ודאו שהשמירה במטמון באזורים שונים עומדת בדרישות של הארגון לגבי מיקום אחסון הנתונים ועמידה בתקנות.

תהליך עבודה כללי

כדי לגשת לנתונים חוצי-עננים, פועלים לפי השלבים הכלליים הבאים:

  • הגדרת Cross-Cloud Interconnect (אופציונלי): מגדירים חיבור פרטי בין ה-VPC של Google Cloud לבין ספק שירותי הענן המרוחק.
  • הגדרת איחוד: מגדירים אימות ויוצרים קטלוג מאוחד ב-Lakehouse.
    • אימות בסיסי (חובה): מגדירים OpenID Connect (OIDC) (מומלץ) או אימות מבוסס-סוד כדי לאפשר ל-Lakehouse לבצע סנכרון סכימה ומטא-נתונים ברקע באמצעות חשבון השירות של הקטלוג.
    • איחוד שירותי אימות הזהות של המשתמשים (אופציונלי): מפעילים את איחוד שירותי אימות הזהות של המשתמשים (--federated-catalog-identity-mode="user-identity-federation") כדי לאפשר הרצת שאילתות באמצעות הזהות המאומתת של משתמש הקצה. כך Databricks Unity Catalog יכול לשייך שאילתות למשתמשי קצה, לאכוף הרשאות וליצור יומני ביקורת.
  • אימות החיבור: מוודאים ש-Lakehouse יכול להתחבר לקטלוג המרוחק.
  • שליחת שאילתות על נתונים: אתם יכולים להריץ שאילתות על הנתונים המאוגדים באמצעות BigQuery או Managed Service for Apache Spark. השמירה במטמון של Lakehouse מופעלת באופן אוטומטי לשאילתות כדי לחסוך בעלויות של תעבורת נתונים יוצאת. למידע נוסף, ראו שאילתות על נתונים מרוחקים.
  • הגדרת הרשאות: משתמשים בממשק של ניהול הזהויות והרשאות הגישה (IAM) כדי לקבוע מי יכול לראות את הנתונים המאוחדים ולשלוח אליהם שאילתות.

הגדרת Cross-Cloud Interconnect (אופציונלי)

כברירת מחדל, שאילתות לקטלוג המרוחק עוברות דרך האינטרנט הציבורי. כדי לשפר את האבטחה והתאימות, לספק ביצועים צפויים ולהפחית את עלויות העברת הנתונים, כדאי להשתמש בחיבור פרטי. כך נוצר חיבור ייעודי ופרטי לרשת בין הענן הווירטואלי הפרטי (VPC) שלכם ב- Google Cloudלבין הרשת של ספק שירותי הענן המרוחק (לדוגמה, AWS).

אתם יכולים להקצות ולהגדיר את אחת מהאפשרויות הבאות לחיבור פרטי בין ה-VPC שלכם ב- Google Cloud לבין ה-VPC של ספק שירותי הענן המרוחק (לדוגמה, AWS):

יוצרים סשנים של BGP בין Cloud Router ב- Google Cloud לבין ה-VPC של ספק שירותי הענן המרוחק כדי להבטיח החלפת מסלולים.

כדי להפעיל שאילתות פרטיות, צריך להגדיר נתיב מ-Lakehouse לקטגוריית האחסון המרוחקת (לדוגמה, קטגוריית AWS Amazon S3) דרך הקישור הפרטי. יש שני תהליכים ארכיטקטוניים שאפשר לבצע כדי להגדיר את הניתוב הזה:

  • ניתוב של מאזן עומסי רשת פנימי אזורי עם שרת proxy: בתהליך הזה משתמשים בGoogle Cloud מאזן עומסי רשת פנימי אזורי עם שרת proxy כדי להפיץ בקשות בין קבוצות של נקודות קצה (endpoint) ברשת (NEG) עם קישוריות היברידית, שמפנות לכמה ממשקי רשת אלסטיים (ENI) של AWS. התהליך הזה חיוני לאיזון עומסים, למדרגיות ולזמינות גבוהה. הוא נדרש ל-Partner CCI ומומלץ ל-Dedicated CCI לצורך איזון עומסים, מדרגיות וזמינות גבוהה.
  • ניתוב ישיר לנקודת קצה: בתהליך הזה, Service Directory מתחבר ישירות לכתובת IP אחת של נקודת קצה (endpoint) של ממשק VPC ב-AWS. התהליך הזה פועל רק ב-CCI ייעודי, ואין תמיכה ב-CCI של שותף.

בוחרים את תהליך ההגדרה שמתאים לדרישות הארכיטקטורה שלכם:

מאזן עומסי רשת אזורי פנימי בשרת proxy

כדי להגדיר מאזן עומסי רשת פנימי אזורי של שרת proxy שיחלק את הבקשות בין כמה ממשקי ENI של AWS, וכך לשפר את הזמינות הגבוהה ואת איזון העומסים, פועלים לפי השלבים הבאים:

הגדרת הרשת ב-AWS

קודם כל, יוצרים נקודת קצה של ממשק VPC ב-Amazon S3 ‏ (AWS PrivateLink):

  1. במסוף AWS VPC, יוצרים נקודת קצה של ממשק ל-Amazon S3.
  2. בשם השירות, מציינים com.amazonaws.AWS_REGION.s3.
  3. בוחרים את ה-VPC ואת רשתות המשנה שמחוברות ל-VPC ב- Google Cloud באמצעות Direct Connect.
  4. מצרפים קבוצות אבטחה לנקודת הקצה כדי לשלוט בגישה הנכנסת.
  5. הפעולה הזו מקצה ממשקי AWS Elastic Network Interface‏ (ENI) בכל רשת משנה שנבחרה. שימו לב לכתובות ה-IP הפרטיות של ממשקי ה-ENI האלה.

בשלב הבא, מגדירים קבוצות אבטחה:

  • מוודאים שקבוצת האבטחה או הקבוצות שמצורפות ל-ENIs של נקודת הקצה של Amazon S3 מאפשרות תעבורת TCP נכנסת ביציאה 443 מה-VPC של Google Cloud . הכלל הזה חייב לכלול את טווח ה-CIDR של תת-הרשת של שרת ה-proxy בלבד, כדי לאפשר בדיקות תקינות ותעבורת נתונים שהועברה.Google Cloud

הגדרה של Google Cloud רשתות

כדי לפשט את ההגדרה, מריצים את הפקודות הבאות כדי להגדיר את מאזן העומסים הפנימי. להגדרות מתקדמות או לפרטים נוספים, קראו את המאמר הגדרת מאזן עומסי רשת פנימי אזורי לנקודות קצה היברידיות.

gcloud compute networks subnets create PROXY_SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK \
    --range=PROXY_SUBNET_RANGE

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROXY_SUBNET_NAME: שם של רשת המשנה שמשמשת רק כשרת proxy.
  • ‫PROXY_SUBNET_RANGE: טווח CIDR שלא נמצא בשימוש ברשת ה-VPC (לדוגמה, 10.129.0.0/23).

  1. יוצרים בדיקת תקינות אזורית:

    gcloud compute health-checks create tcp HEALTH_CHECK_NAME \
    --region=REGION \
    --port=443

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫HEALTH_CHECK_NAME: שם לבדיקת התקינות.
    • ‫REGION: האזור ב- Google Cloud (לדוגמה, us-east4).

  2. יוצרים קבוצות של נקודות קצה (NEG) ברשת עם קישוריות היברידית ומוסיפים נקודות קצה:

    יוצרים קבוצת נקודות קצה היברידית ברשת (NON_GCP_PRIVATE_IP_PORT) לכל אזור:

    gcloud compute network-endpoint-groups create NEG_NAME \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=ZONE \
    --network=VPC_NETWORK

    מוסיפים את כתובת ה-IP הפרטית של AWS ENI ל-NEG ההיברידי התואם:

    gcloud compute network-endpoint-groups update NEG_NAME \
    --zone=ZONE \
    --add-endpoint="ip=AWS_S3_IP,port=443"

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫NEG_NAME: שם ל-NEG ההיברידי.
    • ‫ZONE: האזור של Google Cloud (לדוגמה, us-east4-a). האזור הזה חייב להיות בתוך האזור של הצירוף ל-VLAN של Cross-Cloud Interconnect.
    • ‫VPC_NETWORK: השם של רשת ה-VPC
    • ‫AWS_S3_IP: כתובת ה-IP הפרטית של נקודת הקצה של AWS Amazon S3 VPC‏ (ENI) באותו אזור.

    אם ממשקי ה-ENI של AWS מפוזרים בכמה אזורים, חוזרים על הפקודות האלה כדי ליצור קבוצות NEG ולהוסיף נקודות קצה לאזורים אחרים.

  3. יוצרים ומגדירים את השירות לקצה העורפי:

    יוצרים שירות לקצה עורפי אזורי עם איזון עומסים פנימי מנוהל:

    gcloud compute backend-services create BACKEND_SERVICE_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=TCP \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION

    מוסיפים את קבוצות ה-NEG ההיברידיות לשירות לקצה העורפי:

    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    --region=REGION \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=ZONE \
    --balancing-mode=CONNECTION \
    --max-connections=MAX_CONNECTIONS

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫BACKEND_SERVICE_NAME: שם לשירות לקצה העורפי.
    • ‫NEG_NAME: השם של קבוצת נקודות הקצה ההיברידית שיצרתם בשלב הקודם.
    • ‫ZONE: האזור של Google Cloud (לדוגמה, us-east4-a).
    • ‫MAX_CONNECTIONS: המספר המקסימלי של חיבורים בו-זמניים שה-backend צריך לטפל בהם (לדוגמה, 100).

    חוזרים על הפקודה add-backend לכל קבוצת NEG היברידית שיצרתם.

  4. מגדירים את הקצה הקדמי של מאזן העומסים:

    יצירת שרת proxy של TCP ביעד:

    gcloud compute target-tcp-proxies create TARGET_PROXY_NAME \
    --backend-service=BACKEND_SERVICE_NAME \
    --region=REGION

    יוצרים כלל העברה כדי לנתב את התנועה לשרת ה-Proxy לחלוקת העומס:

    gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=VPC_NETWORK \
    --subnet=VPC_SUBNET \
    --ports=443 \
    --region=REGION \
    --target-tcp-proxy=TARGET_PROXY_NAME \
    --target-tcp-proxy-region=REGION \
    --allow-global-access

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫TARGET_PROXY_NAME: שם לשרת ה-proxy של היעד.
    • ‫FORWARDING_RULE_NAME: שם לכלל ההעברה.
    • ‫VPC_SUBNET: השם של רשת המשנה של ה-VPC.

אחרי שיוצרים את כלל ההעברה של מאזן העומסים, שימו לב לכתובת ה-IP הפנימית שהוקצתה לו. זהו ILB_IP_ADDRESS.

הגדרת Service Directory

רושמים את כתובת ה-IP של ה-ILB ב-Service Directory, כדי ש-Lakehouse יוכל לגלות אותה.

  1. יוצרים מרחב שמות לענן המרוחק:

    gcloud service-directory namespaces create NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫NAMESPACE: מזהה ייחודי של מרחב השמות.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫REGION: האזור של Google Cloud . לדוגמה, us-east4. האזור צריך להיות זהה לאזור של הקטלוג המאוחד.

  2. יוצרים שירות במרחב השמות של Service Directory:

    gcloud service-directory services create SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SERVICE_NAME: מזהה ייחודי של השירות.

  3. יוצרים נקודת קצה ל-ILB בשירות:

    gcloud service-directory endpoints create ENDPOINT_NAME \
    --project=PROJECT_ID \
    --namespace=NAMESPACE \
    --service=SERVICE_NAME \
    --location=REGION \
    --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK \
    --address=ILB_IP_ADDRESS \
    --port=443

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫ENDPOINT_NAME: מזהה ייחודי של נקודת הקצה.
    • ‫PROJECT_NUMBER: מספר הפרויקט ב- Google Cloud. משתמשים במספר הפרויקט בדגל --network.
    • ‫ILB_IP_ADDRESS: כתובת ה-IP הפנימית של כלל ההעברה של ה-ILB.

נקודת קצה ישירה

כדי להגדיר את Service Directory לניתוב תנועה ישירות לכתובת IP אחת של נקודת קצה (endpoint) של ממשק VPC ב-AWS, צריך לבצע את השלבים הבאים:

  1. יוצרים Interface VPC Endpoint ל-Amazon S3 בתוך ה-VPC של AWS. שימו לב לכתובת ה-IP וליציאה של נקודת הקצה הזו.

  2. יוצרים מרחב שמות לענן המרוחק:

    gcloud service-directory namespaces create NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫NAMESPACE: מזהה ייחודי של מרחב השמות.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫REGION: האזור של Google Cloud . לדוגמה, us-east4. האזור צריך להיות זהה לאזור של הקטלוג המאוחד.

  3. יוצרים שירות במרחב השמות של Service Directory:

    gcloud service-directory services create SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SERVICE_NAME: מזהה ייחודי של השירות.

  4. יוצרים נקודת קצה בשירות שמכילה את פרטי הניתוב של נקודת הקצה של ממשק ה-VPC ב-Amazon S3:

    gcloud service-directory endpoints create ENDPOINT_NAME \
    --service=SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION \
    --address=S3_VPCE_IP_ADDRESS \
    --port=S3_VPCE_PORT \
    --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫ENDPOINT_NAME: מזהה ייחודי של נקודת הקצה.
    • ‫S3_VPCE_IP_ADDRESS: כתובת ה-IP של נקודת הקצה של VPC בממשק Amazon S3. לדוגמה, 10.0.1.45.
    • ‫S3_VPCE_PORT: מספר היציאה של נקודת הקצה של ממשק ה-VPC ב-Amazon S3. לדוגמה, 443.
    • ‫PROJECT_NUMBER: מספר הפרויקט ב- Google Cloud. משתמשים במספר הפרויקט בדגל --network.
    • ‫VPC_NETWORK: השם של רשת ה-VPC ב- Google Cloud שמשויכת לחיבור הפרטי שלכם ל-Interconnect.

הגדרת איחוד

כדי לשלוח שאילתות על הנתונים, צריך להגדיר קטלוג מאוחד של Lakehouse שמקושר ל-Databricks Unity Catalog המרוחק.

הגדרת אימות

כדי להשתמש ב-Federation, צריך לבצע אימות לקטלוג המרוחק כחשבון שירות של Databricks. בוחרים אחת מאפשרויות האימות הבאות:

OIDC

‫OpenID Connect‏ (OIDC) מאפשר אימות ללא סודות באמצעות איחוד אסימוני OAuth של Databricks.

  1. יוצרים חשבון ראשי לשירות בחשבון Databricks, עם גישת קריאה ל-Unity Catalog ועם הרשאת EXTERNAL USE SCHEMA בסכימות או בקטלוג של היעד.
  2. שומרים את מזהה האפליקציה (UUID) של מנהל השירות. תצטרכו את הכתובת הזו בשלב מאוחר יותר.

מבוסס-סוד

באפשרות הזו משתמשים במזהה לקוח ובסוד לקוח ב-OAuth שמאוחסנים באופן מאובטח באמצעות סודות אזוריים של Secret Manager.

  1. יוצרים Service Principal בחשבון Databricks עם גישת קריאה ל-Unity Catalog.

  2. יוצרים סוד OAuth לחשבון השירות.

  3. יוצרים קובץ JSON בשם credentials.json עם המטען הייעודי (payload):

    {
    "client_id": "CLIENT_ID",
    "client_secret": "CLIENT_SECRET"
}

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLIENT_ID: מזהה הלקוח ב-OAuth של חשבון השירות של Databricks.
    • ‫CLIENT_SECRET: סוד הלקוח ב-OAuth של חשבון השירות ב-Databricks.

  4. מגדירים את נקודת הקצה האזורית של Secret Manager:

    כברירת מחדל, ב-Secret Manager נעשה שימוש בנקודת קצה גלובלית. עם זאת, ב-Lakehouse הסודות צריכים להיות מאוחסנים באותו אזור שבו נמצא הקטלוג של Lakehouse. כדי לבצע פעולות בסודות אזוריים באמצעות ה-CLI של gcloud, צריך לשנות את נקודת הקצה שמוגדרת כברירת מחדל ל-API בסשן או בפרופיל הנוכחיים. לדוגמה, secretmanager.us-east4.rep.googleapis.com.

    gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫REGION: האזור ב- Google Cloud שבו מאוחסן הסוד של Secret Manager. לדוגמה: us-east4. כדי למנוע בעיות קישוריות, צריך ליצור את הסוד ואת הקטלוג באותו אזור.

  5. מעלים את המטען הייעודי (payload) ל-Secret Manager:

    gcloud secrets create DATABRICKS_SECRET_NAME \
  --location="REGION" \
  --project="PROJECT_ID" \
  --data-file=credentials.json

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫DATABRICKS_SECRET_NAME: שם לסוד של Databricks.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

יצירת קטלוג מאוחד

יוצרים את הקטלוג המאוחד באמצעות מסוף Google Cloud או ה-CLI של gcloud.

שיקולים:

המסוף

כדי ליצור קטלוג מאוחד:

  1. במסוף Google Cloud , נכנסים לדף Lakehouse.

    מעבר אל Lakehouse

  2. לוחצים על ‎ Create catalog‎.

  3. לוחצים על קטלוג מאוחד.

    הקטע Catalog configuration מופיע.

  4. בשדה מקור קטלוג מאוחד, בוחרים באפשרות Databricks (Unity).

  5. בשדה Data location, בוחרים את האזור של Lakehouse שבו רוצים ליצור את הקטלוג המאוחד. לדוגמה, us-east4. כדי לצמצם את זמן האחזור (אפילו באינטרנט הציבורי), כשבוחרים אזור:

    • אם קטלוג Unity נמצא ב-AWS, בוחרים אתGoogle Cloud האזור שהכי קרוב לאזור שלכם ב-AWS.
    • אם Unity Catalog נמצא ב- Google Cloud, צריך לבחור בדיוק את אותו אזור.

  6. לוחצים על Continue.

    הקטע פרטי החיבור מופיע.

  7. בקטע Remote catalog details, בשדה Unity instance name, מזינים את שם המכונה של Databricks. לדוגמה: abcd.cloud.databricks.com.

  8. בשדה Unity catalog name, מזינים את השם של קטלוג Databricks Unity שאליו רוצים להעביר את הנתונים.

  9. בוחרים אפשרות ל-שיטת אימות:

    • בשביל OIDC, מזינים את מזהה האפליקציה של חשבון השירות.
    • בשדה Secret, מזינים את שם ה-Secret. צריך להשתמש בפורמט הבא: projects/PROJECT_ID/locations/REGION/secrets/DATABRICKS_SECRET_NAME.

  10. אופציונלי: בקטע מצב זהות, בוחרים אפשרות:

    • זהות השירות (ברירת המחדל): השאילתות מופעלות באמצעות חשבון השירות של Lakehouse.
    • זהות המשתמש: השאילתות מופעלות באמצעות הזהות המאומתת של משתמש הקצה, ומופצות לקטלוג המרוחק. צריך להגדיר איחוד זהויות בקטלוג המרוחק.

  11. אופציונלי: בשדה Service directory name, מזינים את הנתיב לשירות ספריות של Service Directory. לדוגמה: projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME. השלב הזה נדרש רק אם אתם מגדירים חיבור מקושר פרטי (Cross-Cloud Interconnect).

  12. לוחצים על יצירה.

gcloud

OIDC

אם משתמשים ב-OIDC, צריך לציין את --unity-service-principal-application-id.

אינטרנט ציבורי (ללא CCI)

אם לא מגדירים CCI, החיבור עובר באופן מאובטח דרך האינטרנט הציבורי.

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="unity" \
    --unity-service-principal-application-id="UNITY_SERVICE_PRINCIPAL_APPLICATION_ID" \
    --unity-instance-name="UNITY_INSTANCE_NAME" \
    --unity-catalog-name="UNITY_CATALOG_NAME" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --federated-catalog-identity-mode="IDENTITY_MODE"

בבעלות הלקוח (CCI)

אם הגדרתם קישור פרטי (כמו Dedicated CCI או Partner CCI), צריך לציין את ההפניה לשירות של Service Directory כדי ש-Lakehouse ינתב את התנועה באופן פרטי.

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="unity" \
    --unity-service-principal-application-id="UNITY_SERVICE_PRINCIPAL_APPLICATION_ID" \
    --unity-instance-name="UNITY_INSTANCE_NAME" \
    --unity-catalog-name="UNITY_CATALOG_NAME" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --federated-catalog-identity-mode="IDENTITY_MODE" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME"

מחליפים את מה שכתוב בשדות הבאים:

  • ‫FEDERATED_CATALOG_NAME: שם לקטלוג המאוחד.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫REGION: האזור ב-Lakehouse שבו נוצר הקטלוג המאוחד. הוא חייב להיות באותו אזור שבו נמצאים מרחב השמות של Service Directory והסוד האזורי. כדי לצמצם את זמן האחזור:
    • אם קטלוג Unity נמצא ב-AWS, בוחרים אתGoogle Cloud האזור שהכי קרוב לאזור שלכם ב-AWS.
    • אם Unity Catalog נמצא ב- Google Cloud, צריך לבחור בדיוק את אותו אזור.
  • ‫UNITY_SERVICE_PRINCIPAL_APPLICATION_ID: מזהה האפליקציה (UUID) של חשבון השירות של Databricks.
  • ‫UNITY_INSTANCE_NAME: השם של מכונת Databricks המטורגטת. לדוגמה: abcd.cloud.databricks.com.
  • ‫UNITY_CATALOG_NAME: השם של קטלוג Databricks Unity שאליו רוצים להעביר את הנתונים.
  • ‫REFRESH_INTERVAL: מציין את התדירות שבה מתבצע רענון של המטא-נתונים ברקע. מגדירים את הערך הזה כמשך זמן, לדוגמה 330s או 5m30s.
  • ‫NAMESPACE_FILTERS: אופציונלי: רשימה מופרדת בפסיקים של מרחבי שמות לאיחוד. לדוגמה, ns1,ns2. אם משמיטים את השדה, כל מרחבי השמות ייכללו.
  • ‫IDENTITY_MODE: אופציונלי: מציין את מצב הזהות של הקטלוג. מגדירים את הערך user-identity-federation כדי להפיץ את הזהויות של משתמשי הקצה בשאילתות, או את הערך service-identity כדי להריץ שאילתות בתור חשבון השירות של הקטלוג. אם משמיטים את הפרמטר, ערך ברירת המחדל הוא service-identity.
  • אם אתם משתמשים ב-CCI (חיבור פרטי):
    • ‫SERVICE_DIRECTORY_NAMESPACE: מרחב השמות של Service Directory שיצרתם במהלך ההגדרה של החיבור הפרטי.
    • ‫SERVICE_NAME: השם של שירות Service Directory שיצרתם במהלך ההגדרה של החיבור הפרטי.

מבוסס-סוד

אם משתמשים באימות שמבוסס על סוד, צריך לציין את --secret-name.

אינטרנט ציבורי (ללא CCI)

אם לא מגדירים CCI, החיבור עובר באופן מאובטח דרך האינטרנט הציבורי.

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="unity" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/DATABRICKS_SECRET_NAME" \
    --unity-instance-name="UNITY_INSTANCE_NAME" \
    --unity-catalog-name="UNITY_CATALOG_NAME" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --federated-catalog-identity-mode="IDENTITY_MODE"

בבעלות הלקוח (CCI)

אם הגדרתם קישור פרטי (כמו Dedicated CCI או Partner CCI), צריך לציין את ההפניה לשירות של Service Directory כדי ש-Lakehouse ינתב את התנועה באופן פרטי.

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="unity" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/DATABRICKS_SECRET_NAME" \
    --unity-instance-name="UNITY_INSTANCE_NAME" \
    --unity-catalog-name="UNITY_CATALOG_NAME" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --federated-catalog-identity-mode="IDENTITY_MODE" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME"

מחליפים את מה שכתוב בשדות הבאים:

  • ‫FEDERATED_CATALOG_NAME: שם לקטלוג המאוחד.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫REGION: האזור ב-Lakehouse שבו נוצר הקטלוג המאוחד. הוא חייב להיות באותו אזור שבו נמצאים מרחב השמות של Service Directory והסוד האזורי. כדי לצמצם את זמן האחזור:
    • אם קטלוג Unity נמצא ב-AWS, בוחרים אתGoogle Cloud האזור שהכי קרוב לאזור שלכם ב-AWS.
    • אם Unity Catalog נמצא ב- Google Cloud, צריך לבחור בדיוק את אותו אזור.
  • ‫DATABRICKS_SECRET_NAME: השם של הסוד ב-Databricks.
  • ‫UNITY_INSTANCE_NAME: השם של מכונת Databricks המטורגטת. לדוגמה: abcd.cloud.databricks.com.
  • ‫UNITY_CATALOG_NAME: השם של קטלוג Databricks Unity שאליו רוצים להעביר את הנתונים.
  • ‫REFRESH_INTERVAL: מציין את התדירות שבה מתבצע רענון של המטא-נתונים ברקע. מגדירים את הערך הזה כמשך זמן, לדוגמה 330s או 5m30s.
  • ‫NAMESPACE_FILTERS: אופציונלי: רשימה מופרדת בפסיקים של מרחבי שמות לאיחוד. לדוגמה, ns1,ns2. אם משמיטים את השדה, כל מרחבי השמות ייכללו.
  • ‫IDENTITY_MODE: אופציונלי: מציין את מצב הזהות של הקטלוג. מגדירים את הערך user-identity-federation כדי להפיץ את הזהויות של משתמשי הקצה בשאילתות, או את הערך service-identity כדי להריץ שאילתות בתור חשבון השירות של הקטלוג. אם משמיטים את הפרמטר, ערך ברירת המחדל הוא service-identity.
  • אם אתם משתמשים ב-CCI (חיבור פרטי):
    • ‫SERVICE_DIRECTORY_NAMESPACE: מרחב השמות של Service Directory שיצרתם במהלך ההגדרה של החיבור הפרטי.
    • ‫SERVICE_NAME: השם של שירות Service Directory שיצרתם במהלך ההגדרה של החיבור הפרטי.

השלמת הגדרת האימות

משלימים את תהליך האימות באמצעות סוג האימות שנבחר.

OIDC

כשיוצרים את הקטלוג, Lakehouse מקצה לו חשבון שירות ייחודי. צריך לאחזר את המזהה הייחודי המספרי של חשבון השירות ולהשתמש בו כדי להגדיר מדיניות איחוד ל-Databricks Service Principal.

  1. מאחזרים את המזהה הייחודי המספרי של חשבון השירות של קטלוג Lakehouse:

    gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account-id)'

  2. בחשבון Databricks, מגדירים מדיניות איחוד ל-Service Principal שיצרתם קודם. משתמשים בערכים הבאים:

    • Issuer URL: https://accounts.google.com
    • ‫Subject: המזהה הייחודי המספרי של חשבון השירות של קטלוג Lakehouse, שאוחזר בשלב הקודם.
    • קהל: https://accounts.cloud.databricks.com

    מוודאים שלחשבון השירות של Databricks יש גישת קריאה לקטלוג ולסביבת העבודה של היעד, וגם את ההרשאה EXTERNAL USE SCHEMA בסכימות או בקטלוג של היעד.

מבוסס-סוד

כשיוצרים את הקטלוג, Lakehouse מקצה לו חשבון שירות ייחודי (שמוחזר בתור biglake-service-account בתיאור המשאב).

אתם צריכים לתת לחשבון השירות הזה הרשאת גישה לסוד שיצרתם קודם. שימו לב: יכול להיות שיעברו כמה דקות עד שהמדיניות של IAM תתעדכן.

נותנים לחשבון השירות של הקטלוג הרשאת גישה לסוד:

gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
gcloud secrets add-iam-policy-binding DATABRICKS_SECRET_NAME \
  --project="PROJECT_ID" \
  --location="REGION" \
  --member="serviceAccount:$(gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
      --project="PROJECT_ID" \
      --format='value(biglake-service-account)')" \
  --role="roles/secretmanager.secretAccessor"

כדי לוודא שלחשבון השירות של הקטלוג המאוחד יש גישה לסוד, מריצים את הפקודה הבאה:

gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
gcloud secrets get-iam-policy DATABRICKS_SECRET_NAME \
     --project="PROJECT_ID" \
     --location="REGION"

בפלט, מוודאים שלחשבון השירות biglake-service-account הוקצה התפקיד roles/secretmanager.secretAccessor.

מוודאים שלחשבון השירות של Databricks יש גישת קריאה לקטלוג ולסביבת העבודה של היעד, וגם את ההרשאה EXTERNAL USE SCHEMA בסכימות או בקטלוג של היעד.

השלמת ההגדרה של החיבור הפרטי (Cross-Cloud Interconnect בלבד)

אם אתם מנתבים תנועה דרך חיבור פרטי (Dedicated או Partner CCI), אתם צריכים לתת לחשבון השירות של Lakehouse catalog הרשאות לגלות ולאשר חיבורים דרך Service Directory.

המסוף

  1. נכנסים לדף IAM במסוף Google Cloud .

    כניסה לדף IAM

  2. לוחצים על הענקת גישה (או הוספה).

  3. בשדה New principals, מזינים את כתובת האימייל של חשבון השירות של קטלוג Lakehouse. כדי לאחזר את כתובת האימייל הזו, אפשר לתאר את הקטלוג (ראו את הכרטיסייה gcloud).

  4. בתפריט Role, בוחרים באפשרות Service Directory Viewer ‏ (roles/servicedirectory.viewer).

  5. לוחצים על Add another role ובוחרים את התפקיד Service Directory PSC Authorized Service (roles/servicedirectory.pscAuthorizedService).

  6. לוחצים על Save.

gcloud

מקצים לחשבון השירות של הקטלוג את התפקידים הנדרשים:

# Grant Service Directory Viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:$(gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account)')" \
--role="roles/servicedirectory.viewer"

# Grant Service Directory PSC Authorized Service
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:$(gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account)')" \
--role="roles/servicedirectory.pscAuthorizedService"

אימות החיבור

מוודאים שמחזור הרענון של המטא-נתונים ברקע של הקטלוג הושלם בהצלחה ושהמרחבים המשותפים מסונכרנים.

  1. מוודאים שסטטוס הרענון מציין הצלחה:

    gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
  --project="PROJECT_ID"

  2. מוודאים שמרחבי השמות מסונכרנים:

    gcloud biglake iceberg namespaces list \
  --project="PROJECT_ID" \
  --catalog="FEDERATED_CATALOG_NAME"

הגדרת איחוד שירותי אימות הזהות של המשתמשים (אופציונלי)

אם הגדרתם איחוד של זהויות משתמשים בקטלוג המאוחד, אתם צריכים להגדיר מדיניות איחוד ברמת החשבון ב-Databricks.

רענון המטא-נתונים ברקע מתבצע באמצעות חשבון השירות של הקטלוג, שמוגדר עם אימות בסיסי (מבוסס-OIDC או מבוסס-סוד). לעומת זאת, איחוד זהויות של משתמשים דורש מדיניות ברמת החשבון, כדי ש-Databricks יוכל לאמת אסימוני זהות של משתמשי קצה שנוצרו על ידי Google Cloud במהלך שאילתות אינטראקטיביות. כך Databricks יכולה לשייך שאילתות למשתמשי קצה, לאכוף הרשאות וליצור יומני ביקורת.

  1. (אופציונלי) עדכון קטלוג קיים:

    אם יש לכם קטלוג מאוחד קיים שמוגדר עם מצב זהות השירות שמוגדר כברירת מחדל, אתם יכולים לעדכן אותו לאיחוד זהויות של משתמשים בלי ליצור מחדש את הקטלוג:

    המסוף

    1. במסוף Google Cloud , נכנסים לדף Lakehouse.

      מעבר אל Lakehouse

    2. ברשימת הקטלוגים, לוחצים על שם הקטלוג המאוחד.

      מופיע הדף Catalog details.

    3. לוחצים על עריכת הקטלוג.

    4. בקטע מצב זהות, בוחרים באפשרות זהות המשתמש.

    5. לוחצים על Save.

    gcloud

    מריצים את הפקודה gcloud biglake iceberg catalogs update:

    gcloud biglake iceberg catalogs update FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --federated-catalog-identity-mode="user-identity-federation"

  2. מאחזרים את הצהרות ה-OIDC מהקטלוג:

    מריצים את הפקודה הבאה כדי לאחזר את הצהרות האסימון שנדרשות על ידי Databricks:

    gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='yaml(federated-catalog-options.user-identity-federation-oidc)'

    הפלט אמור להיראות כך:

    federated-catalog-options:
  user-identity-federation-oidc:
    audience: databricks-12345678-abcd-1234-efgh-1234567890ab
    issuer-url: https://www.gstatic.com/biglake/federation/organizations/123456789012

    חשוב לשים לב לנקודות הבאות לגבי הזמינות של תלונות:

    • ‫issuer-url: נגזר מהארגון (https://www.gstatic.com/biglake/federation/organizations/ORGANIZATION_ID) ב- Google Cloud וזמין מיד אחרי שיוצרים את הקטלוג.
    • ‫audience: מוגדרת למטא-חנות של Databricks (databricks-METASTORE_ID) ונגזרת מהמטא-חנות של Unity Catalog. הערך הזה מאוכלס על ידי רענון המטא-נתונים ברקע, ולכן צריך להשלים את האימות הבסיסי ולוודא שרענון המטא-נתונים ברקע פעיל (לא מוגדר כ-0). באימות החיבור מוסבר איך לוודא שרענון המטא-נתונים ברקע מוגדר בצורה נכונה.

  3. מגדירים את מדיניות האיחוד ברמת החשבון ב-Databricks:

    1. במסוף החשבון ב-Databricks, עוברים אל Account settings > Security > Identity provider setup.
    2. בקטע Federation policies, לוחצים על Create policy.
    3. בתיבת הדו-שיח של הגדרת המדיניות, מגדירים את השדות הבאים:
      • Issuer URL: מזינים את הערך של issuer-url שאוחזר בשלב הקודם (לדוגמה, https://www.gstatic.com/biglake/federation/organizations/ORGANIZATION_ID).
      • קהלים: מזינים את הערך audience ברמת המטא-חנות שאוחזר בשלב הקודם (לדוגמה, databricks-METASTORE_ID).
      • Subject claim: משאירים ריק (Databricks משתמש כברירת מחדל ב-claim של sub שמכיל את כתובת האימייל של המשתמש). ב-Databricks משתמשים בכתובת האימייל הזו כדי להתאים אותה למשתמשים שהוגדרו בחשבון Databricks.
    4. לוחצים על Save.

  4. אימות של איחוד שירותי אימות הזהות של המשתמשים ורישום ביומן ביקורת:

    כדי לאמת את הרצת השאילתות שמשויכות למשתמשים ואת הרישום ביומן הביקורת:

    1. כדי להריץ שאילתה ב-BigQuery על טבלה מאוחדת, פועלים לפי ההוראות במאמר הרצת שאילתות על נתונים מרוחקים.

    2. ב-Databricks, מוודאים שאירוע הגישה לשאילתה מתועד ביומני הביקורת של Databricks. שולחים שאילתה לטבלת המערכת system.access.audit בעורך ה-SQL של Databricks (ראו הפניית יומן הביקורת של Databricks). שימו לב: יכול להיות שיעברו 15 דקות או יותר עד שאירועים שניתנים לביקורת יופיעו ביומני הביקורת של Databricks:

      SELECT
  *
FROM
  system.access.audit
WHERE
  service_name = 'accounts'
  AND action_name IN ('oidcTokenAuthorization')
  AND event_time >= NOW() - INTERVAL 30 MINUTE
  AND user_identity.email = 'USER_EMAIL'
ORDER BY
  event_time DESC
LIMIT 10;

המאמרים הבאים