Como o Lakehouse funciona

A arquitetura técnica do Lakehouse para Apache Iceberg 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 de alta performance no Cloud Storage.

  • Catálogo:o catálogo de ambiente de execução do lakehouse oferece uma única fonte de verdade para gerenciar 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 ambientes 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 garantir a portabilidade da carga de trabalho e evitar a dependência de fornecedores.

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

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

Hierarquia de recursos

O Lakehouse do Google Cloud organiza os dados usando uma hierarquia que se alinha aos padrões do Apache Iceberg e aos conceitos de banco de dados padrão. Essa estrutura permite que o catálogo de ambientes 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 abaixo.

  1. Catálogo de ambientes 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 tempo 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 os 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 por um arquivo metadata.json do Apache Iceberg.

Pontos de extremidade compatíveis

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

  • Endpoint do catálogo REST do Apache Iceberg:oferece 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 de lakehouse.

  • Endpoint do catálogo do Apache Hive: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 ambientes de execução do Lakehouse serve como o serviço de metadados regionais de nível superior em Google Cloud. Ele funciona como o contêiner raiz que hospeda suas instâncias de catálogo individuais, centralizando a descoberta de metadados em diferentes mecanismos de consulta.

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

Catálogo

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

As principais características dos catálogos incluem:

  • Associação de armazenamento:só é possível associar um catálogo a um único bucket do Cloud Storage.
  • Replicação regional:a região de um catálogo corresponde automaticamente à região do bucket do Cloud Storage 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 e com escopo reduzido sejam geradas automaticamente em vez de conceder aos usuários permissões diretas de bucket.

Namespace

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

As principais características dos namespaces incluem:

  • Regionalidade:quando você cria um namespace, ele usa automaticamente a mesma região do catálogo principal.
  • Limitações de aninhamento:namespaces aninhados (subnamespaces) não são compatíveis.
  • 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, você pode escolher entre os seguintes tipos de tabela:

Compatível com o catálogo de ambientes de execução do Lakehouse

Recomendado

  • Tabelas do Apache Iceberg:tabelas do Apache Iceberg criadas com mecanismos de código aberto e armazenadas no Cloud Storage. Eles oferecem compatibilidade e gerenciamento abertos pelo endpoint REST do catálogo de ambientes de execução do Lakehouse.

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, enquanto 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 tempo de execução do lakehouse para permitir a interoperabilidade com mecanismos de código aberto.
  • Tabelas externas:tabelas fora do catálogo de tempo de execução do Lakehouse em que os dados e metadados são autogerenciados. Eles oferecem suporte ao acesso delegado por 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 Visão geral da tabela.

Formatos de tabela compatíveis

Somente tabelas do Apache Iceberg V2 são aceitas. As tabelas do Iceberg V1 não são compatíveis. Se você tiver tabelas do Iceberg V1, faça upgrade para a V2 (por exemplo, executando ALTER TABLE catalog.schema.table SET TBLPROPERTIES ('format-version'='2'); ou usando operações de mecanismo semelhantes) antes de usá-las com o Lakehouse para Apache Iceberg.

Sequência de processamento de consultas

Quando você envia uma consulta para a tabela do data lakehouse do Google Cloud, a solicitação segue um caminho específico para aplicar políticas e recuperar metadados antes do processamento dos dados.

  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 do catálogo de tempo 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 com o Identity and Access Management (IAM) e políticas de segurança refinadas.
  4. Resposta de metadados:o catálogo retorna os metadados. Se a venda de credenciais estiver ativada, ela também vai 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 arquitetar 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 conformados e ouro para agregações selecionadas no nível empresarial). Use o BigQuery para a camada de consumo ouro e maximize 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 não interativas do Apache Spark sem servidor, atribua nomes personalizados de lote e job. Isso melhora a observabilidade, facilitando a filtragem e o rastreamento das execuções de jobs no Cloud Logging e no console Google Cloud .
  • Ative a geração de registros de diagnóstico:para pipelines complexos de engenharia de dados, ative os pacotes de diagnóstico e garanta que os registros de driver e executor sejam mantidos para simplificar a solução de problemas e a capacidade de suporte.

A seguir