Configura la lakehouse cross-cloud per AWS Glue

Questo documento descrive come configurare un lakehouse cross-cloud per Apache Iceberg per eseguire query sui dati di un catalogo AWS Glue direttamente all'interno di Google Cloud. Questa funzionalità unifica l'analisi dei dati integrando le origini dati esterne<0x0A]con l'ambiente Google Cloud esistente.

Successivamente, puoi utilizzare Lakehouse per gestire l'accesso ai tuoi dati federati.

Prima di iniziare

1. Consulta la panoramica di Lakehouse per capire come Lakehouse gestisce l'accesso ai dati.
2. Leggi Informazioni su Lakehouse cross-cloud per capire come funziona.
3. Esamina i cataloghi supportati per verificare i requisiti del formato della tabella e le configurazioni supportate.
4. Assicurati che l'amministratore AWS disponga delle autorizzazioni per creare ruoli IAM (Identity and Access Management) e configurare i criteri delle autorizzazioni.
5. (Facoltativo) Se prevedi di instradare le query su un interconnessione privata tra il tuo Google Cloud VPC e il VPC del tuo provider cloud remoto (ad esempio AWS), assicurati di avere un account attivo con il tuo provider remoto, esegui il provisioning di un'interconnessione cross-cloud o di un'Partner Interconnect, stabilisci sessioni BGP con router Cloud e verifica di disporre delle autorizzazioni IAM richieste in entrambi gli ambienti cloud.
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 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

Ruoli obbligatori

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

• Gestisci i cataloghi lakehouse: BigLake Admin (roles/biglake.admin)
• Instradare il traffico tramite l'interconnessione privata: Compute Network Admin (roles/compute.networkAdmin), Service Directory Viewer (roles/servicedirectory.viewer) e Service Directory PSC Authorized Service (roles/servicedirectory.pscAuthorizedService)

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'utilizzo di Lakehouse cross-cloud.

• Provider cloud supportati:l'utilizzo di un'interconnessione privata con il tuo cross-cloud Lakehouse è supportato con i seguenti provider cloud remoti: Amazon Web Services (AWS). Puoi utilizzare un'interconnessione cross-cloud o un'Partner Interconnect.
• Routing di rete:se non è configurata un'interconnessione privata (ad esempio CCI di proprietà del cliente o Partner Interconnect), le query vengono instradate su internet pubblico. Ciò potrebbe comportare tariffe di uscita più elevate dal tuo provider di servizi cloud remoto e prestazioni meno prevedibili.
• Aggiornamento dei dati:il flag --refresh-interval per il catalogo federato determina la frequenza di sincronizzazione dei metadati. Un intervallo più breve fornisce dati più aggiornati, ma potrebbe comportare costi API aggiuntivi da parte del fornitore del catalogo remoto.

• Report sulle metriche Iceberg: il report sulle metriche Iceberg non è disponibile per i cataloghi federati. Imposta la proprietà rest-metrics-reporting-enabled su false nel client Iceberg quando accedi a un catalogo federato.

Flusso di lavoro generale

Per configurare e utilizzare Lakehouse cross-cloud, segui questi passaggi generali:

• (Facoltativo) Configura Cross-Cloud Interconnect: configura una connessione privata tra il tuo VPC Google Cloud e il tuo provider di servizi cloud remoto.
• Configura la federazione:configura l'autenticazione creando un ruolo IAM con un criterio di attendibilità segnaposto con il tuo provider remoto. Poi, crea un catalogo federato in Lakehouse e aggiorna il criterio di attendibilità.
• Verifica la connessione:assicurati che Lakehouse possa connettersi correttamente al catalogo remoto.
• Esegui query sui dati:esegui query sui dati federati utilizzando BigQuery o Managed Service for Apache Spark. Per saperne di più, consulta Utilizzare il cross-cloud Lakehouse.
• Configura le autorizzazioni:utilizza IAM per gestire chi può visualizzare ed eseguire query sui dati federati.

Configura Cross-Cloud Interconnect (facoltativo)

Per impostazione predefinita, le query al catalogo remoto vengono inviate tramite la rete internet pubblica. Per migliorare la sicurezza e la conformità, fornire prestazioni prevedibili e ridurre i costi di trasferimento dei dati, utilizza un interconnessione privata. In questo modo viene stabilita una connessione di rete privata dedicata tra la tua Google Cloud Virtual Private Cloud (VPC) e la rete del tuo provider di servizi cloud remoto (ad esempio AWS).

Puoi eseguire il provisioning e configurare una delle seguenti opzioni di interconnessione privata tra il tuo Google Cloud VPC e il VPC del tuo provider di servizi cloud remoto (ad esempio AWS):

• Cross-Cloud Interconnect: una connessione fisica dedicata.
• Partner Interconnect: una connessione tramite un provider di servizi supportato.

Stabilisci sessioni BGP tra il tuo router Cloud in Google Cloud e il VPC del tuo fornitore di servizi cloud remoto per garantire lo scambio di route.

Per attivare le query private, devi configurare un percorso da Lakehouse al bucket di archiviazione remoto (ad esempio, un bucket AWS Amazon S3) tramite l'interconnessione privata. Esistono due flussi architetturali che puoi seguire per configurare questo routing:

• Routing del bilanciatore del carico di rete proxy interno regionale:questo flusso utilizza un bilanciatore del carico di rete proxy interno regionale per distribuire le richieste tra i gruppi di endpoint di rete (NEG) di connettività ibrida che puntano a più interfacce di rete elastiche (ENI) AWS. Questo flusso è essenziale per il bilanciamento del carico, la scalabilità e l'alta affidabilità. È obbligatorio per Partner Interconnect e consigliato per Cross-Cloud Interconnect per il bilanciamento del carico, la scalabilità e l'alta affidabilità.Google Cloud
• Routing diretto degli endpoint: questo flusso connette Service Directory direttamente a un singolo indirizzo IP dell'endpoint VPC di interfaccia AWS. Questo flusso funziona solo per Cross-Cloud Interconnect e non è supportato per Partner Interconnect.

