הגדרת Lakehouse חוצה עננים ל-Snowflake

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

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

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

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

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

  10. Enable the BigLake, Secret Manager APIs.

    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. Verify that billing is enabled for your Google Cloud project.

  12. Enable the BigLake, Secret Manager APIs.

    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

    13.

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

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

  • ניהול קטלוגים של Lakehouse: BigLake Admin (roles/biglake.admin)
  • ניהול סודות: אדמין Secret Manager (roles/secretmanager.admin)
  • ניתוב תנועה דרך חיבור פרטי בין רשתות: אדמין של רשת Compute‏ (roles/compute.networkAdmin), צפייה בספריית שירותים (roles/servicedirectory.viewer) ושירות מורשה של PSC בספריית שירותים (roles/servicedirectory.pscAuthorizedService)

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

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

פרטי קטלוג נתמכים

במדריך הזה מוסבר איך להגדיר Lakehouse חוצה-ענן עם קטלוג Snowflake ‏ (Snowflake Horizon) ב-Amazon Web Services‏ (AWS) וב- Google Cloud. מידע מפורט על הדרישות לגבי מיקומים חיצוניים והגדרות נתמכות זמין במאמר קטלוגים נתמכים.

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

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

  • ספקי ענן נתמכים: אפשר להשתמש בחיבור פרטי בין רשתות כדי ליצור Lakehouse חוצה עננים עם ספקי הענן המרוחקים הבאים: Amazon Web Services‏ (AWS). אפשר להשתמש ב-Dedicated Cross-Cloud Interconnect או ב-Partner Cross-Cloud Interconnect.
  • ניתוב ברשת: אם לא מוגדר חיבור פרטי (כמו Dedicated CCI או Partner CCI), השאילתות מנותבות דרך האינטרנט הציבורי. התוצאה יכולה להיות עלויות גבוהות יותר של העברת נתונים מספק הענן המרוחק וביצועים פחות צפויים.
  • עדכניות הנתונים: הדגל --refresh-interval בקטלוג המאוחד קובע את תדירות הסנכרון של המטא-נתונים. מרווח קצר יותר מספק נתונים עדכניים יותר, אבל עלול לגרום לעלויות נוספות ב-API של ספק הקטלוג המרוחק.
  • דיווח על מדדי Iceberg: דיווח על מדדי Iceberg לא זמין לקטלוגים מאוחדים. כשניגשים לקטלוג מאוחד, מגדירים את המאפיין rest-metrics-reporting-enabled לערך false בלקוח Iceberg.

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

