Configurar a conexão entre nuvens para o catálogo do Snowflake Horizon

Uma conexão entre nuvens com um catálogo do Snowflake Horizon no Amazon Web Services (AWS), no Microsoft Azure ou no Google Cloud permite consultar dados desse catálogo diretamente no Google Cloud. Esse recurso unifica sua análise de dados integrando suas fontes de dados externas ao ambiente doGoogle Cloud .

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. Entenda como usar os secrets regionais do Secret Manager. Isso é necessário para configurar o Lakehouse com o catálogo do Snowflake Horizon usando a autenticação baseada em secret.
  5. Opcional: se você planeja rotear leituras de consulta ou atualização de metadados em segundo plano por uma interconexão privada entre sua rede de nuvem privada virtual (VPC) do Google Cloud e sua rede de nuvem remota (AWS VPC ou Azure VNet), verifique se você tem uma conta ativa com seu provedor remoto, provisione um Dedicated Cross-Cloud Interconnect ou Cross-Cloud Interconnect por parceiro (para AWS), estabeleça sessões do BGP com seu Cloud Router e verifique se você tem as permissões necessárias do Identity and Access Management (IAM) nos dois ambientes de nuvem.
  6. 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.

  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.

Funções exigidas

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

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.

  • VPC Service Controls: se o projeto que contém o endpoint do catálogo federado ou o bucket do Cloud Storage estiver dentro de um perímetro de serviço do VPC Service Controls, será necessário configurar regras de saída ou entrada. Para mais informações, consulte Usar o VPC Service Controls com endpoints de catálogo federado.
  • Provedores de nuvem Interconexão entre nuvens Interconnect: o uso de uma interconexão particular para rotear o transporte de consultas, a atualização de metadados em segundo plano ou ambos é compatível com a AWS e o Azure. É possível usar o Cross-Cloud Interconnect dedicado (para AWS ou Azure) ou o Cross-Cloud Interconnect por parceiro (para AWS).
  • Roteamento de rede: se você não configurar uma interconexão particular para transporte de consultas ou atualização de metadados em segundo plano, o tráfego correspondente será roteado pela Internet pública usando TLS. O roteamento de leituras de consulta pela Internet pública pode resultar em taxas de saída mais altas do provedor de nuvem remoto e em um desempenho menos previsível.
  • Tabelas compatíveis com o catálogo do Snowflake Horizon: somente as tabelas do Apache Iceberg no catálogo do Snowflake Horizon são sincronizadas com o Lakehouse. As tabelas do Snowflake que não são do Iceberg são ignoradas durante a atualização de metadados em segundo plano.
  • Política de rede e endereços IP de saída: quando a atualização de metadados em segundo plano se conecta pela Internet pública, o Lakehouse usa endereços IP de saída da infraestrutura global do Google para acessar o endpoint do Snowflake voltado para a Internet. Se você configurar uma política de rede do Snowflake para acesso à internet público, adicione os intervalos de endereços IP de saída do Google de goog.json à lista de IPs permitidos da política de rede. Quando você configura a atualização particular de metadados em segundo plano pelo Interconexão entre nuvens, as solicitações de metadados são roteadas de forma particular pela rede VPC para o endpoint do PrivateLink do Snowflake.
  • 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 for excedida, a atual será ignorada, e 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 entre nuvens está desativado por padrão (--cross-cloud-cache=disabled). É possível ativar ou desativar o armazenamento em cache no nível do catálogo federado ou da conexão. As chaves de criptografia gerenciadas pelo cliente (CMEK) não são compatíveis com o armazenamento em cache. Os arquivos 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 uma 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: quando você ativa o armazenamento em cache entre nuvens em um catálogo federado ou conexão federada, o Lakehouse armazena temporariamente os arquivos em cache em repouso na Google Cloud região em que a consulta é executada. Se os arquivos de nuvem remotos estiverem em uma jurisdição diferente, verifique se o armazenamento em cache entre regiões atende aos requisitos de residência de dados e compliance da sua organização antes de ativá-lo.

Fluxo de trabalho geral

