Configurar a conexão entre nuvens para o AWS Glue

Visualizar

Este recurso está sujeito aos Termos das Soluções Pré-GA na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Observação :para receber suporte durante o pré-lançamento, envie um e-mail para [e-mail].

Uma conexão entre nuvens com um Data Catalog do AWS Glue permite consultar dados desse Data Catalog diretamente no Google Cloud. Esse recurso unifica sua análise de dados integrando suas fontes de dados externas ao ambiente Google Cloud atual.

Depois de configurar a conexão, você pode gerenciar o acesso aos dados federados no Lakehouse sem fronteiras.

Antes de começar

1. Leia a visão geral do Lakehouse para entender como ele gerencia o acesso aos dados.
2. Leia sobre como acessar dados entre nuvens para entender como isso funciona.
3. Consulte os catálogos compatíveis para verificar as configurações aceitas.
4. Opcional: se você planeja rotear consultas por uma interconexão privada entre sua VPC do Google Cloud e a VPC do provedor de nuvem remoto (por exemplo, AWS), verifique se você tem uma conta ativa com seu provedor remoto, provisione um Cross-Cloud Interconnect dedicado ou Cross-Cloud Interconnect por parceiro, estabeleça sessões do BGP com o Cloud Router e verifique se você tem as permissões do IAM necessárias nos dois ambientes de nuvem.
Faça login na sua conta do Google Cloud . Se você começou a usar o Google Cloudagora, crie uma conta para avaliar o desempenho dos nossos produtos em situações reais. Clientes novos também recebem US $300 em créditos para executar, testar e implantar cargas de trabalho sem custos financeiros.

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake API, if it is 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 API

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake API, if it is 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 API

Funções exigidas

Para receber as permissões necessárias para configurar o Lakehouse para acesso a dados entre nuvens, peça ao administrador para conceder a você os seguintes papéis do IAM no seu projeto:

• Gerenciar catálogos do Lakehouse: Administrador do BigLake (roles/biglake.admin)
• Rotear o tráfego pela interconexão particular (usuário): Administrador de rede do Compute (roles/compute.networkAdmin)
• Encaminhar o tráfego pela interconexão particular (conta de serviço do catálogo):
  • Leitor do Diretório de Serviços (roles/servicedirectory.viewer)
  • Serviço autorizado do PSC do Diretório de Serviços (roles/servicedirectory.pscAuthorizedService)

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias usando papéis personalizados ou outros papéis predefinidos.

Limitações e considerações

Nesta seção, listamos as limitações e considerações para acessar dados entre nuvens.

• Provedores de nuvem Interconexão entre nuvens Interconnect:o uso de uma interconexão particular para acessar dados entre nuvens é compatível com os seguintes provedores de nuvem remotos: Amazon Web Services (AWS). Você pode usar um Cross-Cloud Interconnect dedicado ou um Cross-Cloud Interconnect por parceiro.
• Roteamento de rede:se uma interconexão particular (como CCI dedicada ou CCI de parceiro) não estiver configurada, as consultas serão roteadas pela Internet pública. Isso pode resultar em taxas de saída mais altas do provedor de nuvem remoto e em um desempenho menos previsível.
• Somente leitura:os catálogos federados no Lakehouse são visualizações somente leitura do catálogo remoto. A manipulação de recursos (como criar, atualizar ou excluir recursos) não é compatível e precisa ser realizada diretamente no catálogo remoto.
• Atualização de dados:a flag --refresh-interval de um catálogo federado determina a frequência com que os metadados são sincronizados. O valor precisa ser 0s (desativado) ou pelo menos 300s (5 minutos). A atualização de metadados em segundo plano de um catálogo pode levar mais tempo quanto mais recursos de namespace e tabela houver. Se a atualização anterior exceder o tempo, a atual será ignorada, mas a próxima será programada para o intervalo seguinte. As consultas usam os metadados do catálogo sincronizados mais recentemente. Portanto, as alterações feitas no catálogo remoto, como novas tabelas, atualizações de esquema ou dados recém-confirmados, não ficam visíveis no Lakehouse até que a próxima atualização de metadados em segundo plano seja concluída.
• Armazenamento em cache do Lakehouse:o armazenamento em cache do Lakehouse é ativado automaticamente para todas as consultas entre nuvens para economizar custos de saída armazenando blocos de dados localmente no Google Cloud. As chaves de criptografia gerenciadas pelo cliente (CMEK) não são compatíveis com o armazenamento em cache. Os dados armazenados em cache são criptografados usando Google-owned and Google-managed encryption keys. Se a restrição da política da organização constraints/gcp.restrictNonCmekServices for aplicada a qualquer tabela na consulta, o armazenamento em cache será desativado automaticamente para essa consulta. Para mais informações, consulte Armazenamento em cache inteligente.
• Residência de dados e compliance:criar um catálogo ou uma conexão federada em uma região do Google Cloud armazena dados em cache em repouso nessa região de destino. Se os dados remotos na nuvem estiverem em uma jurisdição diferente, verifique se o armazenamento em cache entre regiões está em conformidade com os requisitos de residência de dados e conformidade regulatória da sua organização.

