הגדרת חיבור חוצה-עננים ל-Workday Data Lake

חיבור חוצה-עננים ל-Workday Data Lake מאפשר לשלוח שאילתות לנתונים של Workday ישירות ב- Google Cloud. היכולת הזו מאחדת את ניתוח הנתונים שלכם על ידי שילוב מקורות הנתונים החיצוניים עם הסביבה הקיימת שלGoogle Cloud .

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

תרחישים לדוגמה

חיבור Lakehouse ל-Workday Data Lake תומך בכמה תרחישים לדוגמה:

• איחוד ניתוחים: קישור בין נתוני משאבי האנוש והתגמולים של Workday לבין נתוניGoogle Cloud , למשל כדי לספק הקשר למכירות ולמכסות.
• שימוש בסביבה העסקית של Google Cloud: לדוגמה, שימוש ב-Agent Framework של Google עם BigQuery ML ונתוני משאבי אנוש של Workday כדי לחזות את שימור העובדים.
• העברת נתונים בזמן אמת בלי להעתיק אותם: ניתוח נתוני הרכש והחשבונות לתשלום ב-Workday לצד נתוני הלוגיסטיקה והמלאי שמאוחסנים ב-Google Cloud , כדי לדווח על חוסר יעילות בשרשרת האספקה ולשפר את עלויות הספקים.

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

1. בסקירה הכללית של Lakehouse מוסבר איך מתבצע ניהול הגישה לנתונים ב-Lakehouse.
2. איך ניגשים לנתונים חוצי-עננים
3. כדי לוודא תאימות, כדאי לעיין בקטלוגים הנתמכים.
4. איך משתמשים בסודות אזוריים של Secret Manager כדי לאמת את Workday Data Lake
5. כדי להגדיר את האימות כמו שמתואר במסמך הזה, צריך לפנות לאדמינים של Workday Data Lake. יכול להיות שהאדמינים יצטרכו לפנות לתמיכה של Workday כדי להפעיל את הגישה ל-Data Lake, וזה יכול לקחת זמן.
נכנסים לחשבון Google Cloud . אנחנו ממליצים למשתמשים חדשים ב- Google Cloud ליצור חשבון כדי שיוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake, Secret Manager APIs, if any are not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake, Secret Manager APIs, if any are not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

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

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

• ניהול קטלוגים של Lakehouse: אדמין BigLake‏ (roles/biglake.admin)
• ניהול סודות: אדמין של Secret Manager ‏(roles/secretmanager.admin)

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

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

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

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

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

• ‫VPC Service Controls: אם הפרויקט שמכיל את נקודת הקצה של הקטלוג המאוחד או את הקטגוריה הבסיסית של Cloud Storage נמצא בתוך גבולות גזרה לשירות של VPC Service Controls, אתם צריכים להגדיר כללים לתעבורת נתונים נכנסת (ingress) או יוצאת (egress). מידע נוסף זמין במאמר שימוש ב-VPC Service Controls עם נקודות קצה של קטלוג מאוחד.
• לקריאה בלבד: קטלוגים מאוחדים ב-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 שבו השאילתה פועלת. אם קובצי הענן המרוחקים נמצאים בסמכות שיפוט אחרת, לפני שמפעילים את השמירה במטמון באזורים שונים, צריך לוודא שהיא עומדת בדרישות של הארגון לגבי מיקום אחסון הנתונים והתאימות.

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

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

1. הגדרת איחוד: מגדירים אימות מבוסס-סוד ויוצרים קטלוג מאוחד ב-Lakehouse.
   1. ב-Workday, מגדירים את פרטי הכניסה ל-Data Lake ול-Workday API.
   2. יוצרים סוד ב-Secret Manager עם פרטי הכניסה ל-Workday API.
   3. יוצרים קטלוג מאוחד ב-Lakehouse ונותנים לחשבון השירות של הקטלוג גישה לסוד.
2. אימות החיבור: מוודאים ש-Lakehouse יכול להתחבר לקטלוג המרוחק ולסנכרן מטא-נתונים.
3. שליחת שאילתות על נתונים: אתם יכולים להריץ שאילתות על הנתונים המאוגדים באמצעות BigQuery או Managed Service for Apache Spark. אפשר להפעיל שמירה במטמון חוצה-עננים בקטלוג המאוחד כדי להפחית את עלויות תעבורת הנתונים היוצאת חוצת-העננים ולהאיץ את השאילתות הבאות. מידע נוסף זמין במאמר שליחת שאילתות לנתונים מרוחקים.
4. הגדרת הרשאות: משתמשים בממשק של ניהול הזהויות והרשאות הגישה (IAM) כדי לקבוע מי יכול לראות את הנתונים המאוחדים ולשלוח אליהם שאילתות.

הגדרת איחוד

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

