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

במאמר הזה מוסבר איך להגדיר חיבור בין עננים כדי לשלוח שאילתות לנתונים מקטלוג 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.

    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.

    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.

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

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

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

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

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

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

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

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

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

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

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

  • הגדרת 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. מידע נוסף זמין במאמר בנושא שאילתות על נתונים מרוחקים.
  • הגדרת הרשאות: משתמשים ב-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 כדי להפיץ בקשות בין קבוצות של נקודות קצה ברשת (NEG) עם קישוריות היברידית שמפנות לממשקי רשת אלסטיים (ENI) רבים של AWS. התהליך הזה חיוני לאיזון עומסים, למדרגיות ולזמינות גבוהה. הוא נדרש ל-CCI של שותפים ומומלץ ל-CCI ייעודי לצורך איזון עומסים, יכולת הרחבה וזמינות גבוהה.
  • ניתוב ישיר של נקודת קצה: בתרשים הזה, Service Directory מתחבר ישירות לכתובת IP אחת של נקודת קצה של ממשק VPC של AWS. התהליך הזה פועל רק עם 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 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) והוספה של נקודות קצה:

    יוצרים קבוצת קצה רשת היברידית (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: האזור (לדוגמה, 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: השם של רשת ה- 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. לוחצים על קטלוג מאוחד.

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

  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/NAMESPACE/services/SERVICE_NAME. המאפיין הזה נדרש רק אם אתם מגדירים חיבור פרטי (Cross-Cloud Interconnect).

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

‫CLI של gcloud

מבוסס-סוד (PAT)

אינטרנט ציבורי (ללא 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. כדי לצמצם את זמן האחזור, בוחרים את Google Cloud האזור שהכי קרוב לאזור שלכם ב-Snowflake.
  • ‫SNOWFLAKE_SECRET_NAME: השם של הסוד שלכם ב-Snowflake.
  • ‫SNOWFLAKE_ACCOUNT_IDENTIFIER: מזהה החשבון שלכם ב-Snowflake (לדוגמה, my_org-my_account).
  • ‫SNOWFLAKE_WAREHOUSE: מחסן הנתונים של Snowflake שרוצים לאחד איתו את הזהויות. הוא נקרא גם שם מסד הנתונים ב-Snowflake Horizon Catalog.
  • ‫REFRESH_INTERVAL: אופציונלי: מציין את תדירות העדכון של פרטי הקטלוג. מגדירים את הערך הזה כמשך זמן, למשל, 330s או 5m30s. הערך חייב להיות 0s (מושבת) או לפחות 300s (5m). משכי זמן קצרים מ-300s יובילו לשגיאה. עדכונים במרווחי זמן קצרים יותר מאפשרים לעדכן את הנתונים בתדירות גבוהה יותר, אבל עלולים להגדיל את העלויות של קריאות ה-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"

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

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

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

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

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

  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • ‫SNOWFLAKE_ACCOUNT_IDENTIFIER: מזהה חשבון Snowflake.
  • ‫SNOWFLAKE_WAREHOUSE: מחסן הנתונים של Snowflake שרוצים לאחד איתו את הזהויות. הוא נקרא גם שם מסד הנתונים ב-Snowflake Horizon Catalog.
  • ‫SNOWFLAKE_ROLE: התפקיד הספציפי ב-Snowflake שנדרש לסשן. לדוגמה, ICEBERG_VIEW.
  • ‫FEDERATED_CATALOG_NAME: שם לקטלוג המאוחד של Lakehouse.
  • ‫REGION: האזור של Lakehouse שבו נוצר הקטלוג המאוחד.
  • ‫REFRESH_INTERVAL: אופציונלי: מציין את תדירות העדכון של פרטי הקטלוג. מגדירים את הערך הזה כמשך זמן, למשל, 330s או 5m30s. הערך חייב להיות 0s (מושבת) או לפחות 300s (5m). משכי זמן קצרים מ-300s יובילו לשגיאה. עדכונים במרווחי זמן קצרים יותר מאפשרים לעדכן את הנתונים בתדירות גבוהה יותר, אבל עלולים להגדיל את העלויות של קריאות ה-API. מרווחי זמן ארוכים יותר יכולים להיות זולים יותר, אבל יכול להיות שהנתונים שמתקבלים מהשאילתה לא ישקפו את מערך הנתונים העדכני ביותר. אם הערך מושמט או מוגדר ל-0s, רענון המטא-נתונים ברקע לא יתחיל. היא תישאר מושבתת עד שתעדכנו את מרווח הרענון לערך חיובי תקין.
  • ‫NAMESPACE_FILTERS: אופציונלי: רשימה מופרדת בפסיקים של מרחבי שמות שרוצים לאחד. לדוגמה, ns1,ns2. אם לא מציינים מרחבי שמות, כל מרחבי השמות ייכללו.
  • ‫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 Interconnect או Partner Interconnect), אתם צריכים להעניק לחשבון השירות של קטלוג 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.

‫CLI של 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"

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