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

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

  7. Verify that billing is enabled for your Google Cloud project.

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

  9. Verify that billing is enabled for your Google Cloud project.

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

    11.

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

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

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

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

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

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

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

    מעבר אל 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.

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