Para acessar dados entre nuvens, siga estas etapas gerais:

  • Configurar o Interconexão entre nuvens (opcional): configure uma conexão privada entre sua rede VPC do Google Cloud e seu provedor de nuvem remoto.
  • Configurar a federação: configure a autenticação e crie um catálogo federado no Lakehouse.
    • Autenticação baseada em secret (PAT): crie um secret no Secret Manager com suas credenciais de catálogo remoto. Em seguida, crie um catálogo federado no Lakehouse e conceda à conta de serviço do catálogo acesso ao secret.
    • Federação de identidade da carga de trabalho (WIF): crie um catálogo federado no Lakehouse especificando o papel necessário do Snowflake. Em seguida, vincule o ID da conta de serviço do catálogo a um usuário de serviço no Snowflake. O usuário do serviço do Snowflake precisa ter permissões de uso no catálogo remoto do Snowflake Horizon.
  • 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. Se quiser, ative o armazenamento em cache entre nuvens no catálogo federado para reduzir os custos de saída entre nuvens e acelerar as consultas subsequentes. 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 leituras de dados de consulta e a atualização de metadados em segundo plano viajam pela Internet pública usando TLS. Para ajudar a melhorar o isolamento da rede, fornecer latência previsível e reduzir os custos de transferência de dados, é possível configurar uma interconexão privada entre sua rede VPC do Google Cloud e sua rede de nuvem remota (VPC da AWS ou rede virtual do Azure (VNet)).

É possível provisionar uma das seguintes opções de interconexão particular:

Estabeleça sessões do BGP entre o Cloud Router em Google Cloud e sua rede de nuvem remota para permitir a troca de rotas.

É possível configurar o roteamento particular pelo Interconexão entre nuvens para um ou ambos os caminhos de tráfego a seguir, dependendo dos seus requisitos de segurança e custo:

  • Transporte de consultas (--service-directory-name): encaminha as leituras de consulta do BigQuery ou de mecanismos de código aberto para o armazenamento de objetos remoto (Amazon S3 ou Azure Data Lake Storage Gen2 (ADLS Gen2)) para ajudar a reduzir as taxas de saída entre nuvens e manter a latência de consulta previsível.
  • Atualização de metadados em segundo plano (--metadata-service-directory-name): encaminha as solicitações de autenticação e atualização de metadados em segundo plano do plano de controle do catálogo do ambiente de execução do Lakehouse para o endpoint privado remoto do Snowflake Horizon Catalog. Por exemplo, quando o catálogo remoto restringe o acesso à internet público.

Se você rotear o transporte de consultas e a atualização de metadados em segundo plano pelo Interconexão entre nuvens, conclua as etapas de endpoint privado, roteamento e serviço do Diretório de Serviços uma vez para o endpoint de armazenamento remoto e uma vez para o endpoint de catálogo remoto. Os dois serviços do Diretório de Serviços precisam residir na mesma região do Google Cloud que o catálogo federado e podem compartilhar a mesma sub-rede somente proxy e o mesmo namespace do Diretório de Serviços.

É possível usar um dos dois fluxos de arquitetura para rotear o tráfego do Diretório de Serviços para seus endpoints particulares remotos:

  • Roteamento do balanceador de carga de rede de proxy regional interno: usa um balanceador de carga de rede de proxy regional interno Google Cloudpara distribuir solicitações entre grupos de endpoints de rede (NEGs) de conectividade híbrida que apontam para seus endereços IP de endpoint privado remoto (interfaces de rede elástica da AWS (ENIs) ou interfaces de rede de endpoint privado do Azure (NICs)). Esse fluxo é obrigatório para o Interconexão entre nuvens por parceiro e recomendado para o Dedicated Interconexão entre nuvens para balanceamento de carga, escalonabilidade e alta disponibilidade.
  • Roteamento de endpoint direto: conecta o Diretório de Serviços diretamente a um único endereço IP de endpoint particular remoto. Esse fluxo funciona apenas com o Interconexão entre nuvens dedicado e não é compatível com o Interconexão entre nuvens por 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 que distribui solicitações entre os endereços IP do endpoint particular remoto, siga estas etapas:

Configurar endpoints particulares de nuvem remota

