Lakehouse no Microsoft Fabric: guia prático

O dado que não cabe no warehouse e não pode virar pântano#

Toda empresa que cresce em dados chega no mesmo impasse. O warehouse relacional resolve bem o relatório tabular, mas engasga quando chega JSON de API, log de sistema, arquivo de exportação bruta ou evento de sensor. O data lake guarda tudo isso barato, só que sem governança vira o famoso pântano de dados, aquele repositório de arquivos que ninguém mais sabe o que significa nem quem gerou. O Lakehouse no Microsoft Fabric existe justamente para ocupar esse meio termo: ele combina o armazenamento barato e flexível do data lake com a estrutura, a transação e a consulta SQL que antes só o warehouse entregava, tudo dentro de uma plataforma só.

Este guia é prático e opinativo. Vou mostrar o que o Lakehouse é de fato dentro do Fabric, como ele guarda tabelas no formato Delta sobre o OneLake, como os dados entram por pipeline, dataflow ou notebook, por que o endpoint de análise SQL é somente leitura, como o Power BI consome esse dado em Direct Lake sem importar nada e, principalmente, quando escolher Lakehouse em vez de Warehouse. No fim você vai saber organizar tudo em camadas bronze, prata e ouro sem transformar o projeto num amontoado de notebooks soltos.

O que é o Lakehouse no Microsoft Fabric na prática#

O Lakehouse é um item do Fabric, criado dentro de um workspace, que junta duas coisas que historicamente moravam em sistemas separados: uma área de arquivos (Files) e uma área de tabelas (Tables). Na área de arquivos você joga qualquer coisa em formato nativo, CSV, JSON, Parquet, imagens, PDFs, exportações brutas de ERP. Na área de tabelas ficam as tabelas gerenciadas, sempre no formato Delta, que se comportam como tabelas relacionais de verdade, com esquema, tipos e transações.

Essa dupla natureza é o ponto. Você não precisa escolher entre guardar o dado bruto e ter uma tabela consultável por SQL, porque o Lakehouse guarda os dois lado a lado, no mesmo item. É essa combinação que faz dele a porta de entrada natural para a maior parte dos projetos de engenharia de dados no Fabric, principalmente quando existe dado semiestruturado no caminho.

Tabelas Delta sobre o OneLake são o coração do Lakehouse#

Todo Lakehouse guarda suas tabelas no formato Delta Lake, que na prática é Parquet colunar mais um log de transações. Esse log é o que dá ao Lakehouse as garantias que o data lake puro nunca teve: transações ACID, escrita atômica, controle de versão de dados (o chamado time travel) e evolução de esquema controlada. Quando você grava uma tabela, o Fabric escreve arquivos Parquet e registra a operação no log Delta, e é o log que define qual é a versão válida da tabela naquele instante.

Esse armazenamento não fica num storage isolado do Lakehouse. Ele mora no OneLake, o data lake único e lógico do Fabric, um por locatário (tenant). O OneLake é construído sobre o Azure Data Lake Storage Gen2 e usa formatos abertos, então a mesma tabela Delta pode ser lida por um notebook Spark, por uma consulta SQL e por um modelo do Power BI sem gerar três cópias em três sistemas diferentes. Essa é a promessa central: uma cópia do dado, vários motores de consulta por cima.

O SQL analytics endpoint é somente leitura, e isso é de propósito#

Todo Lakehouse expõe automaticamente um SQL analytics endpoint, o endpoint de análise SQL. Ele permite consultar as tabelas Delta do Lakehouse usando T-SQL, do jeito que você consultaria um SQL Server, com suporte a views, funções e permissões. Você aponta o SQL Server Management Studio, o Azure Data Studio ou o próprio portal do Fabric para esse endpoint e escreve SELECT normalmente.

O detalhe que confunde muita gente: esse endpoint é somente leitura. Você não faz INSERT, UPDATE ou DELETE por ele. Isso não é limitação acidental, é decisão de arquitetura. A gravação nas tabelas do Lakehouse acontece pelo motor Spark (notebook), por pipeline ou por dataflow. O endpoint SQL existe para consumo analítico e para criar camadas de consulta lógicas, não para transação. Se você precisa de escrita via T-SQL puro, com comandos de manipulação de dados diretos, o item certo é o Warehouse do Fabric, não o Lakehouse.

Na prática, um analista que só precisa consultar dado já tratado trabalha assim:

-- Consulta somente leitura no SQL analytics endpoint do Lakehouse
SELECT
    d.ano_mes,
    d.regiao,
    SUM(f.valor_liquido) AS receita_liquida,
    COUNT(DISTINCT f.id_pedido) AS pedidos
FROM gold.fato_vendas AS f
JOIN gold.dim_calendario AS d
    ON f.id_data = d.id_data
WHERE d.ano = 2026
GROUP BY d.ano_mes, d.regiao
ORDER BY d.ano_mes, receita_liquida DESC;

Repare que a consulta lê da camada gold. Escrever nessa tabela é trabalho de outra etapa, que veremos adiante.

Três caminhos para colocar dado dentro do Lakehouse#

