Data warehouse, lakehouse e OneLake: qual arquitetura de dados escolher

O problema que aparece antes de qualquer decisão de arquitetura#

A discussão data warehouse vs lakehouse quase nunca começa como discussão de arquitetura. Começa com um sintoma: duas planilhas com o número de faturamento do mês divergindo em 8%, um relatório de Power BI que demora quinze minutos para atualizar, ou um time de dados que passa mais tempo copiando arquivo de um lugar para outro do que analisando alguma coisa. Nesse ponto, alguém pergunta "onde a gente deveria estar guardando os dados", e a resposta depende de decisões que a maioria das empresas nunca parou para tomar de propósito.

Esse artigo existe para destravar essa decisão com critério prático, não com jargão: comparamos data warehouse, data lake e lakehouse, explicamos a arquitetura medalhão (bronze, silver, gold), a diferença entre ETL e ELT, o papel do OneLake dentro do Microsoft Fabric e, principalmente, quando cada modelo faz sentido para o seu volume de dados, seu time e seu orçamento.

Data warehouse: o modelo que ainda resolve a maioria dos casos#

O data warehouse é a arquitetura mais antiga das três e, para boa parte das empresas brasileiras de porte médio, ainda é a resposta certa. Ele guarda dados estruturados, em tabelas com esquema definido antes da carga (schema-on-write), otimizado para consultas SQL rápidas e para relatórios tabulares. Exemplos: SQL Server, Azure Synapse Dedicated SQL Pool, o item Warehouse do Microsoft Fabric.

A força do warehouse está na sua rigidez. Como o esquema é definido antes do dado entrar, a qualidade é validada na porta de entrada, o modelo dimensional (fatos e dimensões) fica previsível, e ferramentas de BI como o Power BI consultam volumes grandes com performance consistente. A fraqueza é a mesma rigidez: dado semiestruturado (JSON de API, log de aplicação, evento de sensor) não cabe bem num warehouse sem transformação prévia cara, e mudar o esquema depois que o sistema está em produção costuma ser um projeto, não uma tarefa.

Data lake: barato, flexível, e um risco real de virar pântano#

O data lake nasceu para resolver justamente o que o warehouse não resolve bem: guardar qualquer tipo de dado, estruturado ou não, sem exigir esquema definido antes da gravação (schema-on-read). Arquivos de log, imagens, PDFs, eventos de IoT, exportações brutas de sistema, tudo pode entrar no lake em formato nativo, geralmente em armazenamento de objeto barato como o Azure Data Lake Storage ou o Amazon S3.

O ganho de custo e flexibilidade é real. O risco também é, e tem nome consolidado no mercado: "data swamp", o pântano de dados. Sem governança, sem catálogo, sem contrato de qualidade, um data lake vira um repositório de arquivos que ninguém sabe mais o que significam, quem gerou, nem se ainda estão corretos. Não é defeito do lake em si, é o que acontece quando a empresa trata "guardar tudo" como estratégia de dados completa, sem investir em governança desde o primeiro dia.

Lakehouse: a tentativa de juntar os dois sem herdar os dois problemas#

O lakehouse é a resposta da última década para essa tensão: um data lake, com armazenamento barato e flexível para qualquer formato, mas com uma camada de governança, transação e estrutura por cima, geralmente usando formatos abertos como Delta Lake ou Apache Iceberg. Na prática, o lakehouse dá ao dado bruto do lake as garantias que antes só o warehouse tinha: transações ACID, versionamento de esquema, controle de acesso granular e consulta via SQL como se fosse uma tabela relacional.

O que muda de fato é que o mesmo dado pode ser lido por um notebook Spark, por uma query SQL e por um modelo de Power BI sem precisar de três cópias em três sistemas diferentes. É essa promessa, mais do que qualquer recurso isolado, que tornou o termo lakehouse central em qualquer conversa recente sobre engenharia de dados no ecossistema Microsoft, AWS ou Google Cloud.