כדי להגדיר ולהשתמש ב-Lakehouse חוצה עננים, צריך לבצע את השלבים הכלליים הבאים:

  • הגדרת Cross-Cloud Interconnect (אופציונלי): הגדרת חיבור פרטי בין Google Cloud ה-VPC שלכם לבין ספק הענן המרוחק.
  • הגדרת איחוד: מגדירים אימות ויוצרים קטלוג מאוחד ב-Lakehouse.
    • אימות מבוסס-סוד (PAT): יוצרים סוד ב-Secret Manager עם פרטי הכניסה של הקטלוג המרוחק. לאחר מכן, יוצרים קטלוג מאוחד ב-Lakehouse ומעניקים לחשבון השירות של הקטלוג גישה לסוד.
    • איחוד שירותי אימות הזהות של עומסי עבודה (WIF): יוצרים קטלוג מאוחד ב-Lakehouse ומציינים את התפקיד הנדרש ב-Snowflake. לאחר מכן, מקשרים את מזהה חשבון השירות של הקטלוג למשתמש שירות ב-Snowflake. למשתמש השירות של Snowflake צריכות להיות הרשאות שימוש בקטלוג Snowflake המרוחק.
  • אימות החיבור: מוודאים ש-Lakehouse יכול להתחבר בהצלחה לקטלוג המרוחק.
  • שליחת שאילתות לנתונים: אתם יכולים להריץ שאילתות על הנתונים המאוחדים באמצעות BigQuery או Managed Service for Apache Spark. מידע נוסף זמין במאמר בנושא שימוש ב-Lakehouse חוצה-ענן.
  • הגדרת הרשאות: משתמשים ב-IAM כדי לנהל את המשתמשים שיכולים לצפות בנתונים המאוחדים ולשאול עליהם שאילתות.

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

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

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

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

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

  • ניתוב של מאזן עומסים אזורי פנימי מסוג Network Load Balancer: בתרשים הזה נעשה שימוש בGoogle Cloud מאזן עומסים אזורי פנימי מסוג Network Load Balancer כדי להפיץ בקשות בין קבוצות של נקודות קצה ברשת (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. יצירה של קבוצות היברידיות של נקודות קצה ברשת (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: האזור (לדוגמה, us-east4-a). האזור הזה צריך להיות באזור של הצירוף ל-VLAN של Cross-Cloud Interconnect. Google Cloud
    • ‫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

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

הגדרת איחוד

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

מבוסס סוד (PAT)

הגדרת אימות

כדי לגשת לקטלוג Snowflake מרוחק, צריך פרטי כניסה. ב-Snowflake Horizon, צריך להשתמש באסימון גישה אישי (PAT), שהוא אסימון ארוך טווח שנוצר על ידי Snowflake, לצד התפקיד הספציפי ב-Snowflake שנדרש להפעלה.

יוצרים סוד ב-Secret Manager אזורי כדי לאחסן את פרטי הכניסה:

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

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

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

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

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

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

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

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

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

  3. מעלים את המטען הייעודי אל 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 .

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

    יוצרים את הקטלוג המאוחד באמצעות הפקודה gcloud alpha biglake iceberg catalogs create.

    אינטרנט ציבורי (ללא 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"

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

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫REGION: האזור של Lakehouse שבו נוצר הקטלוג המאוחד. לדוגמה, us-east4. כדי לצמצם את זמן האחזור, בוחרים את האזור שהכי קרוב לאזור שלכם ב-Snowflake. Google Cloud
    • ‫SNOWFLAKE_SECRET_NAME: השם של סוד Snowflake.
    • ‫SNOWFLAKE_ACCOUNT_IDENTIFIER: מזהה החשבון שלכם ב-Snowflake (לדוגמה, my_org-my_account).
    • ‫SNOWFLAKE_WAREHOUSE: השם של קטלוג Snowflake שרוצים ליצור איתו פדרציה.
    • ‫REFRESH_INTERVAL: אופציונלי: מציין את תדירות העדכון של פרטי הקטלוג. מגדירים את הערך הזה כמשך זמן, למשל, 330s או 5m30s. אם בוחרים במרווחי זמן קצרים יותר, הנתונים מתעדכנים בתדירות גבוהה יותר, אבל עלות הקריאות ל-API עולה. מרווחי זמן ארוכים יותר יכולים לעלות פחות, אבל יכול להיות שהנתונים שנשלחה לגביהם שאילתה לא ישקפו את מערך הנתונים העדכני ביותר. אם הערך מושמט או מוגדר כ-0s, רענון המטא-נתונים ברקע לא יתחיל. הוא יישאר מושבת עד שמרווח הרענון יעודכן לערך חיובי.
    • ‫NAMESPACE_FILTERS: אופציונלי: רשימה מופרדת בפסיקים של מרחבי שמות שרוצים לאחד. לדוגמה, ns1,ns2. אם לא מציינים מרחבי שמות, כל מרחבי השמות ייכללו.

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

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

      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/NAMESPACE/services/SERVICE_NAME/endpoints/ENDPOINT_NAME"

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

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫REGION: האזור של Lakehouse שבו נוצר הקטלוג המאוחד. הערה: האזור הזה חייב להיות זהה למרחב השמות ולסוד האזורי של ספריית השירותים.
    • ‫SNOWFLAKE_SECRET_NAME: השם של סוד Snowflake.
    • ‫SNOWFLAKE_ACCOUNT_IDENTIFIER: מזהה חשבון Snowflake.
    • ‫SNOWFLAKE_WAREHOUSE: השם של קטלוג Snowflake שרוצים לאחד עם Google Cloud
    • ‫REFRESH_INTERVAL: אופציונלי: מציין את תדירות העדכון של פרטי הקטלוג.
    • ‫NAMESPACE_FILTERS: אופציונלי: רשימה מופרדת בפסיקים של מרחבי שמות שרוצים לאחד.
    • ‫NAMESPACE: מרחב השמות של Service Directory שיצרתם במהלך ההגדרה של קישוריות פרטית.
    • ‫SERVICE_NAME: השם של שירות Service Directory שיצרתם במהלך ההגדרה של חיבור פרטי בין רשתות.
    • ‫ENDPOINT_NAME: השם של נקודת הקצה של Service Directory שיצרתם במהלך ההגדרה של חיבור פרטי בין רשתות.

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

    כשיוצרים קטלוג, 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" \
      --location="REGION" \
      --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.

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

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

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

יוצרים את הקטלוג המאוחד באמצעות מסוף Google Cloud , Lakehouse API בארכיטקטורת REST או gcloud CLI. צריך לציין את התפקיד ב-Snowflake שבו רוצים להשתמש.

המסוף

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

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

    מעבר אל Lakehouse

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

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

    יופיעו הפרטים של הגדרת הקטלוג.

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

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

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

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

    יוצגו הפרטים של פרטי החיבור.

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

  8. בשדה Snowflake warehouse, מזינים את שם מחסן הנתונים של Snowflake.

  9. בשדה Secret, מזינים את שם ה-Secret. צריך להשתמש בפורמט הבא: projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME.

  10. אופציונלי: בשדה Service directory name, מזינים את הנתיב לנקודת הקצה או לשירות של Service Directory. הפעולה הזו נדרשת רק אם אתם מגדירים חיבור פרטי (Cross-Cloud Interconnect).

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

‫API בארכיטקטורת REST 

curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -H "x-goog-user-project: PROJECT_ID" \
  -d '{
    "catalog-type": "CATALOG_TYPE_FEDERATED",
    "federated-catalog-options": {
      "snowflake-catalog-info": {
        "account-identifier": "SNOWFLAKE_ACCOUNT_IDENTIFIER",
        "warehouse": "SNOWFLAKE_WAREHOUSE",
        "snowflake-role": "SNOWFLAKE_ROLE"
      },
      "refresh-options": {
        "refresh-schedule": {
          "refresh-interval": "REFRESH_INTERVAL"
        }
      }
    }
}' \
  "https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs?iceberg_catalog_id=FEDERATED_CATALOG_NAME&primary_location=REGION"

‫CLI של gcloud

אינטרנט ציבורי (ללא 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)

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

    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/NAMESPACE/services/SERVICE_NAME/endpoints/ENDPOINT_NAME"

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

  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫SNOWFLAKE_ACCOUNT_IDENTIFIER: מזהה חשבון Snowflake.
  • ‫SNOWFLAKE_WAREHOUSE: השם של קטלוג Snowflake שרוצים ליצור איתו פדרציה.
  • ‫SNOWFLAKE_ROLE: התפקיד הספציפי ב-Snowflake שנדרש לסשן. לדוגמה, ICEBERG_VIEW.
  • ‫FEDERATED_CATALOG_NAME: שם לקטלוג המאוחד של Lakehouse.
  • ‫REGION: האזור של Lakehouse שבו נוצר הקטלוג המאוחד.
  • ‫REFRESH_INTERVAL: אופציונלי: מציין את תדירות העדכון של פרטי הקטלוג. לדוגמה, 300s.
  • ‫NAMESPACE_FILTERS: אופציונלי: רשימה מופרדת בפסיקים של מרחבי שמות שרוצים לאחד. לדוגמה, ns1,ns2. אם לא מציינים מרחבי שמות, כל מרחבי השמות ייכללו.
  • ‫NAMESPACE: מרחב השמות של שירות Service Directory.
  • ‫SERVICE_NAME: השם של השירות שלכם ב-Service Directory.
  • ‫ENDPOINT_NAME: השם של נקודת הקצה של Service Directory.

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

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

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

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

    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 (חייב להיות זהה לתפקיד שצוין במהלך יצירת הקטלוג).

אימות החיבור

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

‫CLI של gcloud

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

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

  2. מוודאים שסכימות של מסדי נתונים מרוחקים מופיעות כמרחבי שמות מסונכרנים:

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

‫API בארכיטקטורת REST

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

    curl -X GET \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -H "x-goog-user-project: PROJECT_ID" \
  "https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME"

  2. הצגת רשימה של מרחבי שמות מסונכרנים:

    curl -X GET \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -H "x-goog-user-project: PROJECT_ID" \
  "https://biglake.googleapis.com/iceberg/v1/restcatalog/v1/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME/namespaces"

  3. הצגת טבלאות במרחב שמות מסונכרן:

    curl -X GET \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -H "x-goog-user-project: PROJECT_ID" \
  "https://biglake.googleapis.com/iceberg/v1/restcatalog/v1/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME/namespaces/NAMESPACE_NAME/tables"

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