Fluxo de trabalho geral

Para acessar dados entre nuvens, siga estas etapas gerais:

• Configurar o Cross-Cloud Interconnect (opcional): configure uma conexão particular entre sua VPC do Google Cloud e seu provedor de nuvem remoto.
• Configurar a federação:configure a autenticação criando um papel do IAM com uma política de confiança de marcador de posição com seu provedor remoto. Em seguida, crie um catálogo federado no Lakehouse e atualize a política de confiança.
• Verifique a conexão:verifique se o Lakehouse pode se conectar ao catálogo remoto.
• Consultar dados:execute consultas nos dados federados usando o BigQuery ou o Serviço Gerenciado para Apache Spark. O armazenamento em cache do Lakehouse é ativado automaticamente para consultas para economizar custos de saída. Para mais informações, consulte Consultar dados remotos.
• Configurar permissões:use o IAM para gerenciar quem pode visualizar e consultar os dados federados.

Configurar o Interconexão entre nuvens (opcional)

Por padrão, as consultas ao catálogo remoto são transmitidas pela Internet pública. Para ajudar a melhorar a segurança e a conformidade, fornecer desempenho previsível e reduzir os custos de transferência de dados, use uma interconexão particular. Isso estabelece uma conexão de rede privada dedicada entre sua nuvem privada virtual (VPC) do Google Cloud e a rede do provedor de nuvem remoto (por exemplo, AWS).

É possível provisionar e configurar uma das seguintes opções de interconexão privada entre sua VPC do Google Cloud e a VPC do provedor de nuvem remoto (por exemplo, AWS):

• Cross-Cloud Interconnect dedicado: uma conexão física dedicada.
• Cross-Cloud Interconnect por parceiro: uma conexão por um provedor de serviços compatível.

Estabeleça sessões do BGP entre o Cloud Router em Google Cloud e a VPC do provedor de nuvem remoto para garantir a troca de rotas.

Para ativar a consulta particular, configure um caminho do Lakehouse para o bucket de armazenamento remoto (por exemplo, um bucket do AWS Amazon S3) usando a interconexão particular. Há dois fluxos de arquitetura que você pode seguir para configurar esse roteamento:

• Roteamento do balanceador de carga de rede de proxy regional interno:esse fluxo usa um balanceador de carga de rede de proxy regional internoGoogle Cloud para distribuir solicitações entre grupos de endpoints de rede (NEGs) de conectividade híbrida que apontam para várias interfaces de rede elástica (ENIs) da AWS. Esse fluxo é essencial para balanceamento de carga, escalonabilidade e alta disponibilidade. Ele é obrigatório para o CCI por parceiro e recomendado para o CCI dedicado para balanceamento de carga, escalonabilidade e alta disponibilidade.
• Roteamento de endpoint direto:esse fluxo conecta o Diretório de Serviços diretamente a um único endereço IP de endpoint de VPC de interface da AWS. Esse fluxo só funciona para CCI dedicada e não é compatível com CCI de parceiro.