Característica	Data warehouse	Data lake	Lakehouse
Tipo de dado	Estruturado (tabelas)	Qualquer formato (bruto)	Qualquer formato, com estrutura aplicada
Esquema	Definido antes da carga (schema-on-write)	Definido na leitura (schema-on-read)	Ambos, dependendo da camada
Custo de armazenamento	Mais alto	Baixo	Baixo (mesmo armazenamento do lake)
Transações ACID	Sim, nativo	Não, nativo	Sim, via Delta Lake ou Iceberg
Consulta SQL direta	Sim, nativa e otimizada	Limitada, exige ferramenta externa	Sim, com performance próxima ao warehouse
Risco principal	Rigidez para dado não tabular	Virar pântano de dados sem governança	Complexidade de implementação e manutenção
Melhor cenário	BI corporativo tradicional, dado 100% tabular	Retenção bruta de dado volumoso e heterogêneo	Empresas com dado tabular e não tabular convivendo

Arquitetura medalhão: bronze, silver e gold#

Dentro de um lakehouse, praticamente todo projeto sério adota alguma variação da arquitetura medalhão, um padrão de organização em camadas que separa dado bruto de dado pronto para consumo. Não é exclusiva de nenhuma ferramenta, mas é padrão de fato dentro do Fabric, do Databricks e de projetos Delta Lake em geral.

Camada	O que contém	Transformação aplicada	Quem consome
Bronze	Dado bruto, exatamente como chegou da origem	Nenhuma, ou só metadados de ingestão (data, origem)	Engenheiros de dados, auditoria
Silver	Dado limpo, validado e com tipos corrigidos	Deduplicação, tratamento de nulos, padronização de formato	Analistas de dados, cientistas de dados
Gold	Dado agregado e modelado para consumo de negócio	Modelagem dimensional, joins de negócio, métricas calculadas	Power BI, relatórios executivos, times de negócio

A bronze funciona como arquivo histórico, imutável na maioria dos projetos, que permite reprocessar tudo do zero se uma regra de negócio mudar ou um erro for descoberto depois. A silver já é confiável para análise exploratória, mas ainda não está no formato certo para o usuário final. A gold é o que chega num dashboard ou numa tabela de relatório, já com a granularidade e as agregações que fazem sentido para quem toma decisão, não para quem processa o dado.

ETL x ELT: onde a transformação acontece muda a arquitetura toda#

A escolha entre warehouse, lake e lakehouse está amarrada a outra decisão que costuma passar despercebida: ETL ou ELT.

No modelo ETL (extract, transform, load), o dado é transformado antes de entrar no destino final, geralmente num servidor intermediário ou numa ferramenta dedicada. É o padrão histórico de data warehouse: só entra dado já limpo e modelado, porque o warehouse não foi desenhado para receber dado bruto barato.

No modelo ELT (extract, load, transform), o dado bruto entra primeiro no destino, sem transformação, e só depois é processado dentro do próprio ambiente, usando o poder de processamento do lakehouse ou do warehouse moderno. É o padrão natural da arquitetura medalhão: a carga bronze é praticamente um ELT puro, e as transformações para silver e gold acontecem dentro da mesma plataforma, sem servidor intermediário.

Arquiteturas modernas em Fabric, Databricks ou Synapse tendem para ELT, porque o custo de processamento caiu e a flexibilidade de manter o dado bruto disponível (para reprocessamento, auditoria ou LGPD) supera o custo extra de armazenar uma cópia a mais. Isso não elimina o ETL: integrações legadas, sistemas on-premises antigos ou requisitos rígidos de qualidade na entrada ainda usam ETL tradicional, especialmente quando o volume não justifica a complexidade de um pipeline em camadas.

OneLake e Direct Lake: como o Microsoft Fabric tenta encerrar essa discussão#

