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

תצוגה מקדימה

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

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

חיבור בין עננים ל-Workday Data Lake מאפשר לכם לשלוח שאילתות לנתוני Workday ישירות ב- Google Cloud. אחרי הייצוא ל-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.

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.

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 Admin (roles/biglake.admin)
• ניהול סודות: אדמין Secret Manager (roles/secretmanager.admin)

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

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

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

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

במאמר הזה מוסבר איך להגדיר Lakehouse עם Workday Data Lake. מידע על קטלוגים אחרים זמין במאמר בנושא קטלוגים נתמכים.

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

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

• קריאה בלבד: קטלוגים מאוחדים ב-Lakehouse הם תצוגות לקריאה בלבד של הקטלוג המרוחק. כדי ליצור, לעדכן או למחוק משאבים, צריך להשתמש ישירות ב-Workday.
• ניתוב ברשת: חיבורים ושאילתות מנותבים בצורה מאובטחת דרך האינטרנט הציבורי.
• עדכניות הנתונים: הדגל --refresh-interval קובע באיזו תדירות מתבצע סנכרון של מטא-נתונים ב-Lakehouse. הערך חייב להיות 0s (מושבת) או לפחות 300s (5 דקות). ככל שמספר מרחבי השמות והטבלאות בקטלוג גדל, רענוני המטא-נתונים ברקע נמשכים זמן רב יותר. אם הרענון הקודם חורג ממרווח הזמן המתוזמן שלו, המערכת מדלגת על המחזור הנוכחי וממשיכה במרווח הזמן המתוזמן הבא.
• Colocation: כדי להימנע מבעיות בקישוריות ולצמצם את זמן האחזור ואת העלויות של העברת הנתונים, צריך ליצור את הקטלוג המאוחד ואת הסוד האזורי בGoogle Cloud אזור הכי קרוב לאזור שבו נמצא מופע Workday שלכם.

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

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

1. הגדרת איחוד: מגדירים אימות מבוסס-סוד ויוצרים קטלוג מאוחד ב-Lakehouse.
   1. ב-Workday, יוצרים משתמש מערכת שילוב (ISU) ולקוח 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. יוצרים חשבון ISU: מריצים את המשימה Create Integration System User כדי ליצור חשבון ייעודי ש-Lakehouse משתמש בו לסנכרון משאבים.
   2. הפעלת גישה ל-Workday Data Lake עבור ה-ISU: נותנים ל-ISU גישה ל-Workday Data Lake. כדי להפעיל את הגישה הזו, צריך לפנות לתמיכה של Workday. אי אפשר לבצע את השלב הזה בעצמכם. צריך לחכות ש-Workday יגדיר את הגישה בדייר שלכם ב-Workday לפני שממשיכים.
   3. הרשמה של לקוח API לשילובים: מריצים את המשימה Register API Client for Integrations.
   4. שמירת מזהה הלקוח והסוד: שומרים את מזהה הלקוח ואת הסוד ב-OAuth לשלב הבא.
   5. יצירת טוקן רענון שלא פג תוקפו: בכלי API Client for Integrations, משתמשים באפשרות Manage Refresh Tokens for Integrations כדי ליצור טוקן רענון שלא פג תוקפו עבור ISU.
   6. שמירת טוקן הרענון: שומרים את טוקן הרענון שנוצר לשלב הבא.

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

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

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

   • ‫CLIENT_ID: מזהה לקוח OAuth מ-Workday API Client for Integrations.
   • ‫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. מעלים את המטען הייעודי אל 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 .

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

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

   [Go to Lakehouse][5]

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.

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

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