Delta Lake e Parquet: por que importam

O formato do arquivo decide mais sobre o seu custo de nuvem do que a ferramenta de BI#

Quase toda conversa sobre plataforma de dados começa errada. O time discute Power BI contra outra ferramenta, discute qual nuvem, discute se vai ter data warehouse ou lakehouse, e ninguém pergunta a coisa que mais afeta desempenho, custo e confiança nos números: em que formato os dados vão ficar gravados no disco. Delta Lake e Parquet são exatamente essa camada invisível, e é ela que separa uma plataforma que responde em segundos de uma que trava, custa caro e volta números diferentes conforme a hora da atualização.

Este artigo explica o que são Parquet e Delta Lake, por que viraram a fundação do lakehouse moderno, o que o Delta acrescenta por cima do Parquet e por que o OneLake do Microsoft Fabric guarda tudo nesse formato. Com opinião de quem implementa em produção, e sem esconder onde está o trabalho.

Parquet é o formato colunar que fez a leitura analítica ficar barata#

Comece pelo Parquet, porque o Delta é construído sobre ele. Parquet é um formato de arquivo colunar, comprimido, feito para leitura analítica. Essas três palavras carregam quase tudo que importa.

Colunar significa que os dados são gravados por coluna, não por linha. Um CSV guarda registro por registro: a linha inteira do cliente A, depois a do cliente B. O Parquet inverte e guarda todos os valores de "valor da venda" juntos, depois todos os de "data", e assim por diante. Quando um dashboard pergunta "qual a soma de vendas por mês", ele precisa de duas colunas de um arquivo que talvez tenha cinquenta. Num formato colunar, o motor lê só essas duas e ignora o resto; num formato por linha, é obrigado a passar por tudo.

Comprimido é consequência direta do colunar. Valores da mesma coluna são parecidos entre si: datas próximas, os mesmos nomes de produto se repetindo, faixas de preço semelhantes. Dado parecido comprime muito melhor do que dado misturado, e o Parquet ainda aplica codificações espertas (dicionário, run-length). O resultado é arquivo menor, menos dado trafegando da nuvem para o motor, menos custo.

Feito para leitura analítica é o propósito. Parquet não serve para atualizar uma linha mil vezes por segundo, isso é trabalho de banco transacional. Ele é ótimo para varrer bilhões de linhas somando, agrupando e filtrando, que é o que BI faz.

Um detalhe que quem trabalha com Power BI precisa entender: formato colunar casa naturalmente com a compressão do motor VertiPaq, a engine por trás do Power BI e dos modelos semânticos. Os dois pensam em coluna. Quando a origem já está organizada por coluna e comprimida, o caminho até o modelo fica mais curto. Não é coincidência, é a mesma filosofia dos dois lados.

O problema que o Parquet sozinho não resolve#

Parquet é excelente, mas é só um formato de arquivo. Arquivo solto tem limites sérios quando você monta uma plataforma de verdade.

Imagine uma pasta na nuvem com centenas de arquivos Parquet representando a sua tabela de vendas. O que acontece se uma carga falha no meio, deixando metade dos arquivos novos gravados e metade não? Bagunça: quem consulta naquele instante lê um número que não fecha, meio antigo, meio novo. E se dois processos escrevem ao mesmo tempo? Pior. E se você precisa saber como a tabela estava ontem às 8h, antes da carga errada? Não dá, o arquivo antigo já foi sobrescrito. E se um arquivo chega com "valor" gravado como texto em vez de número? O Parquet aceita, e o problema só aparece quando o relatório quebra.

Esses não são problemas teóricos. São as dores que derrubam projetos em produção: carga pela metade, número que muda conforme a hora, passado que não se audita, esquema que muda sem aviso. Parquet, sozinho, não tem resposta para nada disso. É um formato de arquivo, não um sistema de tabela.

Delta Lake é a camada que transforma arquivos Parquet em uma tabela confiável#

É aqui que entra o Delta Lake. Delta Lake é uma camada de armazenamento aberta que adiciona transações ACID, time travel, imposição e evolução de esquema por cima de arquivos Parquet. Preste atenção na expressão "por cima de": o Delta não substitui o Parquet, ele usa o Parquet. O que o Delta acrescenta é um registro de transações, o transaction log, um diário que anota cada operação na tabela: quais arquivos entraram, quais saíram, em que ordem, com qual esquema.

Esse diário muda tudo: a tabela ganha propriedades que arquivo solto nunca teve.

Transações ACID. Uma carga só "conta" quando termina inteira. Se falha no meio, é como se não tivesse acontecido: quem consulta continua vendo a versão anterior, consistente. Escritas simultâneas não corrompem a tabela. Acabou o número pela metade.

