Configurer un lakehouse multicloud pour AWS Glue

Ce document explique comment configurer un lakehouse multicloud pour Apache Iceberg afin d'interroger les données d'un catalogue AWS Glue directement dans Google Cloud. Cette fonctionnalité unifie vos analyses de données en intégrant vos sources de données externes à votre environnement Google Cloud existant.

Vous pourrez ensuite utiliser Lakehouse pour gérer l'accès à vos données fédérées.

Avant de commencer

1. Consultez la présentation de Lakehouse pour comprendre comment Lakehouse gère l'accès aux données.
2. Consultez À propos du Lakehouse multicloud pour comprendre son fonctionnement.
3. Consultez les catalogues acceptés pour vérifier les exigences concernant le format des tableaux et les configurations acceptées.
4. Assurez-vous que votre administrateur AWS est autorisé à créer des rôles IAM (Identity and Access Management) et à configurer des stratégies d'autorisation.
5. Facultatif : Si vous prévoyez de router les requêtes via une interconnexion privée entre votre VPC Google Cloud et le VPC de votre fournisseur de cloud distant (AWS, par exemple), assurez-vous d'avoir un compte actif auprès de votre fournisseur distant, provisionnez une interconnexion cross-cloud ou une interconnexion partenaire, établissez des sessions BGP avec votre Cloud Router et vérifiez que vous disposez des autorisations IAM requises dans les deux environnements cloud.
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.

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake API.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the API

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake API.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the API

Rôles requis

Pour obtenir les autorisations nécessaires pour configurer un lakehouse multicloud, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet :

• Gérer les catalogues Lakehouse : Administrateur BigLake (roles/biglake.admin)
• Router le trafic via une interconnexion privée : Administrateur de réseau Compute (roles/compute.networkAdmin), Lecteur Annuaire des services (roles/servicedirectory.viewer) et Service autorisé Annuaire des services PSC (roles/servicedirectory.pscAuthorizedService)

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 l'utilisation du Lakehouse multicloud.