O Microsoft Fabric ataca esse dilema com uma proposta direta: um único repositório de armazenamento, o OneLake, compartilhado por todos os workloads da plataforma. Dado gravado em Delta Parquet dentro do OneLake pode ser lido por um item Lakehouse, por um item Warehouse, por um notebook Spark e por um modelo semântico do Power BI, sem duplicação. Cobrimos essa arquitetura em detalhe em o que é o Microsoft Fabric e quando vale a pena, inclusive o modelo de custo por capacidade.

O recurso que mais muda a rotina de quem já usa Power BI é o Direct Lake, um terceiro modo de conexão, além do tradicional Import e DirectQuery, que lê os arquivos Delta Parquet direto do OneLake sob demanda, sem processo de importação agendado e sem duplicar o dado no modelo tabular. O resultado é performance próxima ao Import com atualização quase em tempo real, mas com um pré-requisito não opcional: os dados precisam já estar em formato Delta dentro do OneLake, organizados em camadas, geralmente seguindo o padrão medalhão. Direct Lake não substitui uma arquitetura de dados madura, depende dela.

Quando cada arquitetura faz sentido na prática#

Não existe arquitetura universalmente certa, existe a adequada ao perfil de dado e à maturidade do time:

Escolha data warehouse puro quando:

• Praticamente todo o dado é tabular, vindo de ERP, CRM e sistemas transacionais estruturados.
• O time é pequeno e já domina SQL, sem experiência prévia com Spark ou processamento distribuído.
• O volume é grande, mas previsível, sem cargas de streaming, log de aplicação ou dado semiestruturado relevante.
• A prioridade é relatório corporativo estável, com governança rígida desde a entrada.

Escolha lakehouse quando:

• Existe convivência real entre dado tabular (ERP, CRM) e não tabular ou semiestruturado (evento, log, IoT, JSON de API, telemetria).
• Ciência de dados e machine learning fazem parte do roadmap, não só relatório descritivo.
• Há necessidade de manter histórico bruto para auditoria ou requisitos regulatórios, sem o custo de um warehouse tradicional.
• O time de engenharia já trabalha, ou topa trabalhar, com pipelines em camadas e alguma disciplina de Spark.

Não escolha lakehouse só porque é a tendência do momento. Empresas com dado 100% tabular e time pequeno pagam um custo de complexidade desnecessário ao adotar uma arquitetura pensada para heterogeneidade que elas não têm. Um warehouse bem modelado, com boa camada semântica, resolve esse cenário com menos gente e menos ferramenta.

Custo real: nuvem, ferramenta e gente#

O custo de qualquer arquitetura tem três componentes que raramente aparecem juntos na conversa comercial, mas deveriam.

Custo de nuvem: armazenamento de objeto (lake) é ordens de grandeza mais barato que armazenamento otimizado para consulta transacional (warehouse dedicado). Mas o custo de processamento, seja capacidade Fabric, cluster Databricks ou compute do Synapse, costuma superar o de armazenamento em qualquer arquitetura minimamente ativa.

Custo de ferramenta: um warehouse tradicional exige menos ferramentas satélites. Um lakehouse, principalmente fora do Fabric, costuma somar catálogo de dados, orquestrador, ferramenta de qualidade de dado e camada de governança como itens separados de licenciamento.

Custo de gente: o mais subestimado. Um lakehouse bem implementado exige engenheiros que entendam Spark, formatos colunar, particionamento e versionamento de esquema. Um warehouse tradicional exige modelagem dimensional sólida e SQL avançado, competência mais disseminada no mercado brasileiro. Contratar ou treinar para a competência errada custa mais, no médio prazo, do que a diferença de licenciamento entre plataformas.

Componente de custo	Data warehouse	Lakehouse
Armazenamento	Mais caro por GB	Mais barato por GB
Processamento	Previsível, escala vertical	Variável, escala horizontal (Spark)
Ferramentas satélites	Poucas, ecossistema mais consolidado	Mais itens: catálogo, orquestração, qualidade
Perfil de time necessário	SQL avançado, modelagem dimensional	Spark, engenharia de dados distribuída, governança de esquema
Risco financeiro típico	Subutilização de capacidade contratada	Explosão de custo de processamento sem governança de job

