dbt para times pequenos: como começar sem complicar

Metade das empresas pequenas com quem converso descarta o dbt como "a ferramenta que os times de analytics no nível de uma FAANG usam". A outra metade tenta adotar, segue um tutorial que joga doze pacotes na cara no primeiro dia, se assusta, e volta sem dizer nada a escrever views SQL direto no warehouse.

Os dois estão errados, mas o segundo grupo tem o instinto certo. O dbt compensa para praticamente qualquer time que roda mais de dez queries em produção, desde que você adote na medida do seu tamanho. Aqui está a versão que eu instalo em empresas pequenas: opinada, enxuta e feita para crescer junto com você, em vez de te obrigar a crescer pra acompanhar.

O que o dbt de fato resolve já no primeiro dia

Esquece o marketing e os tutoriais do YouTube. Logo no primeiro dia, o dbt resolve quatro coisas que você não tem quando escreve views SQL direto no warehouse:

1. Controle de versão. Suas transformações ficam no git. Dá pra revisar mudanças, voltar atrás e ver quem colocou aquele CASE esquisito no modelo de receita seis meses atrás.
2. Testes. Uma linha de YAML e o dbt avisa quando uma chave primária deixa de ser única, quando uma coluna começa a produzir nulls que não devia, ou quando uma foreign key sai do lugar.
3. Documentação que não apodrece. Modelos e colunas são documentados ao lado do SQL que os define, então a doc só desatualiza quando você esquece de atualizar os dois.
4. Um build repetível. Um comando reconstrói toda a pipeline analítica em ordem de dependência. Acabou o "acho que essa view depende daquela mas não tenho certeza".

Todo o resto que o dbt oferece, semantic layer, exposures, snapshots, o hub inteiro de pacotes da comunidade, é coisa que você vai usar quando crescer. Não tente abraçar tudo logo de cara.

O projeto dbt mínimo viável

Para um time de 1 a 5 pessoas com um único warehouse, esta é a menor estrutura de projeto que eu topo colocar em produção:

models/
  staging/
    stg_stripe__charges.sql
    stg_stripe__customers.sql
    stg_hubspot__deals.sql
  marts/
    fct_revenue.sql
    dim_customers.sql
  schema.yml

Duas camadas. Os modelos staging são 1:1 com as tabelas de origem: renomeie as colunas para uma convenção única, faça o cast dos tipos e pare por aí. Nada de regra de negócio. Os modelos marts são as tabelas que os Dashboards leem. Eles juntam os staging e aplicam as regras que de fato definem seus KPIs.

Repare no que ficou de fora: uma camada intermediate, macros customizadas, um pacote utils, exposures, snapshots, seeds. Tudo isso entra quando você tiver um motivo concreto: um join repetido quatro vezes, uma slowly-changing dimension que importa de verdade, o time de financeiro perguntando quando o modelo de receita rodou pela última vez. Adicionar antes da hora cria pastas com um arquivo só dentro, que é o contrário de organizar.

Os quatro testes que todo modelo precisa

Para cada modelo de mart, escreva isso no schema.yml:

• unique + not_null na chave primária. Se fct_revenue tem uma linha por nota fiscal, o id da nota tem que ser único e nunca null. Isso pega uma porção enorme de bugs de pipeline.
• teste de relationships em toda foreign key. Se fct_revenue.customer_id referencia dim_customers.customer_id, o dbt avisa no dia em que um cliente for deletado lá no upstream e sua fact table começar a ter linhas órfãs.
• accepted_values em colunas tipo enum. Status, códigos de país, planos: se um valor novo aparecer, você quer ser avisado, não ver um número estranho surgir do nada no Dashboard.
• checagem de freshness em cada source. Uma linha no YAML de sources e o dbt derruba o run quando a tabela bruta de charges fica 24 horas sem atualizar.

Quatro testes, quinze minutos de YAML. Eles pegam 80% dos problemas silenciosos que fazem um time de dados parecer pouco confiável.

CI desde o primeiro dia (sim, sério)

Eu sei: vocês são um time de duas pessoas, não precisam de CI. Precisam sim. A única coisa que separa um projeto dbt que continua confiável de um que vira "o modelo que a gente não sabe se funciona" é rodar os testes automaticamente em cada PR.

No dbt Cloud é só um toggle: ative o Slim CI num job que roda em cada PR. Se você usa o dbt Core, um workflow de 30 linhas no GitHub Actions resolve a mesma coisa. De qualquer jeito, a regra é uma só: nenhum PR entra com teste vermelho. E essa regra é muito mais fácil de cravar no primeiro dia, com dois contribuidores, do que lá no dia duzentos, com vinte.

O que pular até você precisar de fato

Uma lista curta de coisas que os tutoriais vão mandar você fazer e que dá pra deixar de lado até ter um motivo:

• Snapshots. Úteis quando você realmente precisa acompanhar mudanças ao longo do tempo. Cedo demais quando você só quer os dados de ontem.
• Macros customizadas. Não escreva uma macro até ter copiado o mesmo SQL três vezes. Na terceira cópia é que você finalmente entende qual abstração faz sentido.
• O pacote dbt-utils. São 100 macros que você não vai usar. Coloque quando precisar de uma específica, não por precaução.
• A Semantic Layer. Vale a pena quando você tem várias ferramentas de BI brigando pela mesma métrica. Exagero quando uma analista só olha um Dashboard.

A versão do dbt que você adota no primeiro dia não é a que vai rodar daqui a dois anos. Tudo bem. A ideia é fixar o básico chato, controle de versão, modelos em camadas, testes, CI, e só adicionar complexidade quando uma dor concreta pedir.