Una connessione cross-cloud a Workday Data Lake ti consente di eseguire query sui tuoi dati Workday direttamente in Google Cloud. Puoi quindi utilizzare Lakehouse per gestire l'accesso ai dati federati e analizzarli senza copiarli o spostarli.
Casi d'uso
Il collegamento di Lakehouse a Workday Data Lake supporta diversi casi d'uso chiave:
- Unifica l'analisi:correla i dati di Workday HR e di compensazione con i dati di Google Cloud , ad esempio per fornire il contesto per le vendite e le quote.
- Sfrutta l'ecosistema Google Cloud: ad esempio, utilizza il framework dell'agente di Google con BigQuery ML e i dati HR 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
- Consulta la panoramica di Lakehouse per capire come Lakehouse gestisce l'accesso ai dati.
- Leggi informazioni sull'accesso ai dati cross-cloud per capire come funziona.
- Consulta l'elenco dei cataloghi supportati per verificare la compatibilità.
- Scopri come utilizzare i secret regionali di Secret Manager per l'autenticazione con Workday Data Lake.
- Contatta gli amministratori di Workday Data Lake per configurare l'autenticazione come descritto in questo documento. Gli amministratori potrebbero dover contattare l'assistenza Workday per abilitare l'accesso a Data Lake, la cui risoluzione può richiedere tempo.
- 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 carichi di lavoro.
-
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.enablepermission. 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.-
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.enablepermission. 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.
Ruoli obbligatori
Per ottenere le autorizzazioni necessarie per configurare l'accesso cross-cloud, chiedi all'amministratore di concederti i seguenti ruoli IAM nel progetto:
-
Gestisci i cataloghi lakehouse:
BigLake Admin (
roles/biglake.admin) -
Gestisci i secret:
Secret Manager Admin (
roles/secretmanager.admin)
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.
Dettagli del catalogo supportati
Questo documento fornisce le istruzioni per configurare Lakehouse con Workday Data Lake. Per accedere ad altri cataloghi, vedi Cataloghi supportati.
Limitazioni e considerazioni
Tieni presente quanto segue quando accedi a un Workday Data Lake:
- Sola lettura:i cataloghi federati in Lakehouse sono visualizzazioni di sola lettura del catalogo remoto. Per creare, aggiornare o eliminare risorse, devi utilizzare direttamente Workday.
- Routing di rete:le connessioni e le query vengono instradate in modo sicuro sulla rete internet pubblica.
- Aggiornamento dei dati:il flag
--refresh-intervaldetermina la frequenza di sincronizzazione dei metadati da parte di Lakehouse. Il valore deve essere0s(disattivato) o almeno300s(5 minuti). Man mano che il numero di spazi dei nomi e tabelle in un catalogo aumenta, gli aggiornamenti dei metadati in background richiedono più tempo per essere completati. Se l'aggiornamento precedente supera l'intervallo pianificato, il sistema salta il ciclo corrente e riprende all'intervallo pianificato successivo. - Colocation: per evitare problemi di connettività e ridurre al minimo la latenza e i costi di trasferimento dei dati, crea il catalogo federato e il secret regionale nella regioneGoogle Cloud più vicina alla regione in cui si trova la tua istanza Workday.
Flusso di lavoro generale
Per accedere ai dati cross-cloud in Workday Data Lake, segui questi passaggi generali:
- Configura la federazione:configura l'autenticazione basata su secret e crea un catalogo federato in Lakehouse.
- In Workday, crea un utente del sistema di integrazione (ISU) e un client API per le integrazioni.
- Crea un secret in Secret Manager con le credenziali dell'API Workday.
- Crea un catalogo federato in Lakehouse e concedi al account di servizio del catalogo l'accesso al secret.
- Verifica la connessione: verifica che Lakehouse possa connettersi al catalogo remoto e sincronizzare i metadati.
- Esegui query sui dati:esegui query sui dati federati utilizzando BigQuery o Managed Service for Apache Spark. Per maggiori informazioni, consulta la sezione Eseguire query sui dati remoti.
- 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 connette al tuo Data Lake Workday remoto.
Configura l'autenticazione
La federazione richiede l'autenticazione a Workday Data Lake remoto utilizzando credenziali archiviate in modo sicuro nei secret regionali di Secret Manager.
In Workday, completa la seguente configurazione:
- Crea un utente di sistema di integrazione (ISU): esegui l'attività Crea utente di sistema di integrazione per creare un account dedicato che Lakehouse utilizza per sincronizzare le risorse.
- Abilita l'accesso a Workday Data Lake per l'ISU: concedi all'ISU l'accesso a Workday Data Lake. Contatta l'assistenza Workday per attivare questo accesso. Non puoi eseguire questo passaggio autonomamente; attendi che Workday configuri l'accesso nel tuo tenant Workday prima di continuare.
- Registra client API per le integrazioni:esegui l'attività Registra client API per le integrazioni.
- Salva l'ID client e il client secret:salva l'ID client OAuth e il client secret per il passaggio successivo.
- Genera un token di aggiornamento non scaduto:nel client API per le integrazioni, utilizza Gestisci token di aggiornamento per le integrazioni per generare un token di aggiornamento non scaduto per ISU.
- Salva il token di aggiornamento:salva il token di aggiornamento generato per il passaggio successivo.
Crea un file JSON denominato
credentials.jsoncon i dati salvati nel 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 client API Workday per le integrazioni.REFRESH_TOKEN: il token di aggiornamento senza scadenza generato per la tua ISU Workday.
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 Google Cloud regione in cui memorizzi il secret di Secret Manager. Ad esempious-east4.
Carica il payload in Secret Manager:
gcloud secrets create WORKDAY_SECRET_NAME \ --location="REGION" \ --project="PROJECT_ID" \ --data-file=credentials.json
Elimina in modo sicuro il file
credentials.jsonper evitare la divulgazione delle credenziali.Sostituisci quanto segue:
WORKDAY_SECRET_NAME: un nome univoco per il secret Workday in Secret Manager, ad esempioworkday-api-credentialsoworkday-data-lake-secret.REGION: la Google Cloud regione in cui creare il secret, ad esempious-east4.PROJECT_ID: l'ID progetto Google Cloud .
Crea un catalogo federato
Per creare un catalogo federato utilizzando la CLI 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 catalogo federato in Lakehouse.PROJECT_ID: l'ID progetto Google Cloud .REGION: la regione Lakehouse in cui creare il catalogo federato, ad esempious-east4. Per ridurre al minimo la latenza e i costi di trasferimento dei dati, seleziona la regione Google Cloud più vicina alla tua istanza di Workday. Questa regione deve essere la stessa in cui hai archiviato il secret.WORKDAY_SECRET_NAME: il nome del secret Workday in Secret Manager.WORKDAY_BASE_URL: l'URL di base della tua istanza Workday. Ad esempio,impl-services1.wd12.myworkday.comowd501.myworkday.com.WORKDAY_TENANT: Il nome del tenant Workday.REFRESH_INTERVAL: (facoltativo) specifica la frequenza di aggiornamento delle informazioni del catalogo. Imposta questo valore come durata, ad esempio300so5m. Intervalli più brevi aggiornano i dati più spesso, ma possono costare di più in chiamate API. Intervalli più lunghi possono costare meno, ma i dati interrogati potrebbero non riflettere il set di dati più recente. Se omesso, l'intervallo di aggiornamento è impostato per impostazione predefinita su 5 minuti (300s). L'impostazione del valore su0sdisabilita l'aggiornamento dei metadati in background.NAMESPACE_FILTERS: (facoltativo) un elenco separato da virgole di spazi dei nomi da federare, ad esempiofinance,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.
Potrebbero essere necessari alcuni minuti prima che le nuove policy IAM diventino effettive.
Console
Nella console Google Cloud , vai a Lakehouse.
Fai clic sul nome del catalogo federato che hai creato per Workday.
Nella pagina Dettagli catalogo, fai clic su Concedi autorizzazioni secret nel banner di avviso.
Lakehouse concede il ruolo
roles/secretmanager.secretAccessorsul secret alaccount di serviziot di cui è stato eseguito il provisioning.
gcloud CLI
Concedi all'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"
Per verificare che il account di servizio di 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-accountdisponga del ruoloroles/secretmanager.secretAccessor.
Sostituisci quanto segue:
REGION: la regione Google Cloud in cui memorizzi il secret di Secret Manager e hai creato il catalogo federato, ad esempious-east4.WORKDAY_SECRET_NAME: il nome del secret Workday in Secret Manager.PROJECT_ID: l'ID progetto Google Cloud .FEDERATED_CATALOG_NAME: il nome del catalogo federato in Lakehouse.
Verificare la connessione
Verifica che l'aggiornamento dei metadati in background sia stato completato correttamente e che gli spazi dei nomi e le tabelle siano stati sincronizzati.
Verifica che lo stato di aggiornamento indichi esito positivo:
gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \ --project="PROJECT_ID"
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.