A história das arquiteturas de dados corporativas pode ser contada em três atos. Primeiro vieram os data warehouses, projetados nos anos 1990 para consolidar dados estruturados de sistemas transacionais em um único repositório otimizado para consultas analíticas. Funcionavam bem enquanto os dados eram tabulares, previsíveis e cabiam em schemas rígidos. Depois vieram os data lakes, impulsionados pela explosão de dados não estruturados, logs de aplicações, eventos de IoT e conteúdo de redes sociais. O Hadoop e, posteriormente, o armazenamento em object storage como S3, GCS e ADLS permitiram guardar tudo, de qualquer formato, a custos drasticamente menores. E agora estamos no terceiro ato: a convergência.

A Lakehouse Architecture não é apenas uma evolução incremental. Ela representa uma mudança de paradigma na forma como organizações armazenam, processam e consomem dados. Ao combinar a flexibilidade e a economia do data lake com o rigor transacional e a performance do data warehouse, o lakehouse elimina a necessidade de manter dois sistemas separados e sincronizados — uma fonte histórica de complexidade operacional, inconsistência de dados e custos inflados. Neste artigo, vamos dissecar a arquitetura, entender cada camada e avaliar quando faz sentido adotá-la.

O dilema: Data Lake vs Data Warehouse

Antes de entender o lakehouse, é essencial compreender por que a indústria precisou dele. Data warehouses e data lakes nasceram para resolver problemas diferentes, e cada um carrega limitações inerentes ao seu design original.

O data warehouse é uma máquina de precisão. Ele impõe schema-on-write: os dados precisam ser limpos, transformados e modelados antes de serem carregados. Isso garante consistência, performance de query previsível e governança nativa. Plataformas como Snowflake, BigQuery e Redshift evoluíram essa proposta com separação de compute e storage, escalabilidade elástica e suporte a SQL padrão. Mas o warehouse tem custos de armazenamento significativamente mais altos que object storage, e sua rigidez de schema torna caro e lento incorporar novas fontes de dados, especialmente quando são semi-estruturadas ou não estruturadas. Além disso, workloads de data science e machine learning que precisam de acesso a dados brutos em formato Parquet, JSON ou Avro encontram fricção ao tentar operar dentro do paradigma do warehouse.

O data lake, por outro lado, é o oposto filosófico. Ele aceita qualquer dado, em qualquer formato, sem exigir transformação prévia (schema-on-read). O custo de armazenamento em S3, GCS ou ADLS é uma fração do custo de um warehouse. Engenheiros de dados podem ingerir terabytes de logs, arquivos CSV, JSONs aninhados e imagens sem se preocupar com modelagem dimensional. O problema? Sem governança nativa, o data lake rapidamente se transforma em um data swamp — um pântano de dados onde ninguém sabe o que existe, quais datasets são confiáveis e qual versão de uma tabela é a correta. Não há transações ACID, não há enforcement de schema, e queries analíticas diretamente sobre arquivos Parquet distribuídos em milhares de partições são ordens de magnitude mais lentas do que no warehouse.

O resultado prático? A maioria das empresas acabou mantendo os dois sistemas simultaneamente: um lake para ingesta e data science, e um warehouse para BI e reporting. Isso gera duplicação de dados, pipelines de sincronização frágeis entre os dois ambientes, custos dobrados de infraestrutura e, inevitavelmente, divergência nos números — porque o dashboard do BI aponta para o warehouse enquanto o modelo de ML aponta para o lake, e os dois nem sempre concordam.

O que é Lakehouse Architecture?

A arquitetura Lakehouse foi formalizada por pesquisadores da Databricks em 2020, embora o conceito já viesse sendo construído pela comunidade de data engineering nos anos anteriores. A ideia central é elegante: adicionar uma camada de metadados transacionais sobre o data lake, trazendo as garantias do warehouse para o armazenamento barato e flexível do object storage.

Na prática, um lakehouse armazena todos os dados — brutos, transformados e agregados — em object storage (S3, GCS, ADLS) usando formatos abertos como Parquet e ORC. Sobre esses arquivos, uma camada de table format (Delta Lake, Apache Iceberg ou Apache Hudi) adiciona funcionalidades que antes eram exclusivas de warehouses:

  • Transações ACID: leituras e escritas concorrentes são isoladas, eliminando leituras sujas e corrupção de dados durante atualizações.
  • Schema enforcement e evolution: novos dados são validados contra o schema existente antes da escrita. Quando o schema precisa mudar, a evolução é gerenciada sem quebrar consumidores downstream.
  • Time travel: cada transação cria uma versão imutável da tabela, permitindo consultar o estado dos dados em qualquer ponto no passado, auditar mudanças e fazer rollback se necessário.
  • Otimização de queries: estatísticas de coluna, data skipping, Z-ordering e file compaction permitem que motores SQL executem queries analíticas com performance comparável à de um warehouse dedicado.
  • Acesso direto por BI e ML: ferramentas de BI (Power BI, Looker, Tableau) e frameworks de ML (Spark MLlib, PyTorch, TensorFlow) acessam os mesmos dados, sem duplicação.

