Este documento define os principais termos e conceitos do Lakehouse para Apache Iceberg.
Esta página não é uma lista exaustiva de recursos, mas sim uma referência geral de termos e conceitos usados em toda a documentação do Lakehouse do Google Cloud.
Conceitos básicos
Os conceitos a seguir formam a base da arquitetura de data lakehouse do Google Cloud.
Data lakehouse
Um data lakehouse reúne a economia de custos e a flexibilidade de um data lake com o gerenciamento e o desempenho de dados de um data warehouse. Ele permite armazenar dados em formatos abertos no Cloud Storage e usar recursos do BigQuery, como controles de segurança precisos e consultas rápidas.
Interoperabilidade aberta
A interoperabilidade aberta é a capacidade de vários sistemas analíticos e transacionais, como BigQuery, Apache Spark e Apache Flink, operarem em uma única cópia de dados em formatos abertos, como o Apache Iceberg. Isso elimina a necessidade de duplicação de dados e garante uma visão consistente dos dados em ferramentas diferentes.
Catálogo de ambientes de execução do Lakehouse
O catálogo de ambientes de execução do Lakehouse é um serviço de metadados centralizado e sem servidor que atua como a única fonte de verdade para o Lakehouse do Google Cloud. Ele permite que vários mecanismos, como Apache Spark, Apache Flink e BigQuery, descubram e consultem as mesmas tabelas simultaneamente.
Tipos de catálogo
O catálogo de ambientes de execução do Lakehouse oferece diferentes tipos de catálogos para gerenciar seus metadados.
Endpoint do catálogo REST do Apache Iceberg
É um catálogo baseado no endpoint do catálogo REST do Apache Iceberg. Ele oferece interoperabilidade entre mecanismos de código aberto e o BigQuery, além de oferecer suporte a recursos como venda de credenciais e recuperação de desastres.
Catálogo personalizado do Apache Iceberg para BigQuery
Essa é uma integração que usa o catálogo do BigQuery diretamente como o serviço de metadados de suporte para tabelas gerenciadas do Apache Iceberg.
Endpoint do catálogo do Apache Hive
Esse endpoint 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), permitindo que você execute cargas de trabalho do Apache Hive ou do Spark em um serviço de metastore totalmente gerenciado noGoogle Cloud.
Tipos de tabela
O Lakehouse do Google Cloud é compatível com vários formatos de tabela, dependendo do mecanismo usado para gerenciar os dados e do endpoint do catálogo que você está usando.
Tabelas do Apache Iceberg
São tabelas do Apache Iceberg criadas com mecanismos de código aberto e armazenadas no Cloud Storage. O catálogo de ambientes de execução do Lakehouse gerencia essas tabelas pelo endpoint do catálogo REST do Apache Iceberg. Os mecanismos de código aberto têm acesso de leitura e gravação a essas tabelas, enquanto o BigQuery tem acesso somente leitura. Essa opção é ideal se você quer que seu fluxo de trabalho de ETL seja gerenciado por mecanismos de código aberto.
Tabelas do BigQuery
Essas tabelas são gerenciadas com o BigQuery.
Tabelas do Apache Iceberg
São tabelas do Apache Iceberg criadas no BigQuery e armazenadas no Cloud Storage. O BigQuery processa todo o layout e a otimização dos dados. Embora essas tabelas possam ser lidas por vários mecanismos, o BigQuery é o único que pode gravar diretamente nelas.
Tabelas nativas
Essas tabelas são gerenciadas pelo BigQuery e armazenam dados no armazenamento do BigQuery. É possível conectar essas tabelas ao catálogo de tempo de execução do Lakehouse.
Tabelas externas
As tabelas externas ficam fora do catálogo de ambientes de execução do Lakehouse. Os dados e metadados são autogerenciados em um catálogo de terceiros, como o Cloud Storage, o S3 ou o Armazenamento de Blobs do Azure. O BigQuery só pode ler essas tabelas.
Recursos de tabela
Evolução da tabela
O Lakehouse do Google Cloud é compatível com a evolução da tabela do Apache Iceberg, que permite mudar o esquema ou a especificação de partição de uma tabela ao longo do tempo sem reescrever ou recriar os dados dela.
Viagem no tempo
Com a viagem no tempo, é possível consultar os dados de uma tabela como eles existiam em um momento específico ou ID de snapshot. Isso é útil para auditoria, reprodução de experimentos ou restauração de dados após uma exclusão acidental.
Armazenamento em cache de metadados
O armazenamento em cache de metadados é um recurso que acelera o desempenho das consultas em tabelas externas. Ele armazena uma cópia dos metadados da tabela no armazenamento do BigQuery, reduzindo a necessidade de ler arquivos de metadados do Cloud Storage durante a execução da consulta.
Gerenciamento de tabelas do Lakehouse no Google Cloud
O gerenciamento de tabelas do Lakehouse do Google Cloud simplifica a manutenção do lakehouse automatizando tarefas como compactação e coleta de lixo para tabelas gerenciadas. Isso garante o desempenho ideal da consulta e a eficiência do armazenamento.
Conceitos de interoperabilidade
Federação do catálogo do BigQuery
Com a federação de catálogos do BigQuery, é possível usar o endpoint do catálogo REST do Apache Iceberg do catálogo de ambientes de execução do Lakehouse para expor tabelas gerenciadas pelo BigQuery, como tabelas gerenciadas pelo Iceberg, a mecanismos externos de código aberto (OSS, na sigla em inglês), como o Apache Spark e o Trino.
Em vez de criar um contêiner de catálogo dedicado do Lakehouse para armazenar metadados, o endpoint do catálogo REST do Apache Iceberg atua apenas como um gateway proxy, encaminhando solicitações de catálogo diretamente para o catálogo interno do BigQuery. Isso permite criar e gerenciar tabelas diretamente no BigQuery usando a DDL ou as APIs padrão do BigQuery, além de dar aos mecanismos OSS externos acesso somente leitura para consultar essas tabelas pelo endpoint do catálogo REST.
Lakehouse entre nuvens
O Lakehouse entre nuvens estende o Lakehouse do Google Cloud, permitindo que você se conecte a catálogos externos remotos (por exemplo, o Unity Catalog do Databricks ou o AWS Glue). Ele sincroniza metadados de outros provedores de nuvem, permitindo que você consulte dados com o BigQuery ou mecanismos externos de código aberto pelo endpoint do catálogo REST do Apache Iceberg, sem migrar os dados.
Conjuntos de dados públicos
O Lakehouse do Google Cloud hospeda conjuntos de dados públicos de alta qualidade disponibilizados pelo catálogo REST do Apache Iceberg, oferecendo acesso somente leitura para exploração e testes sem gerenciamento de infraestrutura.
Estrutura de nomenclatura P.C.N.T.
A estrutura de nomenclatura P.C.N.T. é a convenção de quatro partes usada para identificar e consultar tabelas de maneira exclusiva no catálogo de tempo de execução do Lakehouse no BigQuery. Ele significa Project.Catalog.Namespace.Table:
- Projeto: o ID do projeto Google Cloud .
- Catálogo: o nome do catálogo de ambientes de execução do Lakehouse.
- Namespace: o agrupamento lógico de tabelas (semelhante a um conjunto de dados).
- Tabela: o nome da tabela de dados.
Conceitos de segurança
Conexões
Uma conexão é um recurso do BigQuery que armazena credenciais para acessar dados externos. No Lakehouse do Google Cloud, as conexões delegam o acesso ao Cloud Storage permitindo que a conta de serviço da conexão acesse o bucket de armazenamento em seu nome.
Venda de credenciais
A venda de credenciais é um mecanismo de segurança que ajuda a restringir o controle de acesso ao usar o catálogo de ambientes de execução do Lakehouse. Quando ativado, o serviço gera credenciais de curta duração e escopo reduzido projetadas para conceder acesso apenas aos caminhos de arquivo específicos necessários para uma consulta.
Governança unificada
Com a governança unificada, é possível definir e aplicar políticas de segurança e gerenciamento de dados de forma centralizada por meio da integração com o Knowledge Catalog.
Conceitos de confiabilidade
Replicação entre regiões
A replicação entre regiões replica metadados em várias regiões para garantir a disponibilidade do catálogo durante interrupções regionais.
Failover
O failover é o processo de alternar entre regiões primárias e secundárias durante uma interrupção regional para manter as operações do catálogo.