Como funciona o lakehouse sem fronteiras

A arquitetura técnica do Lakehouse sem fronteiras oferece suporte à interoperabilidade entre mecanismos, centralizando o gerenciamento de metadados e processando consultas por caminhos específicos.

Arquitetura

A criação do Lakehouse do Google Cloud consiste nos seguintes componentes técnicos:

  • Armazenamento:o Cloud Storage e o armazenamento do BigQuery servem como a camada de armazenamento, com o Apache Iceberg como o formato de tabela aberta recomendado para armazenamento interoperável e de alta performance no Cloud Storage.

  • Catálogo:o catálogo de ambiente de execução do Lakehouse fornece uma única fonte de verdade para o gerenciamento de metadados. Ele centraliza a descoberta de metadados em vários mecanismos usando várias opções de compatibilidade, como o endpoint do catálogo REST do Apache Iceberg. Os registros de tabelas no catálogo registram automaticamente entradas no catálogo de conhecimento de metadados comerciais.

  • Mecanismo de consulta:o BigQuery e os mecanismos de código aberto, incluindo Apache Spark, Apache Flink e Trino, interoperam perfeitamente ao se conectar ao catálogo de ambiente de execução do Lakehouse. Mecanismos de computação, como o Serviço Gerenciado para Apache Spark, usam o Apache Spark de código aberto com otimizações de execução para ajudar a garantir a portabilidade da carga de trabalho e evitar o bloqueio de fornecedores.

  • Governança:o Knowledge Catalog oferece segurança, linhagem e políticas de governança centralizadas em todo o lakehouse.

  • Ferramentas de gravação e análise de dados:mecanismos e ferramentas integrados oferecem vários caminhos para ingestão de dados e análise, ajudando a garantir o acesso aos dados consistente para cientistas de dados e analistas.

Hierarquia de recursos

O Lakehouse do Google Cloud organiza os dados usando uma hierarquia alinhada aos padrões do Apache Iceberg e aos conceitos de banco de dados padrão. Essa estrutura permite que o catálogo de ambiente de execução do Lakehouse mapeie identidades lógicas para caminhos de armazenamento físico. Para interagir com essa hierarquia de recursos e conectar seus mecanismos de consulta ao catálogo, use endpoints específicos, conforme descrito na lista a seguir.

  1. Catálogo de ambiente de execução do Lakehouse: o recurso de serviço regional de nível superior em Google Cloud que hospeda seus metadados. Para conectar mecanismos de consulta a esse serviço e gerenciar catálogos subjacentes, configure aplicativos cliente usando um endpoint de catálogo específico, como o endpoint do catálogo REST do Apache Iceberg.
  2. Catálogo: um contêiner lógico no serviço de catálogo de ambiente de execução. Na estrutura de nomenclatura Projeto/Catálogo/Namespace/Tabela (P.C.N.T), isso representa a instância de catálogo específica que você está consultando.
  3. Namespace: um agrupamento lógico de tabelas em um catálogo. Para usuários familiarizados com o BigQuery, um namespace é funcionalmente semelhante a um conjunto de dados.
  4. Tabela: a entidade específica que aponta para dados no Cloud Storage. Os metadados da tabela contêm o esquema, as informações de particionamento e um ponteiro para o estado atual da tabela em um arquivo metadata.json do Apache Iceberg.

Pontos de extremidade compatíveis

O catálogo de ambiente de execução do Lakehouse fornece vários endpoints para conectar seus dados no Cloud Storage e no BigQuery.

  • Endpoint do catálogo REST do Apache Iceberg: fornece uma interface REST padrão para ampla compatibilidade com mecanismos de código aberto, como Apache Spark, Apache Flink, e Trino. Essa é a interface recomendada para novas cargas de trabalho e oferece interoperabilidade completa de leitura e gravação.

  • Catálogo personalizado do Apache Iceberg para endpoint do BigQuery:permite que os mecanismos interoperem diretamente com o catálogo do BigQuery. Essa interface é usada principalmente para tabelas do Apache Iceberg gerenciadas pelo BigQuery e cargas de trabalho atuais que estão fazendo a transição para a arquitetura Lakehouse.

  • Endpoint do catálogo do Apache Hive (pré-lançamento) : oferece compatibilidade para cargas de trabalho de código aberto que dependem da interface do metastore do Apache Hive (HMS, na sigla em inglês). Isso permite executar cargas de trabalho do Apache Hive ou do Spark em um serviço de metastore totalmente gerenciado no Google Cloud.

Catálogo de ambientes de execução do Lakehouse

Na hierarquia de recursos, o catálogo de ambiente de execução do Lakehouse serve como o serviço de metadados regional de nível superior em Google Cloud. Ele atua como o contêiner raiz que hospeda suas instâncias de catálogo individuais, centralizando a descoberta de metadados em mecanismos de consulta diferentes.

Ele implementa a API de catálogo REST do Apache Iceberg de código aberto para gerenciar namespaces e tabelas e fornece extensões especificamente para gerenciamento de catálogos.

Para mais detalhes sobre o serviço de metastore, incluindo os principais recursos, mecanismos compatíveis, configuração de endpoint e limitações, consulte Sobre o catálogo de ambiente de execução do Lakehouse.

Catálogo

Um catálogo é um contêiner de metastore lógico com suporte de locais de data warehouse do Cloud Storage. Na estrutura de nomenclatura Project.Catalog.Namespace.Table (P.C.N.T), o catálogo representa a instância de metastore exclusiva que conecta os metadados da tabela aberta aos mecanismos de consulta.

