הגדרת Lakehouse ללא גבולות ב-AWS Glue

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

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

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

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

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake API.

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.

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

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

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

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

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

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

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

בקטע הזה מפורטות המגבלות והשיקולים לשימוש ב-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 שלכם לבין ספק הענן המרוחק.
• הגדרת איחוד: הגדרת אימות על ידי יצירת תפקיד IAM עם מדיניות אמון של placeholder אצל הספק המרוחק. לאחר מכן, יוצרים קטלוג מאוחד ב-Lakehouse ומעדכנים את מדיניות ההרשאות.
• בדיקת החיבור: מוודאים ש-Lakehouse יכול להתחבר בהצלחה לקטלוג המרוחק.
• הפעלת שאילתות על נתונים: אפשר להריץ שאילתות על הנתונים המאוחדים באמצעות BigQuery או Managed Service for Apache Spark. מידע נוסף זמין במאמר בנושא שימוש ב-Lakehouse ללא גבולות.
• הגדרת הרשאות: משתמשים ב-IAM כדי לנהל את האנשים שיכולים לצפות בנתונים המאוחדים ולשאול עליהם שאילתות.

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

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

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

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

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

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

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

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

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

הגדרת איחוד

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

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

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

1. יוצרים קובץ בשם 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"
             ]
           }
         }
       }
     ]
   }

2. מריצים את הפקודה של 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 אם משתמשים בשילוב של טבלאות S3 ב-AWS Lake Formation. אם שדרגתם מהרשאות ברירת המחדל של נתוני AWS Glue למודל AWS Lake Formation, יכול להיות שתצטרכו להעניק הרשאות נוספות ב-Lake Formation במקום זאת.

1. יוצרים קובץ בשם 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"
     ]
   }
   # ...

2. מצרפים את מדיניות ההרשאות הזו לתפקיד ה-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: השם של תפקיד ה-IAM ב-AWS. לדוגמה, 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 , gcloud CLI או API בארכיטקטורת REST.

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

gcloud alpha 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"

gcloud alpha 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" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/NAMESPACE/services/SERVICE_NAME"

curl -s -X POST \
  -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?iceberg_catalog_id=FEDERATED_CATALOG_NAME&primary_location=REGION" \
  -d '{
    "catalog_type": "CATALOG_TYPE_FEDERATED",
    "storage_regions": ["'"REGION"'"],
    "federated_catalog_options": {
      "glue_catalog_info": {
        "warehouse": "'"GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE"'",
        "aws_region": "'"AWS_REGION"'",
        "aws_role_arn": "arn:aws:iam::'"AWS_ACCOUNT_ID"':role/'"AWS_ROLE_NAME"'"
      }
    }
  }'

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

• ‫FEDERATED_CATALOG_NAME: שם לקטלוג המאוחד.
• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
• ‫REGION: האזור של Lakehouse שבו נוצר הקטלוג המאוחד. לדוגמה, us-east4.
• ‫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: השם של תפקיד ה-IAM ב-AWS. לדוגמה, lakehouse_glue_federation_role.
• ‫NAMESPACE: (אופציונלי) מרחב השמות של Service Directory שיצרתם במהלך ההגדרה של קישוריות פרטית.
• ‫SERVICE_NAME: (אופציונלי) שם השירות של Service Directory שיצרתם במהלך ההגדרה של קישוריות פרטית.

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

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

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

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

2. מעדכנים את מדיניות ההרשאות של תפקיד 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

3. מחילים את המדיניות הסופית על התפקיד ב-AWS:

   aws iam update-assume-role-policy \
     --role-name AWS_ROLE_NAME \
     --policy-document file://trust_policy_comprehensive.json

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

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

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

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 Interconnect או Partner Interconnect), אתם צריכים להעניק לחשבון השירות של קטלוג Lakehouse הרשאות לגילוי ולאישור חיבורים דרך Service Directory.

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

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

• שימוש בטבלאות Lakehouse וטבלאות שאילתות ללא גבולות.
• פתרון בעיות ב-Lakehouse ללא גבולות