Configurer une connexion multicloud pour le lac de données Workday

Une connexion cross-cloud à Workday Data Lake vous permet d'interroger vos données Workday directement dans Google Cloud. Cette fonctionnalité unifie votre analyse de données en intégrant vos sources de données externes à votre environnementGoogle Cloud existant.

Une fois la connexion configurée, vous pouvez gérer l'accès à vos données fédérées dans un Lakehouse sans frontières.

Cas d'utilisation

La connexion de Lakehouse à Workday Data Lake permet de répondre à plusieurs cas d'utilisation clés :

  • Unifiez les analyses : mettez en corrélation les données Workday sur les RH et les rémunérations avec les donnéesGoogle Cloud , par exemple pour fournir un contexte aux ventes et aux quotas.
  • Exploiter l'écosystème Google Cloud : par exemple, utilisez le framework d'agent de Google avec BigQuery ML et les données RH Workday pour prédire la rétention des employés.
  • Diffuser des données en temps réel sans copie : analysez les données d'approvisionnement et de comptabilité fournisseurs de Workday, ainsi que les données de logistique et d'inventaire stockées dansGoogle Cloud pour signaler les inefficacités de la chaîne d'approvisionnement et optimiser les coûts des fournisseurs.

Avant de commencer

  1. Consultez la présentation de Lakehouse pour comprendre comment Lakehouse gère l'accès aux données.
  2. Découvrez comment accéder aux données cross-cloud.
  3. Consultez les catalogues compatibles pour vérifier la compatibilité.
  4. Découvrez comment utiliser des secrets Secret Manager régionaux pour vous authentifier auprès du lac de données Workday.
  5. Contactez vos administrateurs Workday Data Lake pour configurer l'authentification comme décrit dans ce document. Les administrateurs devront peut-être contacter l'assistance Workday pour activer l'accès au lac de données, ce qui peut prendre du temps.
  6. Connectez-vous à votre compte Google Cloud . Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits sans frais pour exécuter, tester et déployer des charges de travail.

  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.

Rôles requis

Pour obtenir les autorisations nécessaires pour configurer l'accès cross-cloud, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet :

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Limites et points à noter

Cette section liste les limites et les points à prendre en compte pour accéder aux données cross-cloud.

  • Lecture seule : les catalogues fédérés dans Lakehouse sont des vues en lecture seule du catalogue distant. La manipulation des ressources (par exemple, la création, la mise à jour ou la suppression de ressources) n'est pas possible et doit être effectuée directement dans le catalogue distant.
  • Fraîcheur des données : l'option --refresh-interval d'un catalogue fédéré détermine la fréquence de synchronisation des métadonnées. La valeur doit être 0s (désactivé) ou au moins 300s (5 minutes). L'actualisation des métadonnées en arrière-plan d'un catalogue peut prendre plus de temps s'il existe davantage de ressources d'espace de noms et de table. Si l'actualisation précédente dépasse le délai, l'actualisation actuelle sera ignorée, mais l'actualisation suivante sera planifiée à l'intervalle suivant. Les requêtes utilisent les métadonnées du catalogue synchronisées le plus récemment. Par conséquent, les modifications apportées au catalogue distant, telles que les nouvelles tables, les mises à jour de schéma ou les données récemment validées, ne sont pas visibles dans Lakehouse tant que l'actualisation des métadonnées en arrière-plan n'est pas terminée.
  • Mise en cache Lakehouse : la mise en cache Lakehouse est activée automatiquement pour toutes les requêtes cross-cloud afin de réduire les coûts de sortie en stockant les blocs de données localement dans Google Cloud. Les clés de chiffrement gérées par le client (CMEK) ne sont pas compatibles avec la mise en cache. Les données mises en cache sont chiffrées à l'aide de Google-owned and Google-managed encryption keys. Si la contrainte de règle d'administration constraints/gcp.restrictNonCmekServices est appliquée à une table de la requête, la mise en cache est automatiquement désactivée pour cette requête. Pour en savoir plus, consultez Mise en cache intelligente.
  • Résidence des données et conformité : la création d'un catalogue ou d'une connexion fédérés dans une région Google Cloud stocke les données mises en cache au repos dans cette région cible. Si vos données cloud distantes résident dans une autre juridiction, assurez-vous que la mise en cache interrégionale est conforme aux exigences de résidence des données et de conformité réglementaire de votre organisation.

Workflow général