O lakehouse não é um produto — é um padrão arquitetural. Você pode implementá-lo com diferentes combinações de tecnologias, o que significa que não há vendor lock-in obrigatório. Essa é uma diferença fundamental em relação ao data warehouse proprietário tradicional.

Medallion Architecture: Bronze, Silver e Gold

A Medallion Architecture é o padrão de organização de dados mais adotado dentro do paradigma lakehouse. Ela divide o fluxo de dados em três camadas progressivas de qualidade, cada uma com responsabilidades e SLAs distintos. Pense nela como uma linha de montagem: os dados entram brutos de um lado e saem prontos para consumo do outro.

Camada Bronze (Raw)

A camada Bronze é o ponto de entrada. Ela recebe os dados exatamente como chegam das fontes — APIs, bancos transacionais, arquivos flat, eventos de streaming, webhooks — sem nenhuma transformação. Os dados são armazenados em formato append-only, preservando o histórico completo de cada ingesta. Mesmo que uma fonte envie dados duplicados ou com erros, tudo é registrado tal qual chegou. Isso é fundamental para auditoria, reprocessamento e depuração de problemas nos pipelines downstream.

Exemplo prático: uma tabela bronze.orders contém cada registro de pedido exatamente como a API do ERP retornou, incluindo campos nulos, timestamps em fusos horários diferentes e eventuais duplicatas. Metadados como _ingested_at, _source_system e _batch_id são adicionados para rastreabilidade.

Camada Silver (Cleaned & Enriched)

A camada Silver é onde a engenharia de dados faz seu trabalho mais crítico. Os dados da Bronze são limpos, deduplicados, tipados corretamente e validados contra regras de qualidade. Joins entre fontes diferentes acontecem aqui: pedidos são enriquecidos com dados de clientes, produtos com informações de categoria, eventos com dimensões de tempo. O schema é enforced e versionado. A camada Silver representa a single source of truth da organização — o dataset confiável que qualquer equipe pode consumir com segurança.

Exemplo prático: a tabela silver.orders agora tem pedidos deduplicados por order_id, timestamps normalizados para UTC, campos nulos tratados com defaults ou regras de negócio, e um join com silver.customers que adiciona customer_segment e customer_region. Testes automatizados com dbt ou Great Expectations validam unicidade, completude e ranges esperados a cada execução.

Camada Gold (Business-Ready)

A camada Gold contém agregações e modelagens orientadas a casos de uso específicos. Aqui vivem as métricas de negócio calculadas, os datasets dimensionais para dashboards, os feature stores para modelos de ML e os datasets de reporting regulatório. Cada tabela Gold tem um consumidor claro e um SLA definido.

Exemplo prático: gold.monthly_revenue_by_region agrega receita mensal por região com base nos dados da Silver, aplicando regras de negócio como exclusão de pedidos cancelados e tratamento de devoluções. gold.customer_360 consolida dados de pedidos, interações de suporte e engajamento digital em uma visão única do cliente para o time de CRM.

Tecnologias do ecossistema Lakehouse

O ecossistema de tecnologias que viabiliza a arquitetura Lakehouse evoluiu rapidamente nos últimos anos. Três open table formats lideram a adoção e merecem atenção de qualquer engenheiro de dados que esteja avaliando essa arquitetura.

Delta Lake, criado pela Databricks e agora projeto open-source sob a Linux Foundation, foi o pioneiro em trazer transações ACID para o data lake. Seu transaction log baseado em JSON oferece time travel, schema enforcement e merge operations eficientes. É a escolha natural para quem já opera no ecossistema Databricks ou Spark.

Apache Iceberg, originado no Netflix e também sob a Apache Software Foundation, foi desenhado com foco em interoperabilidade. Seu catálogo de metadados aberto permite que diferentes motores de query — Spark, Trino, Presto, Flink, Dremio — acessem as mesmas tabelas sem conflito. Iceberg se tornou o formato preferido de organizações que querem evitar lock-in a um único vendor ou motor de processamento. A adoção explodiu após Snowflake, BigQuery e AWS anunciarem suporte nativo.

Apache Hudi (Hadoop Upserts Deletes and Incrementals), criado pelo Uber, foca em cenários de ingesta incremental e upserts de alta frequência. Ideal para pipelines CDC (Change Data Capture) onde registros de bancos transacionais precisam ser refletidos no lake em near-real-time.