• Fournisseurs de services cloud compatibles : l'utilisation d'une interconnexion privée avec votre Lakehouse multicloud est compatible avec les fournisseurs de services cloud distants suivants : Amazon Web Services (AWS). Vous pouvez utiliser une interconnexion multicloud ou une interconnexion partenaire.
• Routage réseau : si une interconnexion privée (telle qu'une CCI appartenant au client ou une interconnexion partenaire) n'est pas configurée, les requêtes sont routées sur l'Internet public. Cela peut entraîner des frais de sortie plus élevés de votre fournisseur de cloud à distance et des performances moins prévisibles.
• Fraîcheur des données : l'indicateur --refresh-interval du catalogue fédéré détermine la fréquence de synchronisation des métadonnées. Un intervalle plus court fournit des données plus récentes, mais peut entraîner des coûts d'API supplémentaires auprès du fournisseur de catalogue distant.

• Rapports sur les métriques Iceberg : les rapports sur les métriques Iceberg ne sont pas disponibles pour les catalogues fédérés. Définissez la propriété rest-metrics-reporting-enabled sur false dans votre client Iceberg lorsque vous accédez à un catalogue fédéré.

Workflow général

Pour configurer et utiliser Lakehouse multicloud, procédez comme suit :

• Configurer Cross-Cloud Interconnect (facultatif) : configurez une connexion privée entre votre Google Cloud VPC et votre fournisseur de cloud distant.
• Configurer la fédération : configurez l'authentification en créant un rôle IAM avec une stratégie d'approbation de substitution avec votre fournisseur distant. Créez ensuite un catalogue fédéré dans Lakehouse et mettez à jour la stratégie d'approbation.
• Vérifiez la connexion : assurez-vous que Lakehouse peut se connecter à votre catalogue distant.
• Interroger les 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 Utiliser un lakehouse multicloud.
• Configurer les autorisations : utilisez IAM pour gérer les utilisateurs autorisés à afficher et interroger les données fédérées.

Configurer interconnexion cross-cloud (facultatif)

Par défaut, les requêtes envoyées à votre catalogue distant transitent par l'Internet public. Pour améliorer la sécurité et la conformité, fournir des performances prévisibles et réduire les coûts de transfert de données, utilisez une interconnexion privée. Cela établit une connexion réseau privée dédiée entre votre cloud privé virtuel (VPC) Google Cloudet le réseau de votre fournisseur de services cloud distant (AWS, par exemple).

Vous pouvez provisionner et configurer l'une des options d'interconnexion privée suivantes entre votre VPC Google Cloud et celui de votre fournisseur de cloud à distance (AWS, par exemple) :

• Cross-Cloud Interconnect : connexion physique dédiée.
• Partner Interconnect : connexion via un fournisseur de services agréé.

Établissez des sessions BGP entre votre routeur Cloud Router dans Google Cloud et le VPC de votre fournisseur de services cloud à distance pour assurer l'échange de routes.

Pour activer les requêtes privées, vous devez configurer un chemin d'accès de Lakehouse à votre bucket de stockage à distance (par exemple, un bucket AWS Amazon S3) via votre interconnexion privée. Vous pouvez suivre deux flux d'architecture pour configurer ce routage :

• Routage de l'équilibreur de charge réseau proxy interne régional : ce flux utilise un équilibreur de charge réseau proxy interne régionalGoogle Cloud pour distribuer les requêtes entre les groupes de points de terminaison réseau (NEG) de connectivité hybride pointant vers plusieurs interfaces réseau Elastic AWS (ENI). Ce flux est essentiel pour l'équilibrage de charge, l'évolutivité et la haute disponibilité. Il est obligatoire pour Partner Interconnect et recommandé pour Cross-Cloud Interconnect pour l'équilibrage de charge, l'évolutivité et la haute disponibilité.
• Routage direct des points de terminaison : ce flux connecte l'annuaire des services directement à une seule adresse IP de point de terminaison VPC d'interface AWS. Ce flux ne fonctionne que pour interconnexion cross-cloud et n'est pas compatible avec interconnexion partenaire.

Sélectionnez le flux de configuration qui correspond aux exigences de votre architecture :

Configurer la fédération multicloud

Pour interroger vos données, configurez un catalogue fédéré Lakehouse qui se connecte à votre catalogue AWS à distance.

Créer le rôle AWS IAM avec une stratégie d'approbation de l'espace réservé

Lakehouse provisionne un ID de compte de service Google après la création du catalogue. Créez le rôle AWS IAM avec une stratégie d'approbation de l'espace réservé.

1. Créez un fichier nommé trust_policy.json :

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Federated": "accounts.google.com"
         },
         "Action": "sts:AssumeRoleWithWebIdentity",
         "Condition": {
           "StringEquals": {
             "accounts.google.com:aud": [
               "PLACEHOLDER_VALUE"
             ],
             "accounts.google.com:sub": [
               "PLACEHOLDER_VALUE"
             ]
           }
         }
       }
     ]
   }

2. Exécutez la commande AWS CLI pour créer le rôle avec la stratégie d'approbation du code de substitution. Nous vous recommandons de définir la durée maximale de la session sur 12 heures (43200 secondes) pour éviter l'expiration des identifiants lors des jobs de longue durée :

   aws iam create-role \
     --role-name AWS_ROLE_NAME \
     --assume-role-policy-document file://trust_policy.json \
     --max-session-duration 43200

   Remplacez les éléments suivants :

   • AWS_ROLE_NAME : nom de votre rôle AWS IAM. Exemple : biglake_glue_federation_role.

Associer une règle d'autorisation

Associez une stratégie d'autorisation à votre rôle IAM pour permettre à Lakehouse d'accéder au catalogue de données Glue et aux buckets S3 de la région AWS. Cette stratégie accorde également l'accès aux buckets de tables S3 si vous utilisez l'intégration des tables S3 AWS Lake Formation. Si vous avez migré des autorisations de données AWS Glue par défaut vers le modèle AWS Lake Formation, vous devrez peut-être accorder des autorisations supplémentaires dans Lake Formation.

