Arquitetura dos Dados

Durante algum tempo, imaginei que Data Lake e Data Lakehouse fossem apenas nomes diferentes para a mesma ideia. Ambos armazenam grandes volumes de dados, utilizam arquivos distribuídos e aparecem praticamente em toda arquitetura moderna de Engenharia de Dados. Parecia apenas mais uma mudança de nomenclatura criada pelo mercado.

Quanto mais estudei o assunto, entretanto, mais percebi que essa mudança aconteceu por um motivo muito específico. O Data Lake não deixou de funcionar. Ele apenas começou a ser usado para resolver problemas que nunca havia sido projetado para resolver.

Foi justamente dessa tentativa de expandir seus limites que nasceu o conceito de Data Lakehouse.

Tudo começou com uma ideia bastante simples

Vamos falar com exemplo pra facilitar um pouco, imagine uma empresa que produz dados continuamente: pedidos realizados, cliques em um aplicativo, logs de servidores, arquivos CSV enviados por fornecedores, imagens, vídeos, dados de sensores IoT.

Em vez de decidir antecipadamente como cada informação seria utilizada, surgiu uma proposta muito atraente. Guardar tudo. Foi exatamente essa a promessa dos primeiros Data Lakes. Em vez de transformar os dados antes do armazenamento, como acontecia nos Data Warehouses tradicionais, o Data Lake permitia armazenar praticamente qualquer formato de arquivo.

Data Lake
📄 CSV
📊 Parquet
🧾 JSON
📁 XML
📷 Imagens
🎥 Vídeos
📜 Logs
📦 Avro

A ideia era simples, armazenar primeiro, descobrir como utilizar depois. Durante muitos anos isso representou uma mudança enorme na Engenharia de Dados.

O problema apareceu quando tudo começou a crescer

No início, parecia uma solução perfeita, armazenamento barato, escalabilidade praticamente ilimitada, capacidade de guardar qualquer tipo de dado. Mas, conforme empresas passaram a depender cada vez mais desses ambientes, novos problemas começaram a surgir.

Como garantir que dois analistas enxergassem exatamente a mesma versão dos dados? Como impedir que uma atualização interrompida deixasse uma tabela inconsistente? Como alterar o esquema de uma tabela sem reprocessar milhares de arquivos? Como executar atualizações e remoções em bilhões de registros?

Foi justamente aqui que percebi uma característica interessante, o Data Lake sabia armazenar arquivos, mas não sabia administrar tabelas.

Um Data Lake nunca foi um banco de dados

Essa foi provavelmente a ideia que mais mudou minha forma de enxergar o assunto. Quando armazenamos um arquivo Parquet em um Data Lake, estamos apenas gravando um arquivo. Nada garante automaticamente que outro processo não sobrescreva esse mesmo arquivo. Não existe controle de transações, não existe versionamento, não existe rollback, não existe isolamento entre múltiplos processos escrevendo simultaneamente.

E se dois pipelines tentam atualizar a mesma tabela?

Pipeline A
        │
        ▼
 vendas.parquet
        ▲
        │
Pipeline B

Quem vence? Qual versão permanece? Se um processo falhar no meio da escrita, o que acontece?

Durante muito tempo, essas perguntas precisavam ser resolvidas pela própria aplicação, e isso tornava arquiteturas cada vez mais complexas.

Foi então que alguém teve uma ideia interessante

Em vez de transformar o Data Lake em um banco de dados…

…por que não adicionar apenas as funcionalidades que estavam faltando?

Foi exatamente essa lógica que deu origem aos chamados Open Table Formats. Projetos como Apache Iceberg, Delta Lake e Apache Hudi passaram a adicionar uma camada de metadados sobre os arquivos já existentes. Os dados continuavam armazenados no Data Lake, mas agora existia alguém responsável por organizar tudo.

             Data Lakehouse

        ┌────────────────────┐
        │ Metadados          │
        │ Transações         │
        │ Versionamento      │
        │ Schema Evolution   │
        └────────────────────┘
                 │
                 ▼
      Arquivos Parquet no Data Lake

Percebi que essa mudança era muito mais elegante do que eu imaginava. Os arquivos praticamente não mudaram, o que mudou foi a inteligência colocada sobre eles.

Um exemplo ajuda bastante

Imagine uma tabela de pedidos.

pedidos

No Data Lake tradicional, essa tabela poderia ser apenas uma pasta.

pedidos/
part-001.parquet
part-002.parquet
part-003.parquet

Agora digamos que um pipeline precise atualizar milhares de registros. No modelo antigo, isso normalmente significava reescrever arquivos inteiros. Com um formato como Apache Iceberg (um formato de código aberto de alto desempenho para tabelas analíticas massivas, que facilita o uso de tabelas SQL para big data), existe uma camada de metadados informando exatamente quais arquivos fazem parte daquela versão da tabela.

Tabela Pedidos
        │
Snapshot 37
        │
┌──────────────┐
part-001
part-002
part-004
└──────────────┘

Quando uma atualização acontece, novos arquivos são criados, depois, basta atualizar o ponteiro do snapshot. O resultado é uma operação praticamente atômica.

Essa ideia me lembrou bastante conceitos estudados em bancos de dados. Em vez de modificar diretamente os dados, modificamos primeiro a referência para eles.

Foi aqui que o termo Lakehouse começou a fazer sentido

Durante muito tempo achei que Lakehouse fosse apenas uma estratégia de marketing. Hoje vejo de outra forma. Um Data Lakehouse continua sendo um Data Lake, os mesmos arquivos, o mesmo armazenamento distribuído, o mesmo baixo custo.

A diferença é que agora ele também oferece características que antes pertenciam apenas aos Data Warehouses.

• Transações ACID
• Controle de concorrência
• Evolução de esquema
• Time Travel
• Versionamento
• Atualizações e remoções eficientes

Curiosamente, ninguém precisou abandonar o Data Lake, ele apenas ganhou uma nova camada de inteligência.

O que essa mudança alterou na minha forma de pensar

Antes de estudar esse assunto, eu imaginava que Data Lakehouse fosse uma tecnologia completamente diferente. Hoje tenho a impressão de que ele representa algo muito mais interessante, mostra como boas soluções de engenharia raramente substituem tudo aquilo que já existe.

Na maioria das vezes, elas reutilizam uma base sólida e resolvem apenas aquilo que ainda estava faltando. O Data Lake continuou armazenando arquivos, quem mudou foi a forma como passamos a organizá-los. Talvez seja justamente por isso que essa evolução tenha sido tão rápida.

Empresas não precisaram migrar petabytes de informação para outro sistema, bastou adicionar uma camada capaz de transformar um enorme repositório de arquivos em algo muito mais próximo de um banco de dados analítico.

No fim das contas, acho que essa é a verdadeira história do Data Lakehouse, ele não substituiu o Data Lake, só respondeu à pergunta que os próprios Data Lakes passaram a fazer conforme amadureciam: Como podemos continuar armazenando dados como arquivos, mas administrá-los como tabelas?

Trecho de código

Uma tabela Iceberg sendo criada no Spark.

CREATE TABLE vendas (
    id BIGINT,
    cliente STRING,
    valor DECIMAL(10,2),
    data_venda DATE
)
USING iceberg;

A partir daí, atualizações passam a funcionar como em um banco relacional.

UPDATE vendas
SET valor = valor * 1.05
WHERE data_venda >= '2026-01-01';

Quem já tentou fazer esse tipo de operação diretamente sobre arquivos Parquet entende imediatamente o salto que isso representa.