dbt e transformação de dados: vale a pena?

Sua camada de transformação virou um cemitério de SQL solto#

Toda operação de dados que amadurece chega no mesmo ponto de dor: existem dezenas, às vezes centenas, de queries de transformação espalhadas por procedures no banco, blocos de Dataflow, células de notebook e scripts que só uma pessoa entende. Ninguém sabe ao certo qual tabela depende de qual, uma mudança inocente quebra três relatórios lá na frente, e a documentação, quando existe, está num arquivo desatualizado. É nesse cenário que a conversa sobre dbt e transformação de dados aparece, quase sempre trazida por quem já se cansou de descobrir o problema pela reclamação do usuário final.

O dbt (data build tool) é uma ferramenta que trata a transformação de dados como código: SQL versionado no Git, organizado em modelos, com testes automatizados e documentação gerada a partir do próprio código. Ele opera no padrão ELT, ou seja, transforma o dado depois de já carregado no warehouse ou lakehouse, usando o poder de processamento da própria plataforma. Neste artigo eu explico o que o dbt faz de fato, o que ele não faz, e a pergunta que realmente importa para quem está no ecossistema Microsoft: vale a pena adotar o dbt ou os recursos nativos do Fabric já resolvem?

O dbt não move dados, ele organiza a transformação#

O primeiro mal-entendido que precisa morrer: o dbt não extrai dados de lugar nenhum e não carrega dados em lugar nenhum. Ele não é um pipeline de ingestão, não substitui o Data Factory nem o Dataflow na parte de trazer o dado da origem. O dbt cuida do "T" do ELT, a transformação, e só disso.

O fluxo é direto. Alguma ferramenta de ingestão deposita o dado bruto no warehouse. A partir daí, o dbt assume: você escreve as transformações como consultas SELECT, e o dbt se encarrega de materializar cada uma como tabela ou view, na ordem correta de dependência, dentro do próprio banco. Você descreve o resultado que quer, e o dbt gera o CREATE TABLE ou CREATE VIEW por baixo dos panos.

Um modelo dbt é literalmente um arquivo .sql com um SELECT. Nada de linguagem proprietária:

-- models/staging/stg_pedidos.sql
select
    id_pedido,
    id_cliente,
    cast(data_pedido as date) as data_pedido,
    valor_bruto,
    valor_bruto - coalesce(desconto, 0) as valor_liquido
from {{ source('erp', 'pedidos') }}
where status <> 'cancelado'

Aquele {{ source('erp', 'pedidos') }} é a peça central. Em vez de escrever o nome físico da tabela, você referencia uma fonte declarada. O dbt resolve o nome real no momento da execução e, mais importante, entende que este modelo depende daquela fonte. Quando um modelo referencia outro com {{ ref('stg_pedidos') }}, o dbt monta sozinho o grafo de dependências e executa tudo na ordem certa. Você nunca mais precisa lembrar manualmente que a tabela A tem que rodar antes da B.

Esse grafo é o que separa o dbt de uma pasta cheia de scripts. Ele sabe a linhagem completa: da fonte crua até a tabela que alimenta o Power BI. É o padrão ELT levado a sério, transformar o dado depois de carregado, no destino, e o dbt só faz sentido dentro dessa lógica.

Testes e documentação deixam de ser promessa e viram código#

Aqui está o valor que costuma justificar a adoção, e não é a parte de escrever SQL, que qualquer um já faz. É o que vem junto.

Testes. No dbt você declara expectativas sobre os dados em YAML, e elas rodam como parte do pipeline. Chave única, coluna não nula, valor dentro de uma lista aceita, integridade referencial com outra tabela. Se um teste falha, você fica sabendo antes do dado furado chegar ao relatório da diretoria, não depois.

# models/staging/schema.yml
models:
  - name: stg_pedidos
    columns:
      - name: id_pedido
        tests:
          - unique
          - not_null
      - name: id_cliente
        tests:
          - relationships:
              to: ref('stg_clientes')
              field: id_cliente

Documentação. O dbt gera um site de documentação a partir das descrições que você escreve junto do código, incluindo o diagrama de linhagem clicável. A documentação para de ser um Confluence que ninguém atualiza e passa a viver no mesmo lugar que o código, versionada junto.

Versionamento e engenharia de verdade. Como tudo é arquivo de texto, o dbt herda o ecossistema do Git de graça. Pull request para revisar transformação antes de subir, histórico de quem mudou o quê e por quê, e integração contínua rodando os testes automaticamente a cada alteração. Isso traz para o time de dados as práticas que o time de software já usa há anos. Para uma operação séria de engenharia de dados, esse é o ponto que muda o jogo: transformação deixa de ser artesanato individual e vira processo auditável.

