Como funcionam os modelos incrementais no dbt, e quando você usa um em vez de reconstruir tudo?

Um modelo incremental constrói a tabela uma vez e, nas execuções seguintes, processa apenas linhas novas ou alteradas e faz merge delas, usando um bloco is_incremental para filtrar a origem. Use quando a reconstrução completa fica lenta ou cara demais, tipicamente em tabelas grandes de eventos. Mantenha uma chave única para que atualizações atrasadas façam merge em vez de duplicar, e mantenha o full refresh possível para poder reconstruir depois de mudanças de lógica.

Na primeira execução ele constrói a tabela inteira. Depois disso, o bloco is_incremental adiciona um filtro para que você só escaneie linhas recentes da origem, e o dbt faz o merge delas na tabela existente por uma chave única. Eu só recorro a isso quando a reconstrução completa virou algo realmente doloroso, porque modelos incrementais carregam estado e estado diverge. Dois hábitos os mantêm honestos. Primeiro, uma janela de retrospectiva em vez de um estritamente maior que o timestamp máximo, porque as origens atualizam linhas retroativamente. Nós usamos três dias em um modelo de pedidos depois de descobrir que reembolsos chegavam com até 48 horas de atraso e estavam sendo perdidos por completo. Segundo, um full refresh agendado, semanal no nosso caso, que pega a divergência e prova que o modelo ainda consegue ser reconstruído. A falha que eu já vi foi um modelo incremental sem chave única em uma estratégia de append, que contava tudo em dobro silenciosamente toda vez que uma retentativa rodava, e ninguém percebeu até um número mensal discordar do financeiro.