Crie endpoints particulares na rede remota e nas sub-redes que se conectam à sua rede VPC do Google Cloud pelo Interconexão entre nuvens e anote os endereços IP particulares atribuídos a cada endpoint:

  • Para transporte de consulta particular (repositório de objetos remoto): na AWS, crie um endpoint de VPC de interface para o Amazon S3 (com.amazonaws.AWS_REGION.s3) na VPC da AWS e anote os endereços IP particulares da ENI. No Azure, crie um endpoint particular do Azure para o Armazenamento do Azure visando sua conta de armazenamento do ADLS Gen2 (dfs ou blob) na VNet do Azure e anote o endereço IP particular da NIC.
  • Para atualização de metadados em segundo plano particular (catálogo remoto): no Snowflake, execute SELECT SYSTEM$GET_PRIVATELINK_CONFIG(); para receber o identificador de serviço do PrivateLink e o identificador de conta do .privatelink. Na AWS, siga as instruções em AWS PrivateLink e Snowflake para criar um endpoint de VPC de interface na VPC da AWS e anote os endereços IP privados da ENI. No Azure, siga as instruções em Azure Private Link e Snowflake para criar um endpoint particular do Azure na sua VNet do Azure e anote o endereço IP particular da NIC.
  • Regras de segurança de entrada: verifique se os grupos de segurança da AWS ou os grupos de segurança de rede (NSGs) do Azure anexados aos endpoints particulares permitem o tráfego TCP de entrada na porta 443 (e na porta 80 se a configuração do Snowflake usar OCSP) dos intervalos CIDR da VPC do Google Cloud . Inclua o intervalo CIDR da sub-rede somente proxy do Google Cloud para permitir verificações de integridade e tráfego encaminhado.

Configurar a rede do Google Cloud

Execute os comandos a seguir para configurar o balanceador de carga interno. Se você estiver roteando o transporte de consultas e a atualização de metadados em segundo plano pelo Interconexão entre nuvens, configure um serviço de back-end, um proxy TCP de destino e uma regra de encaminhamento separados para o endpoint de armazenamento e o endpoint de catálogo. Para configurações avançadas, consulte Configurar um balanceador de carga de rede de proxy regional interno para endpoints híbridos.

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).

  1. Crie uma verificação de integridade TCP 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 ou NIC do endpoint remoto ao NEG híbrido:

    gcloud compute network-endpoint-groups update NEG_NAME \
    --zone=ZONE \
    --add-endpoint="ip=REMOTE_ENDPOINT_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.
    • REMOTE_ENDPOINT_IP: o endereço IP particular do armazenamento remoto ou do endpoint particular do catálogo remoto nessa zona.

    Se o endpoint remoto tiver vários endereços IP particulares distribuídos entre zonas, repita esses comandos para criar NEGs híbridos e adicionar endpoints para cada zona.

  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 para o back-end (por exemplo, 100).

    Repita o comando add-backend para cada NEG híbrido que você criou.

  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 balanceador de carga interno no Diretório de Serviços para que o Lakehouse possa descobri-lo e rotear para ele de forma particular. Se você configurou regras de encaminhamento de balanceador de carga separadas para transporte de consultas e atualização de metadados em segundo plano, crie um serviço e um endpoint do Diretório de Serviços separados para cada endereço IP de regra de encaminhamento.

  1. Crie um namespace para os endpoints particulares remotos:

    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). Ela precisa ser a mesma 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 (crie um nome de serviço separado, como METADATA_SERVICE_NAME, ao registrar um endpoint de atualização de metadados em segundo plano).

  3. Crie um endpoint para a regra de encaminhamento do balanceador de carga 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 balanceador de carga.

Endpoint direto

