Cloudübergreifende Verbindung für Workday Data Lake einrichten

Mit einer Cloud-übergreifenden Verbindung zu Workday Data Lake können Sie Ihre Workday-Daten direkt in Google Cloudabfragen. Anschließend können Sie mit Lakehouse den Zugriff auf Ihre föderierten Daten verwalten und diese analysieren, ohne Daten zu kopieren oder zu verschieben.

Anwendungsfälle

Die Verbindung von Lakehouse mit Workday Data Lake unterstützt mehrere wichtige Anwendungsfälle:

  • Analysen vereinheitlichen:Workday-HR- und Vergütungsdaten mitGoogle Cloud -Daten in Beziehung setzen, um beispielsweise Kontext für Umsatz und Quoten zu liefern.
  • Google Cloud-Ökosystem nutzen:Verwenden Sie beispielsweise das Agent-Framework von Google mit BigQuery ML und Workday HR-Daten, um die Mitarbeiterbindung vorherzusagen.
  • Daten in Echtzeit streamen, ohne sie zu kopieren:Analysieren Sie Workday-Daten zu Beschaffung und Kreditorenbuchhaltung zusammen mit Logistik- und Inventardaten, die inGoogle Cloud gespeichert sind, um Ineffizienzen in der Lieferkette zu erkennen und Lieferantenkosten zu optimieren.

Hinweis

  1. Lesen Sie sich den Lakehouse-Überblick durch, um zu verstehen, wie der Zugriff auf Daten in Lakehouse verwaltet wird.
  2. Informationen zum Zugriff auf cloudübergreifende Daten
  3. Sehen Sie sich die unterstützten Kataloge an, um die Kompatibilität zu prüfen.
  4. Informationen zum Verwenden regionaler Secret Manager-Secrets für die Authentifizierung bei Workday Data Lake.
  5. Wenden Sie sich an Ihre Workday Data Lake-Administratoren, um die Authentifizierung wie in diesem Dokument beschrieben einzurichten. Administratoren müssen sich möglicherweise an den Workday-Support wenden, um den Data Lake-Zugriff zu aktivieren. Das kann einige Zeit dauern.
  6. Melden Sie sich in Ihrem Google Cloud -Konto an. Wenn Sie mit Google Cloudnoch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

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

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

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

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

    11.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt zuzuweisen, damit Sie die nötigen Berechtigungen für die Einrichtung des cloudübergreifenden Zugriffs haben:

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Unterstützte Katalogdetails

In diesem Dokument wird beschrieben, wie Sie ein Lakehouse mit Workday Data Lake einrichten. Informationen zum Zugriff auf andere Kataloge finden Sie unter Unterstützte Kataloge.

Einschränkungen und Überlegungen

Beachten Sie beim Zugriff auf einen Workday Data Lake Folgendes:

  • Schreibgeschützt:Föderierte Kataloge in Lakehouse sind schreibgeschützte Ansichten des Remote-Katalogs. Wenn Sie Ressourcen erstellen, aktualisieren oder löschen möchten, müssen Sie Workday direkt verwenden.
  • Netzwerkrouting:Verbindungen und Anfragen werden sicher über das öffentliche Internet weitergeleitet.
  • Datenaktualität:Das Flag --refresh-interval bestimmt, wie oft Metadaten mit Lakehouse synchronisiert werden. Der Wert muss 0s (deaktiviert) oder mindestens 300s (5 Minuten) betragen. Mit zunehmender Anzahl von Namespaces und Tabellen in einem Katalog dauert die Aktualisierung von Hintergrundmetadaten länger. Wenn die vorherige Aktualisierung das geplante Intervall überschreitet, wird der aktuelle Zyklus übersprungen und die Aktualisierung wird beim nächsten geplanten Intervall fortgesetzt.
  • Colocation:Um Verbindungsprobleme zu vermeiden und Latenz- und Datenübertragungskosten zu minimieren, erstellen Sie den föderierten Katalog und das regionale Secret in derGoogle Cloud -Region, die der Region am nächsten ist, in der sich Ihre Workday-Instanz befindet.

Allgemeiner Workflow

