18 min de leitura lakehousedata-lakedata-warehousedelta-lakeapache-icebergapache-hudidatabricksmicrosoft-fabricarquitetura-de-dadosengenharia-de-dados

A Revolução do Lakehouse: Devo Abandonar Data Lakes e Data Warehouses

Resumo

Este guia técnico examina a arquitetura Lakehouse — a convergência entre data lakes e data warehouses em uma única plataforma — e responde a uma pergunta prática: as organizações devem abandonar suas arquiteturas de duas camadas? A análise parte do paper fundacional publicado no CIDR 2021 e percorre os três pilares tecnológicos do Lakehouse (camadas de metadados transacionais, novos motores de consulta e acesso otimizado para ML/DS), compara as quatro grandes plataformas de nuvem — Databricks, Microsoft Fabric, AWS e Google Cloud — e os três formatos de tabela aberta (Delta Lake, Apache Iceberg e Apache Hudi), tudo sustentado por evidências acadêmicas e documentação oficial dos provedores.

1. O Problema que o Lakehouse Resolve

Para entender a revolução, é preciso entender o problema. A arquitetura dominante na indústria desde meados dos anos 2010 é a arquitetura de duas camadas: dados bruto vão para um data lake (armazenamento barato em formato aberto como Parquet) e um subconjunto é passado por um ETL novamente para um data warehouse (armazenamento proprietário otimizado para SQL e BI).

O paper fundacional do Lakehouse, publicado no CIDR 2021 por Armbrust, Ghodsi, Xin e Zaharia (pesquisadores da Databricks, UC Berkeley e Stanford), identifica quatro problemas estruturais dessa arquitetura:

  1. Confiabilidade: Manter o data lake e o warehouse consistentes é difícil e caro. ETLs contínuos entre os dois sistemas criam novos modos de falha.
  2. Obsolescência dos dados (data staleness): Os dados no warehouse estão sempre defasados em relação ao lake. Novos dados frequentemente levam dias para carregar.
  3. Custo total de propriedade (TCO): Além de pagar por ETLs contínuos, as organizações pagam armazenamento duplicado. Warehouses comerciais travam dados em formatos proprietários, aumentando o custo de migração.
  4. Suporte limitado a casos de uso: Data warehouses não são adequados para machine learning e data science. Ferramentas como TensorFlow, PyTorch e pandas não conseguem ler formatos proprietários de warehouses eficientemente, exigindo um terceiro ETL para exportar dados.

"In today's architectures, data is first ETLed into lakes, and then again ELTed into warehouses, creating complexity, delays, and new failure modes." — Armbrust et al., "Lakehouse: A New Generation of Open Platforms", CIDR 2021

Em paralelo, os data lakes puros tinham seus próprios problemas: sem transações ACID, sem enforcement de schema, sem isolamento consistente entre leituras e escritas — o que frequentemente levava ao fenômeno conhecido como data swamp (pântano de dados). A documentação oficial da Databricks resume: "Without governance and ACID support, data lakes suffer from poor data quality, inconsistent access controls, and reliability issues" (Databricks, 2026).

O Lakehouse surge como uma resposta a ambas as limitações: a rigidez e o custo do warehouse de um lado, e o caos e a falta de governança do lake do outro.

2. O que é um Lakehouse, Tecnicamente?

A definição formal do paper CIDR 2021 estabelece que um Lakehouse é caracterizado por três propriedades:

(i) Ser baseado em formatos de dados abertos e de acesso direto (como Apache Parquet e ORC); (ii) Oferecer suporte de primeira classe para workloads de machine learning e data science; (iii) Oferecer performance de estado da arte para consultas analíticas.

Tecnicamente, um Lakehouse implementa funcionalidades de gerenciamento de dados normalmente associadas a warehouses diretamente sobre armazenamento de data lake — ou seja, sobre object stores de baixo custo como Amazon S3, Azure Data Lake Storage (ADLS) ou Google Cloud Storage (GCS).