Selecione o fluxo de configuração que corresponde aos requisitos da sua arquitetura:

Balanceador de carga de rede de proxy interno regional

Para configurar um balanceador de carga de rede de proxy regional interno para distribuir solicitações em várias ENIs da AWS para alta disponibilidade e balanceamento de carga, siga estas etapas:

Configurar a rede da AWS

Primeiro, crie um endpoint de interface de VPC do Amazon S3 (AWS PrivateLink):

1. No console da VPC da AWS, crie um endpoint de interface para o Amazon S3.
2. Em nome do serviço, especifique com.amazonaws.AWS_REGION.s3.
3. Selecione a VPC e as sub-redes conectadas por meio do Direct Connect à sua VPC do Google Cloud .
4. Anexe grupos de segurança ao endpoint para controlar o acesso de entrada.
5. Isso provisiona interfaces de rede elásticas (ENIs, na sigla em inglês) em cada sub-rede selecionada. Anote os endereços IP particulares dessas ENIs.

Em seguida, configure os grupos de segurança:

• Verifique se os grupos de segurança anexados às ENIs do endpoint do Amazon S3 permitem o tráfego TCP de entrada na porta 443 da VPC do Google Cloud . Isso precisa incluir o intervalo CIDR da sua Google Cloud sub-rede somente proxy para permitir verificações de integridade e tráfego encaminhado.

Configurar a rede do Google Cloud

Importante: é preciso implantar todos os Google Cloud recursos nesta seção (verificação de integridade, NEGs híbridos, serviço de back-end e balanceador de carga) na mesma região em que o anexo da VLAN do Interconexão entre nuvens está localizado. Se estiverem em regiões diferentes, o tráfego não será roteado para o armazenamento remoto.

Para simplificar a configuração, execute os comandos a seguir para configurar o balanceador de carga interno. Para configurações avançadas ou mais detalhes, consulte Configurar um balanceador de carga de rede de proxy regional interno para endpoints híbridos.

Observação :antes de começar, verifique se você tem uma sub-rede somente proxy configurada na rede VPC na região. Se você não tiver uma, execute o seguinte comando para criá-la:

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

Substitua:

• PROXY_SUBNET_NAME: um nome para a sub-rede somente proxy.
• PROXY_SUBNET_RANGE: um intervalo CIDR não utilizado na rede VPC (por exemplo, 10.129.0.0/23).

Importante: o Cloud Router não divulga automaticamente sub-redes somente proxy usando o BGP. É preciso configurar manualmente o Cloud Router para anunciar o intervalo CIDR da sub-rede somente proxy para sua rede remota (por exemplo, AWS) usando anúncios de rota personalizados. Isso garante que o tráfego de resposta do armazenamento remoto possa ser roteado de volta para o balanceador de carga.

1. Criar uma verificação de integridade regional:

   gcloud compute health-checks create tcp HEALTH_CHECK_NAME \
       --region=REGION \
       --port=443

   Substitua:

   • HEALTH_CHECK_NAME: um nome para a verificação de integridade.
   • REGION: a região do Google Cloud (por exemplo, us-east4).

2. Crie grupos de endpoints de rede (NEGs) de conectividade híbrida e adicione endpoints:

   Crie um NEG híbrido (NON_GCP_PRIVATE_IP_PORT) para cada zona:

   gcloud compute network-endpoint-groups create NEG_NAME \
       --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
       --zone=ZONE \
       --network=VPC_NETWORK

   Adicione o endereço IP particular da ENI da AWS ao NEG híbrido correspondente:

   gcloud compute network-endpoint-groups update NEG_NAME \
       --zone=ZONE \
       --add-endpoint="ip=AWS_S3_IP,port=443"

   Substitua:

   • NEG_NAME: um nome para o NEG híbrido.
   • ZONE: a zona do Google Cloud (por exemplo, us-east4-a). Essa zona precisa estar na região do anexo da VLAN do Interconexão entre nuvens.
   • VPC_NETWORK: o nome da sua rede VPC.
   • AWS_S3_IP: o endereço IP particular do endpoint de VPC (ENI) do Amazon S3 da AWS nessa zona.

   Repita esses comandos para criar NEGs e adicionar endpoints para outras zonas se as ENIs da AWS estiverem distribuídas em várias zonas.

