Sobre o acesso aos dados entre nuvens

O recurso de acesso a dados entre nuvens permite consultar dados armazenados em outros provedores de nuvem diretamente do Google Cloud sem migrar arquivos ou criar pipelines de ETL complexos. As consultas podem ser roteadas pela Internet pública ou usar o Interconexão entre nuvens para transporte de rede privada.

O acesso a dados entre nuvens no Lakehouse unifica as cargas de trabalho de análise e IA em todos os conjuntos de dados distribuídos usando o BigQuery, ambientes independentes do Apache Spark ou o Serviço Gerenciado para Apache Spark.

Além de executar consultas analíticas, é possível criar agentes de análise de conversação baseados nas tabelas distribuídas, incluindo fontes entre nuvens, para analisar dados entre nuvens em uma única conversa. Também é possível usar o Knowledge Catalog para criação de perfil de dados e insights em plataformas remotas.

Quando usar o acesso a dados entre nuvens

Veja alguns casos de uso comuns:

  • Consultar tabelas multicloud no local: execute análises do BigQuery SQL e do Serviço Gerenciado para Apache Spark diretamente em tabelas externas do Apache Iceberg no Amazon Web Services (AWS) e no Microsoft Azure sem migrar arquivos ou manter pipelines de ETL.
  • Aplicar o isolamento de rede particular entre nuvens: encaminhe as leituras de dados de consulta e a atualização de metadados em segundo plano pelo Interconexão entre nuvens para ajudar a atender às políticas de segurança e conformidade que restringem o tráfego da Internet pública.
  • Reduza os custos recorrentes de transferência de dados entre nuvens: combine taxas de saída previsíveis de interconexão particular com o armazenamento em cache de blocos locais automáticos noGoogle Cloud para painéis de BI repetidos e cargas de trabalho analíticas.
  • Unifique a governança entre nuvens e os agentes de IA: embase os agentes de análise de conversas em tabelas distribuídas e aplique a descoberta, a criação de perfis e a linhagem do Knowledge Catalog em várias nuvens.

Arquitetura

O diagrama a seguir ilustra a arquitetura de acesso a dados entre nuvens do Lakehouse:

Arquitetura de acesso a dados entre nuvens do Lakehouse no Google Cloud, na Amazon Web Services (AWS) e em parceiros de SaaS.
A arquitetura do Lakehouse conecta mecanismos de IA e análise do Google Cloud a catálogos de nuvem externos, armazenamento de objetos e parceiros de SaaS.

O diagrama anterior ilustra a arquitetura no Google Cloud e em ambientes externos de nuvem e SaaS:

  • Google Cloud: fornece IA, governança, análise e acesso a dados entre nuvens em conjuntos de dados remotos:
    • Agentes e experiências de IA: cria agentes autônomos na Análise de Conversação e no Gemini Enterprise que pesquisam dados e significado semântico no Catálogo de Conhecimento e executam consultas usando mecanismos de análise e processamento.
    • Knowledge Catalog: oferece governança unificada e linhagem de dados, além de insights de dados, criação de perfis e produtos de dados, sincronizando metadados e linhagem do Lakehouse.
    • Mecanismos de análise e processamento: executa cargas de trabalho do BigQuery SQL, do BigQuery AI e do Looker ou processa dados remotos com o Serviço Gerenciado para Apache Spark e mecanismos abertos (Apache Spark, Apache Flink e Trino) resolvendo metadados e lendo tabelas pelo Lakehouse.
    • Acesso a dados entre nuvens do Lakehouse: consulta dados remotos no local sem migração de arquivos ou pipelines de ETL:
      • Sincronização de metadados: descobre e sincroniza metadados de tabela pelo Apache Iceberg REST e pelo Delta Sharing usando o catálogo do ambiente de execução do Lakehouse, autentica pelo OpenID Connect (OIDC) ou pelo Secret Manager e vende credenciais temporárias com escopo.
      • Recursos entre nuvens (AWS): armazena em cache os blocos de dados de leitura em Google Cloud usando um cache de leitura no nível do bloco (armazenamento em cache inteligente (cache local)) e roteia o tráfego pelo Interconexão entre nuvens dedicada (CCI), pela Interconexão por parceiro ou pela Internet (com TLS) usando o transporte de rede entre nuvens.
  • Fontes de dados externas de nuvem e SaaS: hospeda os catálogos remotos, os Data Clouds de SaaS e o repositório de objetos:
    • Catálogos externos de nuvem e SaaS: sincroniza metadados de catálogos de dados em nuvem (AWS Glue Data Catalog na AWS, Databricks Unity Catalog e Snowflake Horizon Catalog na AWS ou no Google Cloud) e nuvens de dados SaaS (Salesforce Data Cloud, Workday Data Lake na AWS ou noGoogle Cloude SAP Business Data Cloud (BDC)) pela API REST do Iceberg e pelo Delta Sharing (para SAP BDC).
    • Armazenamento de objetos em nuvem externa (AWS): armazena tabelas do Apache Iceberg (arquivos de dados Parquet) e tabelas do Amazon S3 no Amazon S3 para leituras diretas de blocos por CCI ou pela Internet (com TLS).