A inovação central não é um novo motor de consultas, mas sim uma camada de metadados transacional que adiciona:

  • Transações ACID sobre arquivos Parquet/ORC em object stores
  • Enforcement e evolução de schema
  • Time travel (consulta de versões históricas de tabelas)
  • Streaming I/O (eliminando a necessidade de barramentos de mensagens como Kafka para alguns casos)
  • Governança unificada (auditoria, controle de acesso)

Como a documentação do Microsoft Fabric descreve: "A lakehouse in Fabric combines the scalability of a data lake with the querying capabilities of a warehouse. You store structured and unstructured data in a single location, manage it with Delta Lake, and analyze it with both Apache Spark and SQL — all without moving data between systems" (Microsoft Learn, 2026).

3. A Arquitetura em Camadas

A arquitetura Lakehouse pode ser decomposta em cinco camadas funcionais:

Camada 1: Armazenamento (Object Store)

Armazenamento de baixo custo (S3, ADLS, GCS) que mantém os arquivos de dados em formatos abertos columnares (Parquet, ORC). Esta camada é stateless — não há motor de banco de dados embutido.

Camada 2: Camada de Metadados Transacional

Este é o coração da inovação. Sistemas como Delta Lake, Apache Iceberg e Apache Hudi adicionam um log de transações e metadados sobre os arquivos Parquet, rastreando quais arquivos pertencem a quais versões da tabela. Isso habilita ACID, versionamento e otimizações de leitura.

O paper CIDR 2021 descreve: "The first key idea we propose for implementing a Lakehouse is to have the system store data in a low-cost object store using a standard file format such as Apache Parquet, but implement a transactional metadata layer on top" (CIDR 2021).

Camada 3: Motor de Consultas

Motores de consultas modernos (Photon da Databricks, Presto/Trino, Spark SQL, BigQuery, Amazon Athena) que leem diretamente os arquivos abertos através da camada de metadados. A separação entre compute e storage permite que diferentes motores acessem os mesmos dados.

Camada 4: APIs de Acesso

Interfaces que incluem SQL, DataFrames declarativos (Spark DataFrames, pandas), e acesso direto a arquivos para ferramentas de ML (TensorFlow, PyTorch, scikit-learn).

Camada 5: Consumo

BI (Power BI, Tableau, Looker), data science (Jupyter notebooks), ML (treinamento de modelos), streaming (ingestão contínua) e aplicações operacionais.

A arquitetura resultante elimina o ETL entre lake e warehouse: uma única cópia dos dados serve para todos os workloads.

4. Os Três Pilares Tecnológicos

A viabilidade técnica do Lakehouse depende de três avanços identificados no paper fundacional:

Pilar 1: Camadas de Metadados (Delta Lake, Iceberg, Hudi)

Estas são as tecnologias que tornam possível ACID sobre object stores. Todas as três usam multi-version concurrency control (MVCC), mas diferem significativamente em implementação:

  • Delta Lake (Databricks): Armazena metadados em um log de transações (JSON + checkpoints em Parquet) ao lado dos dados. Processamento de metadados é distribuído via Spark. Oferece serializability e strict serializability.
  • Apache Iceberg (originalmente Netflix): Usa metadados hierárquicos em manifest files. Processamento de metadados em nó único, mas otimizado com índices. Oferece snapshot isolation e serializability.
  • Apache Hudi (Uber): Otimizado para upserts com chaves. Usa tabela de metadados com estratégia merge-on-read. Oferece snapshot isolation.

O paper comparativo de Jain et al. (CIDR 2023) da UC Berkeley e Stanford demonstra que Delta Lake roda TPC-DS 1.4x mais rápido que Hudi e 1.7x mais rápido que Iceberg em workloads equivalentes, embora cada formato tenha vantagens específicas (Jain et al., CIDR 2023).

Pilar 2: Novos Motores de Consulta

Motores como Photon (Databricks), Presto/Trino e o BigQuery advanced runtime (Google) alcançam performance competitiva com warehouses proprietários sobre dados em Parquet. As otimizações incluem:

  • Caching de dados quentes em RAM/SSDs (possível porque a camada de metadados garante consistência)
  • Otimização de layout de dados (clustering de dados co-acessados)
  • Estruturas de dados auxiliares (estatísticas, índices, column metadata indexes)
  • Execução vetorizada em CPUs modernas

