החל מ-20 באפריל 2026, השם של BigLake הוא Lakehouse. מאגר המטא-נתונים של BigLake נקרא עכשיו קטלוג זמן הריצה של Lakehouse. ממשקי ה-API, ספריות הלקוח, פקודות ה-CLI ושמות ה-IAM של Lakehouse נשארים ללא שינוי ועדיין מתייחסים ל-BigLake.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

הגדרת חיבור בין עננים ל-AWS Glue

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

אחרי שמגדירים את החיבור, אפשר לשלוח שאילתות לטבלאות Apache Iceberg המאוגדות ב-Lakehouse ולנהל אותן בלי להעביר קבצים.

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

בסקירה הכללית של Lakehouse מוסבר איך מתבצע ניהול הגישה לנתונים ב-Lakehouse.
כדי להבין איך זה עובד, קראו את המאמר גישה לנתונים חוצי-עננים.
בודקים את הקטלוגים הנתמכים כדי לוודא שההגדרות נתמכות.
אופציונלי: אם אתם מתכננים לנתב קריאות של שאילתות או רענון מטא-נתונים ברקע דרך חיבור פרטי בין רשת ה-VPC שלכם ב- Google Cloudלבין ה-VPC שלכם ב-AWS, ודאו שיש לכם חשבון AWS פעיל, הקצו Dedicated Cross-Cloud Interconnect או Partner Cross-Cloud Interconnect, הגדירו סשנים של BGP עם Cloud Router וודאו שיש לכם את ההרשאות הנדרשות לניהול זהויות והרשאות גישה (IAM) בשתי סביבות הענן.

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

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake API, if it is 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 API

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake API, if it is not already enabled.

Roles required to enable APIs

Enable the API

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

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

ניהול קטלוגים של Lakehouse: אדמין BigLake (roles/biglake.admin)
ניתוב תנועה דרך חיבור פרטי (משתמש): אדמין של רשת Compute ‏(roles/compute.networkAdmin)
ניתוב התנועה דרך חיבור פרטי (חשבון שירות של Catalog):
- צפייה ב-Service Directory (roles/servicedirectory.viewer)
- שירות מורשה של Service Directory PSC ‏(roles/servicedirectory.pscAuthorizedService)

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

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

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

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