Existem três formas oficiais de ingerir dado num Lakehouse, e a escolha depende de quem vai operar e de quão complexa é a transformação. A tabela abaixo resume o critério de decisão.

Método	Quando usar	Perfil de quem opera	Transformação
Pipeline (Data Factory)	Cópia de grandes volumes, orquestração, agendamento, conexão a muitas fontes	Engenheiro de dados	Baixa a média, foco em mover e agendar
Dataflow Gen2	Limpeza visual, regras de negócio, quem já conhece Power Query	Analista técnico ou engenheiro	Média, com interface low code
Notebook Spark	Volume alto, lógica complexa, camadas medalhão, machine learning	Engenheiro de dados com Spark	Alta, código PySpark ou SQL Spark

O pipeline do Data Factory é a escolha para ingestão em escala e orquestração. A atividade Copy Data traz dado de um banco on premises, de um SaaS ou de um storage e grava direto na área de tabelas ou de arquivos do Lakehouse, com agendamento e monitoramento nativos. É o caminho para popular a camada bronze com o dado bruto, sem transformação pesada.

O Dataflow Gen2 é o mesmo Power Query que o pessoal de Power BI já conhece, agora rodando no Fabric com o Lakehouse como destino. Ele brilha quando a transformação é regra de negócio limpa e visual, e quando quem constrói o fluxo não quer escrever código. Se o seu time já vive de Power Query, é o menor atrito para começar.

O notebook Spark é a ferramenta de força bruta e de precisão. Volume alto, lógica que não cabe numa interface visual, construção das camadas prata e ouro, feature engineering para modelos: tudo isso pede código. Um exemplo mínimo de gravação de tabela Delta a partir de um arquivo bruto:

# Notebook Spark no Fabric: bronze -> prata
from pyspark.sql.functions import col, to_date, trim

# Lê o arquivo bruto da area Files do Lakehouse
df_bronze = spark.read.option("header", True).csv("Files/bronze/vendas/2026/*.csv")

# Limpeza e tipagem para a camada prata
df_prata = (
    df_bronze
    .withColumn("valor_liquido", col("valor_liquido").cast("decimal(18,2)"))
    .withColumn("data_pedido", to_date(col("data_pedido"), "yyyy-MM-dd"))
    .withColumn("regiao", trim(col("regiao")))
    .dropDuplicates(["id_pedido"])
    .filter(col("valor_liquido").isNotNull())
)

# Grava como tabela Delta gerenciada na area Tables
df_prata.write.format("delta").mode("overwrite").saveAsTable("prata.vendas")

Depois dessa gravação, a tabela prata.vendas já aparece no SQL analytics endpoint para consulta e já pode alimentar o Power BI. Nenhuma cópia extra foi criada.

Organize por camadas: bronze, prata e ouro#

Ter um Lakehouse não garante ordem. A disciplina que separa um projeto sério de um pântano com nome bonito é a arquitetura medalhão, as três camadas bronze, prata e ouro. O Lakehouse organiza bem essas camadas porque cada uma pode ser um schema (ou até um Lakehouse separado) com propósito claro.

Camada	O que guarda	Transformação	Quem consome
Bronze	Dado bruto, como veio da fonte, sem tratamento	Nenhuma, só ingestão e histórico	Engenharia, auditoria, reprocessamento
Prata	Dado limpo, tipado, deduplicado, com regras aplicadas	Limpeza, validação, padronização	Engenharia e analistas avançados
Ouro	Dado modelado para negócio, fatos e dimensões, agregados	Modelagem dimensional, cálculos de negócio	Power BI, relatórios, diretoria

A regra de ouro é simples: nada consome a camada bronze direto para relatório, e nada pula da bronze para o Power BI sem passar pela prata e pela ouro. A camada bronze existe para preservar o dado original e permitir reprocessar quando uma regra muda. A prata é onde o dado fica confiável. A ouro é onde ele fica pronto para negócio, no formato que o Power BI espera, com fatos e dimensões bem modelados. Essa separação é o que evita a divergência de números entre relatórios que tira o sono de qualquer área de dados. Se quiser aprofundar o desenho dessas camadas, temos um material dedicado a engenharia de dados que trata disso em cenários reais.

Direct Lake: o Power BI lê o Delta sem importar#

Aqui está o recurso que mais justifica o Lakehouse para quem vive de Power BI. O Direct Lake é um modo de conexão em que o modelo semântico do Power BI lê as tabelas Delta direto do OneLake, sem importar os dados para dentro do modelo e sem gerar consulta ao vivo contra um banco como faz o DirectQuery.

Na prática, o Direct Lake carrega os arquivos Parquet do Delta na memória sob demanda, quando a consulta acontece. Você ganha a performance próxima do modo Import, sem o processo de atualização (refresh) que copia tudo, e sem a latência do DirectQuery. Quando o pipeline atualiza a tabela ouro, o Power BI enxerga o dado novo sem um refresh tradicional. Isso muda a operação: menos janelas de atualização, menos duplicação de dado, menos capacidade gasta movendo o mesmo número de um lugar para outro.