O paper CIDR 2021 apresenta resultados de TPC-DS em scale factor 30.000 mostrando que o Delta Engine "outperforms leading cloud data warehouses" em AWS, Azure e Google Cloud (CIDR 2021).

Pilar 3: Acesso Otimizado para ML/DS

Formatos abertos como Parquet são naturalmente legíveis por ferramentas de ML. O Lakehouse adiciona versionamento e auditoria, que melhoram a reprodutibilidade de experimentos de ML — é possível rastrear exatamente qual versão da tabela foi usada em um experimento. A integração do Delta Lake com MLflow, por exemplo, permite que cientistas de dados registrem a versão da tabela usada e reproduzam o experimento posteriormente (Databricks, 2026).

5. As Quatro Plataformas: Comparativo

Databricks

A Databricks é a originadora do conceito e da implementação de referência. A plataforma combina:

  • Delta Lake como formato de tabela padrão (open source, mas com features avançadas exclusivas na plataforma Databricks como Liquid Clustering e Predictive I/O)
  • Photon como motor de execução vetorizado
  • Unity Catalog para governança unificada
  • Integração nativa com MLflow para ML

A Databricks descreve seu Lakehouse como uma plataforma que "combines the flexibility, cost-efficiency, and scale of data lakes with the data management and ACID transactions of data warehouses, enabling business intelligence (BI) and machine learning (ML) on all data" (Databricks, 2026).

Segundo o paper CIDR 2023, mais de 70% dos bytes escritos por clientes Databricks vão para Delta Lake, e as maiores tabelas Delta "span well into the hundreds of petabytes, consist of billions of files, and are updated with hundreds of terabytes of ingested data per day" (Jain et al., CIDR 2023).

Microsoft Fabric

O Microsoft Fabric é a plataforma unificada de analytics da Microsoft, construída sobre a arquitetura Lakehouse. Seus elementos-chave incluem:

  • OneLake: O data lake unificado (essencialmente ADLS Gen2 sob uma camada de virtualização) que serve como armazenamento único para toda a organização
  • Delta Lake como formato padrão para tabelas do Lakehouse
  • Acesso duplo: Spark (Python, Scala, SQL, R) para data engineering e T-SQL para analistas, sobre os mesmos dados
  • Shortcuts em OneLake: Acesso a dados externos sem cópia, incluindo cross-tenant
  • SQL analytics endpoint: Gerado automaticamente ao criar um Lakehouse, permitindo consultas T-SQL somente-leitura diretamente nas tabelas Delta
  • Medallion Architecture (Bronze/Silver/Gold) como padrão recomendado

A documentação oficial explica: "Both [lakehouse and warehouse] share the same SQL engine and store data in Delta format on OneLake" (Microsoft Learn, 2026). O Fabric também oferece um Warehouse separado (para modelagem dimensional e equipes SQL-first), mas ambos operam sobre o mesmo OneLake.

AWS

A AWS constrói seu Lakehouse sobre Amazon S3 como armazenamento, com Apache Iceberg como formato de tabela preferencial. Os componentes incluem:

  • Amazon S3: Armazenamento de objetos com zoneamento (raw, processed, curated)
  • AWS Glue Data Catalog: Catálogo de metadados central
  • AWS Lake Formation: Governança e controle de acesso
  • Amazon Athena: Consultas serverless sobre S3/Iceberg
  • Amazon Redshift: Para workloads de warehouse (com suporte a tabelas externas Iceberg)
  • Amazon S3 Tables: Tabelas Iceberg gerenciadas nativamente no S3 (recurso recente)
  • Amazon SageMaker: Para ML, com arquitetura Lakehouse documentada

A documentação oficial da AWS descreve: "The lakehouse architecture of Amazon SageMaker is a unified data architecture built on AWS's cloud-native infrastructure that bridges Amazon S3 data lakes and Amazon Redshift data warehouses into a cohesive analytics platform. The architecture leverages Apache Iceberg table format for cross-service interoperability" (AWS, 2026).

Google Cloud