Como funciona o acesso a dados entre nuvens

O Lakehouse consulta dados remotos usando o seguinte processo:

  1. Descoberta de metadados: o catálogo do ambiente de execução do Lakehouse se conecta a endpoints remotos do catálogo REST do Apache Iceberg, como o Databricks Unity Catalog, o AWS Glue Data Catalog ou o Snowflake Horizon Catalog, para descobrir metadados de tabela sem copiar arquivos. Dependendo do provedor de catálogo remoto, o Lakehouse se autentica pelo Secret Manager ou pela federação de tokens OIDC com o Google como provedor de identidade.
  2. Transporte seguro: rotear o tráfego por uma interconexão privada (por exemplo, CCI dedicada ou Interconexão por parceiro) reduz significativamente os custos de transferência de dados em comparação com a Internet pública e torna a latência altamente previsível.
  3. Execução otimizada: quando você ativa o armazenamento em cache entre nuvens no seu catálogo federado ou conexão, o Lakehouse armazena em cache os blocos de arquivos recuperados localmente na região de execução da consulta do Google Cloud . As consultas subsequentes que segmentam os mesmos blocos de arquivos são lidas diretamente do cache local, em vez de buscar novamente os arquivos da nuvem remota, o que ajuda a reduzir os custos de saída entre nuvens e melhora o desempenho da consulta.

Catálogos compatíveis

O Lakehouse permite consultar dados dos seguintes provedores de catálogo remoto:

Principais conceitos

O acesso a dados entre nuvens separa a atualização de metadados em segundo plano do transporte de dados de consulta para que você possa rotear uma ou ambas as camadas de tráfego de forma particular com base nos seus requisitos de segurança e custo.

Camada de metadados

A camada de metadados no catálogo do ambiente de execução do Lakehouse se conecta a endpoints remotos do catálogo REST do Apache Iceberg para sincronizar o namespace e os metadados da tabela do Apache Iceberg com base em um intervalo de atualização. O Lakehouse faz a autenticação usando credenciais armazenadas no Secret Manager ou na federação de tokens OIDC.

Por padrão, as solicitações de autenticação e atualização de metadados em segundo plano são transmitidas pela Internet pública usando TLS. Quando o catálogo remoto restringe o acesso à rede pública ou os requisitos da política de segurança exigem tráfego de plano de controle privado, é possível configurar um serviço do Diretório de Serviços de metadados (--metadata-service-directory-name) para o AWS Glue Data Catalog (na AWS), o Databricks Unity Catalog (na AWS e no Azure) e o Snowflake Horizon Catalog (na AWS e no Azure). Essa configuração roteia o tráfego de metadados e autenticação de forma particular pelo Interconexão entre nuvens dedicado ou pelo Interconexão entre nuvens por parceiro (para AWS), de forma independente ou em conjunto com o transporte de consulta particular (--service-directory-name).

Camada de transporte

A camada de transporte permite que o BigQuery e os mecanismos de código aberto consultem arquivos de tabela remota usando os metadados sincronizados da camada de metadados. Para catálogos remotos compatíveis, o Lakehouse permite consultar dados pela Internet pública ou por uma interconexão privada dedicada.

Selecione o método de transporte que corresponde aos seus requisitos de arquitetura e segurança:

Propriedade do cliente (CCI)

É possível configurar o BigQuery para consultar dados armazenados em buckets do Amazon S3 ou contêineres do Azure Data Lake Storage Gen2 (ADLS Gen2) em um Interconexão entre nuvens particular usando o Cross-Cloud Interconnect dedicado ou o Cross-Cloud Interconnect por parceiro.