3. Crie e configure o serviço de back-end:

   Crie um serviço de back-end regional com balanceamento de carga gerenciado interno:

   gcloud compute backend-services create BACKEND_SERVICE_NAME \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --protocol=TCP \
       --region=REGION \
       --health-checks=HEALTH_CHECK_NAME \
       --health-checks-region=REGION

   Adicione os NEGs híbridos ao serviço de back-end:

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
       --region=REGION \
       --network-endpoint-group=NEG_NAME \
       --network-endpoint-group-zone=ZONE \
       --balancing-mode=CONNECTION \
       --max-connections=MAX_CONNECTIONS

   Substitua:

   • BACKEND_SERVICE_NAME: um nome para o serviço de back-end.
   • NEG_NAME: o nome do NEG híbrido que você criou na etapa anterior.
   • ZONE: a zona do Google Cloud (por exemplo, us-east4-a).
   • MAX_CONNECTIONS: o número máximo de conexões simultâneas que o back-end precisa processar (por exemplo, 100).

   Repita o comando add-backend para cada NEG híbrido criado.

4. Configure o front-end do balanceador de carga:

   Crie um proxy TCP de destino:

   gcloud compute target-tcp-proxies create TARGET_PROXY_NAME \
       --backend-service=BACKEND_SERVICE_NAME \
       --region=REGION

   Crie uma regra de encaminhamento para rotear o tráfego para o proxy de destino:

   gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=VPC_NETWORK \
       --subnet=VPC_SUBNET \
       --ports=443 \
       --region=REGION \
       --target-tcp-proxy=TARGET_PROXY_NAME \
       --target-tcp-proxy-region=REGION \
       --allow-global-access

   Substitua:

   • TARGET_PROXY_NAME: um nome para o proxy de destino.
   • FORWARDING_RULE_NAME: um nome para a regra de encaminhamento.
   • VPC_SUBNET: o nome da sub-rede VPC.

Depois de criar a regra de encaminhamento para o balanceador de carga, anote o endereço IP interno atribuído a ele. Esta é sua pasta ILB_IP_ADDRESS.

Configurar o Diretório de Serviços

Registre o endereço IP do ILB no Diretório de Serviços para que o Lakehouse possa descobri-lo.

1. Crie um namespace para sua nuvem remota:

   gcloud service-directory namespaces create NAMESPACE \
       --project=PROJECT_ID \
       --location=REGION

   Substitua:

   • NAMESPACE: um identificador exclusivo para o namespace.
   • PROJECT_ID: o ID do projeto do Google Cloud .
   • REGION: a região do Google Cloud . Por exemplo, us-east4. Precisa ser a mesma região do catálogo federado.

2. Crie um serviço no namespace do Diretório de Serviços:

   gcloud service-directory services create SERVICE_NAME \
       --namespace=NAMESPACE \
       --project=PROJECT_ID \
       --location=REGION

   Substitua:

   • SERVICE_NAME: um identificador exclusivo para seu serviço.

3. Crie um endpoint para o ILB no serviço:

   gcloud service-directory endpoints create ENDPOINT_NAME \
       --project=PROJECT_ID \
       --namespace=NAMESPACE \
       --service=SERVICE_NAME \
       --location=REGION \
       --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK \
       --address=ILB_IP_ADDRESS \
       --port=443

   Substitua:

   • ENDPOINT_NAME: um identificador exclusivo para o endpoint.
   • PROJECT_NUMBER: o número do projeto do Google Cloud. Use o número do projeto na flag --network.
   • ILB_IP_ADDRESS: o endereço IP interno da regra de encaminhamento do ILB.