O Direct Lake tem pré-requisitos que não são negociáveis. O dado precisa estar em Delta Parquet no OneLake, o que pressupõe as camadas já organizadas, e a modelagem na camada ouro precisa estar limpa, porque o Direct Lake não faz transformação, ele lê o que existe. É por isso que Direct Lake e arquitetura medalhão andam juntos: um não entrega valor sem o outro. Para o time de Power BI, o modelo semântico e as medidas DAX continuam sendo o mesmo trabalho de sempre.

Lakehouse ou Warehouse: quando escolher cada um#

O Fabric oferece Lakehouse e Warehouse, e a pergunta certa não é qual é melhor, é qual encaixa no seu dado e no seu time. O Lakehouse é a escolha quando existe dado semiestruturado, quando o time domina Spark ou Python, quando a arquitetura medalhão faz sentido e quando você quer flexibilidade de formato. O Warehouse é a escolha quando o dado é majoritariamente tabular, quando o time é de SQL puro e modelagem dimensional, e quando você precisa de escrita transacional via T-SQL com INSERT, UPDATE e DELETE diretos.

Critério	Lakehouse	Warehouse
Tipo de dado	Estruturado e semiestruturado	Estruturado, tabular
Motor principal	Spark, notebooks	T-SQL
Escrita	Spark, pipeline, dataflow	T-SQL completo (INSERT, UPDATE, DELETE)
SQL endpoint	Somente leitura	Leitura e escrita
Perfil de time	Engenharia de dados, Python	SQL, modelagem dimensional
Direct Lake para Power BI	Sim	Sim

Uma coisa importante: os dois convivem. Um padrão comum e saudável é ingerir e tratar dado bruto e semiestruturado no Lakehouse, construir bronze e prata ali, e servir a camada ouro num Warehouse quando o consumo é predominantemente T-SQL corporativo. Não é uma escolha excludente para a empresa inteira, é uma escolha por carga de trabalho. Se você ainda está avaliando se o Fabric como um todo faz sentido, vale ler antes se o Microsoft Fabric vale a pena em 2026, porque a decisão de Lakehouse mora dentro dessa decisão maior.

Perguntas frequentes#

O Lakehouse no Microsoft Fabric substitui o data warehouse tradicional? Não necessariamente. Ele substitui o warehouse em cenários com dado semiestruturado e time de engenharia com Spark. Para dado puramente tabular, com consumo de T-SQL e escrita transacional, o item Warehouse do Fabric continua sendo a escolha mais direta. Muitos projetos usam os dois, cada um na carga de trabalho que combina.

Por que o SQL analytics endpoint do Lakehouse é somente leitura? Porque a gravação nas tabelas do Lakehouse é responsabilidade do Spark, do pipeline ou do dataflow, não do T-SQL. O endpoint existe para consumo analítico e para criar views de consulta. Se você precisa de INSERT, UPDATE e DELETE via T-SQL, o item correto é o Warehouse, não o Lakehouse.

Preciso saber Spark para usar um Lakehouse? Ajuda muito, mas não é obrigatório para começar. Você consegue ingerir com pipeline e transformar com Dataflow Gen2 usando Power Query, sem escrever uma linha de código. Spark passa a ser necessário quando o volume cresce, a lógica fica complexa ou você entra em camadas prata e ouro mais elaboradas e em machine learning.

Direct Lake é sempre melhor que Import ou DirectQuery no Power BI? É melhor na maioria dos casos que envolvem Lakehouse bem estruturado, porque evita a cópia do Import e a latência do DirectQuery. Mas depende de o dado estar em Delta Parquet no OneLake e de a camada ouro estar limpa. Sem essa base, Import e DirectQuery continuam sendo opções válidas.

Onde ficam fisicamente as tabelas do Lakehouse? No OneLake, o armazenamento único e lógico do Fabric, um por locatário, construído sobre o Azure Data Lake Storage Gen2. As tabelas ficam em formato Delta, que é Parquet mais um log de transações, e o mesmo arquivo pode ser lido por Spark, por SQL e pelo Power BI sem duplicação.

Consigo começar pequeno e crescer o Lakehouse depois? Sim, e é o caminho recomendado. Comece com uma fonte, monte bronze, prata e ouro para ela, conecte um relatório em Direct Lake e valide. A arquitetura medalhão escala por adição de novas fontes e camadas, não por reescrita. Errar cedo com pouco dado é barato, errar tarde com o negócio inteiro dependendo do modelo é caro.

O Lakehouse organiza, mas quem operacionaliza é o time#

O Lakehouse no Fabric resolve um problema real: dar ao dado bruto as garantias do warehouse sem perder a flexibilidade do lake, com uma cópia só do dado servindo Spark, SQL e Power BI. Mas a ferramenta não substitui a disciplina. Sem camadas bem separadas, sem contrato de qualidade entre bronze, prata e ouro e sem um time que saiba operar o que construiu, o Lakehouse vira o mesmo pântano de sempre, só que com nome mais bonito.

Se você quer estruturar um Lakehouse no Fabric com camadas bem desenhadas, ingestão confiável e Direct Lake alimentando o Power BI, com apoio de quem já fez isso em cenários parecidos, fale com a gente.