O Google Cloud adota uma estratégia centrada em BigQuery + BigLake + Dataplex (agora renomeado para Knowledge Catalog):

  • BigLake: Runtime de armazenamento unificado sobre GCS, com suporte nativo a Apache Iceberg (GA) e interoperabilidade com Delta e Hudi
  • BigQuery: Motor analítico que lê e escreve dados Iceberg via BigLake, com features de warehouse proprietário (streaming de alta vazão, reclustering automático, multi-table transactions)
  • BigLake Metastore: Metastore gerenciado com Apache Iceberg REST Catalog API
  • Dataplex Universal Catalog (Knowledge Catalog): Governança unificada com IA (Gemini-enhanced knowledge graph), descoberta automática de metadados de BigQuery, Iceberg, Spanner, Vertex AI
  • AlloyDB: Banco operacional PostgreSQL que pode consultar os mesmos dados Iceberg do BigLake

A documentação do Google Cloud destaca: "The Google Data Cloud is a uniquely integrated platform built on Google's planet-scale infrastructure, infused with AI, and features an open lakehouse architecture for multimodal data" (Google Cloud, 2025). A adoção de BigLake Iceberg com BigQuery "has grown nearly 3x in 18 months, now managing hundreds of petabytes".

6. Delta Lake vs Apache Iceberg vs Apache Hudi

A escolha de formato de tabela é a decisão arquitetural mais importante de um Lakehouse. O paper comparativo de Jain et al. (CIDR 2023) oferece a análise acadêmica mais rigorosa:

Critério Delta Lake Apache Iceberg Apache Hudi
Origem Databricks Netflix Uber
Metadados Log tabular (JSON + Parquet checkpoints) Hierárquico (manifest files) Tabela de metadados
Processamento de metadados Distribuído (via Spark) Nó único Distribuído (via Spark)
Isolamento Serializability, Strict Serializability Snapshot Isolation, Serializability Snapshot Isolation
Estratégia de upsert Copy-on-Write (MoR planejado) CoW e MoR CoW e MoR
Otimizado para Performance de leitura, BI Ecossistema aberto, multi-engine Upserts com chave, CDC
Suporte multi-engine Bom (mas ecossistema Databricks) Excelente (engine-agnostic) Moderado
Performance TPC-DS Mais rápido (baseline) 1.7x mais lento que Delta 1.4x mais lento que Delta

Tendência de mercado: Apache Iceberg está se consolidando como o formato mais adotado em arquiteturas multi-cloud e multi-engine, suportado nativamente por AWS, Google, Snowflake, Trino, Spark, Flink e outros. Delta Lake domina no ecossistema Databricks. Hudi tem adoção forte em cenários de CDC (Change Data Capture).

7. A "Revolução": O que Mudou de Verdade?

A palavra "revolução" é frequentemente usada em marketing, mas há mudanças estruturais reais:

1. Fim da Duplicação de Dados

Na arquitetura de duas camadas, os dados existem em pelo menos dois lugares (lake + warehouse), frequentemente três (com export para ML). O Lakehouse elimina isso: uma cópia, múltiplos workloads.

2. Democratização de ACID sobre Storage Barato

Antes do Delta Lake/Iceberg/Hudi, ACID sobre object stores era considerado impossível ou impraticável. A camada de metadados transacional provou que é possível obter consistência transacional sem um DBMS proprietário.

3. Separar Compute de Storage — de Verdade

Enquanto cloud warehouses (Snowflake, BigQuery, Redshift) já separavam compute de storage, eles mantinham formatos proprietários. O Lakehouse estende essa separação ao formato de armazenamento: os dados estão em Parquet aberto, acessível por qualquer engine.

4. Convergência Warehouse ↔ Lake

O paper CIDR 2023 observa: "warehouse and lakehouse systems are converging, as both rely on low-cost object storage. However, unlike lakehouse storage formats, data warehouses do not provide directly accessible storage through an open data format" (Jain et al., CIDR 2023). Snowflake, BigQuery e Redshift todos adicionaram suporte a tabelas Iceberg — o warehouse está absorvendo características do lake.

5. ML como Cidadão de Primeira Classe

