dbt
Mittleres LevelWie beschleunige ich dbt-Modelle und senke die Snowflake-/BigQuery-Rechenkosten?
In einem dbt-Projekt sind Laufzeit und Warehouse-Rechnung fast dieselbe Kennzahl mit zwei Namen — das eine zu beheben behebt meist auch das andere.
Anders als bei einem selbst provisionierten Spark-Cluster berechnet Ihnen ein dbt-Projekt auf Snowflake/BigQuery die Warehouse-Rechenzeit — ein langsames Modell ist also nicht nur ärgerlich, es ist eine direkte Kostenposition. Das macht die Diagnoseliste kürzer und handlungsrelevanter, als es scheinen mag.
Beginnen Sie mit elapsed_time vs. execution_time, pro Modell
dbts eigenes run_results.json (geschrieben nach jedem dbt run/build)
hat bereits beides: die gesamte verstrichene Zeit des Aufrufs und die Ausführungszeit pro Modell. Ein Modell,
dessen Ausführungszeit klein im Verhältnis zur gesamten verstrichenen Zeit ist, ist nicht das Problem — etwas
davor (Warehouse-Queueing, Abhängigkeitsreihenfolge) ist es. Ein Modell, dessen Ausführungszeit den Lauf
tatsächlich dominiert, ist, wo Sie zuerst nachsehen sollten.
Die Materialisierungswahl ist meist der größte einzelne Hebel
Ein als view materialisiertes Modell, das von vielen nachgelagerten Modellen abgefragt wird,
führt seine eigene Logik effektiv bei jeder einzelnen Referenzierung erneut aus — und macht so aus einer
eigentlich einmaligen Kostenposition eine wiederholte. Eine häufig referenzierte, teure Transformation auf
table oder incremental umzustellen senkt die gesamten Warehouse-Rechenkosten oft
drastisch, auf Kosten von etwas Speicherplatz und etwas Aktualitätsverlust.
Falsch gemachte Incremental-Modelle kosten mehr als volle Refreshes
Ein Incremental-Modell mit schlecht gewähltem unique_key oder einem
is_incremental()-Filter, der den Scan nicht wirklich eingrenzt (bei jedem Lauf „incremental“ die
komplette Quelltabelle scannt), gibt Ihnen die volle Komplexität der Incremental-Materialisierung ohne die
Einsparungen. Es lohnt sich, explizit zu prüfen: Scannt der Incremental-Lauf laut dem eigenen Query-Profil des
Warehouse tatsächlich weniger Daten, als ein voller Refresh würde?
Parallelität (dbts threads-Konfiguration) hat eine Obergrenze
Mehr Threads bedeuten mehr Modelle, die gleichzeitig gegen das Warehouse laufen — bis zu dem Punkt, an dem sie alle um dieselben Warehouse-Compute-Slots konkurrieren, ab dem mehr Threads nur mehr Warteschlange bedeuten, nicht mehr tatsächlichen Durchsatz. Diese Obergrenze hängt von der Warehouse-Größe ab, ein aus einem anderen Projekt kopierter Wert passt also nicht zwangsläufig zu Ihrem.
Was opti-pipe aus einem dbt-Lauf liest: die gesamte verstrichene Zeit und die Ausführungszeit pro
Modell direkt aus run_results.json — nie Ihr SQL, Modellnamen oder Dateipfade — um zu markieren,
welche Modelle tatsächlich die Kosten des Laufs treiben, mit demselben „echte Zahlen ansehen statt raten“-
Ansatz wie die Spark-Regeln oben.
Sehen Sie, wie das bei Ihrer eigenen Pipeline aussieht.
Laden Sie ein echtes Spark-Event-Log, ein dbt run_results.json oder einen Flink-Metrics-Export hoch und erhalten Sie konkrete, vor der Anwendung zu genehmigende Empfehlungen zurück — keine weitere Faustregel.