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

תצוגה מקדימה

השימוש בתכונה הזו כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, שמפורטים בחלק "תנאי שירות הכלליים" בתנאים הספציפיים של השירות. השימוש בתכונות בגרסת טרום-GA הוא "כפי שהן" (As is), ויכול להיות שהתמיכה בהן תהיה מוגבלת. מידע נוסף זמין בקטע תיאור שלבי ההשקה.

הערה: כדי לקבל תמיכה במהלך תקופת התצוגה המקדימה, אפשר לשלוח אימייל לכתובת [e-mail].

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

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

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

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

• איחוד נתונים לצורך ניתוח: אפשר ליצור קורלציה בין נתוני משאבי אנוש ופיצויים של Workday לבין נתוניGoogle Cloud , למשל, כדי לספק הקשר למכירות ולמכסות.
• מינוף האקוסיסטם של Google Cloud: לדוגמה, אפשר להשתמש במסגרת הסוכנים של 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

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

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

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

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

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

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

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

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

• קריאה בלבד: קטלוגים מאוחדים ב-Lakehouse הם תצוגות לקריאה בלבד של הקטלוג המרוחק. אין תמיכה במניפולציה של משאבים (למשל יצירה, עדכון או מחיקה של משאבים), וצריך לבצע אותה ישירות בקטלוג המרוחק.
• עדכניות הנתונים: הדגל --refresh-interval בקטלוג מאוחד קובע את תדירות הסנכרון של המטא-נתונים. הערך צריך להיות 0s (מושבת) או לפחות 300s (5 דקות). יכול להיות שרענון המטא-נתונים ברקע של קטלוג ייקח יותר זמן ככל שיש יותר משאבים של מרחבי שמות וטבלאות. אם החידוש הקודם חורג מהזמן, החידוש הנוכחי יידחה, אבל החידוש הבא יתוזמן במרווח הבא.
• שמירת נתונים במטמון ב-Lakehouse: שמירת נתונים במטמון ב-Lakehouse מופעלת באופן אוטומטי לכל השאילתות חוצות הענן כדי לחסוך בעלויות של תעבורת נתונים יוצאת על ידי אחסון בלוקים של נתונים באופן מקומי ב- Google Cloud. אין תמיכה במפתחות הצפנה בניהול הלקוח (CMEK) לצורך שמירה במטמון. הנתונים שנשמרים במטמון מוצפנים באמצעות Google-owned and Google-managed encryption keys. אם האילוץ constraints/gcp.restrictNonCmekServices של מדיניות הארגון נאכף על טבלה כלשהי בשאילתה, השמירה במטמון מושבתת באופן אוטומטי עבור השאילתה הזו. מידע נוסף זמין במאמר בנושא שמירה חכמה במטמון.
• מיקום הנתונים ותאימות: כשיוצרים קטלוג מאוחד או חיבור באזור Google Cloud , הנתונים שנשמרים במטמון מאוחסנים באותו אזור יעד. אם נתוני הענן המרוחקים שלכם נמצאים בתחום שיפוט אחר, צריך לוודא שהשמירה במטמון בין אזורים עומדת בדרישות של הארגון בנוגע למיקום אחסון הנתונים ולעמידה בתקנות.

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

כדי לגשת לנתונים חוצי-עננים (cross-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 Data Lake המרוחק באמצעות פרטי כניסה שמאוחסנים בצורה מאובטחת בסודות של 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 של Workday לשילובים.
   • ‫CLIENT_SECRET: סוד לקוח OAuth מלקוח Workday API for Integrations.
   • ‫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 או gcloud CLI:

המסוף

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

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

   מעבר אל Lakehouse

2. לוחצים על יצירת קטלוג ואז על קטלוג מאוחד.

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

3. בקטע Catalog configuration (הגדרת קטלוג):

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

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

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

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

‫CLI של gcloud

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

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

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

• ‫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 כולל את כל מרחבי השמות.

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

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

צריך להקצות לחשבון השירות הזה את התפקיד Secret Manager Secret Accessor ‏(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 alpha 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 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"

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

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

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

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