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. Diese Funktion vereinheitlicht Ihre Datenanalyse, indem Ihre externen Datenquellen in Ihre vorhandeneGoogle Cloud -Umgebung eingebunden werden.

Nachdem Sie die Verbindung eingerichtet haben, können Sie den Zugriff auf Ihre föderierten Daten in Borderless Lakehouse verwalten.

Anwendungsfälle

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

  • Analysen vereinheitlichen: Workday-Personal- und Vergütungsdaten mitGoogle Cloud -Daten korrelieren, um beispielsweise Kontext für Verkäufe und Kontingente bereitzustellen.
  • Google Cloud-Ökosystem nutzen: Sie können beispielsweise das Agenten-Framework von Google mit BigQuery ML und Workday-HR-Daten verwenden, um die Mitarbeiterbindung vorherzusagen.
  • Echtzeitdaten ohne Kopieren streamen: Analysieren Sie Workday-Beschaffungs- und Kreditorendaten zusammen mit Logistik- und Inventardaten, die inGoogle Cloud gespeichert sind, um Ineffizienzen in der Lieferkette zu melden und Lieferantenkosten zu optimieren.

Hinweis

  1. In der Lakehouse-Übersicht erfahren Sie, wie Lakehouse den Zugriff auf Daten verwaltet.
  2. Informationen zum Zugriff auf cloudübergreifende Daten
  3. Prüfen Sie die unterstützten Kataloge, um die Kompatibilität zu bestätigen.
  4. Informationen zur Verwendung von regionalen 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 Zugriff auf Data Lake zu aktivieren. Dies kann einige Zeit in Anspruch nehmen.
  6. Melden Sie sich in Ihrem Google Cloud -Konto an. Wenn Sie mit Google Cloudnoch nicht vertraut sind, erstellen Sie einfach 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, 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.

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.

Einschränkungen und Überlegungen

In diesem Abschnitt werden die Einschränkungen und Überlegungen für den Zugriff auf cloudübergreifende Daten aufgeführt.

  • Lesezugriff: Föderierte Kataloge in Lakehouse sind schreibgeschützte Ansichten des Remote-Katalogs. Ressourcenmanipulationen (z. B. Erstellen, Aktualisieren oder Löschen von Ressourcen) werden nicht unterstützt und müssen direkt im Remote-Katalog durchgeführt werden.
  • Datenaktualität: Das Flag --refresh-interval für einen föderierten Katalog bestimmt, wie oft Metadaten synchronisiert werden. Der Wert muss 0s (deaktiviert) oder mindestens 300s (5 Minuten) sein. Die Aktualisierung der Hintergrundmetadaten eines Katalogs kann länger dauern, je mehr Namespace- und Tabellenressourcen vorhanden sind. Wenn die vorherige Aktualisierung länger dauert, wird die aktuelle Aktualisierung übersprungen. Die nächste Aktualisierung wird jedoch für das folgende Intervall geplant. Bei Abfragen werden die zuletzt synchronisierten Katalogmetadaten verwendet. Änderungen im Remote-Katalog, z. B. neue Tabellen, Schemaaktualisierungen oder neu übernommene Daten, sind daher erst nach der nächsten Hintergrundaktualisierung der Metadaten in Lakehouse sichtbar.
  • Lakehouse-Caching: Lakehouse-Caching wird automatisch für alle cloudübergreifenden Abfragen aktiviert, um Kosten für ausgehenden Traffic zu sparen, indem Datenblöcke lokal in Google Cloudgespeichert werden. Kundenverwaltete Verschlüsselungsschlüssel (CMEK) werden für das Caching nicht unterstützt. Im Cache gespeicherte Daten werden mit Google-owned and Google-managed encryption keysverschlüsselt. Wenn die Einschränkung der Organisationsrichtlinie constraints/gcp.restrictNonCmekServices für eine Tabelle in der Abfrage erzwungen wird, wird das Caching für diese Abfrage automatisch deaktiviert. Weitere Informationen finden Sie unter Intelligentes Caching.
  • Datenstandort und Compliance: Wenn Sie einen föderierten Katalog oder eine föderierte Verbindung in einer Google Cloud -Region erstellen, werden im Cache gespeicherte Daten in dieser Zielregion gespeichert. Wenn sich Ihre Remote-Cloud-Daten in einer anderen Gerichtsbarkeit befinden, achten Sie darauf, dass das regionenübergreifende Caching den Anforderungen Ihrer Organisation an den Datenstandort und die Einhaltung regulatorischer Anforderungen entspricht.