So greifen Sie auf cloudübergreifende Daten in Workday Data Lake zu:

  1. Föderation einrichten:Konfigurieren Sie die geheimnisbasierte Authentifizierung und erstellen Sie einen föderierten Katalog in Lakehouse.
    1. Erstellen Sie in Workday einen Integrationssystemnutzer (Integration System User, ISU) und einen API-Client für Integrationen.
    2. Erstellen Sie in Secret Manager ein Secret mit Ihren Workday API-Anmeldedaten.
    3. Erstellen Sie einen föderierten Katalog in Lakehouse und gewähren Sie dem Dienstkonto des Katalogs Zugriff auf das Secret.
  2. Verbindung überprüfen:Prüfen Sie, ob Lakehouse eine Verbindung zu Ihrem Remote-Katalog herstellen und Metadaten synchronisieren kann.
  3. Daten abfragen:Führen Sie mit BigQuery oder Managed Service for Apache Spark Abfragen für Ihre föderierten Daten aus. Weitere Informationen finden Sie unter Remotedaten abfragen.
  4. Berechtigungen konfigurieren:Mit Identity and Access Management (IAM) können Sie verwalten, wer die föderierten Daten ansehen und abfragen darf.

Föderation einrichten

Wenn Sie Ihre Daten abfragen möchten, müssen Sie einen föderierten Lakehouse-Katalog einrichten, der mit Ihrem Workday-Data Lake verbunden ist.

Authentifizierung konfigurieren

Für die Föderation ist eine Authentifizierung beim Remote-Workday Data Lake mit Anmeldedaten erforderlich, die sicher in regionalen Secret Manager-Secrets gespeichert sind.

  1. Nehmen Sie in Workday die folgenden Einstellungen vor:

    1. Integrationssystemnutzer erstellen: Führen Sie die Aufgabe Integrationssystemnutzer erstellen aus, um ein dediziertes Konto zu erstellen, das Lakehouse zum Synchronisieren von Ressourcen verwendet.
    2. Zugriff auf Workday Data Lake für die ISU aktivieren:Gewähren Sie der ISU Zugriff auf Workday Data Lake. Wenden Sie sich an den Workday-Support, um diesen Zugriff zu aktivieren. Sie können diesen Schritt nicht selbst ausführen. Warten Sie, bis Workday den Zugriff in Ihrem Workday-Mandanten konfiguriert hat, bevor Sie fortfahren.
    3. API-Client für Integrationen registrieren:Führen Sie die Aufgabe API-Client für Integrationen registrieren aus.
    4. Client-ID und ‑Schlüssel speichern:Speichern Sie die OAuth-Client-ID und den ‑Schlüssel für den nächsten Schritt.
    5. Aktualisierungstoken ohne Ablaufdatum generieren:Verwenden Sie im API-Client für Integrationen die Option Aktualisierungstokens für Integrationen verwalten, um ein Aktualisierungstoken ohne Ablaufdatum für die ISU zu generieren.
    6. Aktualisierungstoken speichern:Speichern Sie das generierte Aktualisierungstoken für den nächsten Schritt.

  2. Erstellen Sie eine JSON-Datei mit dem Namen credentials.json und den gespeicherten Daten aus dem vorherigen Schritt:

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

    Ersetzen Sie Folgendes:

    • CLIENT_ID: Die OAuth-Client-ID aus Ihrem Workday API-Client für Integrationen.
    • CLIENT_SECRET: Der OAuth-Clientschlüssel aus Ihrem Workday API-Client für Integrationen.
    • REFRESH_TOKEN: Das nicht ablaufende Aktualisierungstoken, das für Ihre Workday-ISU generiert wurde.

  3. Konfigurieren Sie den regionalen Endpunkt für Secret Manager:

    Standardmäßig verwendet Secret Manager einen globalen Endpunkt. Um Verbindungsprobleme zu vermeiden und Latenz- und Datenübertragungskosten zu minimieren, sollten Sie Ihr Secret und Ihren Katalog in derselben Region erstellen. Führen Sie den folgenden Befehl aus, um den globalen Standardendpunkt mit einem regionalen Secret zu überschreiben:

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

    Ersetzen Sie Folgendes:

    • REGION: Die Google Cloud -Region, in der Sie Ihr Secret Manager-Secret speichern. Beispiel: us-east4.

  4. Laden Sie die Nutzlast in Secret Manager hoch:

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

  5. Löschen Sie die Datei credentials.json sicher, um zu verhindern, dass Anmeldedaten offengelegt werden.

    Ersetzen Sie Folgendes:

    • WORKDAY_SECRET_NAME: Ein eindeutiger Name für Ihr Workday-Secret im Secret Manager, z. B. workday-api-credentials oder workday-data-lake-secret.
    • REGION: Die Google Cloud Region, in der Sie das Secret erstellen, z. B. us-east4.
    • PROJECT_ID: Ihre Google Cloud Projekt-ID

Föderierten Katalog erstellen

Führen Sie den folgenden Befehl aus, um einen föderierten Katalog mit der gcloud-CLI zu erstellen:

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"