‫VPC Service Controls: אם הפרויקט שמכיל את נקודת הקצה של הקטלוג המאוחד או את הקטגוריה הבסיסית של Cloud Storage נמצא בתוך גבולות גזרה לשירות של VPC Service Controls, אתם צריכים להגדיר כללים לתעבורת נתונים נכנסת (ingress) או יוצאת (egress). מידע נוסף זמין במאמר שימוש ב-VPC Service Controls עם נקודות קצה של קטלוג מאוחד.
ספקי שירותי ענן שנתמכים ב-Cross-Cloud Interconnect: אפשר להשתמש בקישור פרטי בין רשתות כדי לנתב את תעבורת הנתונים של השאילתות, את רענון המטא-נתונים ברקע או את שניהם ב-AWS. אתם יכולים להשתמש ב-Dedicated Cross-Cloud Interconnect או ב-Partner Cross-Cloud Interconnect.
ניתוב ברשת: אם לא מגדירים חיבור פרטי להעברת שאילתות או לרענון מטא-נתונים ברקע, התנועה הרלוונטית מנותבת דרך האינטרנט הציבורי באמצעות TLS. ניתוב של קריאות שאילתות דרך האינטרנט הציבורי עלול לגרום לעלויות גבוהות יותר של תעבורת נתונים יוצאת מספק שירותי הענן המרוחק, ולביצועים פחות צפויים.
לקריאה בלבד: קטלוגים מאוחדים ב-Lakehouse הם תצוגות לקריאה בלבד של הקטלוג המרוחק. אי אפשר לשנות משאבים (למשל ליצור, לעדכן או למחוק משאבים) וצריך לבצע את הפעולות האלה ישירות בקטלוג המרוחק.
עדכניות הנתונים: הדגל --refresh-interval בקטלוג מאוחד קובע את תדירות הסנכרון של המטא-נתונים. הערך צריך להיות 0s (מושבת) או לפחות 300s (5 דקות). ככל שיש יותר משאבים של מרחבי שמות וטבלאות, יכול להיות שייקח יותר זמן לרענן את המטא-נתונים ברקע של הקטלוג. אם הרענון הקודם חורג מהזמן, הרענון הנוכחי לא יתבצע והרענון הבא יתוזמן במרווח הזמן הבא. השאילתות משתמשות במטא-נתונים של הקטלוג שסונכרנו לאחרונה, כך ששינויים שבוצעו בקטלוג המרוחק, כמו טבלאות חדשות, עדכוני סכימה או נתונים חדשים, לא גלויים ב-Lakehouse עד להשלמת הרענון הבא של המטא-נתונים ברקע.
שמירה במטמון של Lakehouse: כברירת מחדל, השמירה במטמון חוצה-העננים מושבתת (--cross-cloud-cache=disabled). אתם יכולים להפעיל או להשבית את השמירה במטמון ברמת הקטלוג המאוחד או ברמת החיבור. אי אפשר להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) לשמירה במטמון. הקבצים שנשמרים במטמון מוצפנים באמצעות Google-owned and Google-managed encryption keys. אם אילוץ constraints/gcp.restrictNonCmekServices של מדיניות הארגון נאכף על טבלה בשאילתה, השמירה במטמון מושבתת באופן אוטומטי בשאילתה הזו. מידע נוסף זמין במאמר שמירה חכמה במטמון.
מיקום אחסון הנתונים ותאימות: כשמפעילים שמירה במטמון חוצה-עננים בקטלוג מאוחד או בחיבור, Lakehouse שומר באופן זמני קבצים במטמון במצב מנוחה באזור Google Cloud שבו השאילתה פועלת. אם קובצי הענן המרוחקים נמצאים בסמכות שיפוט אחרת, לפני שמפעילים את השמירה במטמון באזורים שונים, צריך לוודא שהיא עומדת בדרישות של הארגון לגבי מיקום אחסון הנתונים והתאימות.

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

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

הגדרת Cross-Cloud Interconnect (אופציונלי): מגדירים חיבור פרטי בין רשת ה-VPC ב- Google Cloud לבין ה-VPC ב-AWS.
הגדרת איחוד: מגדירים אימות על ידי יצירת תפקיד IAM עם מדיניות אמון של פלייסהולדר ב-AWS. אחר כך יוצרים קטלוג מאוחד ב-Lakehouse ומעדכנים את מדיניות האמון.
אימות החיבור: מוודאים ש-Lakehouse יכול להתחבר לקטלוג המרוחק.
שאילתות על נתונים: מריצים שאילתות על הנתונים המאוגדים באמצעות BigQuery או Managed Service for Apache Spark, לפי מוסכמת מתן השמות PROJECT_ID.CATALOG_NAME.NAMESPACE.TABLE שמורכבת מ-4 חלקים. אפשר להפעיל שמירה במטמון חוצה-עננים בקטלוג המאוחד כדי להפחית את עלויות תעבורת הנתונים היוצאת חוצת-העננים ולהאיץ את השאילתות הבאות. מידע נוסף זמין במאמר שליחת שאילתות לנתונים מרוחקים.
הגדרת הרשאות: אתם יכולים להשתמש ב-IAM כדי לנהל את המשתמשים שיכולים לראות את הנתונים המאוגדים ולשלוח אליהם שאילתות.

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

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

אפשר להקצות כל אחת מהאפשרויות הבאות של קישור פרטי:

‫Dedicated Cross-Cloud Interconnect: חיבור פיזי ייעודי.
‫Partner Cross-Cloud Interconnect: חיבור ל-AWS באמצעות ספק שירות נתמך.

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

אתם יכולים להגדיר ניתוב פרטי דרך Cross-Cloud Interconnect לאחד או לשני נתיבי התנועה הבאים, בהתאם לדרישות האבטחה והעלות שלכם:

‫Query transport (--service-directory-name): מעביר קריאות של שאילתות מ-BigQuery או ממנועי קוד פתוח למאגר האובייקטים המרוחק (Amazon S3), כדי להפחית את העמלות על תעבורת נתונים יוצאת חוצת-עננים ולשמור על זמן אחזור צפוי של השאילתות.
רענון מטא-נתונים ברקע (--metadata-service-directory-name): מנתב בקשות אימות ורענון מטא-נתונים ברקע של מישור הבקרה מקטלוג ייעודי לזמן ריצה של Lakehouse לנקודת הקצה הפרטית המרוחקת של AWS Glue Data Catalog – לדוגמה, כשהקטלוג המרוחק מגביל את הגישה לאינטרנט הציבורי.

אם אתם מנתבים גם את העברת השאילתות וגם את רענון המטא-נתונים ברקע דרך Cross-Cloud Interconnect, בצעו את השלבים של נקודת הקצה הפרטית, הניתוב והשירות של Service Directory פעם אחת בשביל נקודת הקצה של האחסון המרוחק ופעם אחת בשביל נקודת הקצה של הקטלוג המרוחק. שני השירותים של Service Directory צריכים להיות באותו אזור ב- Google Cloud שבו נמצא הקטלוג המאוחד, והם יכולים להיות באותו מרחב שמות של Service Directory ובאותה רשת משנה של שרתי proxy בלבד.

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

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

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

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

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

הגדרת נקודות קצה פרטיות בענן מרוחק

יוצרים נקודות קצה פרטיות ברשת המרוחקת וברשתות המשנה שמתחברות לרשת ה-VPC של Google Cloud באמצעות Cross-Cloud Interconnect, ורושמים את כתובות ה-IP הפרטיות שהוקצו לכל נקודת קצה:

להעברת שאילתות פרטיות (מאגר אובייקטים מרוחק): יוצרים נקודת קצה (endpoint) של ממשק VPC ל-Amazon S3 (com.amazonaws.AWS_REGION.s3) ב-VPC של AWS, ורושמים את כתובות ה-IP הפרטיות של ממשקי ה-ENI שהוקצו.
לרענון פרטי המטא-נתונים של הרקע הפרטי (קטלוג מרוחק): יוצרים נקודת קצה (endpoint) של ממשק VPC ל-AWS Glue (com.amazonaws.AWS_REGION.glue) ב-AWS VPC, ורושמים את כתובות ה-IP הפרטיות של ממשקי ה-ENI שהוקצו.
כללי אבטחה לתעבורת נתונים נכנסת: ודאו שקבוצות האבטחה של AWS שמצורפות לנקודות הקצה הפרטיות מאפשרות תעבורת נתונים נכנסת של TCP ביציאה 443 מטווחי ה-CIDR של ה-VPC ב- Google Cloud . צריך לכלול את טווח ה-CIDR של תת-הרשת של שרת ה-proxy בלבד כדי לאפשר בדיקות תקינות ותעבורת נתונים שהועברה. Google Cloud

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

מריצים את הפקודות הבאות כדי להגדיר את מאזן העומסים הפנימי. אם אתם מנתבים גם את תעבורת השאילתות וגם את רענון המטא-נתונים ברקע דרך Cross-Cloud Interconnect, צריך להגדיר שירות נפרד לקצה העורפי, שרת proxy ל-TCP לטירגוט וכלל העברה לנקודת הקצה של האחסון ולנקודת הקצה של הקטלוג. להגדרות מתקדמות, קראו את המאמר הגדרת מאזן עומסי רשת פרוקסי פנימי אזורי לנקודות קצה היברידיות.

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

