Configura la connessione cross-cloud per Workday Data Lake

Una connessione cross-cloud a Workday Data Lake ti consente di eseguire query sui dati di Workday direttamente all'interno di Google Cloud. Questa funzionalità unifica l'analisi dei dati integrando le origini dati esterne con l'ambienteGoogle Cloud esistente.

Dopo aver configurato la connessione, puoi gestire l'accesso ai dati federati in Lakehouse senza confini.

Casi d'uso

La connessione di Lakehouse a Workday Data Lake supporta diversi casi d'uso chiave:

  • Unifica l'analisi: correla i dati relativi alle risorse umane e ai compensi di Workday con i dati diGoogle Cloud , ad esempio per fornire il contesto per le vendite e le quote.
  • Sfrutta l'ecosistema Google Cloud: ad esempio, utilizza il framework degli agenti di Google con BigQuery ML e i dati delle risorse umane di Workday per prevedere la fidelizzazione dei dipendenti.
  • Trasmetti in streaming dati in tempo reale senza copia: analizza i dati di approvvigionamento e contabilità fornitori di Workday insieme ai dati di logistica e inventario archiviati inGoogle Cloud per segnalare le inefficienze della catena di fornitura e ottimizzare i costi dei fornitori.

Prima di iniziare

  1. Consulta la panoramica di Lakehouse per capire in che modo Lakehouse gestisce l'accesso ai dati.
  2. Leggi Informazioni sull'accesso ai dati cross-cloud per capire come funziona.
  3. Consulta i cataloghi supportati per verificare la compatibilità.
  4. Scopri come utilizzare i secret regionali di Secret Manager per l'autenticazione con Workday Data Lake.
  5. Contatta gli amministratori di Workday Data Lake per configurare l'autenticazione come descritto in questo documento. Gli amministratori potrebbero dover contattare l'assistenza di Workday per abilitare l'accesso a Data Lake, il che può richiedere del tempo.
  6. Accedi al tuo account Google Cloud . Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti senza costi per l'esecuzione, il test e il deployment dei workload.

  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.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per configurare l'accesso cross-cloud, chiedi all'amministratore di concederti i seguenti ruoli IAM nel progetto:

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Limitazioni e considerazioni

Questa sezione elenca le limitazioni e le considerazioni per l'accesso ai dati cross-cloud.

  • Sola lettura: i cataloghi federati in Lakehouse sono visualizzazioni di sola lettura del catalogo remoto. La manipolazione delle risorse (ad esempio la creazione, l'aggiornamento o l'eliminazione di risorse) non è supportata e deve essere eseguita direttamente nel catalogo remoto.
  • Aggiornamento dei dati: il flag --refresh-interval per un catalogo federato determina la frequenza con cui vengono sincronizzati i metadati. Il valore deve essere 0s (disattivato) o almeno 300s (5 minuti). L'aggiornamento dei metadati in background di un catalogo potrebbe richiedere più tempo se sono presenti più risorse di spazi dei nomi e tabelle. Se l'aggiornamento precedente supera il tempo previsto, l'aggiornamento corrente verrà saltato, ma l'aggiornamento successivo verrà pianificato nell'intervallo successivo. Le query utilizzano i metadati del catalogo sincronizzati più di recente, pertanto le modifiche apportate nel catalogo remoto, come nuove tabelle, aggiornamenti dello schema o dati di cui è stato eseguito il commit di recente, non sono visibili in Lakehouse fino al completamento del successivo aggiornamento dei metadati in background.
  • Memorizzazione nella cache di Lakehouse: la memorizzazione nella cache di Lakehouse viene attivata automaticamente per tutte le query cross-cloud per risparmiare sui costi di uscita archiviando i blocchi di dati localmente in Google Cloud. Le chiavi di crittografia gestite dal cliente (CMEK) non sono supportate per la memorizzazione nella cache; i dati memorizzati nella cache vengono criptati utilizzando Google-owned and Google-managed encryption keys. Se il vincolo della policy dell'organizzazione constraints/gcp.restrictNonCmekServices viene applicato a una tabella della query, la memorizzazione nella cache viene disattivata automaticamente per quella query. Per saperne di più, consulta Memorizzazione nella cache intelligente.
  • Residenza dei dati e conformità: la creazione di un catalogo o di una connessione federata in una regione Google Cloud archivia i dati memorizzati nella cache at-rest nella regione di destinazione. Se i tuoi dati cloud remoti si trovano in una giurisdizione diversa, assicurati che la memorizzazione nella cache tra regioni sia conforme ai requisiti di residenza dei dati e di conformità legale della tua organizzazione.

Workflow generale

