Comment fonctionnent les modèles incrémentaux dans dbt, et quand en utilisez-vous un plutôt qu'une reconstruction complète ?

Un modèle incrémental construit la table une fois, puis lors des exécutions suivantes ne traite que les lignes nouvelles ou modifiées et les merge, en utilisant un bloc is_incremental pour filtrer la source. Utilisez-en un quand une reconstruction complète est trop lente ou trop coûteuse, typiquement sur de grosses tables d'événements. Gardez une clé unique pour que les mises à jour tardives fusionnent au lieu de dupliquer, et gardez le full refresh possible pour pouvoir reconstruire après un changement de logique.

À la première exécution, il construit toute la table. Ensuite, le bloc is_incremental ajoute un filtre pour ne scanner que les lignes sources récentes, et dbt les merge dans la table existante sur une clé unique. Je n'y ai recours que quand une reconstruction complète est devenue vraiment pénible, parce que les modèles incrémentaux portent de l'état, et l'état dérive. Deux habitudes les gardent honnêtes. D'abord, une fenêtre de rattrapage plutôt qu'un strictement supérieur au timestamp max, parce que les sources mettent à jour des lignes rétroactivement. Nous avons utilisé trois jours sur un modèle de commandes après avoir découvert que les remboursements arrivaient jusqu'à 48 heures plus tard et étaient totalement ratés. Ensuite, un full refresh planifié, hebdomadaire dans notre cas, qui attrape la dérive et prouve que le modèle peut encore être reconstruit. L'échec que j'ai vu, c'est un modèle incrémental sans clé unique en stratégie append seul, qui doublait tranquillement les comptes à chaque reprise, et personne ne l'a remarqué avant qu'un chiffre mensuel ne contredise la finance.