יוצרים בדיקת תקינות אזורית של TCP:
```
gcloud compute health-checks create tcp HEALTH_CHECK_NAME \
    --region=REGION \
    --port=443
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫HEALTH_CHECK_NAME: שם לבדיקת התקינות.
- ‫REGION: האזור של Google Cloud (לדוגמה, us-east4).
יוצרים קבוצות של נקודות קצה ברשת (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 ל-NEG ההיברידי:
```
gcloud compute network-endpoint-groups update NEG_NAME \
    --zone=ZONE \
    --add-endpoint="ip=REMOTE_ENDPOINT_IP,port=443"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫NEG_NAME: שם ל-NEG ההיברידי.
- ‫ZONE: האזור של Google Cloud (לדוגמה, us-east4-a). האזור הזה חייב להיות באותו אזור של הקישור ל-VLAN של Cross-Cloud Interconnect.
- ‫VPC_NETWORK: השם של רשת ה-VPC
- ‫REMOTE_ENDPOINT_IP: כתובת ה-IP הפרטית של נקודת הקצה הפרטית של האחסון המרוחק או הקטלוג המרוחק באותו אזור.
אם לנקודת הקצה המרוחקת יש כמה כתובות IP פרטיות שמופצות בין אזורים, חוזרים על הפקודות האלה כדי ליצור קבוצות NEG היברידיות ומוסיפים נקודות קצה לכל אזור.
יוצרים ומגדירים את השירות לקצה העורפי:

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

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

יוצרים שרת 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 של מאזן העומסים הפנימי ב-Service Directory, כדי ש-Lakehouse יוכל לגלות אותו ולנתב אליו באופן פרטי. אם הגדרתם כללי העברה נפרדים של מאזן העומסים להעברת שאילתות ולרענון מטא-נתונים ברקע, צריך ליצור שירות ונקודת קצה נפרדים ב-Service Directory לכל כתובת IP של כלל העברה.

יוצרים מרחב שמות לנקודות הקצה הפרטיות המרוחקות:
```
gcloud service-directory namespaces create NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫NAMESPACE: מזהה ייחודי של מרחב השמות.
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
- ‫REGION: האזור של Google Cloud (לדוגמה, us-east4). זה חייב להיות אותו אזור של הקטלוג המאוחד.
יוצרים שירות במרחב השמות של Service Directory:
```
gcloud service-directory services create SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫SERVICE_NAME: מזהה ייחודי לשירות (צריך ליצור שם שירות נפרד, כמו METADATA_SERVICE_NAME, כשרושמים נקודת קצה לרענון מטא-נתונים ברקע).
יוצרים נקודת קצה לכלל ההעברה של מאזן העומסים בשירות:
```
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 אחת של נקודת קצה פרטית מרוחקת דרך Dedicated Cross-Cloud Interconnect, מבצעים את השלבים הבאים:

יוצרים את נקודת הקצה הפרטית ברשת הענן המרוחקת:
- להעברת שאילתות פרטיות: יוצרים נקודת קצה של ממשק VPC ל-Amazon S3 (com.amazonaws.AWS_REGION.s3) ב-AWS VPC.
- לרענון פרטי מטא-נתונים ברקע באופן פרטי: יוצרים נקודת קצה (endpoint) של ממשק VPC ל-AWS Glue (com.amazonaws.AWS_REGION.glue) ב- AWS VPC.
שימו לב לכתובת ה-IP הפרטית וליציאה (443) של כל נקודת קצה, וודאו שקבוצות האבטחה של AWS מאפשרות תעבורת נתונים נכנסת של TCP ביציאה 443 מרשת ה-VPC של Google Cloud .
יוצרים מרחב שמות לנקודות הקצה הפרטיות המרוחקות:
```
gcloud service-directory namespaces create NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫NAMESPACE: מזהה ייחודי של מרחב השמות.
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
- ‫REGION: האזור של Google Cloud (לדוגמה, us-east4). זה חייב להיות אותו אזור של הקטלוג המאוחד.
יוצרים שירות במרחב השמות של Service Directory (אם אתם מנתבים באופן פרטי גם את העברת השאילתות וגם את רענון המטא-נתונים ברקע, צריך ליצור שירות נפרד לכל נקודת קצה):
```
gcloud service-directory services create SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫SERVICE_NAME: מזהה ייחודי לשירות (צריך ליצור שם שירות נפרד, כמו METADATA_SERVICE_NAME, כשרושמים נקודת קצה לרענון מטא-נתונים ברקע).
יוצרים נקודת קצה בשירות עם כתובת ה-IP הפרטית והיציאה של נקודת הקצה הפרטית המרוחקת:
```
gcloud service-directory endpoints create ENDPOINT_NAME \
    --service=SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION \
    --address=REMOTE_ENDPOINT_IP \
    --port=REMOTE_ENDPOINT_PORT \
    --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ENDPOINT_NAME: מזהה ייחודי של נקודת הקצה.