1. Créez un fichier nommé permissions_policy.json avec la configuration de règle suivante.

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "GlueRead",
         "Effect": "Allow",
         "Action": [
           "glue:GetCatalog",
           "glue:GetDatabase",
           "glue:GetDatabases",
           "glue:GetTable",
           "glue:GetTables"
         ],
         "Resource": "arn:aws:glue:AWS_REGION:AWS_ACCOUNT_ID:*"
       },
       {
         "Sid": "S3Read",
         "Effect": "Allow",
         "Action": [
           "s3:ListBucket",
           "s3:GetObject"
         ],
         "Resource": [
           "arn:aws:s3:::*"
         ]
       },
       {
         "Sid": "S3TablesRead",
         "Effect": "Allow",
         "Action": [
           "s3tables:GetTableBucket",
           "s3tables:ListNamespaces",
           "s3tables:GetNamespace",
           "s3tables:ListTables",
           "s3tables:GetTable",
           "s3tables:GetTableMetadataLocation",
           "s3tables:GetTableData"
         ],
         "Resource": [
           "arn:aws:s3tables:AWS_REGION:AWS_ACCOUNT_ID:*"
         ]
       }
     ]
   }

2. Associez cette stratégie d'autorisation à votre rôle IAM :

   aws iam put-role-policy \
     --role-name AWS_ROLE_NAME \
     --policy-name AWS_POLICY_NAME \
     --policy-document file://permissions_policy.json

   Remplacez les éléments suivants :

   • AWS_ROLE_NAME : nom de votre rôle AWS IAM. Exemple : biglake_glue_federation_role.
   • AWS_POLICY_NAME : nom de votre règle d'autorisation. Exemple :biglake_glue_permissions
   • AWS_REGION : région AWS dans laquelle résident votre catalogue Glue ou vos tables S3. Exemple :us-east-1
   • AWS_ACCOUNT_ID : chaîne de 12 chiffres correspondant à votre ID de compte AWS. Exemple :123456789012

Créer un catalogue fédéré

Établissez le catalogue fédéré sur Google Cloud à l'aide de l'interface de ligne de commande gcloud ou de l'API REST.

Pour éviter les échecs de synchronisation prématurés des métadonnées pendant la propagation des relations d'approbation AWS, initialisez le catalogue sans spécifier de calendrier d'actualisation (qui est défini par défaut sur 0s).

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="glue" \
    --glue-warehouse="GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE" \
    --glue-aws-region="AWS_REGION" \
    --glue-aws-role-arn="arn:aws:iam::AWS_ACCOUNT_ID:role/AWS_ROLE_NAME"

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="glue" \
    --glue-warehouse="GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE" \
    --glue-aws-region="AWS_REGION" \
    --glue-aws-role-arn="arn:aws:iam::AWS_ACCOUNT_ID:role/AWS_ROLE_NAME" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/NAMESPACE/services/SERVICE_NAME"

curl -s -X POST \
  -H "x-goog-user-project: PROJECT_ID" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs?iceberg_catalog_id=FEDERATED_CATALOG_NAME&primary_location=REGION" \
  -d '{
    "catalog_type": "CATALOG_TYPE_FEDERATED",
    "storage_regions": ["'"REGION"'"],
    "federated_catalog_options": {
      "glue_catalog_info": {
        "warehouse": "'"GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE"'",
        "aws_region": "'"AWS_REGION"'",
        "aws_role_arn": "arn:aws:iam::'"AWS_ACCOUNT_ID"':role/'"AWS_ROLE_NAME"'"
      }
    }
  }'

Remplacez les éléments suivants :