Pour accéder aux données cross-cloud dans Workday Data Lake, procédez comme suit :

  1. Configurer la fédération : configurez l'authentification basée sur un secret et créez un catalogue fédéré dans Lakehouse.
    1. Dans Workday, configurez le lac de données et les identifiants de l'API Workday.
    2. Créez un secret dans Secret Manager avec vos identifiants d'API Workday.
    3. Créez un catalogue fédéré dans Lakehouse et accordez au compte de service du catalogue l'accès au secret.
  2. Vérifier la connexion : vérifiez que Lakehouse peut se connecter à votre catalogue distant et synchroniser les métadonnées.
  3. Interroger des données : exécutez des requêtes sur vos données fédérées à l'aide de BigQuery ou de Managed Service pour Apache Spark. Pour en savoir plus, consultez Interroger des données distantes.
  4. Configurer les autorisations : utilisez Identity and Access Management (IAM) pour gérer les utilisateurs autorisés à afficher et à interroger les données fédérées.

Configurer la fédération

Pour interroger vos données, vous devez configurer un catalogue fédéré Lakehouse qui se connecte à votre lac de données Workday distant.

Configurer l'authentification

La fédération nécessite une authentification auprès du lac de données Workday distant à l'aide d'identifiants stockés de manière sécurisée dans des secrets régionaux Secret Manager.

  1. Dans Workday, procédez comme suit :

    1. Configurer le lac de données.
    2. Enregistrez le client API pour le lac de données (octroi de jeton d'actualisation).
    3. Configurez la sécurité et les exportations de tables dans le lac de données.

    Pour obtenir des instructions détaillées sur cette procédure, consultez Premiers pas avec Workday Data Lake.

  2. Créez un fichier JSON nommé credentials.json avec les identifiants de l'étape précédente :

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

    Remplacez les éléments suivants :

    • CLIENT_ID : ID client OAuth de votre client API Workday pour les intégrations.
    • CLIENT_SECRET : code secret du client OAuth de votre client API Workday pour les intégrations.
    • REFRESH_TOKEN : jeton d'actualisation sans expiration généré pour votre ISU Workday.

  3. Configurez le point de terminaison régional pour Secret Manager :

    Par défaut, Secret Manager utilise un point de terminaison global. Pour éviter les problèmes de connectivité et minimiser la latence et les coûts de transfert de données, créez votre secret et votre catalogue dans la même région. Pour remplacer le point de terminaison global par défaut par un secret régional, exécutez la commande suivante :

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

    Remplacez les éléments suivants :

    • REGION : région Google Cloud dans laquelle vous stockez votre secret Secret Manager. Exemple : us-east4.

  4. Importez la charge utile dans Secret Manager :

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

  5. Supprimez de manière sécurisée le fichier credentials.json pour éviter toute fuite d'identifiants.

    Remplacez les éléments suivants :

    • WORKDAY_SECRET_NAME : nom unique de votre secret Workday dans Secret Manager, par exemple workday-api-credentials ou workday-data-lake-secret.
    • REGION : région Google Cloud dans laquelle vous créez le secret, par exemple us-east4.
    • PROJECT_ID : ID de votre projet Google Cloud .

Créer un catalogue fédéré

Créez le catalogue fédéré à l'aide de la console Google Cloud ou de la CLI gcloud :

Console

Pour créer un catalogue fédéré, procédez comme suit :

  1. Dans la console Google Cloud , accédez à Lakehouse.

    Accéder à Lakehouse

  2. Cliquez sur Créer un catalogue, puis sélectionnez Catalogue fédéré.

    La page Créer un catalogue fédéré s'affiche.

  3. Dans la section Configuration du catalogue :

    1. Dans la liste Source du catalogue fédéré, sélectionnez Workday (lac de données).
    2. Dans le champ Nom du catalogue (dans Lakehouse), saisissez un nom pour le catalogue.
    3. Dans la liste Emplacement des données, sélectionnez la région dans laquelle vous souhaitez créer le catalogue fédéré, par exemple us-east4. Celle-ci doit correspondre à la région de votre secret Secret Manager. Pour réduire la latence et les coûts de transfert de données, procédez comme suit lorsque vous sélectionnez une région :
      • Si votre instance Workday se trouve sur Amazon Web Services (AWS), sélectionnez laGoogle Cloud région la plus proche de votre région AWS.
      • Si votre instance Workday se trouve dans Google Cloud, sélectionnez exactement la même région.
    4. Cliquez sur Continuer.

  4. Dans la section Détails de connexion :

    1. Dans la section Détails du catalogue distant :
      • Dans le champ URL de base Workday, saisissez l'URL de base de votre instance Workday. Par exemple, impl-services1.wd12.myworkday.com ou wd501.myworkday.com.
      • Dans le champ Locataire Workday, saisissez le nom de votre locataire Workday, par exemple google_dp3.
    2. Dans la section Méthode d'authentification, dans le champ Secret Secret Manager, saisissez le nom de ressource de votre secret régional. Utilisez le format suivant : projects/PROJECT_ID/locations/REGION/secrets/WORKDAY_SECRET_NAME.
    3. Dans la section Intervalle d'actualisation, dans le champ Intervalle d'actualisation, saisissez la fréquence (en secondes) de mise à jour des métadonnées du catalogue (par exemple, 300). Pour désactiver l'actualisation en arrière-plan, saisissez 0.

  5. Cliquez sur Créer.

gcloud CLI

Pour créer un catalogue fédéré à l'aide de la CLI gcloud, exécutez la commande suivante :

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"

Remplacez les éléments suivants :

  • FEDERATED_CATALOG_NAME : nom de votre catalogue fédéré dans Lakehouse.
  • PROJECT_ID : ID de votre projet Google Cloud .
  • REGION : région Lakehouse dans laquelle vous créez le catalogue fédéré, par exemple us-east4. Cette région doit être la même que celle où vous avez stocké votre secret. Pour réduire la latence et les coûts de transfert de données, procédez comme suit lorsque vous sélectionnez une région :
    • Si votre instance Workday se trouve sur AWS, sélectionnez la régionGoogle Cloud la plus proche de votre région AWS.
    • Si votre instance Workday se trouve sur Google Cloud, sélectionnez exactement la même région.
  • WORKDAY_SECRET_NAME : nom de votre secret Workday dans Secret Manager.
  • WORKDAY_BASE_URL : URL de base de votre instance Workday. Par exemple, impl-services1.wd12.myworkday.com ou wd501.myworkday.com.
  • WORKDAY_TENANT : nom du locataire Workday.
  • REFRESH_INTERVAL : (facultatif) spécifie la fréquence de mise à jour des informations du catalogue. Définissez cette valeur en tant que durée, par exemple 300s ou 5m. Des intervalles plus courts permettent de mettre à jour les données plus souvent, mais peuvent augmenter le coût des appels d'API. Des intervalles plus longs peuvent coûter moins cher, mais les données interrogées peuvent ne pas refléter votre ensemble de données le plus récent. Si cette option est omise, l'intervalle d'actualisation est défini par défaut sur cinq minutes (300s). Définir la valeur sur 0s désactive l'actualisation des métadonnées en arrière-plan.
  • NAMESPACE_FILTERS (facultatif) : liste de noms d'espaces de noms à fédérer, séparés par une virgule, par exemple finance,hr. Si cette option est omise, Lakehouse inclut tous les espaces de noms.

Terminer la configuration de l'authentification

Une fois le catalogue créé, Lakehouse provisionne un compte de service unique pour celui-ci, identifié par biglake-service-account dans la description de la ressource.

Vous devez attribuer à ce compte de service le rôle d'Accesseur de secrets Secret Manager (roles/secretmanager.secretAccessor) sur le secret que vous avez créé précédemment. La prise en compte des nouvelles stratégies IAM peut prendre quelques minutes.

Console

  1. Dans la console Google Cloud , accédez à Lakehouse.

    Accéder à Lakehouse

  2. Cliquez sur le nom du catalogue fédéré que vous avez créé pour Workday.

  3. Sur la page Détails du catalogue, dans la bannière d'alerte, cliquez sur Accorder des autorisations de secret.

    Lakehouse attribue le rôle roles/secretmanager.secretAccessor sur le secret au compte de service provisionné.

gcloud CLI

  1. Accordez au compte de service du catalogue l'autorisation d'accéder au 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. Pour vérifier que le compte de service du catalogue fédéré a accès au secret, exécutez la commande suivante :

    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"

    Dans le résultat, vérifiez que le compte de service biglake-service-account dispose du rôle roles/secretmanager.secretAccessor.

Remplacez les éléments suivants :

  • REGION : région Google Cloud dans laquelle vous stockez votre secret Secret Manager et avez créé le catalogue fédéré, par exemple us-east4.
  • WORKDAY_SECRET_NAME : nom de votre secret Workday dans Secret Manager.
  • PROJECT_ID : ID de votre projet Google Cloud .
  • FEDERATED_CATALOG_NAME : nom de votre catalogue fédéré dans Lakehouse.

Vérifier la connexion

Vérifiez que l'actualisation des métadonnées en arrière-plan s'est terminée correctement et qu'elle a synchronisé vos espaces de noms et vos tables.

  1. Vérifiez que l'état de l'actualisation indique que l'opération a réussi :

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

  2. Vérifiez que les espaces de noms sont synchronisés :

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

Remplacez les éléments suivants :

  • PROJECT_ID : ID de votre projet Google Cloud .
  • FEDERATED_CATALOG_NAME : nom de votre catalogue fédéré dans Lakehouse.

Étapes suivantes