Governança e LGPD não são camada opcional#

Seja qual for a arquitetura escolhida, a camada de governança não é um extra que se adiciona depois. Dado pessoal presente em qualquer camada, bronze, silver ou gold, está sujeito à LGPD independentemente do formato em que está armazenado. Isso significa mapear onde o dado pessoal entra, quem tem acesso a cada camada, por quanto tempo o dado bruto fica retido e como um pedido de exclusão de titular se propaga por bronze, silver e gold sem deixar rastro esquecido em algum notebook antigo.

Arquiteturas de lakehouse, por guardarem dado bruto por padrão, tendem a acumular mais risco de exposição de dado pessoal na camada bronze do que um warehouse tradicional, que já nasce com esquema controlado. Isso não é motivo para evitar lakehouse, é motivo para tratar governança de dados como parte do projeto de arquitetura, não como auditoria posterior.

Perguntas frequentes#

Data warehouse ainda faz sentido em 2026, ou todo mundo deveria migrar para lakehouse? Faz sentido, e continuará fazendo para boa parte das empresas. Quem tem dado majoritariamente tabular e prioridade em relatório corporativo estável não ganha nada relevante migrando para lakehouse, só adiciona complexidade. A migração faz sentido quando existe dado não tabular real no roadmap.

Lakehouse é sempre mais barato que data warehouse? Não necessariamente. O armazenamento é mais barato, mas o processamento distribuído e as ferramentas satélites podem tornar o custo total maior, especialmente sem maturidade para operar Spark com eficiência. O custo de gente costuma pesar mais que o de infraestrutura.

O que é exatamente a arquitetura medalhão? É o padrão de organizar dados em três camadas dentro de um lakehouse: bronze (dado bruto, sem transformação), silver (dado limpo e validado) e gold (dado agregado e modelado para consumo de negócio, como relatórios de Power BI). Não é tecnologia específica, é um padrão de organização que qualquer ferramenta de lakehouse pode seguir.

OneLake substitui a necessidade de pensar em bronze, silver e gold? Não. O OneLake resolve onde o dado é armazenado e evita duplicação entre workloads do Fabric, mas a organização em camadas continua sendo trabalho de arquitetura e engenharia de dados. Sem essa disciplina, vira um repositório único, só que igualmente confuso.

ETL está obsoleto diante do ELT? Não está obsoleto, mudou de proporção. Arquiteturas modernas favorecem ELT porque o custo de armazenar dado bruto caiu e a flexibilidade de reprocessar dentro da própria plataforma compensa. Integrações legadas ou requisitos rígidos de qualidade na entrada ainda justificam ETL tradicional.

Preciso de Direct Lake para o Power BI funcionar bem com lakehouse? Não é obrigatório. DirectQuery e Import continuam funcionando normalmente sobre um lakehouse. O Direct Lake é um ganho de performance e atualização, mas exige que o dado já esteja em Delta Parquet dentro do OneLake, o que pressupõe camadas já organizadas.

A arquitetura certa é a que seu time consegue operar#

Data warehouse, data lake e lakehouse não competem entre si como produtos de prateleira, são respostas a perfis diferentes de dado, de time e de orçamento. A pergunta que importa não é "qual é a arquitetura mais moderna", é "qual arquitetura minha equipe consegue operar com qualidade nos próximos três anos, dado o que já tenho e o que ainda vou receber de dado não estruturado".

Essa decisão custa caro para desfazer depois de implementada, mais ainda quando é tomada sem diagnóstico do cenário real de dados da empresa. Se você já usa Power BI e quer entender como a camada de dados por trás dele deveria estar estruturada, vale revisar nosso guia completo de Power BI para empresas no Brasil, que trata do outro lado dessa decisão, o consumo do dado, não só o armazenamento.

Se você quer avaliar qual arquitetura faz sentido para o seu volume de dados, seu time e seu orçamento, com apoio de quem já estruturou engenharia de dados em cenários parecidos, fale com a gente.