Por que quebramos nosso monolito no dbt (e os trade-offs reais de migrar para o dbt Mesh)
Fala, pessoal!
Quero compartilhar uma decisão arquitetural que tomamos recentemente envolvendo modelagem de dados, especificamente sobre quando e por que abandonar um projeto dbt monolítico.
A literatura de Engenharia de Dados faz o Data Mesh parecer o próximo passo natural e óbvio, mas na prática, a complexidade não desaparece, ela só muda de lugar.
O Limite do Monolito
No começo, ter um único repositório dbt é excelente para governança. Mas quando você bate a marca de 1.500 modelos, a realidade bate à porta:
O tempo de compilação local (o dbt parse) passa a ser frustrante.
Times de domínios diferentes (Finanças, Marketing, Produto) começam a pisar no pé um do outro em Pull Requests, sobrescrevendo macros globais.
O blast radius (raio de impacto) fica incontrolável: um analista de marketing altera uma regra numa tabela de staging e quebra silenciosamente o modelo final de faturamento da diretoria.
A Migração para o dbt Mesh
Para isolar os domínios, adotamos a topologia Mesh suportada pelas versões mais recentes do dbt-core. Basicamente, você passa a ter repositórios Git independentes se comunicando.
Criamos um Projeto Core (mantido pela Engenharia de Dados, focado em integrações e limpeza, usando Model Contracts rigorosos) e Projetos de Domínio, que importam o Core via Cross-Project References ({{ ref('projeto_core', 'stg_clientes') }}).
A conta chega: Os Trade-offs
Se você pensa em seguir esse caminho, prepare a sua infraestrutura. Aqui estão os atritos que enfrentamos e que você precisa mapear:
O Pesadelo da Orquestração: Num monolito, um simples dbt build resolve a ordem de execução. Num ambiente distribuído, o seu orquestrador (como Airflow ou Dagster) precisa saber que a DAG de Finanças só pode iniciar depois que a DAG Core terminar. Exige a criação de sensores de dependência externa e muita lógica customizada.
Gestão de Estado no CI/CD: Para o CI de um time de domínio funcionar e compilar os modelos que dependem do Core, ele precisa acessar o manifest.json do projeto Core de produção. Tivemos que construir pipelines extras para fazer upload contínuo desses artefatos para o S3/GCS.
RBAC (Role-Based Access Control): Para isolar custos, cada projeto roda com roles diferentes no Data Warehouse (BigQuery/Snowflake). Consequentemente, o projeto de Finanças precisa de Grants explícitos para conseguir fazer SELECT nas views do projeto Core. Sem Terraform, gerenciar isso vira um caos.
Resumo da obra: Quebrar o monolito resolveu nosso gargalo humano e isolou falhas, mas exigiu um nível de maturidade em DevOps absurdamente maior. Se o seu time de dados tem menos de 5 engenheiros ativos no repositório, faça um favor a si mesmo e fique no monolito.
Este relato é um aprofundamento de um caso real. A documentação original e estendida da nossa equipe está neste link no blog da BIX.