As principais características dos catálogos incluem o seguinte:

  • Associação de armazenamento:a relação entre um catálogo e o armazenamento subjacente depende do tipo de catálogo configurado.
  • Replicação regional:a região de um catálogo corresponde automaticamente à região do bucket subjacente.
  • Delegação de acesso:os administradores podem ativar a venda de credenciais no catálogo para delegar o acesso, permitindo que credenciais de curta duração com escopo reduzido sejam geradas automaticamente em vez de conceder permissões diretas de bucket aos usuários.

Namespace

Um namespace é um agrupamento lógico de tabelas em um catálogo, funcionando de maneira semelhante a um banco de dados, esquema ou conjunto de dados do BigQuery. Ele fornece uma estrutura para organizar e gerenciar controles de acesso para tabelas.

As principais características dos namespaces incluem o seguinte:

  • Regionalidade:quando você cria um namespace, ele usa automaticamente a mesma região do catálogo pai.
  • Flexibilidade de local:as opções para especificar locais de namespace personalizados são determinadas pelo tipo de data warehouse do catálogo.
  • Limitações de aninhamento:namespaces aninhados (subnamespaces) não são aceitos.
  • Limites de segurança:é possível conceder papéis do IAM no nível do namespace para gerenciar o acesso a todas as tabelas contidas nele.

Tabelas

Ao criar com o Lakehouse do Google Cloud, é possível escolher entre os seguintes tipos de tabela:

Com suporte do catálogo de ambiente de execução do Lakehouse

Recomendado

  • Tabelas do Apache Iceberg:tabelas do Apache Iceberg criadas em mecanismos de código aberto e armazenadas no Cloud Storage. Elas oferecem compatibilidade e gerenciamento abertos pelo endpoint REST do catálogo de ambiente de execução do Lakehouse. Para garantir que não haja duas tabelas no mesmo local, os caminhos de tabela personalizados precisam ser aninhados no caminho do namespace pai, e os locais de tabela resultantes recebem automaticamente um sufixo de string aleatório para evitar conflitos.

    Formatos de tabela com suporte

    As tabelas do Apache Iceberg V2 (GA) e V3 (pré-lançamento) são aceitas. As tabelas do Iceberg V1 não são aceitas. Antes de usar tabelas V1 atuais com o Lakehouse, é necessário fazer upgrade delas para uma versão compatível. Para mais informações, consulte Fazer upgrade de tabelas do Iceberg V1 para V2.

Com suporte do BigQuery

  • Tabelas do Apache Iceberg:tabelas do Apache Iceberg criadas e gerenciadas pelo BigQuery. Os metadados dessas tabelas são armazenados no catálogo do BigQuery, e os dados da tabela e os metadados físicos são armazenados no Cloud Storage.
  • Tabelas nativas:tabelas totalmente gerenciadas pelo BigQuery que podem ser conectadas ao catálogo de ambiente de execução do Lakehouse para permitir a interoperabilidade com mecanismos de código aberto.
  • Tabelas externas:tabelas fora do catálogo de ambiente de execução do Lakehouse em que os dados e metadados são autogerenciados. Elas oferecem suporte ao acesso delegado por meio de conexões para dados armazenados no Cloud Storage, no Amazon S3 ou no Azure Blob Storage.

Para uma comparação detalhada dessas opções, consulte Entender os tipos e recursos de tabelas.

Sequência de processamento de consultas

Quando você envia uma consulta a uma tabela do Apache Iceberg gerenciada pelo Lakehouse, a solicitação segue um caminho específico para aplicar políticas e recuperar metadados antes que os dados sejam processados.

  1. Envio:você envia uma consulta SQL a um mecanismo compatível, como Apache Spark, Trino ou BigQuery.
  2. Solicitação de metadados:o mecanismo solicita metadados da tabela no catálogo de ambiente de execução do Lakehouse para identificar a tabela e o local dos metadados.
  3. Autorização: se compatível com o endpoint que você está usando, o catálogo valida a solicitação em relação ao Identity and Access Management (IAM) e às políticas de segurança detalhadas.
  4. Resposta de metadados:o catálogo retorna os metadados. Se a venda de credenciais estiver ativada, ela também fornecerá um token de curta duração para ajudar no acesso seguro ao armazenamento.
  5. Recuperação de dados:o mecanismo usa os metadados e o token opcional para ler arquivos de dados diretamente do Cloud Storage.
  6. Execução:o mecanismo processa os dados e retorna os resultados.

Práticas recomendadas

Ao criar e operar um data lakehouse no Google Cloud, considere as seguintes práticas recomendadas:

  • Adote uma arquitetura medallion:estruture seu data warehouse em camadas lógicas progressivas (bronze para ingestão bruta, prata para dados limpos e conformes e ouro para agregações selecionadas no nível comercial). Use o BigQuery para a camada de consumo de ouro para maximizar a performance e a simultaneidade das consultas.
  • Use modelos de sessão para cargas de trabalho interativas:para análises exploratórias e criação de notebooks, use modelos de sessão para padronizar as configurações de ambiente em equipes de desenvolvimento e reduzir a configuração repetitiva.
  • Atribua identificadores de lote personalizados:ao enviar cargas de trabalho em lote do Apache Spark sem servidor não interativas, atribua nomes de lote e job personalizados. Isso melhora a observabilidade, o que ajuda a filtrar e acompanhar as execuções de job no Cloud Logging e no Google Cloud console.
  • Ative o registro de diagnóstico:para pipelines complexos de engenharia de dados, ative pacotes de diagnóstico e ajude a garantir que os registros de driver e executor sejam mantidos para ajudar na solução de problemas e na capacidade de suporte.

A seguir