- ‫REMOTE_ENDPOINT_IP: כתובת ה-IP הפרטית של נקודת הקצה הפרטית של האחסון או הקטלוג המרוחקים (לדוגמה, 10.0.1.45).
- ‫REMOTE_ENDPOINT_PORT: מספר היציאה של נקודת הקצה הפרטית המרוחקת (לדוגמה, 443).
- ‫PROJECT_NUMBER: מספר הפרויקט ב- Google Cloud. משתמשים במספר הפרויקט בדגל --network.
- ‫VPC_NETWORK: השם של רשת ה-VPC ב- Google Cloudשמשויכת לחיבור ה-Interconnect הפרטי.

הגדרת איחוד

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

יצירת תפקיד AWS IAM עם מדיניות אמון של פלייסהולדר

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

יוצרים קובץ בשם trust_policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "accounts.google.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "accounts.google.com:aud": [
            "PLACEHOLDER_VALUE"
          ],
          "accounts.google.com:sub": [
            "PLACEHOLDER_VALUE"
          ]
        }
      }
    }
  ]
}

מריצים את הפקודה של AWS CLI כדי ליצור את התפקיד עם מדיניות האמון של ה-placeholder. מומלץ להגדיר את משך הסשן המקסימלי ל-12 שעות (43200 שניות) כדי למנוע את פקיעת התוקף של פרטי הכניסה במהלך משימות ארוכות:
```
aws iam create-role \
  --role-name AWS_ROLE_NAME \
  --assume-role-policy-document file://trust_policy.json \
  --max-session-duration 43200
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫AWS_ROLE_NAME: שם לתפקיד ב-AWS IAM. לדוגמה, lakehouse_glue_federation_role.

צירוף מדיניות הרשאות

מצרפים מדיניות הרשאות לתפקיד ה-IAM שמאפשר ל-Lakehouse לגשת ל-Glue Data Catalog ול-S3 buckets באזור AWS. המדיניות הזו גם נותנת גישה לקטגוריות של טבלאות S3 אם אתם משתמשים בשילוב של טבלאות AWS Lake Formation S3. אם שדרגתם מהרשאות הנתונים שמוגדרות כברירת מחדל ב-AWS Glue למודל AWS Lake Formation, יכול להיות שתצטרכו לתת הרשאות נוספות ב-Lake Formation.

יוצרים קובץ בשם permissions_policy.json עם הגדרת המדיניות הבאה.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GlueRead",
      "Effect": "Allow",
      "Action": [
        "glue:GetCatalog",
        "glue:GetDatabase",
        "glue:GetDatabases",
        "glue:GetTable",
        "glue:GetTables"
      ],
      "Resource": "arn:aws:glue:AWS_REGION:AWS_ACCOUNT_ID:*"
    },
    {
      "Sid": "S3Read",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::*"
      ]
    },
    {
      "Sid": "S3TablesRead",
      "Effect": "Allow",
      "Action": [
        "s3tables:GetTableBucket",
        "s3tables:ListNamespaces",
        "s3tables:GetNamespace",
        "s3tables:ListTables",
        "s3tables:GetTable",
        "s3tables:GetTableMetadataLocation",
        "s3tables:GetTableData"
      ],
      "Resource": [
        "arn:aws:s3tables:AWS_REGION:AWS_ACCOUNT_ID:*"
      ]
    }
  ]
}

אם אתם משתמשים במפתחות בניהול הלקוח שמתארחים ב-AWS Key Management Service (KMS) כדי להצפין משאבים של AWS Glue,‏ Amazon S3 או Amazon S3 Tables, אתם צריכים להוסיף הצהרה שמעניקה גישה למפתח KMS כדי לפענח את המשאבים:

# ...
{
  "Sid": "GlueS3S3TablesKmsDecrypt",
  "Effect": "Allow",
  "Action": [
      "kms:Decrypt"
  ],
  "Resource": [
      "arn:aws:kms:AWS_REGION:AWS_ACCOUNT_ID:key/key_id_for_glue",
      "arn:aws:kms:AWS_REGION:AWS_ACCOUNT_ID:key/key_id_for_s3",
      "arn:aws:kms:AWS_REGION:AWS_ACCOUNT_ID:key/key_id_for_s3_tables"
  ]
}
# ...

מצרפים את מדיניות ההרשאות הזו לתפקיד ה-IAM:
```
aws iam put-role-policy \
  --role-name AWS_ROLE_NAME \
  --policy-name AWS_POLICY_NAME \
  --policy-document file://permissions_policy.json
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫AWS_ROLE_NAME: השם של התפקיד ב-AWS IAM. לדוגמה, lakehouse_glue_federation_role.
- ‫AWS_POLICY_NAME: שם למדיניות ההרשאות. לדוגמה, lakehouse_glue_federation_policy.
- ‫AWS_REGION: האזור ב-AWS שבו נמצאים קטלוג Glue או טבלאות S3. לדוגמה, us-east-1.
- ‫AWS_ACCOUNT_ID: מחרוזת מזהה החשבון ב-AWS, שמורכבת מ-12 ספרות. לדוגמה, 123456789012.

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

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

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