Endpoint direto

Para configurar o Diretório de Serviços para rotear o tráfego diretamente para um único endereço IP de endpoint de VPC de interface da AWS, siga estas etapas:

1. Crie um endpoint de VPC de interface para o Amazon S3 na VPC da AWS. Anote o endereço IP e a porta desse endpoint.

2. Crie um namespace para sua nuvem remota:

   gcloud service-directory namespaces create NAMESPACE \
       --project=PROJECT_ID \
       --location=REGION

   Substitua:

   • NAMESPACE: um identificador exclusivo para o namespace.
   • PROJECT_ID: o ID do projeto do Google Cloud .
   • REGION: a região do Google Cloud . Por exemplo, us-east4. Precisa ser a mesma região do catálogo federado.

3. Crie um serviço no namespace do Diretório de Serviços:

   gcloud service-directory services create SERVICE_NAME \
       --namespace=NAMESPACE \
       --project=PROJECT_ID \
       --location=REGION

   Substitua:

   • SERVICE_NAME: um identificador exclusivo para seu serviço.

4. Crie um endpoint no serviço que contenha as informações de roteamento do endpoint da VPC da interface do Amazon S3:

   gcloud service-directory endpoints create ENDPOINT_NAME \
       --service=SERVICE_NAME \
       --namespace=NAMESPACE \
       --project=PROJECT_ID \
       --location=REGION \
       --address=S3_VPCE_IP_ADDRESS \
       --port=S3_VPCE_PORT \
       --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK

   Substitua:

   • ENDPOINT_NAME: um identificador exclusivo para o endpoint.
   • S3_VPCE_IP_ADDRESS: o endereço IP do endpoint da VPC da interface do Amazon S3. Por exemplo, 10.0.1.45.
   • S3_VPCE_PORT: o número da porta do endpoint da VPC da interface do Amazon S3. Por exemplo, 443.
   • PROJECT_NUMBER: o número do projeto do Google Cloud. Use o número do projeto na flag --network.
   • VPC_NETWORK: o nome da rede VPC Google Cloud associada à interconexão particular.

Configurar a federação

Para consultar seus dados, configure um catálogo federado do Lakehouse que se conecte ao catálogo remoto do AWS Glue.

Crie o papel do IAM da AWS com uma política de confiança de marcador de posição

O Lakehouse provisiona um ID de conta de serviço do Google após a criação do catálogo. Crie o papel do IAM da AWS com uma política de confiança de marcador de posição.

1. Crie um arquivo chamado 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. Execute o comando da CLI da AWS para criar o papel com a política de confiança de marcador de posição. Recomendamos definir a duração máxima da sessão como 12 horas (43200 segundos) para evitar que as credenciais expirem durante jobs de longa duração:

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

   Substitua:

   • AWS_ROLE_NAME: um nome para o papel do IAM da AWS. Por exemplo, lakehouse_glue_federation_role.

Anexar uma política de permissões

Anexe uma política de permissões ao seu papel do IAM que permita que o Lakehouse acesse o Glue Data Catalog e os buckets do S3 da região da AWS. Essa política também concede acesso a buckets de tabela do S3 se você usar a integração de tabelas do S3 do AWS Lake Formation. Se você tiver feito upgrade das permissões de dados padrão do AWS Glue para o modelo do AWS Lake Formation, talvez seja necessário conceder outras permissões no Lake Formation.

