dbt para Analistas de Dados em 2026: Modelagem SQL, Testes Automatizados e Perguntas de Entrevista

O dbt (data build tool) se tornou pecachave na stack moderna de dados, e em 2026 praticamente toda vaga de analista de dados no Brasil e no exterior lista a ferramenta como requisito tecnico. Com o dbt Core v2.0 em fase alpha e a versao estavel v1.12 amplamente adotada, o ecossistema abrange modelagem SQL, testes automatizados, documentacao integrada e controle de versao via Git.

Este artigo apresenta a estrutura de projetos dbt, os padroes de modelagem mais utilizados no mercado, estrategias de teste de qualidade de dados e as perguntas que mais aparecem em entrevistas tecnicas para vagas de dbt data analyst e engenharia de dados.

Estrutura de Projeto dbt: Camadas Staging, Intermediate e Marts

Projetos dbt profissionais seguem uma arquitetura em camadas bem definida. Cada camada tem uma funcao clara, e essa organizacao impede que o codigo SQL se transforme em uma massa confusa e dificil de manter conforme a equipe cresce.

O padrao de mercado adota tres camadas principais:

• Staging — modelos enxutos que fazem renomeacao de colunas, conversao de tipos e limpeza basica dos dados brutos. A regra e criar um modelo staging para cada tabela de origem.
• Intermediate — camada onde acontecem joins, agregacoes e calculos que funcionam como blocos de construcao. Esses modelos nao sao acessados diretamente por dashboards.
• Marts — modelos finais que alimentam dashboards, relatorios e analises ad hoc. Cada mart corresponde a uma entidade de negocio ou metrica consolidada.

-- models/staging/stripe/stg_stripe__payments.sql
with source as (
    select * from {{ source('stripe', 'payments') }}
),

renamed as (
    select
        id as payment_id,
        amount / 100.0 as amount_usd,  -- Stripe stores cents
        status as payment_status,
        created::timestamp as created_at,
        customer_id
    from source
    where status != 'failed'  -- Filter invalid records early
)

select * from renamed

O modelo staging acima lida com casting de tipos e padronizacao de nomes. Na sequencia, o modelo mart aplica a logica de negocio:

-- models/marts/finance/fct_monthly_revenue.sql
with payments as (
    select * from {{ ref('stg_stripe__payments') }}
),

monthly as (
    select
        date_trunc('month', created_at) as revenue_month,
        count(*) as total_transactions,
        sum(amount_usd) as gross_revenue,
        sum(case when payment_status = 'refunded' then amount_usd else 0 end) as refunds
    from payments
    group by 1
)

select
    revenue_month,
    total_transactions,
    gross_revenue,
    refunds,
    gross_revenue - refunds as net_revenue  -- Key business metric
from monthly

A separacao entre staging e marts traz um beneficio pratico imediato: quando o schema de uma fonte muda, apenas o modelo staging correspondente precisa ser atualizado. Todas as queries downstream que dependem dele permanecem intactas, desde que o contrato de colunas do staging seja mantido.

Materializacoes no dbt: Como Escolher a Estrategia Adequada

O dbt disponibiliza quatro materializacoes que determinam como os modelos sao persistidos no warehouse. Uma escolha inadequada pode resultar em queries lentas demais ou em custos de computacao desnecessarios.

| Materialization | Use Case | Rebuild Behavior | |----------------|----------|-------------------| | view | Lightweight staging models, low query frequency | Recreated as SQL view on each run | | table | Mart models queried often by dashboards | Full table rebuild on each run | | incremental | Large fact tables (events, logs) | Appends/merges new rows only | | ephemeral | Reusable CTEs, never queried directly | Compiled inline as subquery |

Dentre essas opcoes, modelos incrementais merecem destaque especial porque resolvem o principal gargalo de performance em projetos de data analytics dbt: o reprocessamento integral de tabelas com bilhoes de linhas.

-- models/marts/product/fct_page_views.sql
{{ config(
    materialized='incremental',
    unique_key='page_view_id',
    incremental_strategy='merge'
) }}

with events as (
    select
        event_id as page_view_id,
        user_id,
        page_url,
        session_id,
        event_timestamp
    from {{ ref('stg_snowplow__events') }}
    where event_type = 'page_view'

    {% if is_incremental() %}
        -- Only process new events since last run
        and event_timestamp > (select max(event_timestamp) from {{ this }})
    {% endif %}
)

select * from events