No nível de plataforma, as principais opções são Databricks (lakehouse nativo com Delta Lake integrado, Unity Catalog para governança e Spark otimizado), Snowflake (que evoluiu de warehouse puro para suportar Iceberg Tables e workloads de data engineering), e Google BigQuery (com BigLake unificando queries sobre Cloud Storage e tabelas nativas). A decisão entre open table format e plataforma proprietária depende do grau de autonomia que a organização deseja manter, da maturidade do time de engenharia e do ecossistema de ferramentas já existente.

Benefícios concretos do Lakehouse

Além da elegância arquitetural, o lakehouse entrega benefícios tangíveis e mensuráveis que justificam a migração:

  • Redução de custos de 50-70%: armazenar dados em object storage com formatos abertos custa uma fração do armazenamento em warehouse proprietário. Empresas que migram de um modelo warehouse-centric para lakehouse frequentemente reportam economias nessa faixa, especialmente em datasets históricos de grande volume que raramente são consultados mas precisam ser retidos.
  • Single source of truth: ao eliminar a duplicação entre lake e warehouse, os números do dashboard de BI e os dados que alimentam modelos de ML vêm da mesma tabela. Isso acaba com as reuniões improdutivas onde metade do tempo é gasta debatendo qual número está certo.
  • Unificação de batch e real-time: o mesmo table format suporta tanto pipelines batch (ETL noturno com dbt + Spark) quanto streaming (Spark Structured Streaming, Flink) escrevendo na mesma tabela com garantias ACID. Não é necessário manter duas infraestruturas paralelas.
  • ACID no data lake: transações atômicas eliminam leituras sujas, partições corrompidas e os temidos "dados parciais" que aparecem quando um pipeline falha no meio de uma escrita.
  • Arquitetura simplificada: menos sistemas para manter significa menos integrações para monitorar, menos credenciais para gerenciar, menos pontos de falha e uma superfície de ataque menor para a equipe de segurança.

Quando usar Lakehouse?

A arquitetura Lakehouse não é uma bala de prata — mas é a escolha certa para um perfil crescente de organizações. Avalie a adoção se sua empresa se encaixa em um ou mais dos cenários abaixo.

Dados em escala: se você processa mais de alguns terabytes por dia ou armazena datasets históricos na casa dos petabytes, o custo diferencial entre object storage e warehouse storage se torna significativo o suficiente para justificar a migração. Quanto maior o volume, maior a economia.

Workloads mistos (BI + ML): se sua organização tem tanto equipes de BI construindo dashboards quanto equipes de data science treinando modelos, o lakehouse elimina a necessidade de duplicar dados entre os dois mundos. Analistas acessam tabelas Gold via SQL e conectores de BI, enquanto cientistas de dados consomem dados Silver diretamente em notebooks com PySpark ou pandas.

Problemas de qualidade de dados: se sua empresa sofre com dados inconsistentes entre sistemas, dashboards que quebram porque schemas mudaram sem aviso ou métricas que divergem entre departamentos, a camada de schema enforcement e data contracts do lakehouse endereça essas dores diretamente.

Pressão por redução de custos: se o CFO está questionando o crescimento da fatura de cloud, especialmente custos de warehouse, a migração para lakehouse oferece uma narrativa clara de ROI: mesmos dados, mesma governança, metade do custo de armazenamento.

Necessidade de real-time e batch no mesmo ambiente: se você mantém pipelines batch para reports e uma infraestrutura de streaming separada para alertas ou dashboards operacionais, o lakehouse unifica os dois em uma única arquitetura, reduzindo complexidade operacional.

Como a Preditiva implementa Lakehouse

Na Preditiva, tratamos a implementação de Lakehouse como um projeto de engenharia de dados completo, não como uma migração de ferramenta. Começamos com um assessment da sua arquitetura atual, mapeando fontes de dados, padrões de consumo, volumes, latências requeridas e maturidade do time. A partir disso, desenhamos a arquitetura target com as camadas Bronze, Silver e Gold, definimos o table format mais adequado (Delta Lake, Iceberg ou Hudi), escolhemos a plataforma de processamento e implementamos os pipelines de forma iterativa.

Nossa equipe de Data Engineering tem experiência comprovada na construção de lakehouses em produção com bilhões de registros, incluindo pipelines batch e streaming, testes automatizados de data quality e observabilidade end-to-end. Para a camada de infraestrutura, trabalhamos com Cloud & Infraestrutura para garantir que o ambiente seja seguro, escalável e otimizado em custo, utilizando IaC com Terraform e monitoramento proativo.

O resultado é uma arquitetura de dados moderna que escala com o seu negócio, reduz custos de infraestrutura e entrega dados confiáveis para toda a organização — do dashboard do CEO ao feature store do time de data science.