Per accedere ai dati cross-cloud in Workday Data Lake, segui questi passaggi generali:

  1. Configura la federazione: configura l'autenticazione basata su secret e crea un catalogo federato in Lakehouse.
    1. In Workday, configura il data lake e le credenziali dell'API Workday.
    2. Crea un secret in Secret Manager con le tue credenziali API Workday.
    3. Crea un catalogo federato in Lakehouse e concedi al account di servizio del catalogo l'accesso al secret.
  2. Verifica la connessione: verifica che Lakehouse possa connettersi al catalogo remoto e sincronizzare i metadati.
  3. Esegui query sui dati: esegui query sui dati federati utilizzando BigQuery o Managed Service for Apache Spark. Per saperne di più, consulta Esegui query sui dati remoti.
  4. Configura le autorizzazioni: utilizza Identity and Access Management (IAM) per gestire chi può visualizzare ed eseguire query sui dati federati.

Configura la federazione

Per eseguire query sui dati, devi configurare un catalogo federato Lakehouse che si connetta al tuo Workday Data Lake remoto.

Configura l'autenticazione

La federazione richiede l'autenticazione al Workday Data Lake remoto utilizzando le credenziali archiviate in modo sicuro nei secret di Secret Manager regionali.

  1. In Workday, completa i seguenti passaggi:

    1. Configura il data lake.
    2. Registra il client API per il data lake (concessione del token di aggiornamento).
    3. Configura la sicurezza e le esportazioni delle tabelle nel data lake.

    Per istruzioni end-to-end su come completare questa procedura, consulta Inizia a utilizzare Workday Data Lake.

  2. Crea un file JSON denominato credentials.json con le credenziali del passaggio precedente:

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

    Sostituisci quanto segue:

    • CLIENT_ID: l'ID client OAuth del tuo client API Workday per le integrazioni.
    • CLIENT_SECRET: il client secret OAuth del tuo client API Workday per le integrazioni.
    • REFRESH_TOKEN: il token di aggiornamento senza scadenza generato per l'ISU Workday.

  3. Configura l'endpoint regionale per Secret Manager:

    Per impostazione predefinita, Secret Manager utilizza un endpoint globale. Per evitare problemi di connettività e ridurre al minimo la latenza e i costi di trasferimento dei dati, crea il secret e il catalogo nella stessa regione. Per eseguire l'override dell'endpoint globale predefinito con un secret regionale, esegui questo comando:

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

    Sostituisci quanto segue:

    • REGION: la regione Google Cloud in cui archivi il secret di Secret Manager. Ad esempio us-east4.

  4. Carica il payload in Secret Manager:

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

  5. Elimina in modo sicuro il file credentials.json per evitare la fuga di credenziali.

    Sostituisci quanto segue:

    • WORKDAY_SECRET_NAME: un nome univoco per il tuo secret Workday in Secret Manager, ad esempio workday-api-credentials o workday-data-lake-secret.
    • REGION: la regione Google Cloud in cui crei il secret, ad esempio us-east4.
    • PROJECT_ID: l'ID progetto Google Cloud .

Crea un catalogo federato

Crea il catalogo federato utilizzando la console Google Cloud o l'interfaccia a riga di comando gcloud:

Console

Per creare un catalogo federato, segui questi passaggi:

  1. Nella console Google Cloud , vai a Lakehouse.

    Vai a Lakehouse

  2. Fai clic su Crea catalogo e poi seleziona Catalogo federato.

    Viene visualizzata la pagina Crea catalogo federato.

  3. Nella sezione Configurazione catalogo:

    1. Nell'elenco Origine del catalogo federato, seleziona Workday (Data Lake).
    2. Nel campo Nome del catalogo (in Lakehouse), inserisci un nome per il catalogo.
    3. Nell'elenco Località dei dati, seleziona la regione in cui vuoi creare il catalogo federato, ad esempio us-east4. Deve corrispondere alla regione del secret di Secret Manager. Per ridurre al minimo la latenza e i costi di trasferimento dei dati, quando selezioni una regione:
      • Se la tua istanza Workday si trova su Amazon Web Services (AWS), seleziona la regioneGoogle Cloud più vicina alla tua regione AWS.
      • Se la tua istanza Workday si trova in Google Cloud, seleziona la stessa regione.
    4. Fai clic su Continua.

  4. Nella sezione Dettagli connessione:

    1. Nella sezione Dettagli catalogo remoto:
      • Nel campo URL di base Workday, inserisci l'URL di base della tua istanza Workday. Ad esempio, impl-services1.wd12.myworkday.com o wd501.myworkday.com.
      • Nel campo Tenant Workday, inserisci il nome del tenant Workday, ad esempio google_dp3.
    2. Nella sezione Metodo di autenticazione, nel campo Secret Manager Secret, inserisci il nome della risorsa del secret regionale. Utilizza il seguente formato: projects/PROJECT_ID/locations/REGION/secrets/WORKDAY_SECRET_NAME.
    3. Nella sezione Intervallo di aggiornamento, nel campo Intervallo di aggiornamento, inserisci la frequenza (in secondi) con cui aggiornare i metadati del catalogo (ad esempio, 300). Per disattivare l'aggiornamento in background, inserisci 0.

  5. Fai clic su Crea.