O uso de uma interconexão particular oferece os seguintes benefícios:

  • Segurança aprimorada: os dados são transmitidos por uma conexão de rede privada entre o Google Cloud e a AWS ou o Azure, evitando a Internet pública.
  • Custos reduzidos: cobranças de saída potencialmente menores da AWS ou do Azure em comparação com a saída de dados para a internet, especialmente quando combinadas com sua capacidade de interconexão particular.
  • Desempenho consistente: latência de rede e largura de banda mais previsíveis em comparação com a Internet pública.

Informações gerais da arquitetura

Para ativar a consulta particular, configure um caminho do BigQuery para o bucket do Amazon S3 ou o contêiner do ADLS Gen2 pela interconexão particular. Um componente essencial na Google Cloud nuvem privada virtual (VPC) é um balanceador de carga interno (ILB). O ILB distribui solicitações do BigQuery para os endpoints privados do Amazon S3 na VPC da AWS (provisionada usando o AWS PrivateLink) ou do ADLS Gen2 na rede virtual do Azure (VNet), provisionada usando o Azure Private Link.

Usar um ILB com várias interfaces de rede elásticas (ENIs) ou placas de rede (NICs) como back-ends é essencial para balanceamento de carga, escalonabilidade e alta disponibilidade. Isso se aplica se você usa o CCI dedicado ou a Interconexão por parceiro.

O fluxo de trabalho da consulta particular segue este processo:

  1. O BigQuery usa uma conexão configurada com um serviço do Diretório de Serviços.
  2. O Diretório de Serviços resolve o nome do serviço para o endereço IP interno do ILB do Google Cloud .
  3. O ILB recebe as solicitações do BigQuery e as distribui para os back-ends configurados.
  4. Os back-ends do ILB são grupos de endpoints de rede (NEGs) de conectividade híbrida, cada um apontando para o endereço IP particular de uma ENI na VPC da AWS ou uma NIC na VNet do Azure.
  5. O tráfego flui do ILB, pelos NEGs, pela interconexão privada, para as ENIs da AWS ou NICs do Azure.
  6. As ENIs da AWS, parte de um endpoint de interface de VPC do Amazon S3 (AWS PrivateLink), ou as NICs do Azure, parte de um endpoint privado do ADLS Gen2 (Azure Private Link), fornecem acesso privado ao serviço do Amazon S3 ou do ADLS Gen2.

Internet pública (sem CCI)

Se você não configurar uma interconexão particular, as consultas ao catálogo remoto vão passar pela Internet pública por padrão.

Ao consultar dados pela Internet pública, considere as seguintes implicações:

  • Criptografia padrão: as solicitações de acesso e as transferências de dados são criptografadas em trânsito usando protocolos TLS padrão na Internet pública.
  • Custos de saída: a transferência de dados gera cobranças padrão de saída de dados para a internet do seu provedor de nuvem remoto (por exemplo, AWS ou Azure), que normalmente são mais altas do que as taxas de saída de interconexão particular.
  • Latência variável: o desempenho, a largura de banda e a latência da rede dependem do roteamento e do congestionamento da Internet pública, o que resulta em tempos de execução de consulta menos previsíveis em comparação com uma interconexão dedicada particular.
  • Configuração simplificada: não requer infraestrutura de rede adicional, peering de VPC ou configuração do Diretório de Serviços no Google Cloud ou no provedor de nuvem remoto.

Informações gerais da arquitetura

Ao consultar dados pela Internet pública, o Lakehouse se conecta diretamente aos endpoints remotos de catálogo e armazenamento de objetos sem exigir uma infraestrutura de rede em nuvem privada Google Cloud ou remota.

O fluxo de trabalho de consulta da Internet pública segue este processo:

  1. O BigQuery inicia uma consulta em uma tabela remota definida no catálogo do Lakehouse.
  2. O Lakehouse se autentica com segurança no catálogo remoto do Apache Iceberg usando credenciais armazenadas no Secret Manager ou na federação de tokens OIDC.
  3. O Lakehouse recupera os metadados da tabela e os arquivos de manifesto pela Internet pública para identificar os arquivos de dados subjacentes relevantes (por exemplo, no Amazon S3 ou no ADLS Gen2).
  4. As solicitações de acesso a dados para os objetos subjacentes são enviadas diretamente do Google Cloud pela Internet pública usando a criptografia TLS padrão.
  5. O serviço de armazenamento remoto verifica a solicitação usando credenciais temporárias e com escopo vendidas pelo Lakehouse e retorna os blocos de arquivos solicitados pela Internet pública para o Google Cloud.

