Wie funktionieren inkrementelle Modelle in dbt, und wann nimmst du eins statt eines kompletten Neubaus?

Ein inkrementelles Modell baut die Tabelle einmal auf und verarbeitet bei späteren Läufen nur neue oder geänderte Zeilen und merged sie hinein, über einen is_incremental-Block, der die Quelle filtert. Nimm eins, wenn ein kompletter Neubau zu langsam oder zu teuer ist, typischerweise bei großen Event-Tabellen. Halt einen Unique Key vor, damit späte Updates gemerged statt dupliziert werden, und halt Full Refresh möglich, damit du nach Logikänderungen neu bauen kannst.

Beim ersten Lauf wird die ganze Tabelle gebaut. Danach fügt der is_incremental-Block einen Filter hinzu, sodass du nur jüngere Quellzeilen scannst, und dbt merged sie über einen Unique Key in die bestehende Tabelle. Ich greife erst danach, wenn ein kompletter Neubau wirklich schmerzhaft geworden ist, denn inkrementelle Modelle tragen State, und State driftet. Zwei Gewohnheiten halten sie ehrlich. Erstens ein Lookback-Fenster statt eines strikten größer als max(Timestamp), denn Quellen aktualisieren Zeilen rückwirkend. Wir haben in einem Orders-Modell drei Tage genommen, nachdem wir gemerkt hatten, dass Rückerstattungen bis zu 48 Stunden später eintrafen und komplett übersehen wurden. Zweitens ein geplanter Full Refresh, bei uns wöchentlich, der sowohl Drift aufdeckt als auch beweist, dass sich das Modell überhaupt noch neu bauen lässt. Der Fehler, den ich gesehen habe: ein inkrementelles Modell ohne Unique Key mit Append-Strategie, das bei jedem Retry still doppelt gezählt hat, und niemand hat es gemerkt, bis eine Monatszahl der Finanzabteilung widersprach.