A macro is_incremental() verifica se o modelo ja existe. Na primeira execucao, todos os dados sao processados. Nas execucoes subsequentes, apenas os registros novos entram no pipeline, transformando um job que levaria horas em uma operacao de poucos minutos.

Testes de Qualidade de Dados no dbt

A abordagem de testes do dbt opera em dois niveis complementares: testes de schema declarados em YAML e testes customizados escritos diretamente em SQL. Ambos sao acionados com o comando dbt test e bloqueiam o pipeline sempre que uma violacao e identificada.

Testes de schema atendem as verificacoes de qualidade mais comuns sem exigir a escrita de nenhuma query:

# models/staging/stripe/_stripe__models.yml
version: 2

models:
  - name: stg_stripe__payments
    description: "Cleaned payment records from Stripe"
    columns:
      - name: payment_id
        description: "Unique payment identifier"
        tests:
          - unique
          - not_null
      - name: payment_status
        tests:
          - accepted_values:
              values: ['succeeded', 'pending', 'refunded']
      - name: amount_usd
        tests:
          - not_null
          - dbt_utils.expression_is_true:
              expression: ">= 0"  # No negative payments

Quando a logica de validacao excede o que o YAML consegue representar, testes singulares preenchem essa lacuna. O teste abaixo verifica uma regra de negocio critica: a receita liquida mensal jamais pode ser negativa.

-- tests/assert_revenue_not_negative.sql
-- This test fails if any month has negative net revenue
select
    revenue_month,
    net_revenue
from {{ ref('fct_monthly_revenue') }}
where net_revenue < 0  -- Should never happen

A logica dos testes singulares e direta: qualquer linha retornada pela query indica falha. Esse mecanismo detecta corrupcao de dados, bugs em sistemas upstream e erros de logica antes que cheguem aos dashboards consumidos pelas areas de negocio.

Jinja e Macros: Eliminando Repeticao no SQL

O dbt utiliza Jinja como engine de templates para tornar o SQL dinamico e reutilizavel. As funcoes fundamentais sao ref() para referenciar outros modelos e source() para apontar para dados brutos. Alem delas, macros permitem encapsular padroes SQL que se repetem ao longo do projeto.

Um exemplo classico e a conversao de centavos para dolares, operacao recorrente em qualquer projeto que lida com dados financeiros:

-- macros/cents_to_dollars.sql
{% macro cents_to_dollars(column_name) %}
    ({{ column_name }} / 100.0)::numeric(12, 2)
{% endmacro %}

-- Usage in any model
select
    payment_id,
    {{ cents_to_dollars('amount_cents') }} as amount_usd,
    {{ cents_to_dollars('tax_cents') }} as tax_usd
from {{ source('stripe', 'payments') }}

No momento do build, a macro e compilada em SQL padrao. O ganho real dessa abordagem e a consistencia: a logica de conversao monetaria fica centralizada em um unico ponto. Caso a regra de arredondamento precise mudar, basta alterar a macro e a mudanca se propaga automaticamente para todos os modelos que a utilizam.

Perguntas de Entrevista sobre dbt: O que os Recrutadores Cobram

Processos seletivos que avaliam conhecimento em dbt priorizam o entendimento pratico sobre definicoes teoricas. As perguntas listadas a seguir sao recorrentes em entrevistas de data analytics e vagas de dbt data analyst no Brasil e no exterior.

P1: Qual a diferenca entre ref() e source()?

A funcao source() referencia tabelas brutas carregadas por ferramentas de ingestao, declaradas em um arquivo sources.yml. Ja ref() referencia outros modelos dbt. O uso sistematico de ref() e o que permite ao dbt construir o DAG (grafo aciclico direcionado), determinar a ordem correta de execucao e rastrear a linhagem completa dos dados. Substituir ref() por nomes de tabelas hardcodados quebra o rastreamento de linhagem e impede que o dbt execute os modelos na sequencia adequada.

P2: Em que situacao um modelo incremental e preferivel a uma table?

A materializacao incremental e indicada quando os dados de origem sao predominantemente append-only ou possuem uma coluna de timestamp confiavel, e quando o volume da tabela torna o rebuild completo lento ou caro. Tabelas de eventos, logs de aplicacao e series temporais sao os candidatos mais comuns. Tabelas de dimensao pequenas devem continuar como table, pois o overhead da logica incremental nao compensa para volumes reduzidos.