Allgemeiner Workflow

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

  1. Föderation einrichten: Konfigurieren Sie die Secret-basierte Authentifizierung und erstellen Sie einen föderierten Katalog in Lakehouse.
    1. Richten Sie in Workday den Data Lake und die Workday API-Anmeldedaten ein.
    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 prüfen: Prüfen Sie, ob Lakehouse eine Verbindung zu Ihrem Remote-Katalog herstellen und Metadaten synchronisieren kann.
  3. Daten abfragen: Führen Sie Abfragen für Ihre föderierten Daten mit BigQuery oder Managed Service for Apache Spark aus. Weitere Informationen finden Sie unter Remote-Daten abfragen.
  4. Berechtigungen konfigurieren: Mit Identity and Access Management (IAM) können Sie festlegen, 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 eine Verbindung zu Ihrem Remote-Workday-Data Lake herstellt.

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. Führen Sie in Workday die folgenden Schritte aus:

    1. Richten Sie den Data Lake ein.
    2. API-Client für Data Lake registrieren (Aktualisierungstoken-Gewährung).
    3. Sicherheit und Tabellenexporte im Data Lake einrichten

    Eine vollständige Anleitung für diesen Vorgang finden Sie unter Erste Schritte mit Workday Data Lake.

  2. Erstellen Sie eine JSON-Datei mit dem Namen credentials.json und den Anmeldedaten 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 Ihren Workday-ISU generiert wurde.

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

    Secret Manager verwendet standardmäßig einen globalen Endpunkt. Um Verbindungsprobleme zu vermeiden und die Latenz und die Kosten für die Datenübertragung zu minimieren, erstellen Sie Ihr Secret und Ihren Katalog in derselben Region. 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 ein Datenleck zu verhindern.

    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

Erstellen Sie den föderierten Katalog mit der Google Cloud Console oder der gcloud CLI:

Console

So erstellen Sie einen föderierten Katalog:

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

    Zu Lakehouse

  2. Klicken Sie auf Katalog erstellen und wählen Sie dann Föderierter Katalog aus.

    Die Seite Föderierten Katalog erstellen wird angezeigt.

  3. Im Abschnitt Katalogkonfiguration:

    1. Wählen Sie in der Liste Föderierte Katalogquelle die Option Workday (Data Lake) aus.
    2. Geben Sie im Feld Katalogname (in Lakehouse) einen Namen für den Katalog ein.
    3. Wählen Sie in der Liste Speicherort der Daten die Region aus, in der Sie den föderierten Katalog erstellen möchten, z. B. us-east4. Sie muss mit der Region des Secret Manager-Secrets übereinstimmen. So minimieren Sie die Latenz und die Datenübertragungskosten bei der Auswahl einer Region:
      • Wenn sich Ihre Workday-Instanz in Amazon Web Services (AWS) befindet, wählen Sie dieGoogle Cloud -Region aus, die Ihrer AWS-Region am nächsten liegt.
      • Wenn sich Ihre Workday-Instanz in Google Cloudbefindet, wählen Sie genau dieselbe Region aus.
    4. Klicken Sie auf Weiter.

  4. Im Abschnitt Verbindungsdetails:

    1. Im Abschnitt Details zum Remote-Katalog:
      • Geben Sie im Feld Workday-Basis-URL die Basis-URL Ihrer Workday-Instanz ein. Beispiel: impl-services1.wd12.myworkday.comoder wd501.myworkday.com.
      • Geben Sie im Feld Workday-Mandant den Namen Ihres Workday-Mandanten ein, z. B. google_dp3.
    2. Geben Sie im Abschnitt Authentifizierungsmethode im Feld Secret Manager-Secret den Ressourcennamen Ihres regionalen Secrets ein. Verwenden Sie das folgende Format: projects/PROJECT_ID/locations/REGION/secrets/WORKDAY_SECRET_NAME.
    3. Geben Sie im Abschnitt Aktualisierungsintervall im Feld Aktualisierungsintervall ein, wie oft (in Sekunden) die Katalogmetadaten aktualisiert werden sollen (z. B. 300). Wenn Sie die Aktualisierung im Hintergrund deaktivieren möchten, geben Sie 0 ein.

  5. Klicken Sie auf Erstellen.

gcloud-CLI

Führen Sie den folgenden Befehl aus, um einen föderierten Katalog mit der gcloud-Befehlszeile 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 in Lakehouse.
  • PROJECT_ID: Ihre Google Cloud Projekt-ID
  • REGION: Die Lakehouse-Region, in der Sie den föderierten Katalog erstellen, z. B. us-east4. Diese Region muss mit der Region übereinstimmen, in der Sie Ihr Secret gespeichert haben. So minimieren Sie die Latenz und die Datenübertragungskosten bei der Auswahl einer Region:
    • Wenn sich Ihre Workday-Instanz in AWS befindet, wählen Sie dieGoogle Cloud -Region aus, die Ihrer AWS-Region am nächsten ist.
    • Wenn sich Ihre Workday-Instanz in Google Cloudbefindet, wählen Sie genau dieselbe Region aus.
  • 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 die Daten häufiger aktualisiert, aber es können mehr Kosten für API-Aufrufe anfallen. Längere Intervalle können weniger kosten, aber die abgefragten Daten spiegeln möglicherweise nicht Ihr aktuellstes Dataset wider. Wenn Sie nichts angeben, beträgt das Aktualisierungsintervall standardmäßig 5 Minuten (300s). Wenn Sie den Wert auf 0s festlegen, wird die Aktualisierung von Metadaten im Hintergrund deaktiviert.
  • NAMESPACE_FILTERS: Optional: Eine durch Kommas getrennte Liste von Namespaces, die föderiert werden sollen, z. B. finance,hr. Wenn Sie nichts angeben, enthält Lakehouse alle Namespaces.

Authentifizierungseinrichtung abschließen

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

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

  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 Secret-Berechtigungen gewähren.

    Lakehouse weist dem bereitgestellten Dienstkonto die Rolle roles/secretmanager.secretAccessor für das Secret zu.

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 für den föderierten Katalog 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 Hintergrundaktualisierung der Metadaten 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