// stack.lumi

Dados

dbt

Engenharia analytics versionada, testavel e governada.

// o que é

dbt organiza transformacoes SQL como software: versionamento, testes, documentacao, lineage e deploy. No contexto da Lumi Data, dbt e o pilar para transformar dados brutos em metricas confiaveis e reutilizaveis.

O dbt representa a consolidação do paradigma ELT — Extract, Load, Transform — em que a transformação ocorre dentro do próprio data warehouse, aproveitando o poder computacional das engines modernas (Kleppmann, 2017). Ele aplica princípios do desenvolvimento de software — controle de versão, testes automatizados, documentação e modularidade — às transformações analíticas em SQL, criando o que dbt Labs (2020) denominou "analytics engineering" como disciplina formal. A modelagem dimensional de Kimball & Ross (2013) encontra no dbt um ambiente natural de implementação: fatos, dimensões e métricas reutilizáveis tornam-se objetos versionados com contratos de qualidade explícitos. Fowler (2018) já antecipava que mudanças evolutivas em bancos de dados exigem rastreabilidade e automação — o dbt entrega exatamente isso no contexto analítico.

Como a Lumi enxerga:A Lumi cria modelos dbt com contratos, testes, nomenclatura e CI/CD para que analytics seja sustentavel e auditavel.

// na prática

Como empresas usam dbt

Fintech com 20+ analistas de dados e múltiplas squads consumindo métricas

Times de analytics engineering usam dbt para criar uma camada gold centralizada com métricas de negócio — churn, LTV, conversão, inadimplência — que todas as squads consomem via Looker ou Power BI. O resultado é uma única definição de "receita líquida" ou "cliente ativo" que elimina discrepâncias entre relatórios de áreas diferentes, reduzindo reuniões de reconciliação e aumentando confiança nos números.

E-commerce de médio porte migrando de planilhas para BI estruturado

O dbt organiza a ingestão bruta de ERP, plataforma de e-commerce e CRM em camadas bronze/silver/gold, com testes de not_null e uniqueness nos campos críticos. A equipe de dados passa a entregar novos relatórios em horas em vez de dias, porque os modelos base já existem, versionados e documentados. O lineage automático permite rastrear de onde vem cada número no dashboard sem depender de documentação manual.

Empresa de agronegócio estruturando governança de dados operacionais

Dados de sensores, colheita, logística e preços de commodity chegam de fontes heterogêneas; o dbt padroniza nomenclatura, aplica regras de negócio (conversão de unidades, calendário safra) e publica modelos gold para os sistemas de planejamento. Os testes de schema detectam quebras de contrato quando fornecedores alteram estrutura de arquivos, evitando que dados incorretos cheguem silenciosamente ao BI de diretoria.

// decisão técnica

Quando usar — e quando não usar

Use quando

A empresa já tem um data warehouse (BigQuery, Redshift, Snowflake, Databricks) e precisa organizar a camada de transformação SQL que hoje vive em scripts avulsos, procedures ou notebooks sem versionamento.
Existem múltiplas definições conflitantes para métricas de negócio (receita, clientes ativos, CAC) e é necessário criar uma fonte única de verdade acessível a todos os consumidores de dados.
O time quer aplicar práticas de software — CI/CD, code review, testes automatizados — ao pipeline analítico sem abandonar SQL como linguagem principal.
A organização precisa de documentação e lineage automáticos para fins de auditoria, conformidade (LGPD, SOX) ou simplesmente para onboarding de novos analistas.
Há necessidade de reprocessamento confiável de dados históricos: modelos dbt são idempotentes por natureza, o que simplifica backfills e correções.

Evite quando

O volume de transformações é trivial — cinco ou seis queries fixas que não mudam — e adicionar dbt criaria overhead de projeto (profiles, packages, CI) desproporcional ao benefício.
A empresa não tem ou não pretende ter um data warehouse SQL como destino; dbt não processa dados fora do warehouse e não substitui ferramentas de ingestão ou orquestração.
O time é composto exclusivamente por engenheiros de software sem afinidade com SQL analítico e modelagem dimensional; a curva de adoção pode ser subestimada e resultar em modelos mal estruturados que criam mais problemas do que resolvem.
O requisito é processamento de streaming ou near-realtime com latência de segundos; dbt opera em batch sobre snapshots do warehouse e não é adequado para esse padrão.

// visão lumi

Na Lumi, dbt não é adotado como ferramenta de moda — é adotado quando existe uma camada de transformação SQL desestruturada que está causando problemas reais: métricas inconsistentes, medo de mudar código legado, dependência de uma pessoa-chave que "sabe de onde vêm os números". O primeiro passo em qualquer projeto dbt é mapear quais métricas de negócio estão gerando conflito ou desconfiança, e construir os modelos gold em torno delas. Preferimos implementações limpas com 20 modelos bem testados do que projetos com 200 modelos sem testes e documentação vazia. Integramos dbt com Airflow ou dbt Cloud para orquestração, e usamos dbt-expectations para testes além dos built-in — qualidade de dados não é opcional.

Lumi escolhe quando

Quando o cliente tem BigQuery, Redshift, Snowflake ou Databricks SQL como destino e pelo menos um analista com fluência em SQL para manter os modelos.
Quando há pelo menos duas squads ou áreas consumindo as mesmas métricas e a discrepância entre seus números já gerou conflito ou decisão errada.
Quando o projeto inclui implementação de Data Warehouse ou migração de relatórios legados, aproveitando para estruturar a camada analítica desde o início.
Quando existe um time de dados comprometido com revisão de código e testes — dbt sem disciplina de engenharia vira outro repositório de scripts desorganizados.

Lumi não recomenda quando

Quando o cliente tem menos de dois ou três tabelas relevantes para análise e o custo de manutenção de um projeto dbt supera o custo de uma query SQL documentada.
Quando o time de dados tem resistência a controle de versão e code review — sem esse processo, os benefícios do dbt desaparecem em semanas.
Quando a arquitetura de dados ainda não está definida e adotar dbt prematuramente vai apenas cristalizar estruturas ruins com aparência de organização.

// aplicações

Onde essa tecnologia gera valor

Camadas bronze, silver e gold

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

Modelos dimensionais

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

Testes de qualidade de dados

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

Documentacao e lineage para BI

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

// fundamentos

Referências acadêmicas e técnicas

dbt Labs. (2020). What is Analytics Engineering? dbt Blog. https://www.getdbt.com/what-is-analytics-engineering/

Define o papel do analytics engineer e o paradigma ELT como fundação conceitual do dbt.

Kimball, R., & Ross, M. (2013). The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd ed.). Wiley.

Referência canônica de modelagem dimensional; fatos, dimensões e métricas que o dbt implementa como objetos versionados.

Kleppmann, M. (2017). Designing Data-Intensive Applications. O'Reilly Media.

Estabelece o vocabulário de sistemas de dados modernos, incluindo o papel das transformações e da confiabilidade de dados.

Fowler, M. (2018). Evolutionary Database Design. martinfowler.com. https://martinfowler.com/articles/evodb.html

Argumenta que mudanças em bancos de dados exigem rastreabilidade e automação — princípio central do dbt.

Reis, J., & Huyen, C. (2022). Fundamentals of Data Engineering. O'Reilly Media.

Formaliza o ciclo de vida de engenharia de dados incluindo a camada de transformação onde o dbt atua.

// tecnologias relacionadas

Dados

// próximo passo

Quer saber se esse stack faz sentido para você?

A Lumi avalia contexto, dados, equipe, custo e maturidade para recomendar a tecnologia certa e entregar com responsabilidade.

Avaliar meu stack →Voltar ao stack