Sobre o lakehouse entre nuvens

Com o Lakehouse entre nuvens para Apache Iceberg, é possível consultar dados armazenados em outros provedores de nuvem diretamente do Google Cloud sem migrar arquivos ou criar pipelines de ETL complexos.

Como parte do Lakehouse, essa capacidade 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.

Casos de uso

O Lakehouse entre nuvens 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 entre nuvens, é possível aplicar modelos de IA, agentes autônomos e machine learning diretamente aos seus dados remotos sem migrá-los.

Como funciona o lakehouse entre nuvens

As consultas do Lakehouse entre nuvens consultam dados remotos usando o seguinte processo:

  1. Descoberta de metadados:o Lakehouse do Google Cloudse conecta a catálogos REST remotos do Apache Iceberg, 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 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 entre nuvens permite consultar dados dos seguintes provedores de catálogo remoto:

  • Catálogo do Unity do Databricks:compatível com a Amazon Web Services (AWS) e o Google Cloud.
  • AWS Glue:compatível com a Amazon Web Services (AWS).

Principais conceitos

Esta seção descreve os principais componentes essenciais para usar o Lakehouse entre nuvens.

Catálogos REST remotos do Apache Iceberg

Essa é a camada de metadados. Você se conecta a catálogos REST remotos do Apache Iceberg. O lakehouse descobre os dados sem copiar arquivos. Com a federação de tokens OIDC ou credenciais OAuth, o Lakehouse faz a autenticação de forma segura sem exigir chaves de acesso de longa duração.

Camada de transporte

Essa é a camada de transporte. É possível configurar o Lakehouse para consultar dados armazenados em provedores de nuvem remotos 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) por uma conexão de rede privada e dedicada usando o Cross-Cloud Interconnect ou a Interconexão 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 nuvem privada virtual (VPC) do Google Cloudé 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 o balanceamento de carga, a escalonabilidade e a 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 em 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 remota na nuvem.

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.

A seguir