• FEDERATED_CATALOG_NAME : nom de votre catalogue fédéré.
• PROJECT_ID : ID de votre projet Google Cloud .
• REGION : région Lakehouse dans laquelle le catalogue fédéré est créé. Exemple :us-east4
• GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE : identifiant de catalogue de votre entrepôt cible. Pour le Data Catalog Glue d'une région AWS, saisissez la chaîne de votre ID de compte AWS à 12 chiffres. Exemple : 123456789012. Pour utiliser un bucket de table S3 dans la région, saisissez AWS_ACCOUNT_ID:s3tablescatalog/S3_TABLE_BUCKET. Par exemple, 123456789012:s3tablescatalog/my-table-bucket.
• AWS_ACCOUNT_ID : chaîne de 12 chiffres correspondant à votre ID de compte AWS. Exemple :123456789012
• AWS_REGION : région AWS dans laquelle se trouve votre catalogue Glue ou votre bucket de table S3. Exemple :us-east-1
• AWS_ROLE_NAME : nom de votre rôle IAM AWS. Exemple :biglake_glue_federation_role
• NAMESPACE : (facultatif) espace de noms de l'Annuaire des services que vous avez créé lors de la configuration de l'interconnexion privée.
• SERVICE_NAME : (facultatif) nom du service Annuaire des services que vous avez créé lors de la configuration de l'interconnexion privée.

Mettre à jour la stratégie de confiance

Lorsque le catalogue est créé, Lakehouse provisionne un compte de service unique pour celui-ci, qui est renvoyé en tant que champ biglake-service-account-id dans la réponse de création du catalogue. Vous utiliserez ce compte de service pour établir la relation d'approbation.

1. Exécutez la commande suivante pour extraire la valeur biglake-service-account-id dans une variable bash active :

   BIGLAKE_SA_ID=$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
     --project="PROJECT_ID" \
     --format="value(biglake-service-account-id)")

2. Mettez à jour la stratégie d'approbation de votre rôle AWS IAM pour remplacer l'espace réservé par l'ID de votre agent de service Google validé. Le bloc de condition valide la correspondance sub et aud. Écrivez la stratégie dans un fichier nommé trust_policy_comprehensive.json :

   cat > trust_policy_comprehensive.json << EOF
   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Federated": "accounts.google.com"
         },
         "Action": "sts:AssumeRoleWithWebIdentity",
         "Condition": {
           "StringEquals": {
             "accounts.google.com:aud": [
               "$BIGLAKE_SA_ID"
             ],
             "accounts.google.com:sub": [
               "$BIGLAKE_SA_ID"
             ]
           }
         }
       }
     ]
   }
   EOF

3. Appliquez la stratégie finalisée à votre rôle AWS :

   aws iam update-assume-role-policy \
     --role-name AWS_ROLE_NAME \
     --policy-document file://trust_policy_comprehensive.json

Activer l'actualisation en arrière-plan

Maintenant que des relations d'approbation sécurisées ont été établies avec succès sur les deux plates-formes, mettez à jour votre catalogue pour activer l'actualisation en arrière-plan (toutes les cinq minutes ou 300s, ou plus).

gcloud alpha biglake iceberg catalogs update FEDERATED_CATALOG_NAME \
  --project="PROJECT_ID" \
  --refresh-interval="300s"

curl -s -X PATCH \
-H "x-goog-user-project: PROJECT_ID" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME?updateMask=federated_catalog_options.refresh_options.refresh_schedule" \
-d '{
  "federated_catalog_options": {
    "refresh_options": {
      "refresh_schedule": {
        "refresh_interval": "300s"
      }
    }
  }
}'

Vérifier la connexion

Vérifiez que le cycle d'actualisation en arrière-plan du catalogue s'est terminé correctement et que les espaces de noms sont synchronisés.

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" \
     --location="REGION"

2. Vérifiez que les bases de données distantes apparaissent comme des espaces de noms synchronisés :

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

Étapes suivantes

• Utilisez Lakehouse multicloud et interrogez des tables.
• Résoudre les problèmes liés au lakehouse multicloud