הגדרת חיבור בין עננים לקטלוג Snowflake Horizon

במאמר הזה מוסבר איך להגדיר חיבור חוצה-עננים (cross-cloud) כדי לשלוח שאילתות לנתונים מקטלוג Snowflake Horizon ישירות מתוך Google Cloud. היכולת הזו מאחדת את ניתוח הנתונים שלכם על ידי שילוב של מקורות נתונים חיצוניים עם סביבת Google Cloud העבודה הקיימת שלכם.

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

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

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

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

  8. 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

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

  10. 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

    11.

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

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

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

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

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

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

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

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

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

  • הגדרת Cross-Cloud Interconnect (אופציונלי): הגדרת חיבור פרטי בין Google Cloud ה-VPC שלכם לבין ספק הענן המרוחק.
  • הגדרת איחוד: מגדירים אימות ויוצרים קטלוג מאוחד ב-Lakehouse.
    • אימות מבוסס-סוד (PAT): יוצרים סוד ב-Secret Manager עם פרטי הכניסה של הקטלוג המרוחק. לאחר מכן, יוצרים קטלוג מאוחד ב-Lakehouse ומעניקים לחשבון השירות של הקטלוג גישה לסוד.
    • איחוד זהויות של עומסי עבודה (WIF): יוצרים קטלוג מאוחד ב-Lakehouse ומציינים את התפקיד הנדרש ב-Snowflake. לאחר מכן, מקשרים את מזהה חשבון השירות של הקטלוג למשתמש שירות ב-Snowflake. למשתמש השירות של Snowflake צריכות להיות הרשאות שימוש בקטלוג Snowflake Horizon המרוחק.
  • אימות החיבור: מוודאים ש-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) דרך הקישור הפרטי. יש שני תרשימי זרימה ארכיטקטוניים שאפשר לפעול לפיהם כדי להגדיר את הניתוב הזה:

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

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

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

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

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

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

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

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

  • מוודאים שקבוצת האבטחה או קבוצות האבטחה שמצורפות לנקודת הקצה של Amazon S3 ENI מאפשרות תעבורת 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. יוצרים קבוצות היברידיות של נקודות קצה ברשת (NEGs) ומוסיפים נקודות קצה:

    יוצרים 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 הפרטית של ה-ENI ב-AWS ל-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 הפרטית של נקודת הקצה (ENI) של AWS Amazon S3 VPC באזור הזה.

    אם ממשקי ה-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

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

    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: השם של ה-NEG ההיברידי שיצרתם בשלב הקודם.
    • ‫ZONE: האזור Google Cloud (לדוגמה, us-east4-a).
    • ‫MAX_CONNECTIONS: מספר החיבורים המקסימלי בו-זמנית שהקצה העורפי צריך לטפל בהם (לדוגמה, 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 בספריית השירותים, כדי ש-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. יוצרים נקודת קצה עבור איזון העומסים הפנימי בשירות:

    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 הפנימית של כלל ההעברה של איזון העומסים הפנימי.

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

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

  1. יוצרים נקודת קצה של ממשק VPC עבור Amazon S3 בתוך הענן הווירטואלי הפרטי של 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. יוצרים נקודת קצה בשירות שמכילה את פרטי הניתוב של נקודת הקצה של ממשק Amazon S3 VPC:

    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: השם של רשת ה- Google Cloud VPC שמשויכת לחיבור הפרטי שלכם.

הגדרת איחוד

כדי לשלוח שאילתות על הנתונים, צריך להגדיר קטלוג מאוחד של Lakehouse שמתחבר לקטלוג Snowflake Horizon המרוחק.

הגדרת אימות

כדי לגשת לקטלוג המרוחק של Snowflake Horizon, צריך להגדיר פרטי כניסה או תפקיד. בוחרים אחת מהשיטות הבאות.

מבוסס סוד (PAT)

באפשרות הזו נעשה שימוש באסימון גישה לתכנות (PAT) שמאוחסן בצורה מאובטחת בסודות אזוריים של Secret Manager.

  1. יוצרים אסימון גישה פרוגרמטית (PAT) עם גישת קריאה לקטלוג היעד.

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

    {
  "client_secret": "SNOWFLAKE_PAT_TOKEN",
  "scope": "session:role:SNOWFLAKE_ROLE"
}

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

    • ‫SNOWFLAKE_PAT_TOKEN: טוקן הגישה הפרוגרמטית (PAT) שלכם ב-Snowflake.
    • ‫SNOWFLAKE_ROLE: התפקיד הספציפי ב-Snowflake שנדרש לסשן. לדוגמה, ICEBERG_VIEW.

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

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

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

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

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

  4. מעלים את המטען הייעודי אל Secret Manager:

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

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

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

איחוד שירותי אימות הזהות של עומסי עבודה

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

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

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

המסוף

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

  1. במסוף Google Cloud , עוברים אל Lakehouse.

    מעבר אל Lakehouse

  2. לוחצים על Create catalog (יצירת קטלוג).

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

    מופיע הקטע Catalog configuration (הגדרת קטלוג).

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

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

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

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

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

  7. בקטע פרטי קטלוג מרוחק, בשדה מזהה חשבון Snowflake, מזינים את מזהה חשבון Snowflake. לדוגמה: my_org-my_account.

  8. בשדה Snowflake warehouse (מחסן נתונים ב-Snowflake), מזינים את שם מחסן הנתונים ב-Snowflake. השם הזה נקרא גם שם מסד הנתונים ב-Snowflake Horizon Catalog.

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

    • בשדה Secret, מזינים את השם של ה-Secret עבור Secret-based (PAT). צריך להשתמש בפורמט הבא: projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME.
    • בקטע OIDC, מזינים את התפקיד שלכם ב-Snowflake עבור איחוד זהויות של עומסי עבודה. לדוגמה: ICEBERG_VIEW.

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

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

gcloud

מבוסס סוד (PAT)

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

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

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

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS"

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

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

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME"

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

  • ‫FEDERATED_CATALOG_NAME: שם לקטלוג המאוחד.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫REGION: האזור של Lakehouse שבו נוצר הקטלוג המאוחד. האזור הזה צריך להיות זהה למרחב השמות ולסוד האזורי של ספריית השירותים.
  • ‫SNOWFLAKE_SECRET_NAME: השם של הסוד שלכם ב-Snowflake.
  • ‫SNOWFLAKE_ACCOUNT_IDENTIFIER: מזהה חשבון Snowflake.
  • ‫SNOWFLAKE_WAREHOUSE: מחסן הנתונים של Snowflake שרוצים ליצור איתו פדרציה. הוא נקרא גם שם מסד הנתונים ב-Snowflake Horizon Catalog.
  • ‫REFRESH_INTERVAL: אופציונלי: מציין את התדירות שבה מתבצע רענון של מטא-נתונים ברקע. מגדירים את הערך הזה כמשך זמן, למשל, 330s או 5m30s.
  • ‫NAMESPACE_FILTERS: אופציונלי: רשימה מופרדת בפסיקים של מרחבי שמות שרוצים לאחד. לדוגמה, ns1,ns2. אם לא מציינים מרחבי שמות, כל מרחבי השמות ייכללו.
  • אם אתם משתמשים בחיבור פרטי (CCI):
    • ‫SERVICE_DIRECTORY_NAMESPACE: מרחב השמות של Service Directory שיצרתם במהלך ההגדרה של קישוריות פרטית.
    • ‫SERVICE_NAME: השם של שירות Service Directory שיצרתם במהלך ההגדרה של קישוריות פרטית.

איחוד שירותי אימות הזהות של עומסי עבודה

אם משתמשים באיחוד שירותי אימות הזהויות של עומסי עבודה, צריך לציין את --snowflake-role.

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

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

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --snowflake-role="SNOWFLAKE_ROLE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS"

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

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

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --snowflake-role="SNOWFLAKE_ROLE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME"

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

  • ‫FEDERATED_CATALOG_NAME: שם לקטלוג המאוחד.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫REGION: האזור של Lakehouse שבו נוצר הקטלוג המאוחד. האזור הזה צריך להיות זהה למרחב השמות ולסוד האזורי של ספריית השירותים.
  • ‫SNOWFLAKE_ACCOUNT_IDENTIFIER: מזהה חשבון Snowflake.
  • ‫SNOWFLAKE_WAREHOUSE: מחסן הנתונים של Snowflake שרוצים ליצור איתו פדרציה. הוא נקרא גם שם מסד הנתונים ב-Snowflake Horizon Catalog.
  • ‫SNOWFLAKE_ROLE: התפקיד הספציפי ב-Snowflake שנדרש לסשן. לדוגמה, ICEBERG_VIEW.
  • ‫REFRESH_INTERVAL: מציין את התדירות שבה מתבצע רענון של מטא-נתונים ברקע. מגדירים את הערך הזה כמשך זמן, למשל, 330s או 5m30s.
  • ‫NAMESPACE_FILTERS: אופציונלי: רשימה מופרדת בפסיקים של מרחבי שמות שרוצים לאחד. לדוגמה, ns1,ns2. אם לא מציינים מרחבי שמות, כל מרחבי השמות ייכללו.
  • אם אתם משתמשים בחיבור פרטי (CCI):
    • ‫SERVICE_DIRECTORY_NAMESPACE: מרחב השמות של Service Directory שיצרתם במהלך ההגדרה של קישוריות פרטית.
    • ‫SERVICE_NAME: השם של שירות Service Directory שיצרתם במהלך ההגדרה של קישוריות פרטית.

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

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

מבוסס סוד (PAT)

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

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

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

gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
gcloud secrets add-iam-policy-binding SNOWFLAKE_SECRET_NAME \
  --project="PROJECT_ID" \
  --location="REGION" \
  --member="serviceAccount:$(gcloud alpha 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 SNOWFLAKE_SECRET_NAME \
    --project="PROJECT_ID" \
    --location="REGION"

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

איחוד שירותי אימות הזהות של עומסי עבודה

אחרי שיוצרים את הקטלוג, צריך לקשר את הזהות של חשבון השירות שלו למשתמש שירות ב-Snowflake.

  1. מחפשים את מזהה חשבון השירות של Lakehouse (נושא) בפרטי הקטלוג.

    אפשר לקבל את הערך הזה מתגובת ה-JSON של פקודת היצירה (השדה biglake-service-account-id).

    אפשרות אחרת היא להריץ את הפקודה describe בקטלוג כדי לקבל את הערך:

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

    מחפשים את biglake-service-account-id בפלט.

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

    USE ROLE ACCOUNTADMIN;

CREATE USER SNOWFLAKE_SERVICE_USER
  TYPE = SERVICE
  WORKLOAD_IDENTITY = (
    TYPE = GCP
    SUBJECT = 'LAKEHOUSE_SERVICE_ACCOUNT_ID'
  )
  DEFAULT_ROLE = SNOWFLAKE_ROLE
  COMMENT = 'Service user for Lakehouse federation over WIF';

-- Also explicitly GRANT permissions to the role
GRANT ROLE SNOWFLAKE_ROLE TO USER SNOWFLAKE_SERVICE_USER;

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

    • ‫SNOWFLAKE_SERVICE_USER: שם למשתמש השירות החדש ב-Snowflake.
    • ‫LAKEHOUSE_SERVICE_ACCOUNT_ID: מזהה חשבון השירות שחולץ בשלב הקודם.
    • ‫SNOWFLAKE_ROLE: התפקיד ב-Snowflake (חייב להיות זהה לתפקיד שצוין במהלך יצירת הקטלוג).

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

אם אתם מנתבים תנועה דרך חיבור פרטי (Dedicated או Partner CCI), אתם צריכים להעניק לחשבון השירות של קטלוג Lakehouse הרשאות לגילוי ולאישור חיבורים דרך 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 alpha 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 alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account)')" \
--role="roles/servicedirectory.pscAuthorizedService"

אימות החיבור

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

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

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

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

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

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

    gcloud alpha biglake iceberg tables list \
  --project="PROJECT_ID" \
  --catalog="FEDERATED_CATALOG_NAME" \
  --namespace="NAMESPACE_ID"

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