Time travel. Como o log guarda o histórico das versões, você consulta a tabela como ela estava em qualquer ponto do passado. "Me mostre o faturamento como estava antes da carga de ontem" vira uma consulta, não uma escavação em backup. Ouro para auditoria e para reprocessar com segurança.

Imposição e evolução de esquema. Se um arquivo tenta entrar com o tipo errado ou uma coluna que não bate, o Delta recusa em vez de aceitar calado (schema enforcement): o erro aparece na porta de entrada, onde é barato consertar. E quando a mudança é legítima, o Delta permite evoluir a tabela de forma controlada (schema evolution). Bloquear o acidental, permitir o intencional.

A tabela abaixo resume a diferença de responsabilidades.

Capacidade	Parquet puro	Delta Lake (sobre Parquet)
Armazenamento colunar comprimido	Sim	Sim (usa Parquet por baixo)
Transações ACID	Não	Sim
Time travel / histórico de versões	Não	Sim
Imposição de esquema	Não	Sim
Evolução de esquema controlada	Não	Sim
Registro de transações (log)	Não	Sim
Formato aberto, sem lock-in de fornecedor	Sim	Sim

Repare na última linha: nenhum dos dois é formato proprietário de um fabricante. Isso importa muito na hora de escolher plataforma.

Delta Lake e Parquet são a dupla que define o lakehouse moderno#

O termo "lakehouse" virou palavra de marketing, mas por baixo dele existe uma ideia concreta. Durante anos você tinha que escolher entre dois mundos:

• Data lake: barato, flexível, guarda qualquer coisa, mas sem garantias. Fácil virar "data swamp", o pântano de arquivos que ninguém confia.
• Data warehouse: confiável, transacional, governado, mas caro, rígido e com dado preso no formato do fabricante.

O lakehouse é a tentativa de ficar com o melhor dos dois: o custo e a flexibilidade do lake com a confiabilidade e a governança do warehouse. E a peça que torna isso possível é exatamente a dupla Parquet mais Delta: o Parquet dá o armazenamento barato e eficiente; o Delta dá as transações e o esquema. Não é conceito de slide, é escolha de formato de arquivo. Quem entende Delta Lake e Parquet entende o que o lakehouse realmente é.

Se você quer o quadro maior de como isso se encaixa na plataforma da Microsoft, vale ler Microsoft Fabric: o que é e vale a pena em 2026. Aqui o foco é a fundação.

O OneLake do Fabric guarda tudo em Delta, e isso é uma decisão de arquitetura, não um detalhe#

O OneLake é o armazenamento único do Fabric, a ideia de "um só lago de dados" para a organização inteira, e guarda as tabelas no formato Delta. Não é opcional decorativo, é a fundação da plataforma. Isso tem consequências práticas grandes:

Uma cópia, vários motores. Como tudo mora em Delta no OneLake, os diferentes motores do Fabric (warehouse SQL, Spark dos notebooks, motor do Power BI) leem a mesma tabela física. Você não fica com três cópias do mesmo dado, uma por ferramenta. Menos duplicação, menos ETL de cópia, menos ponto de divergência.

O Direct Lake do Power BI. O modo Direct Lake lê os arquivos Delta diretamente do OneLake, sem importar tudo para dentro do modelo e sem consulta ao vivo pesada a cada clique. Só é viável porque o dado já está em formato colunar comprimido (Parquet) e transacionalmente consistente (Delta). É a sinergia entre colunar e VertiPaq virando desempenho.

Formato aberto de verdade. Como Delta e Parquet são formatos abertos, o dado no OneLake não é refém do Fabric: outras ferramentas que falam Delta conseguem ler. Isso reduz o lock-in, preocupação legítima de quem aposta alto numa plataforma.

A tabela abaixo mostra por que o formato afeta decisões que parecem não ter nada a ver com ele.

Decisão de negócio	Como Delta e Parquet afetam
Custo de nuvem	Parquet comprime e lê só as colunas necessárias: menos armazenamento e menos processamento pago
Confiança nos números	Transações ACID do Delta evitam carga pela metade e leitura inconsistente
Auditoria e conformidade	Time travel permite reconstruir o estado passado da tabela sem depender de backup
Velocidade do Power BI	Direct Lake lê Delta no OneLake sem duplicar o dado no modelo
Risco de aprisionamento	Formato aberto: o dado pode ser lido fora do Fabric
Manutenção de pipeline	Uma cópia em Delta serve vários motores: menos ETL de cópia

Onde está o trabalho de verdade, a parte honesta#

Nada disso é mágica, e essa é a parte que os fornecedores omitem. Delta e Parquet criam responsabilidades novas:

Arquivos pequenos demais matam desempenho. Se o seu processo grava milhares de arquivinhos Delta minúsculos, a leitura fica lenta, ironicamente. O "small files problem" é real e exige manutenção: compactar arquivos (o comando OPTIMIZE), organizar por colunas de filtro comum. Delta dá as ferramentas, mas não roda sozinho.

O histórico ocupa espaço. Time travel é ótimo, mas guardar todas as versões para sempre custa armazenamento. Existe manutenção (VACUUM) para limpar o que já não é necessário, e é preciso decidir por quanto tempo o histórico faz sentido. Sem política, o custo cresce calado.

Esquema imposto exige disciplina de origem. Schema enforcement recusa dado errado, o que significa que uma origem que muda sem avisar vai quebrar a carga. Isso é feature, não bug: melhor a carga parar e alguém ser avisado do que o número errado passar. Mas exige processo para tratar as rejeições.

Fundação não é casa. Delta e Parquet são a base certa, mas modelagem dimensional, camadas (bronze, prata, ouro), governança, testes de qualidade e camada semântica continuam sendo trabalho de engenharia. O formato remove uma classe inteira de problemas, não a arquitetura.

É por isso que a gente insiste: a escolha de formato é a base, não o projeto inteiro. Fazer a fundação certa poupa meses de retrabalho, mas a plataforma que gera valor é a soma de fundação boa com engenharia de dados bem-feita, uma camada de Power BI que as pessoas usam e, quando o assunto é análise mais pesada, analytics avançado. É assim que pensamos a entrega de soluções: o formato é uma peça de um conjunto maior.

Perguntas frequentes#

Delta Lake substitui o Parquet?

Não, e essa é a confusão mais comum. O Delta é uma camada construída em cima do Parquet: os dados continuam gravados fisicamente em arquivos Parquet, e o Delta adiciona um registro de transações que os transforma em uma tabela com garantias. Você não escolhe entre um e outro: quando usa Delta, está usando Parquet por baixo.

Preciso do Microsoft Fabric para usar Delta Lake e Parquet?

Não. Parquet e Delta Lake são formatos abertos, independentes de fornecedor, e funcionam em várias plataformas e nuvens. O que o Fabric faz é adotar o Delta como formato nativo do OneLake, o que traz vantagens dentro daquele ecossistema, como o Direct Lake no Power BI. A tecnologia não é exclusiva da Microsoft.

Qual a diferença prática entre imposição e evolução de esquema?

Imposição (schema enforcement) bloqueia dado que não bate com a estrutura esperada, por exemplo um texto onde deveria haver número. Evolução (schema evolution) permite mudar a estrutura da tabela de forma controlada quando a mudança é legítima, como adicionar uma coluna. Um protege do acidental, o outro habilita o intencional.

O que é time travel e para que serve no dia a dia?

É a capacidade de consultar a tabela como ela estava em um ponto anterior no tempo, porque o Delta guarda o histórico de versões no registro de transações. Serve para auditar ("como estava esse número antes da carga de ontem"), depurar um valor que mudou sem explicação e reprocessar com segurança sabendo que dá para voltar atrás. Substitui parte do que antes dependia de backups manuais.

Formato colunar acelera mesmo o Power BI?

Sim, por um motivo estrutural. O motor VertiPaq, por trás do Power BI, também é colunar e comprimido. Quando a origem já está em Parquet, organizada por coluna, o caminho até o modelo semântico é mais curto. No Fabric, o Direct Lake leva isso ao limite ao ler os arquivos Delta diretamente do OneLake.

Adotar Delta e Parquet resolve meus problemas de dados?

Resolve uma classe importante deles: carga inconsistente, número que muda de valor, passado que não se audita, esquema que muda sem aviso. Mas não substitui arquitetura. Modelagem, camadas, governança, qualidade e a própria manutenção do Delta continuam sendo trabalho de engenharia. O formato é a fundação certa; a casa ainda precisa ser bem construída.

Fundação certa poupa o retrabalho mais caro#

Delta Lake e Parquet não aparecem em nenhuma tela que a diretoria vê, mas decidem se a plataforma vai ser rápida, barata e confiável ou lenta, cara e cheia de números que não fecham. Parquet dá o armazenamento colunar comprimido e eficiente; Delta acrescenta as transações, o histórico e o esquema que faltavam. Juntos, são a fundação do lakehouse e a razão pela qual o OneLake do Fabric guarda tudo em Delta.

Se você está avaliando o Fabric, sofrendo com custo de nuvem ou com números que divergem entre ferramentas, fale com a gente. Ajudamos a acertar a fundação antes que o retrabalho apareça.