המסוף

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

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

מעבר אל Lakehouse
לוחצים על ‎ Create catalog‎.
לוחצים על קטלוג מאוחד.

הקטע Catalog configuration מופיע.
בשדה מקור קטלוג מאוחד, בוחרים באפשרות AWS Glue.
בשדה Data location, בוחרים את האזור של Lakehouse שבו רוצים ליצור את הקטלוג המאוחד. לדוגמה, us-east4. כדי לצמצם את זמן האחזור (אפילו באינטרנט הציבורי), בוחרים את האזור של Google Cloud שהכי קרוב לאזור של AWS.
לוחצים על Continue.

הקטע פרטי החיבור מופיע.
בקטע Remote catalog details, בשדה AWS warehouse מזינים את מזהה החשבון ב-AWS או את קטלוג הקטגוריות של טבלאות S3. לדוגמה: 123456789012 או 123456789012:s3tablescatalog/my-table-bucket.
בשדה AWS region, מזינים את האזור ב-AWS. לדוגמה: us-east-1.
בשדה AWS role ARN, מזינים את ה-ARN של התפקיד ב-AWS. צריך להשתמש בפורמט הבא: arn:aws:iam::AWS_ACCOUNT_ID:role/AWS_ROLE_NAME.
בקטע שכבת התעבורה, בוחרים באפשרות Public internet או Dedicated private interconnect. אם בוחרים באפשרות Dedicated private interconnect, מגדירים את השדות הבאים:
- בשדה Service directory name, מזינים את הנתיב לשירות ספריות להעברה בפורמט projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME.
- אופציונלי: כדי לסנכרן את המטא-נתונים של הקטלוג באופן פרטי דרך Cross-Cloud Interconnect, בשדה Metadata service directory name מזינים את הנתיב לשירות של ספריית השירותים של המטא-נתונים בפורמט projects/PROJECT_ID/locations/REGION/namespaces/METADATA_SERVICE_DIRECTORY_NAMESPACE/services/METADATA_SERVICE_NAME.
לוחצים על יצירה.