P3: Como o dbt implementa dimensoes de mudanca lenta (SCD Type 2)?

O recurso de snapshots do dbt implementa o rastreamento SCD Type 2. Um snapshot monitora uma tabela de origem e registra cada alteracao ao longo do tempo por meio das colunas dbt_valid_from e dbt_valid_to. Duas estrategias estao disponiveis: timestamp (baseia-se em uma coluna updated_at) e check (compara valores das colunas diretamente). Snapshots sao executados com dbt snapshot, em separado do comando dbt run.

P4: Descreva o padrao staging/intermediate/marts e sua importancia.

Modelos staging realizam limpeza e padronizacao dos dados brutos da fonte: um modelo por tabela de origem, sem joins e sem agregacoes. Modelos intermediate encapsulam a logica de negocio, incluindo joins, filtros e calculos intermediarios. Modelos mart representam as saidas finais consumidas por analistas e dashboards. Essa arquitetura em camadas assegura responsabilidade unica por modelo e isola o impacto de mudancas no schema de origem exclusivamente na camada staging.

P5: Qual a diferenca entre testes de schema e testes singulares customizados?

Testes de schema sao declarados em YAML e abrangem verificacoes padrao como unique, not_null, accepted_values e relationships. Testes singulares sao queries SQL armazenadas no diretorio tests/: qualquer linha retornada pela query indica falha. Testes genericos customizados sao macros parametrizadas reutilizaveis entre modelos, funcionando de forma similar aos testes de schema. A recomendacao e utilizar testes de schema para restricoes convencionais e reservar testes singulares para regras de negocio complexas, como a validacao de que a receita liquida nunca seja negativa.

Boas Praticas de dbt para Projetos em Producao

Projetos dbt que crescem alem de uma dezena de modelos demandam convencoes rigorosas para evitar o acumulo de divida tecnica. As praticas a seguir sao consideradas padrao de mercado em equipes de data analytics.

Nomenclatura padronizada facilita a navegacao no projeto. Modelos staging recebem o prefixo stg_, intermediarios usam int_, e tabelas fato e dimensao adotam fct_ ou dim_. Subdiretorios organizados por fonte (models/staging/stripe/, models/staging/salesforce/) agrupam modelos relacionados e tornam a estrutura intuitiva.

Documentacao integrada ao codigo. Cada modelo e coluna deve conter uma description no arquivo YAML correspondente. O comando dbt docs generate produz um site de documentacao navegavel com um DAG visual interativo, recurso indispensavel para onboarding de novos integrantes e auditoria de linhagem de dados.

Monitoramento de freshness das fontes identifica falhas de ingestao antes que comprometam as transformacoes:

# models/staging/stripe/_stripe__sources.yml
version: 2

sources:
  - name: stripe
    database: raw
    schema: stripe
    freshness:
      warn_after: {count: 12, period: hour}
      error_after: {count: 24, period: hour}
    loaded_at_field: _fivetran_synced
    tables:
      - name: payments
      - name: customers

Ao executar dbt source freshness, o dbt verifica se os dados da fonte foram atualizados dentro da janela configurada. Um gap de 24 horas nos dados de pagamento, por exemplo, sinaliza uma falha no pipeline de ingestao que precisa ser investigada antes de qualquer transformacao ser executada.

Para aprofundar as habilidades SQL aplicadas em modelos dbt, os guias sobre window functions e CTEs em SQL e SQL avancado para entrevistas abordam os padroes de query mais frequentes em projetos de dbt modeling.

Conclusao

• O dbt e a camada de transformacao do pipeline ELT, executando SQL diretamente no data warehouse sem depender de motores de processamento externos
• A arquitetura staging/intermediate/marts isola a limpeza de dados da logica de negocio, tornando manutencao e evolucao do projeto previsiveis
• Materializacoes incrementais eliminam o reprocessamento desnecessario em tabelas volumosas ao tratar apenas registros novos ou atualizados
• Testes de schema (YAML) garantem restricoes basicas de qualidade; testes singulares (SQL) validam regras de negocio especificas do dominio
• Macros Jinja centralizam logica SQL repetitiva e asseguram consistencia em todo o projeto
• Verificacoes de source freshness interceptam falhas de ingestao upstream antes que dados desatualizados contaminem modelos downstream
• A preparacao para dbt interview questions deve privilegiar cenarios praticos como linhagem no DAG, trade-offs entre materializacoes e estrategias de teste, em detrimento de definicoes memorizadas