Sobre o lakehouse entre nuvens

O Lakehouse entre nuvens para Apache Iceberg permite consultar dados armazenados em outros provedores de nuvem diretamente do BigQuery sem migrar arquivos ou criar pipelines ETL complexos. Google Cloud

Como parte do Lakehouse, esse recurso permite realizar análises unificadas e aplicar IA aos conjuntos de dados distribuídos usando o BigQuery, ambientes Apache Spark independentes 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:

  • O movimento de dados reduzido permite consultar dados armazenados em outros ambientes de nuvem diretamente, simplificando o acesso aos dados e o processamento.
  • A 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.
  • A IA e o ML entre nuvens permitem aplicar modelos de IA, agentes autônomos e machine learning diretamente aos dados remotos sem migrá-los.

Como o Lakehouse entre nuvens funciona

O Lakehouse entre nuvens consulta dados remotos usando o seguinte processo:

  1. Descoberta de metadados: Google Cloud's Lakehouse se 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 autentica com segurança pelo Secret Manager ou pela 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 entre nuvens oferece suporte à consulta de dados dos seguintes provedores de catálogo remoto:

  • Catálogo do Unity do Databricks: com suporte na Amazon Web Services (AWS) e Google Cloud.
  • AWS Glue:com suporte na 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. Por meio da federação de tokens OIDC ou das credenciais OAuth, o Lakehouse autentica com segurança 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 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) por 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 o Google Cloud e a AWS, evitando a Internet pública.
  • Custos reduzidos:taxas de saída potencialmente mais baixas 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 se você usar a CCI dedicada ou a 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 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 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 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 pela Internet pública para identificar os arquivos de dados subjacentes relevantes (por exemplo, no Amazon S3 da AWS).
  4. As solicitações de acesso aos 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 o Google Cloud.

A seguir