Ersetzen Sie Folgendes:

  • FEDERATED_CATALOG_NAME: Ein Name für Ihren föderierten Katalog im Lakehouse.
  • PROJECT_ID: Ihre Google Cloud Projekt-ID
  • REGION: Die Lakehouse-Region, in der Sie den föderierten Katalog erstellen, z. B. us-east4. Wählen Sie die Google Cloud-Region aus, die Ihrer Workday-Instanz am nächsten ist, um Latenz und Datenübertragungskosten zu minimieren. Diese Region muss mit der Region übereinstimmen, in der Sie Ihr Secret gespeichert haben.
  • WORKDAY_SECRET_NAME: Der Name Ihres Workday-Secrets im Secret Manager.
  • WORKDAY_BASE_URL: Die Basis-URL Ihrer Workday-Instanz. Beispiel: impl-services1.wd12.myworkday.com oder wd501.myworkday.com.
  • WORKDAY_TENANT: Der Name des Workday-Mandanten.
  • REFRESH_INTERVAL (optional): Gibt an, wie oft die Informationen des Katalogs aktualisiert werden sollen. Legen Sie diesen Wert als Dauer fest, z. B. 300s oder 5m. Bei kürzeren Intervallen werden Daten häufiger aktualisiert, was jedoch mehr API-Aufrufe erfordern kann. Längere Intervalle können weniger kosten, aber die abgefragten Daten spiegeln möglicherweise nicht Ihren aktuellen Datensatz wider. Wenn das Intervall nicht angegeben ist, wird standardmäßig ein Aktualisierungsintervall von 5 Minuten (300s) verwendet. Wenn Sie den Wert auf 0s festlegen, wird die Aktualisierung von Metadaten im Hintergrund deaktiviert.
  • NAMESPACE_FILTERS: Optional: Eine durch Kommas getrennte Liste der Namespaces, die zusammengeführt werden sollen, z. B. finance,hr. Wenn diese Option nicht angegeben wird, enthält Lakehouse alle Namespaces.

Authentifizierungseinrichtung abschließen

Nachdem Sie den Katalog erstellt haben, wird in Lakehouse ein eindeutiges Dienstkonto dafür bereitgestellt, das in der Ressourcenbeschreibung als biglake-service-account angegeben ist.

Sie müssen diesem Dienstkonto die Rolle „Secret Manager Secret Accessor“ (roles/secretmanager.secretAccessor) für das Secret zuweisen, das Sie zuvor erstellt haben. Es kann einige Minuten dauern, bis neue IAM-Richtlinien wirksam werden.

Console

  1. Rufen Sie in der Google Cloud Console Lakehouse auf.

    [Zu Lakehouse wechseln][5]

  2. Klicken Sie auf den Namen des föderierten Katalogs, den Sie für Workday erstellt haben.

  3. Klicken Sie auf der Seite Katalogdetails im Benachrichtigungsbanner auf Geheime Berechtigungen erteilen.

    Lakehouse gewährt dem bereitgestellten Dienstkonto die Rolle roles/secretmanager.secretAccessor für das Secret.

gcloud-CLI

  1. Gewähren Sie dem Dienstkonto des Katalogs die Berechtigung für den Zugriff auf das Secret:

    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. Führen Sie den folgenden Befehl aus, um zu prüfen, ob das Dienstkonto des föderierten Katalogs Zugriff auf das Secret hat:

    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"

    Prüfen Sie in der Ausgabe, ob das Dienstkonto biglake-service-account die Rolle roles/secretmanager.secretAccessor hat.

Ersetzen Sie Folgendes:

  • REGION: Die Google Cloud Region, in der Sie Ihr Secret Manager-Secret speichern und den föderierten Katalog erstellt haben, z. B. us-east4.
  • WORKDAY_SECRET_NAME: Der Name Ihres Workday-Secrets im Secret Manager.
  • PROJECT_ID: Ihre Google Cloud Projekt-ID
  • FEDERATED_CATALOG_NAME: Der Name Ihres föderierten Katalogs in Lakehouse.

Verbindung prüfen

Prüfen Sie, ob die Aktualisierung der Hintergrundmetadaten erfolgreich abgeschlossen wurde und Ihre Namespaces und Tabellen synchronisiert wurden.

  1. Prüfen Sie, ob der Aktualisierungsstatus „Erfolgreich“ lautet:

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

  2. Prüfen Sie, ob die Namespaces synchronisiert sind:

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

Ersetzen Sie Folgendes:

  • PROJECT_ID: Ihre Google Cloud Projekt-ID
  • FEDERATED_CATALOG_NAME: Der Name Ihres föderierten Katalogs in Lakehouse.

Nächste Schritte