Warehouses tradicionais tratavam ML como afterthought (exportar dados via ETL). O Lakehouse posiciona ML ao lado de BI, no mesmo armazenamento, com as mesmas garantias de governança.

6. Open Table Formats como Padrão de Indústria

O surgimento de Apache Iceberg como padrão de fato para interoperabilidade — suportado por AWS, Google, Snowflake, Trino, Flink, Spark — é uma mudança de paradigma. Pela primeira vez, múltiplos vendors concordam em um formato de tabela aberto.

8. Devo Abandonar Data Lakes e Data Warehouses?

A resposta curta é: não, mas a forma como você os usa deve mudar.

Data Lakes não morrem — evoluem

Um data lake puro (Parquet/ORC sem camada transacional) ainda faz sentido para:

  • Arquivamento e compliance de dados brutos em longo prazo
  • Exploração inicial de dados não estruturados (imagens, vídeo, áudio, texto livre)
  • Zona de landing na arquitetura Medallion (camada Bronze)

O que muda é que a zona curada (Silver/Gold) agora usa formatos transacionais (Delta/Iceberg) em vez de Parquet puro. Em outras palavras: o lake continua existindo como infraestrutura, mas ganha uma camada de gestão.

Data Warehouses não morrem — convergem

Data warehouses tradicionais (Snowflake, BigQuery, Redshift) permanecem superiores em cenários específicos:

  • Modelagem dimensional complexa (star schemas, slowly changing dimensions)
  • Equipes SQL-first sem competência em Spark/Python
  • Workloads de BI de baixa latência (sub-segundo)
  • Conformidade regulatória que exige controles rigorosos de transação multi-tabela

No entanto, todos os grandes warehouses já suportam tabelas Iceberg externas, efetivamente tornando-se query engines sobre um lake. A documentação do Microsoft Fabric inclusive recomenda usar ambos no mesmo workspace: "land and transform data in a lakehouse with Spark, then expose curated datasets to a warehouse for SQL-based reporting" (Microsoft Learn, 2026).

O que realmente muda

A pergunta não é "lakehouse vs warehouse", mas sim:

  1. Onde seus dados residem? → Cada vez mais em formatos abertos (Iceberg/Delta) sobre object stores
  2. Qual motor os consulta? → Múltiplos motores, cada um otimizado para seu workload
  3. Quantas cópias você mantém? → O ideal: uma

O paper CIDR 2021 prevê: "the data warehouse architecture as we know it today will wither in the coming years and be replaced by a new architectural pattern, the Lakehouse" (CIDR 2021). A realidade em 2026 é mais matizada: warehouses não desapareceram, mas estão se transformando em motores de consulta sobre formatos abertos — efetivamente tornando-se parte de uma arquitetura lakehouse.

9. Limitações e Desafios do Lakehouse

A literatura acadêmica e a documentação técnica identificam desafios reais:

1. Transações Cross-Table

O paper CIDR 2021 admite: "Delta Lake, Iceberg and Hudi only support transactions on one table at a time, but it should be possible to extend them to support cross-table transactions" (CIDR 2021). Em 2026, BigQuery introduziu multi-table transactions (Preview), mas a maioria dos formatos abertos ainda não suporta transações ACID multi-tabela nativamente.

2. Performance de Metadados em Escala

O paper CIDR 2023 demonstra que Iceberg tem degradação de performance em tabelas com muitos arquivos pequenos porque faz processamento de metadados em nó único. Delta Lake, com processamento distribuído, escala melhor: "Delta Lake's distributed planning scales better and improves performance by 7–12× for a 200K file table" (Jain et al., CIDR 2023).

3. Complexidade de Multi-Engine

Embora formatos abertos permitam acesso multi-engine, na prática cada motor gera planos de consulta diferentes. O paper CIDR 2023 documenta que Spark "occasionally generates different query plans over data stored in Iceberg" vs Delta, devido a diferenças nas APIs (DSv2 vs DSv1) (Jain et al., CIDR 2023).

4. Maturidade do Ecossistema

Ferramentas de BI tradicionais ainda são otimizadas para warehouses. Conexões ODBC/JDBC a engines Lakehouse existem, mas a experiência de baixa latência para dashboards em tempo real ainda é superior em warehouses nativos.