gcloud

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

אם לא מגדירים את Cross-Cloud Interconnect, החיבורים עוברים דרך האינטרנט הציבורי באמצעות TLS.

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="glue" \
    --glue-warehouse="GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE" \
    --glue-aws-region="AWS_REGION" \
    --glue-aws-role-arn="arn:aws:iam::AWS_ACCOUNT_ID:role/AWS_ROLE_NAME" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --cross-cloud-cache="CROSS_CLOUD_CACHE_MODE"

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

אם הגדרתם חיבור פרטי (Dedicated או Partner Cross-Cloud Interconnect), ציינו את ההפניה לשירות של Service Directory להעברת שאילתות פרטיות (--service-directory-name), לרענון פרטי של מטא-נתונים ברקע (--metadata-service-directory-name) או לשניהם. אפשר גם להוסיף או לעדכן את אחד מהדגלים בקטלוג קיים באמצעות הפעלת gcloud biglake iceberg catalogs update.

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="glue" \
    --glue-warehouse="GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE" \
    --glue-aws-region="AWS_REGION" \
    --glue-aws-role-arn="arn:aws:iam::AWS_ACCOUNT_ID:role/AWS_ROLE_NAME" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --cross-cloud-cache="CROSS_CLOUD_CACHE_MODE" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME" \
    --metadata-service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/METADATA_SERVICE_DIRECTORY_NAMESPACE/services/METADATA_SERVICE_NAME"

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

‫FEDERATED_CATALOG_NAME: שם לקטלוג המאוחד.
‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
‫REGION: האזור ב-Lakehouse שבו נוצר הקטלוג המאוחד. האזור הזה צריך להיות זהה לאזור של מרחב השמות של Service Directory והסוד האזורי.
‫GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE: מזהה הקטלוג של מחסן הנתונים שאליו רוצים להעביר את הנתונים. ב-Glue Data Catalog של אזור AWS, מזינים את המחרוזת של מזהה החשבון ב-AWS, שמורכבת מ-12 ספרות. לדוגמה, 123456789012. כדי להשתמש בקטגוריית טבלאות S3 באזור, מזינים את הערך AWS_ACCOUNT_ID:s3tablescatalog/S3_TABLE_BUCKET. לדוגמה, 123456789012:s3tablescatalog/my-table-bucket.
‫AWS_ACCOUNT_ID: מחרוזת מזהה החשבון ב-AWS, שמורכבת מ-12 ספרות. לדוגמה, 123456789012.
‫AWS_REGION: האזור ב-AWS שבו נמצאים קטלוג Glue או קטגוריית הטבלאות ב-S3. לדוגמה, us-east-1.
‫AWS_ROLE_NAME: השם של התפקיד ב-AWS IAM. לדוגמה, lakehouse_glue_federation_role.
‫NAMESPACE_FILTERS: אופציונלי: רשימה מופרדת בפסיקים של מרחבי שמות לאיחוד. לדוגמה, ns1,ns2. אם לא מציינים את הפרמטר, Lakehouse כולל את כל מרחבי השמות.
‫CROSS_CLOUD_CACHE_MODE: אופציונלי: אם להפעיל שמירה במטמון חוצה-עננים בקטלוג המאוחד (enabled או disabled). ברירת המחדל היא disabled. אם הערך הוא enabled, ‫Lakehouse שומר במטמון קבצים מרוחקים באזור של הקטלוג ב-Google Cloud . למידע נוסף, ראו שמירה חכמה במטמון.
אם אתם משתמשים בחיבור פרטי (Cross-Cloud Interconnect), ציינו את אחד מההפניות הבאות ל-Service Directory או את שתיהן (השמיטו את אחד מהדגלים אם אתם לא מנתבים את שכבת התנועה הזו דרך Cross-Cloud Interconnect):
- ‫SERVICE_DIRECTORY_NAMESPACE ו-SERVICE_NAME: מרחב השמות של Service Directory ושם השירות שיצרתם להעברת שאילתות פרטיות למאגר אובייקטים מרוחק.
- ‫METADATA_SERVICE_DIRECTORY_NAMESPACE ו-METADATA_SERVICE_NAME: מרחב השמות של Service Directory ושם השירות שיצרתם לרענון פרטי המטא-נתונים ברקע באופן פרטי.