O que o dbt entrega e o que ele deliberadamente não faz#

Vale ser honesto sobre o escopo, porque metade da frustração com a ferramenta vem de esperar dela o que ela nunca se propôs a fazer.

O dbt faz	O dbt não faz
Transformar dados já carregados no warehouse	Extrair ou ingerir dados da origem
Versionar SQL no Git com PR e revisão	Orquestrar ingestão de sistemas externos
Gerenciar dependências entre modelos	Substituir Data Factory ou Dataflow
Rodar testes de qualidade de dados	Fazer transformação visual sem código
Gerar documentação e linhagem	Processar dados fora de um banco SQL
Materializar tabelas, views e incrementais	Servir dados em tempo real

A leitura correta dessa tabela é: o dbt é uma peça especializada, não uma plataforma completa. Ele precisa de uma ferramenta de ingestão à frente e de um orquestrador para agendar as execuções. No mundo Microsoft, o Data Factory ou o Dataflow trazem o dado, o dbt transforma, e o agendamento roda por um pipeline ou pela versão gerenciada do próprio dbt.

E existe um pré-requisito humano que ninguém deveria ignorar: o dbt é SQL puro em arquivo de texto. Se o seu time transforma dados arrastando caixinhas e nunca escreveu um JOIN fora de uma interface visual, a curva não é trivial. Não é sobre inteligência, é sobre maturidade e hábito de trabalhar com código.

No Microsoft Fabric, o dbt compete e coexiste com os recursos nativos#

Esta é a pergunta que todo cliente nosso no ecossistema Microsoft faz, e a resposta honesta é: depende de quem vai manter. O Fabric já oferece três caminhos nativos para transformar dados, e cada um serve a um perfil diferente.

O Dataflow Gen2 é a transformação visual via Power Query, ótima para analistas que pensam em passos e não em código. O notebook com Spark é o caminho para quem precisa de Python, escala de big data ou lógica que SQL não expressa bem. E o Warehouse roda T-SQL direto, com procedures e views, familiar para quem vem do SQL Server. O dbt entra como uma quarta opção que se conecta ao Warehouse do Fabric e traz a disciplina de engenharia que os três nativos, sozinhos, não impõem.

Abordagem	Perfil ideal	Versionamento	Testes nativos	Curva
Dataflow Gen2	Analista, low-code	Limitado	Não	Baixa
Notebook Spark	Engenheiro, Python	Sim, via Git	Manual	Média a alta
Warehouse T-SQL	Time SQL Server	Parcial	Manual	Média
dbt sobre o Warehouse	Engenharia de analytics	Nativo, Git	Sim, declarativo	Média a alta

Repare que o dbt não substitui o Fabric, ele se apoia nele. O Warehouse continua sendo o motor que executa o SQL; o dbt é a camada de organização, teste e documentação por cima. Você usa a computação do Fabric e ganha as práticas de engenharia que o Dataflow não dá. Se o seu contexto ainda é decidir se o Fabric faz sentido antes mesmo de pensar em dbt, comece pelo nosso guia sobre o que é o Microsoft Fabric e quando vale a pena.

Quando o dbt vale a pena e quando é só complexidade a mais#

Vou ser direto, porque é para isso que consultoria serve. O dbt vale a pena quando três coisas são verdade ao mesmo tempo: você tem volume de transformações que já virou difícil de manter, você tem gente que sabe ou quer aprender SQL de verdade, e você valoriza controle, teste e rastreabilidade acima da rapidez do arrasta e solta.

O dbt faz sentido quando:

• A camada de transformação passou de algumas dezenas de tabelas e ninguém domina o todo.
• Vários analistas mexem nos mesmos modelos e você precisa de revisão antes de subir.
• Qualidade de dado é crítica e você quer testes barrando erro antes do relatório.
• O time já pensa em termos de engenharia: Git, PR, CI já fazem parte da rotina ou estão no plano.
• Você quer independência de fornecedor na lógica de transformação, já que é SQL portável.

O dbt não compensa quando:

• A operação é pequena, poucos modelos, e o Dataflow resolve com menos fricção.
• Não há ninguém confortável com SQL e não há apetite para desenvolver essa competência.
• A necessidade real é ingestão e orquestração, não organização da transformação.
• O time busca uma solução visual de ponta a ponta sem tocar em código.