Para configurar o Diretório de Serviços para rotear o tráfego diretamente para um único endereço IP de endpoint privado remoto pelo Interconexão entre nuvens dedicado, siga estas etapas:

  1. Crie o endpoint particular na rede de nuvem remota:

    Anote o endereço IP particular e a porta (443) de cada endpoint e verifique se os grupos de segurança da AWS ou os NSGs do Azure permitem o tráfego TCP de entrada na porta 443 da sua rede VPC do Google Cloud .

  2. Crie um namespace para os endpoints particulares remotos:

    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). Ela precisa ser a mesma do catálogo federado.

  3. Crie um serviço no namespace do Diretório de Serviços. Se você estiver roteando o transporte de consultas e a atualização de metadados em segundo plano de forma particular, crie um serviço separado para cada endpoint:

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

    Substitua:

    • SERVICE_NAME: um identificador exclusivo para seu serviço (crie um nome de serviço separado, como METADATA_SERVICE_NAME, ao registrar um endpoint de atualização de metadados em segundo plano).

  4. Crie um endpoint no serviço com o endereço IP privado e a porta do endpoint privado remoto:

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

    Substitua:

    • ENDPOINT_NAME: um identificador exclusivo para o endpoint.
    • REMOTE_ENDPOINT_IP: o endereço IP privado do endpoint privado do armazenamento remoto ou do catálogo remoto (por exemplo, 10.0.1.45).
    • REMOTE_ENDPOINT_PORT: o número da porta do endpoint particular remoto (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 Snowflake Horizon.

Configurar a autenticação

A federação requer credenciais ou configuração de papel para acessar o catálogo remoto do Snowflake Horizon. Escolha um dos seguintes métodos.

Baseado em secret (PAT)

Essa opção usa um token de acesso programático (PAT, na sigla em inglês) armazenado com segurança com secrets regionais do Secret Manager.

  1. Gere um token de acesso programático (PAT, na sigla em inglês) que tenha acesso de leitura ao catálogo de destino.

  2. Crie um arquivo JSON chamado credentials.json com seu payload:

    {
  "client_secret": "SNOWFLAKE_PAT_TOKEN",
  "scope": "session:role:SNOWFLAKE_ROLE"
}

    Substitua:

    • SNOWFLAKE_PAT_TOKEN: seu Token de Acesso Programático (PAT, na sigla em inglês) do Snowflake.
    • SNOWFLAKE_ROLE: o papel específico do Snowflake necessário para a sessão. Por exemplo, ICEBERG_VIEW.

  3. Configure o endpoint regional para o Secret Manager:

    Por padrão, o Secret Manager usa um endpoint global. No entanto, o Lakehouse exige que os secrets sejam armazenados na mesma região do catálogo do Lakehouse. Para interagir com secrets regionais usando a Google Cloud CLI, é necessário substituir o endpoint de API padrão da sessão ou do perfil atual.

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

    Substitua:

    • REGION: a região do Google Cloud em que o secret do Secret Manager está armazenado. Por exemplo, us-east4. Para evitar problemas de conectividade, o secret e o catálogo precisam ser criados na mesma região.

  4. Faça upload do payload para o Secret Manager:

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

    Substitua:

    • SNOWFLAKE_SECRET_NAME: um nome para o secret do Snowflake.
    • PROJECT_ID: o ID do projeto Google Cloud .

Federação de identidade da carga de trabalho

A federação de identidade da carga de trabalho (WIF) evita o uso de secrets de longa duração vinculando uma conta de serviço do catálogo do Lakehouse diretamente a um usuário de serviço do Snowflake. Não há pré-requisitos de configuração. Continue criando o catálogo federado.

Criar um catálogo federado

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

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 Snowflake (Horizon).

  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), faça o seguinte ao selecionar uma região:

    • Se o catálogo do Snowflake Horizon estiver na AWS, selecione a região doGoogle Cloud mais próxima da sua região da AWS.
    • Se o catálogo do Snowflake Horizon estiver no Azure, selecione a região doGoogle Cloud mais próxima da sua região do Azure.
    • Se o catálogo do Snowflake Horizon estiver em Google Cloud, selecione a mesma região.

  6. Opcional: em Armazenamento em cache entre nuvens, selecione Ativar o armazenamento em cache entre nuvens para armazenar em cache arquivos remotos na região do Google Clouddo catálogo e acelerar o desempenho da consulta. Também é possível atualizar essa configuração mais tarde editando os detalhes do catálogo. Para mais informações sobre como o armazenamento em cache funciona, retenção e preços, consulte Armazenamento em cache inteligente.

  7. Clique em Continuar.

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

  8. Na seção Detalhes do catálogo remoto, no campo Identificador da conta do Snowflake, insira o identificador da sua conta do Snowflake (por exemplo, myorg-myaccount). Se você rotear a atualização de metadados em segundo plano de forma particular pelo AWS PrivateLink ou pelo Azure Private Link, insira o identificador da sua conta do .privatelink (por exemplo, myorg-myaccount.privatelink).

  9. No campo Snowflake warehouse, insira o nome do seu warehouse do Snowflake. Também conhecido como o nome do banco de dados no catálogo do Snowflake Horizon.

  10. Selecione uma opção para Método de autenticação:

    • Em Secret, insira o nome do secret para Baseado em secret (PAT). Use o seguinte formato: projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME.
    • Para OIDC, insira seu papel do Snowflake para a federação de identidade da carga de trabalho. Por exemplo: ICEBERG_VIEW.

  11. Em Camada de transporte, selecione Internet pública ou Interconexão privada dedicada. Se você selecionar Interconexão dedicada particular, configure os seguintes campos:

    • No campo Nome do diretório de serviços, insira o caminho para o serviço de transporte do serviço do diretório no formato projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME.
    • Opcional: para sincronizar os metadados do catálogo de forma particular pelo Interconexão entre nuvens, no campo Nome do diretório de serviços de metadados, insira o caminho para o serviço do Diretório de Serviços de metadados no formato projects/PROJECT_ID/locations/REGION/namespaces/METADATA_SERVICE_DIRECTORY_NAMESPACE/services/METADATA_SERVICE_NAME.

  12. Clique em Criar.