gcloud CLI

Per creare un catalogo federato utilizzando l'interfaccia a riga di comando gcloud, esegui questo comando:

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"

Sostituisci quanto segue:

  • FEDERATED_CATALOG_NAME: un nome per il tuo catalogo federato in Lakehouse.
  • PROJECT_ID: l'ID progetto Google Cloud .
  • REGION: la regione del lakehouse in cui crei il catalogo federato, ad esempio us-east4. Questa regione deve essere la stessa in cui hai archiviato il secret. Per ridurre al minimo la latenza e i costi di trasferimento dei dati, quando selezioni una regione:
    • Se la tua istanza Workday si trova su AWS, seleziona la regioneGoogle Cloud più vicina alla tua regione AWS.
    • Se la tua istanza Workday si trova in Google Cloud, seleziona esattamente la stessa regione.
  • WORKDAY_SECRET_NAME: il nome del secret di Workday in Secret Manager.
  • WORKDAY_BASE_URL: l'URL di base della tua istanza Workday. Ad esempio, impl-services1.wd12.myworkday.com o wd501.myworkday.com.
  • WORKDAY_TENANT: il nome del tenant Workday.
  • REFRESH_INTERVAL: (facoltativo) specifica la frequenza con cui aggiornare le informazioni del catalogo. Imposta questo valore come durata, ad esempio 300s o 5m. Intervalli più brevi aggiornano i dati più spesso, ma possono comportare costi maggiori per le chiamate API. Intervalli più lunghi possono costare meno, ma i dati su cui viene eseguita la query potrebbero non riflettere il set di dati più recente. Se omesso, l'intervallo di aggiornamento predefinito è di 5 minuti (300s). L'impostazione del valore su 0s disabilita l'aggiornamento dei metadati in background.
  • NAMESPACE_FILTERS: (Facoltativo) un elenco separato da virgole di spazi dei nomi da federare, ad esempio finance,hr. Se omesso, Lakehouse include tutti gli spazi dei nomi.

Completa la configurazione dell'autenticazione

Dopo aver creato il catalogo, Lakehouse esegue il provisioning di un account di servizio univoco, identificato come biglake-service-account nella descrizione della risorsa.

Devi concedere a questo account di servizio il ruolo Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) per il secret che hai creato in precedenza. L'applicazione delle nuove policy IAM potrebbe richiedere alcuni minuti.

Console

  1. Nella console Google Cloud , vai a Lakehouse.

    Vai a Lakehouse

  2. Fai clic sul nome del catalogo federato che hai creato per Workday.

  3. Nella pagina Dettagli catalogo, nel banner di avviso, fai clic su Concedi autorizzazioni secret.

    Lakehouse concede il ruolo roles/secretmanager.secretAccessor sul secret al account di servizio di cui è stato eseguito il provisioning.

gcloud CLI

  1. Concedi al account di servizio del catalogo l'autorizzazione per accedere al 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. Per verificare che l'account di servizio del catalogo federato abbia accesso al secret, esegui questo comando:

    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"

    Nell'output, verifica che il account di servizio biglake-service-account abbia il ruolo roles/secretmanager.secretAccessor.

Sostituisci quanto segue:

  • REGION: la regione Google Cloud in cui archivi il secret di Secret Manager e hai creato il catalogo federato, ad esempio us-east4.
  • WORKDAY_SECRET_NAME: il nome del secret di Workday in Secret Manager.
  • PROJECT_ID: l'ID progetto Google Cloud .
  • FEDERATED_CATALOG_NAME: il nome del tuo catalogo federato in Lakehouse.

Verificare la connessione

Verifica che l'aggiornamento dei metadati in background sia stato completato correttamente e che abbia sincronizzato gli spazi dei nomi e le tabelle.

  1. Verifica che lo stato di aggiornamento indichi l'esito positivo:

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

  2. Verifica che gli spazi dei nomi siano sincronizzati:

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

Sostituisci quanto segue:

  • PROJECT_ID: l'ID progetto Google Cloud .
  • FEDERATED_CATALOG_NAME: il nome del catalogo federato in Lakehouse.

Passaggi successivi