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.

Como parte do Lakehouse sem fronteiras, esse recurso unifica as cargas de trabalho de análise e IA nos seus 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 com base 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.

Casos de uso

O Lakehouse é compatível com vários casos de uso importantes para acessar dados em vários provedores de nuvem:

  • A redução da movimentação de dados permite consultar dados armazenados em outros ambientes de nuvem diretamente, simplificando o acesso e o processamento de dados.
  • A análise unificada permite realizar análises avançadas com recursos consistentes e otimização de hardware em todos os seus dados, independentemente de onde eles estejam.
  • Com a IA e o ML sem fronteiras, é possível aplicar modelos de IA, agentes autônomos e machine learning diretamente aos dados remotos sem migrá-los.

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 os 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 no 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:
    • Nuvem externa e catálogos de SaaS: sincroniza metadados de catálogos de dados na nuvem (AWS Glue Data Catalog na AWS, Databricks Unity Catalog e Snowflake Horizon Catalog na AWS ou no Google Cloud) e nuvens de dados de 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).
    • Repositório de objetos em nuvem externa (AWS): armazena tabelas do Apache Iceberg (arquivos de dados do Parquet) e tabelas do Amazon S3 no Amazon S3 para leituras de método de bloqueio diretas 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 Lakehouse do Google Cloud se conecta a catálogos REST remotos do Apache Iceberg, como o Databricks Unity Catalog ou o AWS Glue. O Lakehouse descobre os dados sem copiar nenhum arquivo. Dependendo do provedor de catálogo remoto, o Lakehouse se autentica com segurança 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:à medida que as consultas leem dados de nuvens remotas, o Lakehouse armazena temporariamente esses segmentos de dados localmente no Google Cloud em um armazenamento especializado. As consultas subsequentes usam o cache local, o que evita uma parte significativa das cobranças de saída entre nuvens.

Catálogos compatíveis

O Lakehouse é compatível com a consulta de dados dos seguintes provedores de catálogo remoto:

Principais conceitos

Nesta seção, descrevemos os principais componentes essenciais para usar o recurso de acesso a dados entre nuvens.

Camada de metadados

A camada de metadados se conecta a endpoints remotos do catálogo REST do Apache Iceberg para sincronizar os metadados de recursos do Iceberg (namespace, tabela) com base em um intervalo de atualização. O Lakehouse se autentica com segurança com credenciais do OAuth armazenadas no Secret Manager ou na federação de tokens do OIDC.

Camada de transporte

A camada de transporte permite que o BigQuery e os mecanismos de código aberto consultem os dados usando os metadados sincronizados da camada de metadados. Para determinados tipos de catálogos remotos, 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 AWS Amazon S3 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 trafegam por uma conexão de rede privada entre o Google Cloud e a AWS, evitando a Internet pública.
  • Custos reduzidos:cobranças de saída potencialmente menores da AWS 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 da AWS usando sua interconexão particular. Um componente essencial na nuvem privada virtual (VPC) do Google Cloudé um balanceador de carga interno (ILB). O ILB distribui solicitações do BigQuery para os endpoints particulares do Amazon S3 na VPC da AWS, que são provisionados usando o AWS PrivateLink.

O uso de um ILB com várias interfaces de rede elástica (ENIs, na sigla em inglês) 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 de 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 privado de uma ENI na VPC da AWS.
  5. O tráfego flui do ILB, pelos NEGs, pela interconexão privada, até as ENIs da AWS.
  6. As ENIs da AWS, que fazem parte de um endpoint de interface de VPC do Amazon S3 (AWS PrivateLink), fornecem acesso privado ao serviço do Amazon S3.

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 da Internet do seu provedor de nuvem remoto (por exemplo, AWS), que geralmente são mais altas do que as taxas de saída de interconexão privada.
  • 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 repositório de objetos sem exigir 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 AWS Amazon S3).
  4. As solicitações de acesso aos dados dos 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 fornecidas pelo Lakehouse e retorna os blocos de dados solicitados pela Internet pública para o Google Cloud.

Armazenamento em cache inteligente

Quando você consulta dados remotos da nuvem, o Lakehouse armazena em cache automaticamente os blocos de dados recuperados localmente no Google Cloud. O armazenamento em cache é ativado automaticamente para todas as consultas entre nuvens para ajudar a minimizar as taxas de saída de provedores de nuvem remotos. As consultas subsequentes que segmentam dados armazenados em cache são lidas diretamente do armazenamento local do Google Cloud , em vez de buscar os dados novamente nas nuvens.

Economia de custos de saída

Na execução inicial da consulta, o Lakehouse busca os blocos de dados necessários no provedor de nuvem remoto e preenche o cache local. As consultas subsequentes que segmentam os mesmos blocos de dados são lidas diretamente do cache local doGoogle Cloud , em vez de buscar os dados novamente nas nuvens.

Para cargas de trabalho com padrões de consulta repetidos no mesmo conjunto de dados, o armazenamento em cache reduz as taxas de saída entre nuvens ao atender às solicitações de dados do armazenamento local. A economia real de custos de saída depende de fatores como padrões de acesso a consultas, taxas de modificação de dados e retenção de cache na região de destino do Google Cloud.

Como verificar o uso do cache e a economia de custos de saída nas estatísticas do job

Para verificar as taxas de ocorrência em cache e a economia de custos de saída de uma consulta, inspecione as estatísticas de consulta no console ou na API do BigQuery (JobStatistics2). Como uma consulta pode referenciar dados em vários provedores, as estatísticas do job fornecem um campo object_storage_stats (objectStorageStats) repetido com uma entrada para cada provedor de nuvem acessado durante a execução.

Cada entrada object_storage_stats informa as seguintes métricas:

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

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

Criar um catálogo ou uma conexão remota em uma região do Google Cloud armazena dados em repouso em cache localmente nessa região de destino.

Se os dados remotos na nuvem estiverem em uma região geográfica ou jurisdição diferente (por exemplo, AWS Amazon S3 na União Europeia pareado com a computação do BigQuery em us-east4), as consultas entre nuvens vão armazenar cópias em cache de dados em repouso dos dados remotos na região Google Cloud de destino. O usuário ou administrador que cria a conexão ou o catálogo precisa garantir que o armazenamento em cache entre jurisdições esteja em conformidade com os requisitos de residência de dados, soberania e compliance de dados da organização.

Suporte à criptografia e CMEK

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

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 não armazenam em cache blocos de dados nem se beneficiam da economia de saída relacionada ao cache.

A seguir