dbt para times pequenos: como começar sem complicar

Metade das empresas pequenas com quem converso descarta dbt como "a ferramenta que os times de analytics escala FAANG usam". A outra metade tenta adotar, segue um tutorial que apresenta doze pacotes no primeiro dia, se assusta, e silenciosamente volta a escrever views SQL no warehouse.

Os dois grupos estão errados, mas o segundo grupo tem o instinto melhor. dbt vale o investimento para praticamente qualquer time rodando mais de dez queries em produção, desde que você adote em proporção ao seu tamanho. Aqui está a versão que eu instalo em empresas pequenas: opinada, mínima e desenhada para crescer com você em vez de te forçar a crescer pra ela.

O que dbt de fato te dá no primeiro dia

Tira o marketing e os tutoriais do YouTube. No dia um, dbt te dá quatro coisas que você não tem se está escrevendo views SQL no warehouse:

1. Controle de versão. Suas transformações vivem no git. Você consegue revisar mudanças, voltar atrás, e ver quem introduziu aquele CASE esquisito no modelo de receita seis meses atrás.
2. Testes. Uma linha de YAML e o dbt te avisa quando uma chave primária não é única, quando uma coluna começa a produzir nulls que não deveria, ou quando uma foreign key se desalinha.
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 sua pipeline analítica em ordem de dependência. Acabou o "acho que essa view depende daquela mas não tenho certeza".

Tudo o mais que dbt oferece, semantic layer, exposures, snapshots, todo o hub de pacotes da comunidade, é valor que você vai crescer pra usar. Não tente usar tudo no dia um.

O projeto dbt mínimo viável

Para um time de 1–5 pessoas trabalhando com um único warehouse, aqui está a menor estrutura de projeto que eu aceito botar 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. Modelos staging são 1:1 com tabelas de origem, renomeie colunas para uma convenção consistente, faça cast de tipos, e pare por aí. Sem regra de negócio. Modelos marts são as tabelas que seus Dashboards leem. Eles juntam os staging e aplicam as regras que realmente definem seus KPIs.

Repare no que está faltando: uma camada intermediate, macros customizadas, um pacote utils, exposures, snapshots, seeds. Você vai adicionar tudo isso quando tiver um motivo concreto, um join reutilizado quatro vezes, uma slowly-changing dimension que importa de verdade, um time de financeiro perguntando quando o modelo de receita atualizou pela última vez. Adicionar antes da hora cria pastas com um arquivo dentro, que é o oposto de clarear.

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 deve ser único e nunca null. Isso pega uma classe enorme de bugs de pipeline.
• teste de relationships em toda foreign key. Se fct_revenue.customer_id referencia dim_customers.customer_id, o dbt te avisa no dia em que um cliente é deletado upstream e sua fact table começa 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 um aviso, não um mistério silencioso no Dashboard.
• checagem de freshness em cada source. Uma linha no YAML de sources e o dbt falha o run quando a tabela bruta de charges não atualiza há 24 horas.

Quatro testes, quinze minutos de YAML. Eles vão pegar 80% dos quebradores silenciosos que fazem times de dados parecerem pouco confiáveis.

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

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

No dbt Cloud, isso é um toggle: ative Slim CI num job que roda em cada PR. Se você está no dbt Core, um workflow de 30 linhas no GitHub Actions te dá a mesma coisa. De qualquer jeito, o contrato é: nenhum PR mergeia com testes vermelhos. Esse contrato é muito mais fácil de impor no dia um com dois contribuidores do que no dia duzentos com vinte.

O que pular até você precisar de fato

Uma lista curta de coisas que tutoriais vão te dizer para fazer e que você deve resistir até ter um motivo:

• Snapshots. Útil quando você genuinamente precisa rastrear mudanças ao longo do tempo. Prematuro quando você só quer os dados de ontem.
• Macros customizadas. Não escreva uma macro até ter copiado o mesmo SQL três vezes. A terceira cópia é quando você sabe o que a abstração realmente quer ser.
• O pacote dbt-utils. Adiciona 100 macros que você não vai usar. Adicione quando precisar de uma específica, não preventivamente.
• A Semantic Layer. Vale a pena quando você tem múltiplas ferramentas de BI competindo pela mesma métrica. Exagero quando uma analista bate num único Dashboard.

A versão de dbt que você adota no dia um não é a versão que vai estar rodando em dois anos. Tudo bem. O ponto é travar os fundamentos chatos, controle de versão, modelos em camadas, testes, CI, e adicionar complexidade só quando uma dor concreta exigir.