Sobre o acesso aos dados entre nuvens

O recurso de acesso aos dados entre nuvens permite consultar dados armazenados em outros provedores de nuvem diretamente do BigQuery Google Cloud sem migrar arquivos ou criar pipelines ETL complexos 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 os dados federados para insights e governança orientados por IA:

  • Análise conversacional: crie agentes especializados com base nas suas fontes de dados exatas, incluindo tabelas entre nuvens, para analisar dados em nuvens a partir de 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:

  • Movimentação de dados reduzida permite consultar dados armazenados em outros ambientes de nuvem diretamente, simplificando o acesso aos dados e o processamento.
  • Análise unificada : permite realizar análises avançadas com recursos consistentes e otimização de hardware em todos os dados, independentemente de onde eles estejam.
  • IA e ML sem fronteiras : permite aplicar modelos de IA, agentes autônomos e machine learning diretamente aos dados remotos sem migrá-los.

Como funciona o acesso a dados entre nuvens

O Lakehouse consulta dados remotos usando o seguinte processo:

  1. Descoberta de metadados: Google Cloud's Lakehouse se conecta a endpoints de catálogo REST do Apache Iceberg remotos, como o Databricks Unity ou o AWS Glue. O Lakehouse descobre os dados sem copiar arquivos. Dependendo do provedor de catálogo remoto, o Lakehouse autentica com segurança usando o Secret Manager ou a federação de tokens do OpenID Connect com o Google como provedor de identidade (federação de tokens OIDC).
  2. Transporte seguro:o roteamento de 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 em cache localmente em Google Cloud 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 oferece suporte à consulta de dados dos seguintes provedores de catálogo remoto:

  • Databricks Unity Catalog:com suporte na Amazon Web Services (AWS) e no Azure Google Cloud.
  • AWS Glue:com suporte na Amazon Web Services (AWS).
  • Snowflake Horizon Catalog:com suporte na Amazon Web Services (AWS) e Google Cloud.
  • SAP Business Data Cloud (BDC) : com suporte usando o conector SAP BDC.

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 de catálogo REST do Apache Iceberg remotos para sincronizar metadados de recursos do Iceberg (namespace, tabela) com base em um intervalo de atualização. O Lakehouse autentica com segurança usando credenciais 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 determinados tipos de catálogos remotos, o Lakehouse oferece suporte à consulta de dados pela Internet pública ou por uma interconexão privada dedicada.

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

De propriedade do cliente (CCI)

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

O uso de uma interconexão privada 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:potencialmente menores cobranças de saída da AWS em comparação com a saída da Internet, especialmente quando combinadas com a capacidade de interconexão privada.
  • Desempenho 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 a consulta privada, configure um caminho do BigQuery para o bucket do Amazon S3 da AWS pela interconexão privada. 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, que são provisionados usando o AWS PrivateLink.

O uso de um ILB com várias interfaces de rede elástica (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 privada 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 de o Google Cloud ILB.
  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, para as ENIs da AWS.
  6. As ENIs da AWS, 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 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 a 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 incorre em cobranças de saída da Internet padrão do 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 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 consulta 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 provedor de nuvem remoto.

Informações gerais da arquitetura

Ao consultar dados pela Internet pública, o Lakehouse se conecta diretamente aos endpoints de catálogo remoto e de armazenamento de objetos sem exigir infraestrutura de rede de 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 federada definida no catálogo do Lakehouse.
  2. O Lakehouse autentica com segurança com o 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 subjacentes relevantes (por exemplo, no Amazon S3 da AWS).
  4. As solicitações de acesso a dados para os 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 com escopo fornecidas pelo Lakehouse e retorna os blocos de dados solicitados pela Internet pública para Google Cloud.

Armazenamento em cache inteligente

Ao consultar dados de nuvem remotos, o Lakehouse armazena automaticamente em cache os blocos de dados recuperados localmente no BigQuery 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 direcionadas a dados armazenados em cache são lidas diretamente do armazenamento local Google Cloud em vez de buscar os dados novamente nas nuvens.

Economia de custos de saída

Na execução da consulta inicial, o Lakehouse busca os blocos de dados necessários do provedor de nuvem remoto e preenche o cache local. As consultas subsequentes direcionadas aos mesmos blocos de dados são lidas diretamente do cache Google Cloud local 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, atendendo à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 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 BigQuery (JobStatistics2). Como uma consulta pode referenciar dados em vários provedores, as estatísticas de jobs 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 de armazenamento de objetos remotos.
  • 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 Google Cloud região armazena dados em cache em repouso localmente nessa região de destino.

Se os dados da nuvem remota residirem 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), a consulta entre nuvens armazena cópias em cache de dados remotos em repouso na região de destino. Google 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 conformidade da organização.

Criptografia e suporte a 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 armazenados em cache são criptografados em repouso usando a criptografia padrão do BigQuery Google-owned and Google-managed encryption keys.

Se a organização aplicar a restrição de política da organização Restringir serviços não CMEK (constraints/gcp.restrictNonCmekServices), o Lakehouse desativará automaticamente o armazenamento em cache para consultas que acessam tabelas restritas. As consultas ainda são executadas corretamente, mas não armazenam blocos de dados em cache nem se beneficiam da economia de saída relacionada ao cache.

A seguir