gcloud

Baseado em secret (PAT)

Se você usar a autenticação baseada em secret, especifique --secret-name.

Internet pública (sem CCI)

Se você não configurar o Interconexão entre nuvens, as conexões vão passar pela Internet pública usando TLS.

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --cross-cloud-cache="CROSS_CLOUD_CACHE_MODE"

Propriedade do cliente (CCI)

Se você configurou uma interconexão particular (Interconexão dedicada ou por parceiro entre nuvens), forneça a referência de serviço do Diretório de Serviços para transporte de consulta particular (--service-directory-name), atualização de metadados em segundo plano particular (--metadata-service-directory-name) ou ambos. Também é possível adicionar ou atualizar qualquer uma das flags em um catálogo atual executando gcloud biglake iceberg catalogs update.

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --cross-cloud-cache="CROSS_CLOUD_CACHE_MODE" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME" \
    --metadata-service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/METADATA_SERVICE_DIRECTORY_NAMESPACE/services/METADATA_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. Para minimizar a latência:
    • Se o catálogo do Snowflake Horizon estiver na AWS, selecione a região doGoogle Cloud mais próxima da sua região da AWS.
    • Se o catálogo do Snowflake Horizon estiver no Azure, selecione a região doGoogle Cloud mais próxima da sua região do Azure.
    • Se o catálogo do Snowflake Horizon estiver em Google Cloud, selecione a mesma região.
  • SNOWFLAKE_SECRET_NAME: o nome do secret do Snowflake.
  • SNOWFLAKE_ACCOUNT_IDENTIFIER: o identificador da sua conta do Snowflake (por exemplo, myorg-myaccount). Se você especificar --metadata-service-directory-name para sincronizar metadados pelo PrivateLink ou Private Link, use o identificador da sua conta do .privatelink (por exemplo, myorg-myaccount.privatelink).
  • SNOWFLAKE_WAREHOUSE: o warehouse do Snowflake com que você quer fazer a federação. Também conhecido como o nome do banco de dados no catálogo do Snowflake Horizon.
  • REFRESH_INTERVAL: opcional. Especifica a frequência com que a atualização de metadados em segundo plano é executada. Defina esse valor como uma duração, por exemplo, 330s ou 5m30s.
  • NAMESPACE_FILTERS: opcional: uma lista separada por vírgulas de namespaces para federar. Por exemplo, ns1,ns2. Se omitido, o Lakehouse inclui todos os namespaces.
  • CROSS_CLOUD_CACHE_MODE: opcional: se o armazenamento em cache entre nuvens deve ser ativado no catálogo federado (enabled ou disabled). O padrão é disabled. Quando definido como enabled, o Lakehouse armazena em cache os arquivos remotos na região Google Cloud do catálogo. Para mais informações, consulte Armazenamento em cache inteligente.
  • Se você estiver usando uma interconexão particular (Interconexão entre nuvens), especifique uma ou ambas as referências do Diretório de Serviços a seguir (omita qualquer uma das sinalizações se você não estiver roteando essa camada de tráfego pelo Interconexão entre nuvens):
    • SERVICE_DIRECTORY_NAMESPACE e SERVICE_NAME: o namespace do Diretório de serviços e o nome do serviço que você criou para o transporte de consultas particulares para o repositório de objetos remoto.
    • METADATA_SERVICE_DIRECTORY_NAMESPACE e METADATA_SERVICE_NAME: o namespace e o nome do serviço do Diretório de Serviços que você criou para a atualização de metadados em segundo plano particular.