הגדרת אימות

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

1. ב-Workday, מבצעים את הפעולות הבאות:

   1. מגדירים את אגם הנתונים.
   2. רישום לקוח API ל-Data Lake (הענקת טוקן רענון).
   3. מגדירים אבטחה וייצוא של טבלאות ב-Data Lake.

   הוראות מפורטות להשלמת התהליך הזה זמינות במאמר תחילת העבודה עם Workday Data Lake.

2. יוצרים קובץ JSON בשם credentials.json עם פרטי הכניסה מהשלב הקודם:

   {
     "client_id": "CLIENT_ID",
     "client_secret": "CLIENT_SECRET",
     "refresh_token": "REFRESH_TOKEN"
   }

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

   • ‫CLIENT_ID: מזהה הלקוח ב-OAuth מ-API Client for Integrations ב-Workday.
   • ‫CLIENT_SECRET: סוד הלקוח ב-OAuth מלקוח ה-API של Workday לשילובים.
   • ‫REFRESH_TOKEN: טוקן הרענון ללא תפוגה שנוצר בשביל Workday ISU.

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

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

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

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

   • ‫REGION: האזור ב- Google Cloud שבו מאוחסן הסוד של Secret Manager. לדוגמה: us-east4.

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

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

5. מוחקים באופן מאובטח את הקובץ credentials.json כדי למנוע דליפה של פרטי הכניסה.

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

   • ‫WORKDAY_SECRET_NAME: שם ייחודי לסוד של Workday ב-Secret Manager, לדוגמה workday-api-credentials או workday-data-lake-secret.
   • ‫REGION: האזור ב- Google Cloud שבו יוצרים את הסוד, לדוגמה us-east4.
   • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

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

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

המסוף

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

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

   מעבר אל Lakehouse

2. לוחצים על Create catalog ובוחרים באפשרות קטלוג מאוחד.

   מופיע הדף יצירת קטלוג מאוחד.

3. בקטע Catalog configuration:

   1. ברשימת מקור קטלוג מאוחד, בוחרים באפשרות Workday (אגם נתונים).
   2. בשדה Catalog name (in Lakehouse), מזינים שם לקטלוג.
   3. ברשימה מיקום הנתונים, בוחרים את האזור שבו רוצים ליצור את הקטלוג המאוחד, לדוגמה us-east4. האזור הזה צריך להיות זהה לאזור של הסוד ב-Secret Manager. כדי לצמצם את זמן האחזור ואת עלויות העברת הנתונים, כשבוחרים אזור צריך:
      • אם המכונה של Workday נמצאת ב-Amazon Web Services‏ (AWS), בוחרים את Google Cloud האזור הכי קרוב לאזור של AWS.
      • אם המכונה של Workday נמצאת ב- Google Cloud, צריך לבחור בדיוק את אותו אזור.
   4. אופציונלי: בקטע Cross-cloud caching, בוחרים באפשרות Enable cross-cloud caching כדי לשמור במטמון קבצים מרוחקים באזור של הקטלוג ב-Google Cloud ולשפר את ביצועי השאילתות. אפשר גם לעדכן את ההגדרה הזו מאוחר יותר על ידי עריכת פרטי הקטלוג. מידע נוסף על אופן הפעולה של שמירה במטמון, שמירת נתונים ותמחור זמין במאמר שמירה חכמה במטמון.
   5. לוחצים על Continue.

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

   1. בקטע פרטי הקטלוג המרוחק:
      • בשדה Workday Base URL, מזינים את כתובת ה-URL הבסיסית של המכונה ב-Workday. לדוגמה, impl-services1.wd12.myworkday.com או wd501.myworkday.com.
      • בשדה Workday Tenant, מזינים את שם הדייר ב-Workday, לדוגמה, my_company_tenant.
   2. בקטע שיטת אימות, בשדה Secret Manager Secret, מזינים את שם המשאב של הסוד האזורי. צריך להשתמש בפורמט הבא: projects/PROJECT_ID/locations/REGION/secrets/WORKDAY_SECRET_NAME.
   3. בקטע Refresh interval, בשדה Refresh interval, מזינים את התדירות (בשניות) שבה רוצים לעדכן את המטא-נתונים של הקטלוג (לדוגמה, 300). כדי להשבית את הרענון של המטא-נתונים ברקע, מזינים 0.

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

‫CLI של gcloud

כדי ליצור קטלוג מאוחד באמצעות ה-CLI של gcloud, מריצים את הפקודה הבאה:

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="workday" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/WORKDAY_SECRET_NAME" \
    --workday-base-url="WORKDAY_BASE_URL" \
    --workday-tenant="WORKDAY_TENANT" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --cross-cloud-cache="CROSS_CLOUD_CACHE_MODE"

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