1. Crie um arquivo chamado permissions_policy.json com a seguinte configuração de política.

   Importante: para facilitar o uso, a política do IAM da AWS a seguir não tem elementos Resource restritivos. Recomendamos restringir o acesso aos recursos do Glue, buckets do S3 e buckets de tabela do S3 específicos que sua arquitetura exige.

   {
     "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:*"
         ]
       }
     ]
   }

   Se você estiver usando chaves gerenciadas pelo cliente hospedadas no serviço de gerenciamento de chaves (KMS) da AWS para criptografar recursos do AWS Glue, do Amazon S3 ou das tabelas do Amazon S3, adicione uma instrução que conceda acesso à chave do KMS para descriptografar os recursos:

   # ...
   {
     "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. Anexe esta política de permissões ao seu papel do IAM:

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

   Substitua:

   • AWS_ROLE_NAME: o nome do papel do IAM da AWS. Por exemplo, lakehouse_glue_federation_role.
   • AWS_POLICY_NAME: um nome para a política de permissões. Por exemplo, lakehouse_glue_federation_policy.
   • AWS_REGION: a região da AWS em que o catálogo do Glue ou as tabelas do S3 estão. Por exemplo, us-east-1.
   • AWS_ACCOUNT_ID: a string de ID da conta da AWS com 12 dígitos. Por exemplo, 123456789012.

Criar um catálogo federado

Crie o catálogo federado usando o console do Google Cloud ou a CLI do gcloud.

Observação: ao estabelecer um catálogo federado do AWS Glue, a propriedade warehouse dentro de glue_catalog_info (ou flag --glue-warehouse) precisa ser definida como a string de ID da conta da AWS de 12 dígitos ou o catálogo de buckets de tabela do S3, em vez de um URI de bucket do S3. Os endpoints REST do Iceberg do AWS Glue resolvem catálogos de armazenamento usando o ID da conta diretamente.

Para evitar falhas prematuras de atualização de metadados em segundo plano enquanto as relações de confiança da AWS estão se propagando, inicialize o catálogo sem especificar uma programação de atualização (que tem como padrão 0s).

Console

Para criar um catálogo federado:

1. No console do Google Cloud , acesse Lakehouse.

   Acessar o Lakehouse

2. Clique em Criar catálogo.

3. Clique em Catálogo federado.

   A seção Configuração do catálogo é exibida.

4. Em Origem do catálogo federado, selecione AWS Glue.

5. Em Local de dados, selecione a região do Lakehouse em que você quer criar o catálogo federado. Por exemplo, us-east4. Para minimizar a latência (mesmo na Internet pública), selecione a região do Google Cloud mais próxima da sua região da AWS.

6. Clique em Continuar.

   A seção Detalhes da conexão é exibida.

7. Na seção Detalhes do catálogo remoto, no campo Warehouse da AWS, insira o ID da sua conta da AWS ou o catálogo de buckets de tabelas do S3. Por exemplo: 123456789012 ou 123456789012:s3tablescatalog/my-table-bucket.

8. No campo Região da AWS, insira sua região da AWS. Por exemplo, us-east-1.

9. No campo ARN do papel da AWS, insira o ARN do papel da AWS. Use o seguinte formato: arn:aws:iam::AWS_ACCOUNT_ID:role/AWS_ROLE_NAME.

10. Opcional: no campo Nome do diretório de serviços, insira o caminho para o serviço do Diretório de Serviços. Por exemplo, projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME. Isso só é necessário se você estiver configurando uma interconexão particular (Interconexão entre nuvens).

11. Clique em Criar.

gcloud

Internet pública (sem CCI)

Se você não configurar a CCI, a conexão vai passar com segurança pela Internet pública.

gcloud 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" \
    --namespace-filters="NAMESPACE_FILTERS"

Propriedade do cliente (CCI)

Se você configurou uma interconexão particular (como CCI dedicada ou CCI de parceiro), forneça a referência do serviço do diretório de serviços para que o Lakehouse encaminhe o tráfego de forma particular.

gcloud 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" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME"

Substitua:

• FEDERATED_CATALOG_NAME: um nome para o catálogo federado.
• PROJECT_ID: o ID do projeto Google Cloud .
• REGION: a região do Lakehouse em que o catálogo federado é criado. Precisa ser a mesma região do namespace do Diretório de Serviços e do secret regional.
• GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE: o identificador do catálogo do data warehouse de destino. Para o Glue Data Catalog de uma região da AWS, insira sua string de ID da conta da AWS com 12 dígitos. Por exemplo, 123456789012. Para usar um bucket de tabela do S3 na região, insira AWS_ACCOUNT_ID:s3tablescatalog/S3_TABLE_BUCKET. Por exemplo, 123456789012:s3tablescatalog/my-table-bucket.
• AWS_ACCOUNT_ID: a string de ID da conta da AWS com 12 dígitos. Por exemplo, 123456789012.
• AWS_REGION: a região da AWS em que o catálogo do Glue ou o bucket de tabela do S3 está localizado. Por exemplo, us-east-1.
• AWS_ROLE_NAME: o nome do papel do IAM da AWS. Por exemplo, lakehouse_glue_federation_role.
• NAMESPACE_FILTERS: opcional: uma lista separada por vírgulas de namespaces para federar. Por exemplo, ns1,ns2. Se omitido, todos os namespaces serão incluídos.
• Se você estiver usando uma interconexão particular (CCI):
  • SERVICE_DIRECTORY_NAMESPACE: o namespace do Diretório de Serviços que você criou durante a configuração da interconexão particular.
  • SERVICE_NAME: o nome do serviço do Diretório de Serviços que você criou durante a configuração da interconexão particular.

Atualizar a política de confiança

Quando o catálogo é criado, o Lakehouse provisiona uma conta de serviço exclusiva para ele, que é retornada como o campo biglake-service-account-id na resposta de criação do catálogo. Você usa essa conta de serviço para estabelecer a relação de confiança.

1. Execute o comando a seguir para extrair o valor biglake-service-account-id em uma variável bash ativa:

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

2. Atualize a política de confiança do papel do IAM da AWS para substituir o marcador de posição pelo ID verificado do agente de serviço do Google. O bloco de condição valida a correspondência de sub e aud. Grave a política em um arquivo chamado 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. Aplique a política finalizada ao seu papel da AWS:

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

   Observação :as mudanças no IAM da AWS podem levar alguns minutos para serem propagadas.

Ativar a atualização de metadados em segundo plano

Agora que as relações de confiança seguras foram estabelecidas nas duas plataformas, atualize seu catálogo para ativar a atualização de metadados em segundo plano (a cada 5 minutos ou 300s, ou mais).

gcloud

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

REST

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

Concluir a configuração da interconexão particular (somente Interconexão entre nuvens)

Se você estiver roteando o tráfego por uma interconexão particular (CCI dedicada ou de parceiro), conceda à conta de serviço do catálogo do Lakehouse permissões para descobrir e autorizar conexões pelo Diretório de Serviços.

Observação: a conta de serviço do catálogo é uma conta de serviço interna do Google Cloud (agente de serviço). Talvez ela não esteja visível na lista de conta de serviço do projeto no Google Cloud console, mas é possível atribuir papéis a ela manualmente.

Console

1. No console do Google Cloud , acesse a página IAM.

   Acessar IAM

2. Clique em Conceder acesso (ou Adicionar).

3. No campo Novos principais, insira o endereço de e-mail da conta de serviço do catálogo do Lakehouse. Para recuperar esse endereço de e-mail, descreva o catálogo (consulte a guia gcloud).

4. No menu Papel, selecione Leitor do Diretório de Serviços (roles/servicedirectory.viewer).

5. Clique em Adicionar outro papel e selecione Serviço autorizado do PSC do Diretório de Serviços (roles/servicedirectory.pscAuthorizedService).

6. Clique em Salvar.

gcloud

Conceda os papéis necessários à conta de serviço do catálogo:

# Grant Service Directory Viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:$(gcloud 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 biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account)')" \
--role="roles/servicedirectory.pscAuthorizedService"

Verifique a conexão

Verifique se o ciclo de atualização de metadados em segundo plano do catálogo foi concluído e se os namespaces estão sincronizados.

1. Verifique se o status de atualização indica sucesso:

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

2. Confirme se os namespaces estão sincronizados:

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

A seguir

• Consultar dados remotos.
• Resolver problemas de acesso a dados entre nuvens.