Federação de identidade da carga de trabalho

Se você usar a federação de identidade da carga de trabalho, especifique --snowflake-role.

Internet pública (sem CCI)

Se você não configurar o Interconexão entre nuvens, as conexões vão passar pela Internet pública usando TLS.

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --snowflake-role="SNOWFLAKE_ROLE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --cross-cloud-cache="CROSS_CLOUD_CACHE_MODE"

Propriedade do cliente (CCI)

Se você configurou uma interconexão particular (Interconexão dedicada ou por parceiro entre nuvens), forneça a referência de serviço do Diretório de Serviços para transporte de consulta particular (--service-directory-name), atualização de metadados em segundo plano particular (--metadata-service-directory-name) ou ambos. Também é possível adicionar ou atualizar qualquer uma das flags em um catálogo atual executando gcloud biglake iceberg catalogs update.

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --snowflake-role="SNOWFLAKE_ROLE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --cross-cloud-cache="CROSS_CLOUD_CACHE_MODE" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME" \
    --metadata-service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/METADATA_SERVICE_DIRECTORY_NAMESPACE/services/METADATA_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. Para minimizar a latência:
    • Se o catálogo do Snowflake Horizon estiver na AWS, selecione a região doGoogle Cloud mais próxima da sua região da AWS.
    • Se o catálogo do Snowflake Horizon estiver no Azure, selecione a região doGoogle Cloud mais próxima da sua região do Azure.
    • Se o catálogo do Snowflake Horizon estiver em Google Cloud, selecione a mesma região.
  • SNOWFLAKE_ACCOUNT_IDENTIFIER: o identificador da sua conta do Snowflake (por exemplo, myorg-myaccount). Se você especificar --metadata-service-directory-name para sincronizar metadados pelo PrivateLink ou Private Link, use o identificador da sua conta do .privatelink (por exemplo, myorg-myaccount.privatelink).
  • SNOWFLAKE_WAREHOUSE: o warehouse do Snowflake com que você quer fazer a federação. Também conhecido como o nome do banco de dados no catálogo do Snowflake Horizon.
  • SNOWFLAKE_ROLE: o papel específico do Snowflake necessário para a sessão. Por exemplo, ICEBERG_VIEW.
  • REFRESH_INTERVAL: especifica a frequência com que a atualização de metadados em segundo plano é executada. Defina esse valor como uma duração, por exemplo, 330s ou 5m30s.
  • NAMESPACE_FILTERS: opcional: uma lista separada por vírgulas de namespaces para federar. Por exemplo, ns1,ns2. Se omitido, o Lakehouse inclui todos os namespaces.
  • CROSS_CLOUD_CACHE_MODE: opcional: se o armazenamento em cache entre nuvens deve ser ativado no catálogo federado (enabled ou disabled). O padrão é disabled. Quando definido como enabled, o Lakehouse armazena em cache os arquivos remotos na região Google Cloud do catálogo. Para mais informações, consulte Armazenamento em cache inteligente.
  • Se você estiver usando uma interconexão particular (Interconexão entre nuvens), especifique uma ou ambas as referências do Diretório de Serviços a seguir (omita qualquer uma das sinalizações se você não estiver roteando essa camada de tráfego pelo Interconexão entre nuvens):
    • SERVICE_DIRECTORY_NAMESPACE e SERVICE_NAME: o namespace do Diretório de serviços e o nome do serviço que você criou para o transporte de consultas particulares para o repositório de objetos remoto.
    • METADATA_SERVICE_DIRECTORY_NAMESPACE e METADATA_SERVICE_NAME: o namespace e o nome do serviço do Diretório de Serviços que você criou para a atualização de metadados em segundo plano particular.

