dbt
Nível médioModelos incrementais do dbt: quando «incremental» silenciosamente vira um full refresh
Todo o sentido de um modelo incremental é processar só linhas novas ou alteradas. Alguns gatilhos comuns transformam isso silenciosamente numa reconstrução completa, a cada execução, sem nenhum erro.
O dbt decide se roda um modelo de forma incremental ou como full refresh com base em algumas condições - e mais de uma delas pode mudar silenciosamente depois de meses do modelo funcionando bem.
Como o dbt decide entre incremental e full refresh
Além de uma flag explícita --full-refresh, o dbt recorre a uma reconstrução completa se
a tabela destino ainda não existir, ou - dependendo da sua configuração de on_schema_change -
se o conjunto de colunas do modelo mudou desde que a tabela foi criada. on_schema_change: "fail"
para a execução na hora diante de uma divergência; "ignore" (o padrão) ou um
"append_new_columns"/"sync_all_columns" mal configurado podem, em vez disso,
disparar silenciosamente uma reconstrução completa dependendo do que realmente mudou.
Por que é silencioso: sem erro, só uma execução muito mais longa
Um full refresh não é um estado de falha do ponto de vista do dbt - a execução continua verde. O que
muda é o execution_time em run_results.json, saltando bem acima da faixa
normal, e uma linha na fatura do warehouse que não bate com «só adicionamos um dia de dados». Ninguém é
alertado por um sucesso lento.
Como pegar isso antes da fatura
Compare o execution_time de cada modelo incremental com sua própria média histórica,
não com um limite fixo - um modelo que normalmente leva 40 segundos e de repente leva 25 minutos é o
sinal, não importa o que seja «aceitável» para outro modelo no mesmo projeto.
Um modelo em que isso acontece não está quebrado - sua configuração está simplesmente
fazendo exatamente o que você pediu, sob uma condição que você não esperava encontrar. O ajuste quase
sempre está no on_schema_change ou em o que quer que tenha mudado o conjunto de colunas
mais acima, não no SQL do modelo em si.
Veja como isso fica no seu próprio pipeline.
Envie um event log real do Spark, um run_results.json do dbt, ou uma exportação de
métricas do Flink, e receba recomendações concretas que exigem sua aprovação - não mais uma regra
geral.