Sobre o acesso aos dados entre nuvens

Com o recurso de acesso aos dados entre nuvens, é possível consultar dados armazenados em outros provedores de nuvem diretamente do Google Cloud sem migrar arquivos ou criar pipelines complexos de ETL com o Interconexão entre nuvens.

Como parte do Lakehouse sem fronteiras, esse recurso permite realizar análises unificadas e aplicar IA aos conjuntos de dados distribuídos usando o BigQuery, ambientes autônomos do Apache Spark ou o Serviço gerenciado para Apache Spark.

Além das consultas analíticas, é possível usar seus dados federados para insights e governança baseados em IA:

  • Análise conversacional: crie agentes especializados com base nas suas fontes de dados exatas, incluindo tabelas entre nuvens, para analisar dados em várias nuvens em uma única conversa.
  • Knowledge Catalog: use os recursos do Knowledge Catalog para criação de perfil de dados e insights com fontes de dados federadas.

Casos de uso

O lakehouse oferece suporte a vários casos de uso importantes para acessar dados em vários provedores de nuvem:

  • Com a redução da movimentação de dados, é possível consultar diretamente os dados armazenados em outros ambientes de nuvem, simplificando o acesso aos dados e o processamento.
  • Com a análise unificada, você realiza análises avançadas com recursos consistentes e otimização de hardware em todos os seus dados, não importa 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 seus dados remotos sem migrá-los.

Como funciona o acesso a dados entre nuvens

As consultas do data lakehouse acessam dados remotos usando o seguinte processo:

  1. Descoberta de metadados: Google Cloudo Lakehouse se conecta a catálogos REST remotos do Apache Iceberg, como Databricks Unity ou AWS Glue. O lakehouse descobre os dados sem copiar arquivos. Dependendo do provedor de catálogo remoto, o Lakehouse faz a autenticação de forma segura usando o Secret Manager ou a federação de tokens do OpenID Connect com o Google como provedor de identidade (federação de tokens do OIDC).
  2. Transporte seguro:ao optar por rotear o tráfego por uma interconexão particular (por exemplo, CCI dedicada ou Interconexão por parceiro), os custos de transferência de dados são significativamente reduzidos em comparação com a Internet pública, e a latência se torna altamente previsível.
  3. Execução otimizada:à medida que as consultas leem dados de nuvens remotas, o Lakehouse armazena em cache 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 permite consultar dados dos seguintes provedores de catálogo remoto:

Principais conceitos

Esta seção descreve os principais componentes essenciais para usar o recurso de acesso aos dados entre nuvens.

Camada de metadados

A camada de metadados se conecta a endpoints remotos do catálogo REST do Apache Iceberg para sincronizar metadados de recursos do Iceberg (namespace, tabela) com base em um intervalo de atualização. O Lakehouse faz a autenticação com segurança usando credenciais do OAuth armazenadas no Secret Manager ou na federação de tokens 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 alguns 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:

De propriedade do cliente (CCI)

É possível configurar o BigQuery para consultar dados armazenados em buckets do Amazon S3 do Amazon Web Services (AWS) usando um Interconexão entre nuvens privada, seja com a Cross-Cloud Interconnect dedicada ou a Cross-Cloud Interconnect por parceiro.

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

  • Segurança aprimorada:os dados viajam por uma conexão de rede privada entre Google Cloud e a AWS, evitando a Internet pública.
  • Custos reduzidos:taxas de saída potencialmente menores da AWS em comparação com a saída da Internet, especialmente quando combinadas com sua capacidade de interconexão privada.
  • Performance consistente:latência e largura de banda de rede mais previsíveis em comparação com a Internet pública.

Informações gerais da arquitetura

Para ativar consultas particulares, configure um caminho do BigQuery para seu bucket do Amazon S3 da AWS usando sua interconexão particular. Um componente essencial na Google Cloudnuvem privada virtual (VPC) é um balanceador de carga interno (ILB, na sigla em inglês). O ILB distribui solicitações do BigQuery para os endpoints particulares do Amazon S3 na sua VPC da AWS, que são provisionados usando o AWS PrivateLink.

Usar um ILB com várias interfaces de rede elásticas (ENIs) como back-ends é essencial para balanceamento de carga, escalonabilidade e alta disponibilidade. Isso se aplica ao uso da CCI dedicada ou da 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. Diretório de serviços resolve o nome do serviço para o endereço IP interno do ILB Google Cloud .
  3. O ILB recebe as solicitações do BigQuery e as distribui para 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 sua VPC da AWS.
  5. O tráfego flui do ILB, pelas NEGs, pela interconexão privada e até as ENIs da AWS.
  6. As ENIs da AWS, parte de um endpoint de interface de VPC do Amazon S3 (AWS PrivateLink), oferecem acesso privado ao serviço do Amazon S3.

Internet pública (sem CCI)

Se você não configurar uma interconexão privada, as consultas ao catálogo remoto vão viajar 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 aos dados 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 remota (por exemplo, AWS), que normalmente são mais altas do que as taxas de saída de interconexão privada.
  • Latência variável:o desempenho da rede, a largura de banda e a latência dependem do roteamento e do congestionamento da Internet pública, resultando em tempos de execução de consultas menos previsíveis em comparação com uma interconexão privada dedicada.
  • 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 remota.

Informações gerais da arquitetura

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

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

  1. O BigQuery inicia uma consulta em uma tabela federada definida no catálogo do Lakehouse.
  2. O Lakehouse faz a autenticação segura com seu 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 na Internet pública para identificar os arquivos de dados relevantes (por exemplo, no AWS Amazon S3).
  4. As solicitações de acesso aos dados dos objetos subjacentes são enviadas diretamente de 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 limitadas vendidas pelo Lakehouse e retorna os blocos de dados solicitados pela Internet pública para 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 em Google Cloud. O armazenamento em cache é ativado automaticamente para todas as consultas entre nuvens, ajudando a minimizar as taxas de saída de provedores de nuvem remotos. Consultas subsequentes que têm como destino dados armazenados em cache são lidas diretamente do armazenamento local Google Cloud em vez de buscar os dados novamente em nuvens.

Economia de custos de saída

Na execução inicial da consulta, o Lakehouse busca os blocos de dados necessários do provedor de nuvem remota e preenche o cache local. As consultas subsequentes que têm como destino os mesmos blocos de dados são lidas diretamente do cacheGoogle Cloud local em vez de buscar os dados novamente em várias 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 atendendo a 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 Google Cloud.

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

Para verificar as ocorrências em 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 de 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 armazenamento de objetos (por exemplo, AWS ou AZURE).
  • cache_bytes_read (cacheBytesRead): o total de bytes lidos do cache Google Cloud local, evitando uma leitura remota do armazenamento de objetos.
  • object_storage_bytes_read (objectStorageBytesRead): o total de bytes lidos diretamente do armazenamento de objetos do provedor de nuvem remoto.

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

A criação de um catálogo ou conexão federada em uma região 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 computação do BigQuery em us-east4), a consulta entre nuvens armazenará cópias em cache de dados remotos em repouso na região de destinoGoogle Cloud . 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 da organização.

Criptografia e suporte para CMEK

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

Se a organização aplicar a restrição de 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 com sucesso, mas não armazenam em cache blocos de dados nem se beneficiam das economias de saída relacionadas ao cache.

A seguir