• ‫FEDERATED_CATALOG_NAME: שם לקטלוג המאוחד ב-Lakehouse.
• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
• ‫REGION: האזור ב-Lakehouse שבו יוצרים את הקטלוג המאוחד, לדוגמה us-east4. האזור הזה צריך להיות זהה לאזור שבו אחסנתם את הסוד. כדי לצמצם את זמן האחזור ואת עלויות העברת הנתונים, כשבוחרים אזור צריך:
  • אם המכונה של Workday נמצאת ב-AWS, בוחרים אתGoogle Cloud האזור שהכי קרוב לאזור שלכם ב-AWS.
  • אם המכונה של Workday נמצאת ב- Google Cloud, צריך לבחור בדיוק את אותו אזור.
• ‫WORKDAY_SECRET_NAME: השם של הסוד של Workday ב-Secret Manager.
• ‫WORKDAY_BASE_URL: כתובת ה-URL הבסיסית של המכונה ב-Workday. לדוגמה, impl-services1.wd12.myworkday.com או wd501.myworkday.com.
• ‫WORKDAY_TENANT: שם הדייר ב-Workday.
• REFRESH_INTERVAL: אופציונלי: מציין את התדירות שבה צריך לעדכן את המידע בקטלוג. צריך להגדיר את הערך הזה כמשך זמן, לדוגמה, 300s או 5m. מרווחים קצרים יותר מעדכנים את הנתונים בתדירות גבוהה יותר, אבל יכולים לעלות יותר בקריאות ל-API. מרווחים ארוכים יותר יכולים לעלות פחות, אבל יכול להיות שהנתונים שיתקבלו בשאילתה לא ישקפו את מערך הנתונים העדכני ביותר. אם לא מציינים ערך, מרווח הזמן לרענון הוא 5 דקות (300s) כברירת מחדל. אם מגדירים את הערך ל-0s, הרענון של המטא-נתונים ברקע מושבת.
• ‫NAMESPACE_FILTERS: אופציונלי: רשימה מופרדת בפסיקים של מרחבי שמות לאיחוד, לדוגמה, finance,hr. אם לא מציינים את הפרמטר, Lakehouse כולל את כל מרחבי השמות.
• ‫CROSS_CLOUD_CACHE_MODE: אופציונלי: אם להפעיל שמירה במטמון חוצה-עננים בקטלוג המאוחד (enabled או disabled). ברירת המחדל היא disabled. אם הערך הוא enabled, ‫Lakehouse שומר במטמון קבצים מרוחקים באזור של הקטלוג ב-Google Cloud . למידע נוסף, ראו שמירה חכמה במטמון.

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

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

אתם צריכים להקצות לחשבון השירות הזה את התפקיד "גישה לסודות ב-Secret Manager" (roles/secretmanager.secretAccessor) בסוד שיצרתם קודם. יכול להיות שיעברו כמה דקות עד שמדיניות IAM חדשה תיכנס לתוקף.

המסוף

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

   מעבר אל Lakehouse

2. לוחצים על השם של הקטלוג המאוחד שיצרתם ל-Workday.

3. בדף Catalog details, לוחצים על Grant secret permissions בבאנר ההתראה.

   ‫Lakehouse מקצה את התפקיד roles/secretmanager.secretAccessor בסוד לחשבון השירות שהוקצה.

‫CLI של gcloud

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

   gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
   gcloud secrets add-iam-policy-binding WORKDAY_SECRET_NAME \
     --project="PROJECT_ID" \
     --location="REGION" \
     --member="serviceAccount:$(gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
         --project="PROJECT_ID" \
         --format='value(biglake-service-account)')" \
         --role="roles/secretmanager.secretAccessor"

2. כדי לוודא שלחשבון השירות של הקטלוג המאוחד יש גישה לסוד, מריצים את הפקודה הבאה:

   gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
   gcloud secrets get-iam-policy WORKDAY_SECRET_NAME \
        --project="PROJECT_ID" \
        --location="REGION"

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

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

• ‫REGION: האזור ב- Google Cloud שבו אתם מאחסנים את הסוד של Secret Manager ושבו יצרתם את הקטלוג המאוחד, לדוגמה us-east4.
• ‫WORKDAY_SECRET_NAME: השם של הסוד של Workday ב-Secret Manager.
• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
• ‫FEDERATED_CATALOG_NAME: השם של הקטלוג המאוחד ב-Lakehouse.

אימות החיבור

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

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

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

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

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

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

• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
• ‫FEDERATED_CATALOG_NAME: השם של הקטלוג המאוחד ב-Lakehouse.

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

• שליחת שאילתות לנתונים מרוחקים.
• שימוש ב-VPC Service Controls עם נקודות קצה של קטלוג מאוחד.
• פתרון בעיות בגישה לנתונים חוצי-עננים