Treibt Ihr dbt-Run still und leise die Warehouse-Compute-Kosten hoch?

dbt, inzwischen gemeinsam mit Fivetran unter einem Dach, führt jedes Modell im Warehouse aus. Das ist die richtige Architektur. Es bedeutet auch, dass Ineffizienz keinen Fehlerzustand hat: Ein Modell, das jede Nacht ein Jahr Historie neu baut, läuft erfolgreich durch, und die Kosten tauchen woanders auf.

Warum die Compute-Kosten schleichend steigt

• Vollständige Neuaufbauten sind der Standard. Eine table Materialisierung löscht und erstellt bei jedem Lauf neu. Sie inkrementell zu machen ist Zusatzarbeit pro Modell, und diese Arbeit lässt sich leicht verschieben.
• Inkrementelle Logik erfordert Handarbeit. Unique-Keys, Lookback-Fenster und Merge-Strategien werden pro Modell entschieden, von dem, der es geschrieben hat, und zwischen Entwicklern driften sie auseinander.
• Der DAG läuft breiter als die Änderung. Eine geänderte Eingabe kann einen Lauf über viele Modelle weiter unten auslösen, von denen die meisten dieselbe Ausgabe liefern wie gestern.
• Solange ein Lauf grün durchläuft, hinterfragt niemand die Effizienz. Eine Performance-Analyse findet nicht statt. Compute pro Modell ist in der Warehouse Konsole sichtbar, nicht in der Pipeline.

Nichts davon ist ein Fehler von dbt. Handgeschriebene Transformationslogik ist so effizient, wie die Person, die sie geschrieben hat, Zeit hatte, sie zu machen.

Wo Effizienz hingehört

• Inkrementelles Delta-Laden muss der Standard sein. Wenn das Lademuster generiert wird, ist inkrementell keine Wahl, die ein Entwickler unter Termindruck trifft. Es ist die Art, wie jeder Load geschrieben wird.
• Historie sollte an einem Ort isoliert sein. Satelliten halten Änderungen über die Zeit, die Mart-Schicht muss also nie Historie neu berechnen, um eine Frage zum Jetzt zu beantworten.
• Mengenbasiertes SQL für die Engine, die Sie betreiben. Generierter Code lässt sich einmal pro Plattform tunen, statt pro Modell durch den, der es geschrieben hat.

Was sich mit Datavault Builder ändert

Datavault Builder generiert mengenbasierte Delta-Loads für Hubs, Links und Satelliten, abgestimmt auf die Zielengine, sodass der teure Teil der Pipeline immer nur das berührt, was sich geändert hat.

• Jeder Load ist konzeptionell bedingt ein Delta. Neue und geänderte Zeilen werden gegen das erkannt, was bereits historisiert ist. Nichts wird gelöscht und neu erstellt.
• Historie lebt in Satelliten. Stichtagsabfragen (As-Was) werden aus gespeicherten Änderungen beantwortet, nicht indem die Vergangenheit bei jedem Lauf neu gebaut wird. Bitemporale Loads und Point-in-Time-Tabellen sind Patterns, die die Plattform von Haus aus bietet, nichts, was aus Makros gebaut werden muss.
• Der Ausführungsumfang richtet sich nach den tatsächlichen Änderungen. Abhängigkeiten werden abgeleitet, eine Änderung lädt also, was sie berührt, und nichts darüber hinaus.
• dbt-State und Fusion helfen weiterhin, wenn dbt bleibt. Datavault Builder kann die dbt Modelle für Teams generieren, die den Betrieb dort behalten, und diese profitieren von übersprungenen unveränderten Modellen. Die generierten Schichten darunter mussten nie übersprungen werden, weil sie nie die volle Arbeit gemacht haben.
• Compute wird vorhersehbar. Die Ladekosten folgen dem, wie viel sich die Quellen geändert haben, nicht der Gesamtgröße des Warehouse, und das ist eine Zahl, die Sie beobachten können.

Was zu entscheiden ist

Nehmen Sie die zehn teuersten Modelle aus der Warehouse Query-Historie des letzten Monats. Wenn die meisten davon Staging oder Historienmodelle sind, die komplett neu gebaut werden, ist das die generierte Schicht, die darauf wartet zu existieren.