O erro clássico é adotar o dbt por status técnico, montar toda a estrutura e descobrir que o time volta para o Dataflow no primeiro prazo apertado porque ninguém se sentia à vontade escrevendo modelo. Ferramenta sem maturidade de time vira prateleira cara. A decisão pesa muito mais a padronização que você quer impor e a maturidade de quem vai manter do que qualquer característica técnica isolada da ferramenta.

Um exemplo de modelo incremental para fechar a ideia#

Para deixar concreto o que "transformação como código" significa no dia a dia, veja um modelo incremental, o padrão que evita reprocessar a tabela inteira toda vez e só trata o que chegou de novo:

-- models/marts/fct_vendas.sql
{{ config(materialized='incremental', unique_key='id_pedido') }}

select
    p.id_pedido,
    p.id_cliente,
    p.data_pedido,
    p.valor_liquido,
    c.segmento
from {{ ref('stg_pedidos') }} p
left join {{ ref('stg_clientes') }} c
    on p.id_cliente = c.id_cliente

{% if is_incremental() %}
where p.data_pedido > (select max(data_pedido) from {{ this }})
{% endif %}

O bloco entre {% if is_incremental() %} só entra em ação nas execuções seguintes à primeira, filtrando apenas os pedidos novos. Na criação inicial da tabela, ele é ignorado e tudo é processado. Essa lógica, escrita à mão em procedures, é onde os erros se escondem. No dbt ela é declarativa, testável e revisável. É esse tipo de padronização que sustenta uma operação de analytics avançado que precisa crescer sem virar caos.

Perguntas frequentes#

O dbt substitui o Power BI?

Não, são camadas diferentes e complementares. O dbt prepara e trata os dados dentro do warehouse, entregando tabelas limpas e confiáveis. O Power BI consome essas tabelas para modelagem semântica, DAX e visualização. O dbt cuida do dado antes; o Power BI, da análise depois. Um bom projeto de Power BI fica mais simples quando a transformação pesada já foi resolvida a montante.

Preciso de dbt se já uso o Microsoft Fabric?

Não necessariamente. O Fabric já transforma dados via Dataflow Gen2, notebook e Warehouse. O dbt agrega valor quando você quer versionamento nativo, testes declarativos e documentação automática que os recursos nativos não entregam com a mesma disciplina. Para times pequenos ou pouco maduros em SQL, os nativos costumam bastar.

O dbt custa caro?

O dbt Core é open source e gratuito. O que você paga é a computação do warehouse que executa as transformações, custo que existiria de qualquer forma no ELT. Há também a versão gerenciada em nuvem, paga, que adiciona agendamento, interface e recursos de time. Para muitos casos, o Core somado a um orquestrador que você já tem resolve.

Qual a diferença entre dbt e um Dataflow do Fabric?

O Dataflow é transformação visual, baseada em passos do Power Query, ideal para quem não quer escrever código. O dbt é transformação como código SQL versionado, com testes e documentação embutidos. O Dataflow ganha em facilidade e velocidade inicial; o dbt ganha em controle, escala de manutenção e rastreabilidade quando o número de modelos cresce.

Preciso saber programar para usar o dbt?

Você precisa saber SQL bem, porque todo modelo é uma consulta SELECT. Não precisa ser desenvolvedor de software, mas precisa estar confortável com JOIN, agregação e lógica de transformação escrita à mão. Conceitos de Git ajudam bastante, já que o versionamento é parte central do fluxo. Sem essa base, a adoção trava.

O dbt funciona com qualquer banco de dados?

Ele funciona com os principais warehouses e plataformas de dados de mercado por meio de adaptadores, incluindo opções do ecossistema Microsoft como o Warehouse do Fabric. Como o núcleo é SQL, a lógica de transformação é bastante portável entre plataformas, o que reduz a dependência de um único fornecedor na camada de negócio.

O veredito#

O dbt vale a pena quando a transformação já é grande o bastante para doer e o time tem, ou quer construir, maturidade em SQL e em práticas de engenharia. Ele não é obrigatório, não substitui o Fabric e não faz mágica em time que não escreve código. Para operações que precisam de controle, teste e rastreabilidade na transformação de dados, ele é uma das melhores respostas disponíveis. Para o resto, os recursos nativos resolvem com menos fricção.

Se você está avaliando qual caminho de transformação faz sentido para o seu cenário no Fabric, fale com a gente. A gente ajuda a decidir com base na sua realidade, não na moda do momento.