~/questoes/dados
O padrão layering em dbt organiza modelos em três camadas: staging (dados brutos limpos), intermediate (transformações intermediárias) e marts (modelos finais prontos para análise). Essa estrutura modular garante que cada transformação tenha responsabilidade clara, facilitando manutenção, testes e rastreamento de dependências entre modelos.
Layering segue uma progressão lógica onde dados brutos passam por refinamentos graduais. A camada staging limpa e valida dados de origem (sources), a intermediate realiza transformações complexas e agrupamentos, e a marts entrega dados prontos para consumo de analistas e dashboards. Essa separação evita que mudanças em uma camada quebrem modelos dependentes.
Organizar por ordem alfabética ignora completamente a lógica de negócio e as dependências entre modelos. Essa abordagem dificultaria a compreensão do fluxo de dados e tornaria a manutenção caótica conforme o projeto crescesse.
Separar modelos apenas por warehouse (Snowflake, BigQuery, etc.) foca em infraestrutura, não em arquitetura lógica. Mesmo que os dados estejam em warehouses diferentes, você ainda precisa organizar modelos por camadas de transformação para manter clareza e rastreabilidade.
Layering é o padrão recomendado porque cria uma progressão clara: staging trata dados brutos vindo de sources, intermediate realiza transformações reutilizáveis, e marts entrega tabelas analíticas finais. Essa estrutura torna pipelines escaláveis, testáveis e fáceis de documentar.
Colocar todos os modelos em um único arquivo SQL violaria princípios básicos de engenharia de software como modularidade e reutilização. Além disso, um único arquivo gigante se tornaria imanagenável rapidamente e impossível de testar de forma isolada.