Configurer le Lakehouse sans bordure pour AWS Glue

Ce document explique comment configurer un Lakehouse sans bordure pour 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 Apache Iceberg afin de 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. Pour comprendre son fonctionnement, consultez À propos du Lakehouse sans bordure.
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 celui de votre fournisseur de cloud à distance (AWS, par exemple), assurez-vous d'avoir un compte actif auprès de votre fournisseur à distance, provisionnez une interconnexion cross-cloud dédiée ou une interconnexion cross-cloud 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 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 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 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 API

Rôles requis

Pour obtenir les autorisations nécessaires pour configurer Lakehouse sans frontières, 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 (utilisateur) : Administrateur de réseaux Compute (roles/compute.networkAdmin)
• Acheminer le trafic via une interconnexion privée (compte de service du catalogue) :
  • Lecteur de l'Annuaire des services (roles/servicedirectory.viewer)
  • Service autorisé PSC de l'Annuaire des services (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 de Lakehouse sans bordure.

• Fournisseurs de services cloud compatibles : l'utilisation d'une interconnexion privée avec votre Lakehouse sans frontières est compatible avec les fournisseurs de services cloud distants suivants : Amazon Web Services (AWS). Vous pouvez utiliser une interconnexion Cross-Cloud dédiée ou une interconnexion Cross-Cloud partenaire.
• Routage réseau : si une interconnexion privée (telle que Dedicated CCI ou Partner CCI) n'est pas configurée, les requêtes sont acheminées sur l'Internet public. Cela peut entraîner des frais de sortie plus élevés de la part 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 de la part du fournisseur de catalogue à distance.
• Rapports de métriques Iceberg : Les rapports de 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 sans bordure, 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 l'espace réservé avec votre fournisseur distant. Créez ensuite un catalogue fédéré dans Lakehouse et mettez à jour la règle de confiance.
• 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 sans bordure.
• 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 dédié : connexion physique dédiée.
• Partner Cross-Cloud 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 (ENI) AWS. Ce flux est essentiel pour l'équilibrage de charge, l'évolutivité et la haute disponibilité. Il est obligatoire pour Partner CCI et recommandé pour Dedicated CCI 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 les CCI dédiées et n'est pas compatible avec les CCI partenaires.

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

gcloud compute networks subnets create PROXY_SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK \
    --range=PROXY_SUBNET_RANGE

Configurer la fédération

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

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 de confiance 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 : lakehouse_glue_federation_role.

Associer une règle d'autorisation

Associez une stratégie d'autorisations à votre rôle IAM pour permettre à Lakehouse d'accéder au Data Catalog Glue et aux buckets S3 de la région AWS. Cette règle 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:*"
         ]
       }
     ]
   }

   Si vous utilisez des clés gérées par le client hébergées dans AWS Key Management Service (KMS) pour chiffrer les ressources AWS Glue, Amazon S3 ou Amazon S3 Tables, vous devez ajouter une instruction accordant l'accès à la clé KMS pour déchiffrer les ressources :

   # ...
   {
     "Sid": "GlueS3S3TablesKmsDecrypt",
     "Effect": "Allow",
     "Action": [
         "kms:Decrypt"
     ],
     "Resource": [
         "arn:aws:kms:AWS_REGION:AWS_ACCOUNT_ID:key/key_id_for_glue",
         "arn:aws:kms:AWS_REGION:AWS_ACCOUNT_ID:key/key_id_for_s3",
         "arn:aws:kms:AWS_REGION:AWS_ACCOUNT_ID:key/key_id_for_s3_tables"
     ]
   }
   # ...

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 : lakehouse_glue_federation_role.
   • AWS_POLICY_NAME : nom de votre règle d'autorisation. Exemple :lakehouse_glue_federation_policy
   • 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 la console Google Cloud , de la CLIgcloud ou de l'API REST.

Pour éviter les échecs prématurés d'actualisation des métadonnées en arrière-plan pendant la propagation des relations de confiance 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 :lakehouse_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 :

   LAKEHOUSE_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 de confiance 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": [
               "$LAKEHOUSE_SA_ID"
             ],
             "accounts.google.com:sub": [
               "$LAKEHOUSE_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 des métadonnées 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 des métadonnées 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"
      }
    }
  }
}'

Configurer complètement l'interconnexion privée (interconnexion cross-cloud uniquement)

Si vous acheminez le trafic via une interconnexion privée (interconnexion dédiée ou partenaire), vous devez accorder au compte de service du catalogue Lakehouse les autorisations nécessaires pour découvrir et autoriser les connexions via Annuaire des services.

# Grant Service Directory Viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account)')" \
--role="roles/servicedirectory.viewer"

# Grant Service Directory PSC Authorized Service
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account)')" \
--role="roles/servicedirectory.pscAuthorizedService"

Vérifier la connexion

Vérifiez que le cycle d'actualisation des métadonnées d'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"

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

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

Étapes suivantes

• Utilisez des tables Lakehouse et des tables de requête sans bordure.
• Résoudre les problèmes liés aux lakehouses sans bordure