Lakehouse architecture: unindo data lake e data warehouse com Delta Lake

1. Fundamentos da Arquitetura Lakehouse

O conceito de Lakehouse surgiu como resposta a uma dor crescente no ecossistema de dados: a necessidade de unificar o melhor dos dois mundos — a flexibilidade e baixo custo dos Data Lakes com a confiabilidade e performance dos Data Warehouses. Tradicionalmente, organizações mantinham pipelines separados: um Data Lake para armazenar dados brutos em formatos como Parquet, Avro ou JSON, e um Data Warehouse para consultas analíticas estruturadas. Essa separação gerava complexidade operacional, inconsistências e altos custos de manutenção.

A arquitetura Lakehouse propõe uma única plataforma de dados que combina:
- Armazenamento escalável e de baixo custo (como S3, ADLS ou GCS)
- Formato aberto e transacional (Delta Lake, Apache Iceberg ou Apache Hudi)
- Motor de consulta unificado (Apache Spark, Trino, Dremio)
- Governança e catálogo centralizado (Unity Catalog, Hive Metastore)

O Delta Lake é a peça central dessa arquitetura, atuando como uma camada de armazenamento transacional sobre dados em Parquet, adicionando suporte a ACID, versionamento e controle de concorrência.

2. Problemas Clássicos que o Lakehouse Resolve

Inconsistência de dados e falta de ACID

Data Lakes tradicionais não oferecem garantias transacionais. Operações concorrentes podem levar a leituras inconsistentes ou dados corrompidos. Por exemplo, se um job de escrita falha no meio, o dado fica parcialmente escrito sem mecanismo de rollback.

Unificação de dados heterogêneos

Empresas precisam processar dados estruturados (tabelas SQL), semiestruturados (JSON, logs) e não estruturados (imagens, áudio). Manter dois sistemas separados para isso é custoso e propenso a erros.

Custos e complexidade de pipelines híbridos

Manter um Data Lake + Data Warehouse demanda times distintos, ferramentas ETL diferentes e replicação de dados. O Lakehouse elimina essa duplicidade.

3. Delta Lake: A Camada de Transação e Versionamento

Internamente, o Delta Lake é implementado como um formato de arquivo baseado em Parquet, acrescido de um log de transações (armazenado em _delta_log/). Esse log registra todas as operações (inserções, atualizações, exclusões) como arquivos JSON, permitindo:

  • Propriedades ACID: atomicidade, consistência, isolamento e durabilidade
  • Controle de concorrência otimista: múltiplos escritores podem operar simultaneamente, e conflitos são resolvidos via retry
  • Time travel: consultas a versões anteriores dos dados

Exemplo de consulta histórica:

-- Restaurar estado de uma tabela para versão 5
RESTORE TABLE eventos TO VERSION AS OF 5;

-- Consultar dados de 3 dias atrás
SELECT * FROM eventos TIMESTAMP AS OF '2024-01-15';

4. Componentes Chave de uma Arquitetura Lakehouse

Catálogo de dados

O catálogo gerencia metadados, esquemas e linhagem. Unity Catalog (Databricks) e Hive Metastore são opções populares.

Motor de consulta unificado

Apache Spark é o motor mais comum, mas Trino e Dremio também oferecem suporte nativo a Delta Lake.

Camada de governança

RBAC (controle de acesso baseado em funções), auditoria de acessos e linhagem de dados são essenciais para conformidade.

5. Padrões de Ingestão e Transformação com Delta Lake

Ingestão incremental com CDC

Change Data Capture (CDC) captura alterações em bancos de dados transacionais e as aplica ao Lakehouse via streaming.

-- Ingestão streaming com Auto Loader (Databricks)
CREATE OR REFRESH STREAMING TABLE bronze_eventos
AS SELECT * FROM cloud_files(
  '/mnt/datalake/raw/eventos/',
  'json',
  map('cloudFiles.inferColumnTypes', 'true')
);

Transformações com merge e schema evolution

O comando MERGE permite upserts eficientes:

MERGE INTO silver_clientes AS target
USING bronze_clientes_atualizados AS source
ON target.id = source.id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

Otimização de performance

  • Z-Ordering: reorganiza dados fisicamente para acelerar filtros
  • Compactação: mescla pequenos arquivos em arquivos maiores
  • Particionamento: por data, região ou outra chave de alta cardinalidade
OPTIMIZE silver_vendas
ZORDER BY (produto_id, data_venda);

6. Casos de Uso Práticos e Exemplos de Código

Exemplo 1: Criando tabela Delta com particionamento

CREATE TABLE bronze_pedidos (
  id INT,
  cliente_id INT,
  valor DECIMAL(10,2),
  data_pedido DATE,
  status STRING
)
USING DELTA
PARTITIONED BY (data_pedido)
LOCATION '/mnt/datalake/bronze/pedidos/';

Exemplo 2: Time travel para auditoria

-- Consultar versão anterior para auditoria
SELECT cliente_id, COUNT(*) AS total_pedidos
FROM bronze_pedidos VERSION AS OF 10
GROUP BY cliente_id;

-- Restaurar tabela para estado anterior
RESTORE TABLE bronze_pedidos TO VERSION AS OF 10;

Exemplo 3: Merge para upsert de streaming

MERGE INTO gold_metricas_diarias AS target
USING (
  SELECT data, produto_id, SUM(valor) AS receita
  FROM silver_vendas
  WHERE data = current_date()
  GROUP BY data, produto_id
) AS source
ON target.data = source.data AND target.produto_id = source.produto_id
WHEN MATCHED THEN UPDATE SET target.receita = source.receita
WHEN NOT MATCHED THEN INSERT *;

7. Comparação com Arquiteturas Tradicionais e Modernas

Característica Lambda Architecture Kappa Architecture Lakehouse
Caminhos de processamento Batch + Stream (2 pipelines) Apenas streaming Unificado (batch + streaming)
Consistência Eventual Eventual ACID
Complexidade operacional Alta Média Baixa a média
Suporte a ML Limitado Limitado Nativo
Custo de armazenamento Alto (duplicação) Médio Baixo

O Lakehouse supera a Lambda ao eliminar a duplicação de pipelines e a complexidade de sincronização entre batch e streaming. Comparado à Kappa, oferece melhor suporte a dados históricos e consultas ad-hoc.

8. Boas Práticas e Considerações Finais

Governança e catalogação

  • Use Unity Catalog ou Apache Atlas para linhagem e metadados
  • Implemente RBAC para controle de acesso granular
  • Habilite auditoria de acesso para conformidade (GDPR, LGPD)

Monitoramento de custos e desempenho

  • Em AWS S3, monitore custos de requisições LIST e GET
  • Em Azure Data Lake, use camadas de acesso (hot/cool/archive)
  • Em GCS, otimize com armazenamento Nearline para dados históricos

Roadmap para migração

  1. Avaliação: mapeie fontes de dados e pipelines existentes
  2. Piloto: migre um domínio de negócio para Lakehouse
  3. Padronização: defina convenções de nomenclatura e particionamento
  4. Automação: implemente pipelines CI/CD para deploy de tabelas Delta
  5. Governança: estabeleça políticas de retenção e versionamento

A arquitetura Lakehouse com Delta Lake representa o estado da arte para plataformas de dados modernas, combinando escalabilidade, confiabilidade e baixo custo. Organizações que adotam esse modelo conseguem acelerar a entrega de insights, reduzir custos operacionais e simplificar sua stack de dados.

Referências