Concluir a configuração da autenticação

Conclua o processo de autenticação usando o tipo de autenticação escolhido.

Baseado em secret (PAT)

Quando o catálogo é criado, o Lakehouse provisiona uma conta de serviço exclusiva para ele (retornada como biglake-service-account na descrição do recurso).

É necessário conceder a essa conta de serviço permissão para acessar o secret que você criou anteriormente. A propagação de políticas do IAM pode levar alguns minutos.

Conceda à conta de serviço do catálogo permissão para acessar o secret:

gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
gcloud secrets add-iam-policy-binding SNOWFLAKE_SECRET_NAME \
  --project="PROJECT_ID" \
  --location="REGION" \
  --member="serviceAccount:$(gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
      --project="PROJECT_ID" \
      --format='value(biglake-service-account)')" \
  --role="roles/secretmanager.secretAccessor"

Para verificar se a conta de serviço do catálogo federado tem acesso ao secret, execute o seguinte comando:

gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
gcloud secrets get-iam-policy SNOWFLAKE_SECRET_NAME \
    --project="PROJECT_ID" \
    --location="REGION"

Na saída, verifique se a conta de serviço biglake-service-account tem o papel roles/secretmanager.secretAccessor atribuído a ela.

Federação de identidade da carga de trabalho

Depois de criar o catálogo, vincule a identidade da conta de serviço a um usuário de serviço no Snowflake.

  1. Extraia o ID da conta de serviço do Lakehouse (assunto) dos detalhes do catálogo.

    É possível conseguir isso na resposta JSON do comando de criação (campo biglake-service-account-id).

    Como alternativa, execute o comando describe no catálogo para receber o valor:

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

    Procure biglake-service-account-id na saída.

  2. Faça login na instância de gerenciamento do Snowflake e execute o script a seguir para estabelecer a relação de confiança com a identidade de serviço do Lakehouse:

    USE ROLE ACCOUNTADMIN;

CREATE USER SNOWFLAKE_SERVICE_USER
  TYPE = SERVICE
  WORKLOAD_IDENTITY = (
    TYPE = GCP
    SUBJECT = 'LAKEHOUSE_SERVICE_ACCOUNT_ID'
  )
  DEFAULT_ROLE = SNOWFLAKE_ROLE
  COMMENT = 'Service user for Lakehouse federation over WIF';

-- Also explicitly GRANT permissions to the role
GRANT ROLE SNOWFLAKE_ROLE TO USER SNOWFLAKE_SERVICE_USER;

    Substitua:

    • SNOWFLAKE_SERVICE_USER: um nome para o novo usuário de serviço no Snowflake.
    • LAKEHOUSE_SERVICE_ACCOUNT_ID: o ID da conta de serviço extraído na etapa anterior.
    • SNOWFLAKE_ROLE: o papel do Snowflake (precisa corresponder ao papel especificado durante a criação do catálogo).

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

Se você rotear o transporte de consultas, a atualização de metadados em segundo plano ou ambos por uma interconexão privada (Cross-Cloud Interconnect dedicada ou Cross-Cloud Interconnect por parceiro), conceda permissões à conta de serviço do catálogo do Lakehouse para descobrir e autorizar conexões pelo Diretório de Serviços. Se o serviço de transporte do Diretório de Serviços e o serviço de metadados do Diretório de Serviços estiverem hospedados em projetos Google Cloud diferentes, conceda esses papéis em cada projeto que hospeda um serviço do Diretório de Serviços.

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 no projeto que hospeda os serviços do Diretório de Serviços:

# 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 e as tabelas 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"

  3. Confirme se as tabelas em um namespace estão sincronizadas:

    gcloud biglake iceberg tables list \
  --project="PROJECT_ID" \
  --catalog="FEDERATED_CATALOG_NAME" \
  --namespace="NAMESPACE_ID"

A seguir