Seleziona il flusso di configurazione che corrisponde ai requisiti dell'architettura:

Configura la federazione cross-cloud

Per eseguire query sui dati, configura un catalogo federato Lakehouse che si connette al catalogo AWS remoto.

Crea il ruolo AWS IAM con un criterio di trust segnaposto

Lakehouse esegue il provisioning di un ID account di servizio Google dopo la creazione del catalogo. Crea il ruolo IAM AWS con un criterio di attendibilità segnaposto.

1. Crea un file denominato 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. Esegui il comando AWS CLI per creare il ruolo con la policy di attendibilità segnaposto. Ti consigliamo di impostare la durata massima della sessione su 12 ore (43200 secondi) per evitare la scadenza delle credenziali durante i job a lunga esecuzione:

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

   Sostituisci quanto segue:

   • AWS_ROLE_NAME: un nome per il tuo ruolo AWS IAM. Ad esempio, biglake_glue_federation_role.

Allegare una policy delle autorizzazioni

Collega un criterio di autorizzazioni al tuo ruolo IAM che consenta a Lakehouse di accedere al Data Catalog Glue e ai bucket S3 della regione AWS. Questo criterio concede anche l'accesso ai bucket delle tabelle S3 se utilizzi l'integrazione di AWS Lake Formation S3 Tables. Se hai eseguito l'upgrade dalle autorizzazioni dati AWS Glue predefinite al modello AWS Lake Formation, potresti dover concedere autorizzazioni aggiuntive in Lake Formation.

1. Crea un file denominato permissions_policy.json con la seguente configurazione delle policy.

   {
     "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. Collega questa policy delle autorizzazioni al tuo ruolo IAM:

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

   Sostituisci quanto segue:

   • AWS_ROLE_NAME: il nome del tuo ruolo IAM AWS. Ad esempio, biglake_glue_federation_role.
   • AWS_POLICY_NAME: un nome per la policy delle autorizzazioni. Ad esempio, biglake_glue_permissions.
   • AWS_REGION: la regione AWS in cui si trovano il catalogo Glue o le tabelle S3. Ad esempio, us-east-1.
   • AWS_ACCOUNT_ID: la stringa dell'ID account AWS di 12 cifre. Ad esempio, 123456789012.

Crea un catalogo federato

Stabilisci il catalogo federato su Google Cloud utilizzando l'interfaccia a riga di comando gcloud o l'API REST.

Per evitare errori di sincronizzazione prematuri dei metadati durante la propagazione delle relazioni di trust AWS, inizializza il catalogo senza specificare una pianificazione dell'aggiornamento (che per impostazione predefinita è 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"'"
      }
    }
  }'

Sostituisci quanto segue:

• FEDERATED_CATALOG_NAME: un nome per il catalogo federato.
• PROJECT_ID: il tuo ID progetto Google Cloud .
• REGION: la regione Lakehouse in cui viene creato il catalogo federato. Ad esempio, us-east4.
• GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE: l'identificatore del catalogo del magazzino di destinazione. Per il Data Catalog Glue di una regione AWS, inserisci la stringa dell'ID account AWS di 12 cifre. Ad esempio, 123456789012. Per utilizzare un bucket della tabella S3 nella regione, inserisci AWS_ACCOUNT_ID:s3tablescatalog/S3_TABLE_BUCKET. Ad esempio: 123456789012:s3tablescatalog/my-table-bucket.
• AWS_ACCOUNT_ID: la stringa dell'ID account AWS di 12 cifre. Ad esempio, 123456789012.
• AWS_REGION: la regione AWS in cui si trova il bucket della tabella del catalogo Glue o di S3. Ad esempio, us-east-1.
• AWS_ROLE_NAME: il nome del ruolo IAM di AWS. Ad esempio, biglake_glue_federation_role.
• NAMESPACE: (facoltativo) lo spazio dei nomi di Service Directory che hai creato durante la configurazione dell'interconnessione privata.
• SERVICE_NAME: (facoltativo) il nome del servizio Service Directory che hai creato durante la configurazione dell'interconnessione privata.

Aggiorna la policy di attendibilità

Quando viene creato il catalogo, Lakehouse esegue il provisioning di un account di servizio univoco, che viene restituito come campo biglake-service-account-id nella risposta alla creazione del catalogo. Utilizzi questo account di servizio per stabilire la relazione di trust.

1. Esegui questo comando per estrarre il valore biglake-service-account-id in una variabile bash attiva:

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

2. Aggiorna il criterio di attendibilità del ruolo AWS IAM per sostituire il segnaposto con l'ID agente di servizio Google verificato. Il blocco della condizione convalida la corrispondenza sia di sub che di aud. Scrivi la policy in un file denominato 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. Applica la policy finalizzata al tuo ruolo AWS:

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

Attivare l'aggiornamento in background

Ora che le relazioni di trust sicure sono state stabilite correttamente su entrambe le piattaforme, aggiorna il catalogo per attivare l'aggiornamento in background (ogni 5 minuti o 300s o più).

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"
      }
    }
  }
}'

Verificare la connessione

Verifica che il ciclo di aggiornamento in background del catalogo sia stato completato correttamente e che gli spazi dei nomi siano sincronizzati.

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

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

2. Verifica che i database remoti vengano visualizzati come spazi dei nomi sincronizzati:

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

Passaggi successivi

• Utilizza Lakehouse cross-cloud ed esegui query sulle tabelle.
• Risolvi i problemi relativi a Lakehouse cross-cloud.