עדכון מדיניות האמון

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

מריצים את הפקודה הבאה כדי לחלץ את הערך של biglake-service-account-id למשתנה bash פעיל:

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

מעדכנים את מדיניות האמון של התפקיד ב-AWS IAM כדי להחליף את ה-placeholder במזהה המאומת של סוכן השירות של Google. בלוק התנאי מאמת את ההתאמה של sub ושל aud. כותבים את המדיניות בקובץ בשם trust_policy_comprehensive.json:

cat > trust_policy_comprehensive.json << EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "accounts.google.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "accounts.google.com:aud": [
            "$LAKEHOUSE_SA_ID"
          ],
          "accounts.google.com:sub": [
            "$LAKEHOUSE_SA_ID"
          ]
        }
      }
    }
  ]
}
EOF

מחילים את המדיניות הסופית על התפקיד ב-AWS:
```
aws iam update-assume-role-policy \
  --role-name AWS_ROLE_NAME \
  --policy-document file://trust_policy_comprehensive.json
```
הערה: יכול להיות שיעברו כמה דקות עד שהשינויים ב-AWS IAM יתעדכנו.

הפעלת רענון מטא-נתונים ברקע

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

gcloud

gcloud biglake iceberg catalogs update FEDERATED_CATALOG_NAME \
  --project="PROJECT_ID" \
  --refresh-interval="300s"

REST

curl -s -X PATCH \
  -H "x-goog-user-project: PROJECT_ID" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME?updateMask=federated_catalog_options.refresh_options.refresh_schedule" \
  -d '{
    "federated_catalog_options": {
      "refresh_options": {
        "refresh_schedule": {
          "refresh_interval": "300s"
        }
      }
    }
  }'

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

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

המסוף

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

כניסה לדף IAM
לוחצים על הענקת גישה (או הוספה).
בשדה New principals, מזינים את כתובת האימייל של חשבון השירות של קטלוג Lakehouse. כדי לאחזר את כתובת האימייל הזו, אפשר לתאר את הקטלוג (ראו את הכרטיסייה gcloud).
בתפריט Role, בוחרים באפשרות Service Directory Viewer (roles/servicedirectory.viewer).
לוחצים על Add another role ובוחרים באפשרות Service Directory PSC Authorized Service (roles/servicedirectory.pscAuthorizedService).
לוחצים על Save.

gcloud

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

# 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"

אימות החיבור

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

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

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

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

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

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

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

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

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

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

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

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

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

הגדרת איחוד

יצירת תפקיד AWS IAM עם מדיניות אמון של פלייסהולדר

צירוף מדיניות הרשאות

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

המסוף

gcloud

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

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

עדכון מדיניות האמון

הפעלת רענון מטא-נתונים ברקע

gcloud

REST

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

המסוף

gcloud

אימות החיבור

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

הגדרת חיבור בין עננים ל-AWS Glue