Armazenamento em cache inteligente

Para ajudar a reduzir os custos de saída entre nuvens e acelerar as consultas que leem os mesmos blocos de arquivos, é possível ativar o armazenamento em cache entre nuvens nos catálogos federados do Lakehouse e nas conexões entre nuvens do BigQuery sem custo financeiro adicional.

Quando você ativa o armazenamento em cache entre nuvens, o Lakehouse armazena em cache os blocos de arquivos recuperados do Amazon S3 ou do Armazenamento de Blobs do Azure localmente na região de execução de consultas do Google Cloud . As consultas subsequentes, incluindo consultas diferentes que segmentam os mesmos blocos de arquivos, são lidas diretamente do cache local, em vez de buscar novamente os arquivos da nuvem remota.

O Google gerencia automaticamente a capacidade, a retenção e a remoção do cache. A economia real de custos de saída depende dos padrões de consulta, da frequência com que os arquivos de origem mudam e da retenção de cache na região de destino do Google Cloud. Antes de exibir dados em cache, cada consulta verifica os metadados e as permissões de acesso com a fonte de armazenamento remoto para que você não leia dados desatualizados ou ignore permissões revogadas.

O armazenamento em cache entre nuvens está desativado por padrão. É possível ativar ou desativar o armazenamento em cache ao criar ou atualizar um catálogo federado do Lakehouse ou uma conexão entre nuvens do BigQuery. Para instruções de configuração, consulte o guia de configuração do seu provedor de catálogo compatível ou Criar conexões entre nuvens.

Verificar o uso do cache e a economia de custos de saída

Para verificar as taxas de ocorrência em cache e medir a economia de custos de saída, inspecione os detalhes do job no console do BigQuery ou verifique o campo objectStorageStats (object_storage_stats) nas estatísticas do job de consulta JobStatistics2 do BigQuery:

  • cloudProvider (cloud_provider): o provedor de nuvem que hospeda o repositório de objetos (por exemplo, AWS ou AZURE).
  • cacheBytesRead (cache_bytes_read): o total de bytes lidos do cache local do Google Cloud , evitando uma leitura de repositório de objetos remotos.
  • objectStorageBytesRead (object_storage_bytes_read): o total de bytes lidos diretamente do repositório de objetos do provedor de nuvem.

Para instruções sobre como recuperar essas métricas usando a ferramenta de linha de comando bq, consulte Monitorar o uso do cache e a economia de custos de saída.

Considerações sobre residência de dados e jurisdição

Quando você ativa o armazenamento em cache entre nuvens, o Lakehouse armazena temporariamente cópias em cache dos arquivos remotos em repouso na região do Google Cloud em que a consulta é executada. Antes de ativar o armazenamento em cache para arquivos localizados em outra região geográfica ou jurisdição (por exemplo, Amazon S3 ou Armazenamento de Blobs do Azure na União Europeia consultados no us-east4), verifique se o armazenamento de cópias temporárias em cache na região de destino Google Cloud atende aos requisitos de residência de dados e conformidade da sua organização.

Suporte à criptografia e CMEK

Os dados em cache são criptografados em repouso usando oGoogle-owned and Google-managed encryption keyspadrão. As chaves de criptografia gerenciadas pelo cliente (CMEK) não são compatíveis com o armazenamento em cache entre nuvens.

Se a organização aplicar a restrição da política da organização Restringir serviços que não usam CMEK (constraints/gcp.restrictNonCmekServices), o Lakehouse vai desativar automaticamente o armazenamento em cache para consultas que acessam tabelas restritas. As consultas ainda são executadas, mas leem diretamente do armazenamento remoto sem armazenar em cache os blocos de arquivos.

Modo de identidade

O Lakehouse é compatível com dois modos de identidade para acesso a dados entre nuvens:

  • Identidade de serviço (padrão): a atualização de metadados em segundo plano e as consultas são executadas usando a conta de serviço do catálogo, que pode ser configurada com autenticação baseada em OIDC (recomendado) ou em secret.

  • Federação de identidade do usuário: a atualização de metadados em segundo plano é executada usando a conta de serviço do catálogo, mas as consultas são executadas usando a identidade do usuário final e são propagadas para o catálogo remoto. Isso permite que o catálogo remoto atribua consultas de Google Cloud aos usuários finais, permitindo a aplicação de permissões e a geração registro de auditoria. A federação de identidade precisa ser configurada no catálogo remoto.

A seguir