5. Lock-in de Plataforma

Embora os formatos sejam abertos, features avançadas (Liquid Clustering da Databricks, BigQuery advanced runtime do Google, S3 Tables da AWS) criam lock-in funcional. Migrar tabelas Iceberg entre clouds é possível, mas as otimizações específicas de cada plataforma não são portáteis.

6. Custo de Migração

Migrar de uma arquitetura de duas camadas existente para Lakehouse requer reescrever pipelines de ETL, reestruturar modelagem de dados e treinar equipes. O TCO melhora a longo prazo, mas o investimento inicial é significativo.

10. Recomendações Práticas

Quando adotar Lakehouse como arquitetura primária:

  • Sua organização tem workloads mistos (BI + ML/DS) sobre os mesmos dados
  • O custo de duplicação de dados entre lake e warehouse é mensurável e significativo
  • Você precisa de multi-engine (Spark + SQL + Trino + Flink sobre os mesmos dados)
  • Sua estratégia inclui IA generativa e agentes sobre dados corporativos
  • Você está em greenfield (sem arquitetura legada a preservar)

Quando manter um warehouse dedicado:

  • Equipes de BI são exclusivamente SQL e não têm competência em Spark/Python
  • Workloads exigem latência sub-segundo para dashboards em tempo real
  • Há requisitos regulatórios de transações ACID multi-tabela
  • O warehouse já está otimizado e o custo de migração supera o benefício

Quando manter um data lake puro:

  • Para zoneamento de dados brutos (camada Bronze da Medallion)
  • Para dados não estruturados (imagens, vídeo, áudio)
  • Para arquivamento de longo prazo com custo mínimo

Estratégia híbrida (mais comum na prática):

A maioria das organizações está adotando uma abordagem incremental:

  1. Começar com novos workloads em Lakehouse (Iceberg ou Delta)
  2. Manter warehouses existentes para BI crítico
  3. Migrar gradualmente pipelines conforme o ROI é comprovado
  4. Usar warehouses como motores de consulta sobre tabelas Iceberg (já suportado por Snowflake, BigQuery, Redshift)

Referências

  1. Armbrust, M., Ghodsi, A., Xin, R., & Zaharia, M. (2021). Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics. Proceedings of CIDR 2021. Link

  2. Databricks. (2026). What is a Data Lakehouse? Databricks Blog/Documentation. Link

  3. Microsoft. (2026). What is a lakehouse in Microsoft Fabric? Microsoft Learn. Link

  4. Jain, P., Kraft, P., Power, C., Das, T., Stoica, I., & Zaharia, M. (2023). Analyzing and Comparing Lakehouse Storage Systems. Proceedings of VLDB/CIDR 2023. Link

  5. AWS. (2026). The lakehouse architecture of Amazon SageMaker. Amazon SageMaker Unified Studio User Guide. Link

  6. Gutmans, A., & Ahmad, Y. (2025). Google Cloud's open lakehouse: Architected for AI, open data, and unrivaled performance. Google Cloud Blog. Link

  7. Armbrust, M., et al. (2020). Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores. Databricks Technical Report. Link

  8. Databricks. (2025). Data Lakehouse Architecture. Databricks Product Page. Link

  9. Databricks. (2026). Databricks Reference Architectures. Databricks Documentation. Link

  10. Microsoft. (2026). Lakehouse end-to-end scenario: overview and architecture. Microsoft Learn. Link

  11. Microsoft. (2026). What is a Data Lakehouse? Microsoft Fabric Resources. Link

  12. AWS. (2026). Amazon S3 data lakes for the lakehouse architecture of Amazon SageMaker. AWS Documentation. Link

  13. AWS Builder Center. (2025). Build Lakehouse architecture on AWS with S3 Iceberg, AWS Services and Snowflake. Link

  14. Google Cloud. Data Lakehouse Solutions. Google Cloud Products. Link

  15. Google Cloud. (2026). Dataplex / Knowledge Catalog overview. Google Cloud Documentation. Link

  16. Google Cloud Skills. (2026). Build Data Lakes and Data Warehouses on Google Cloud. Curso. Link