Tecnologia
Consultoria e implementação de dbt
O time adotou dbt e a produção de modelo acelerou. Agora existem modelos demais e duas versões defensáveis de receita: uma no relatório da diretoria, outra no painel da área comercial, ambas em SQL correto. A reunião passa a discutir de quem é o número, em vez de discutir o que fazer com ele. E a resposta honesta — depende do modelo que você abriu — é a pior possível.
Como a gente encara.
O trabalho começa pelas métricas que a empresa usa para decidir, não pelo repositório. Cada uma recebe uma definição só, num modelo só, e os demais referenciam esse. Onde há duas regras, quem escolhe é alguém do negócio: é decisão de dono, não de engenharia. Depois as camadas ganham contrato — o que pode ser consumido de fora e quais colunas não mudam sem aviso. E cada materialização é escolhida contra a conta do seu armazém, não pelo hábito do repositório.
Onde costuma quebrar
Os erros que aparecem sempre, e que ninguém conta na demonstração.
- 01
A mesma regra de negócio reimplementada em modelos diferentes. Nenhum deles está errado em SQL, e é por isso que a divergência sobrevive tanto tempo: dois números defensáveis para a mesma pergunta, e ninguém com mandato para desempatar.
- 02
Teste aplicado por obrigação: chave única e coluna não nula (unique, not_null) em toda coluna de chave, e nenhum teste dizendo que aquele valor não pode ser negativo ou que o total precisa bater com o sistema de origem. A sua suíte fica verde exatamente na falha que teria importado.
- 03
Camada nomeada e não contratada. As pastas dizem staging, intermediário e consumo, mas o painel referencia direto o modelo do meio. Quando alguém renomeia uma coluna que julgava interna, quebra um relatório que você não sabia que existia.
- 04
Materialização por hábito: tudo vira view até a consulta do BI ficar insuportável, ou tudo vira tabela até a janela de execução não caber mais na madrugada. Incremental adotado sem chave e sem tratar registro que muda depois entrega o pior arranjo — rápido e errado.
- 05
Fonte sem verificação de atualidade (source freshness). O modelo roda, termina em verde e publica o dado do dia anterior como se fosse o do dia, porque a ingestão falhou antes e ninguém colocou teste na porta de entrada.
O que custa mais do que parece
- dbt torna barato criar modelo, e o custo apenas muda de lugar: vai para o armazém que executa tudo isso a cada rodada. Você não recebe fatura maior da ferramenta, recebe do banco — e paga por modelo que ninguém mais consome.
- A documentação gerada dá aparência de governança. O catálogo fica apresentável e continua sem dono: campo de descrição preenchido não diz quem decide o que a métrica significa nem quem responde quando ela quebra.
- Integração contínua em dbt gasta armazém de verdade. Cada pull request que reconstrói o projeto inteiro executa consulta paga, e a cobrança chega pelo banco, não pela ferramenta, então ninguém liga uma coisa à outra. O aperto aparece quando a quantidade de modelos e a de pessoas contribuindo crescem juntas. Construir só o que mudou (state:modified) exige comparar a execução com o estado de uma anterior, e essa montagem quase nunca é feita antes de a fatura obrigar.
O que você recebe
- Lista das métricas que a empresa usa para decidir, cada uma com uma definição só e o modelo onde ela mora.
- Camadas com contrato explícito: o que é público, o que é interno e quais colunas têm garantia de não mudar sem aviso.
- Testes que expressam regra de negócio, além dos genéricos, e verificação de atualidade (source freshness) declarada nas fontes.
- Materialização revisada modelo a modelo, com o custo de execução de cada escolha visível para quem decide.
- Convenção escrita de nomes, revisão obrigatória em pull request e o procedimento para aposentar modelo que ninguém consome.
O que fazemos com dbt
Open source ou enterprise, a frente é a mesma.
Implantar
Do zero, com a arquitetura decidida no diagnóstico e não pelo catálogo do fornecedor.
Migrar
De outra ferramenta, ou de uma versão antiga, com o que já roda continuando a rodar.
Desenvolver em cima
Aplicação, integração e automação construídas sobre dbt, incluindo o que a ferramenta não faz sozinha.
Sustentar
Operação, custo sob controle e correção de rota depois que entra em produção.
Perguntas diretas.
- Quando dbt não se justifica?
- Quando a transformação cabe em um punhado de consultas, uma pessoa cuida delas e não há reprocessagem nem dependência entre modelos: aí dbt acrescenta repositório, ambiente, integração contínua e vocabulário novo para um problema que você não tem, e uma view versionada no Git resolve. Também não é a peça certa quando o dado ainda nem chega ao armazém — dbt transforma o que já foi carregado, não ingere — nem quando o trabalho pesado é sobre dado não estruturado ou treino de modelo, que não é SQL. Dizer isso é mais útil do que montar um projeto para justificar a ferramenta.
- dbt substitui o orquestrador?
- Só em parte. dbt entende a dependência entre os modelos dele e executa o grafo na ordem certa, mas não sabe nada sobre o que precisa acontecer antes: a ingestão que carrega a fonte, a exportação que sai depois, o modelo de machine learning que consome o resultado. Vale lembrar que o dbt Core não agenda nada: ele roda quando alguém o chama. Se a sua rotina é só transformar o que já está no armazém, um agendador simples resolve — o do dbt Cloud, se você paga por ele, ou o da sua nuvem. Quando existem etapas antes e depois, o orquestrador continua sendo uma peça separada, e o dbt é uma tarefa dentro dele.
- Por que dois relatórios mostram receitas diferentes se ambos usam dbt?
- Porque dbt garante que a transformação rode sempre do mesmo jeito, não que a regra seja a mesma. Na prática costuma ser um filtro divergente — um exclui cancelamento e o outro não — ou um recorte de data diferente, com um contando pela emissão e o outro pela liquidação. A ferramenta não decide qual está certo; alguém do negócio precisa escolher. A correção é eleger uma definição e fazer o outro modelo referenciar essa, e a parte demorada desse trabalho é a conversa, não o código.
Antes de escolher a ferramenta
A ferramenta é consequência da arquitetura. Nunca a premissa.
Esta página existe porque alguém procura por esse nome. Mas a escolha certa sai do diagnóstico do seu cenário, não do catálogo de quem vende. Se a resposta for outra ferramenta, ou nenhuma, é isso que você vai ouvir.
Não está na lista? Não é impedimento, é conversa. O que decide não é o nome do produto, é o problema que ele precisa resolver.