Grafische Einordnung zu dbt Core und dbt Fusion ohne Fließtext. Geteilter Hintergrund in Orange und Blau. Links dbt Core mit Symbolen für Open Source, Python-basierte Verarbeitung und lokale Ausführung. Rechts dbt Fusion mit Symbolen für state-aware Orchestration, höhere Performance und moderne Architektur. Pfeile und Icons zeigen den Übergang von Einordnung zur möglichen Migration.

Dbt Fusion Migration Quick-Checklist

Wenn du darüber nachdenkst ein Projekt von dbt Core zu dbt Fusion zu migrieren, gibt es aus meiner Sicht drei essenzielle Dinge, die zuerst gemacht bzw. kontrolliert werden sollten. Zuallererst muss der dbt Fusion Adapter Support geprüft werden. Zum Zeitpunkt dieses Artikels ist ein Adapter für Snowflake, Databricks, Big Query und Redshift verfügbar​ [7]​. Weitere sind in Planung. Sollte die im Unternehmen genutzte Datenbanktechnologie hier (noch) nicht vorhanden sein, ergibt eine Migration zum aktuellen Zeitpunkt keinen Sinn. Des Weiteren müssen die im Einsatz befindlichen Packages auf Kompatibilität geprüft werden​ [6]​. Um die dbt Migration durchzuführen, sollte das zu migrierende Projekt mindestens auf dbt Core Version 1.10 laufen ​[8]​. Alle Warnungen, die angezeigt werden, weil Features deprecated werden, müssen bearbeitet werden. Dbt Fusion wird diese so nicht mehr anbieten. Allerdings sollte dies aus Gründen der Aktualität so oder so irgendwann gemacht werden, selbst wenn keine dbt Fusion Migration ansteht. Hier gibt es auch ein autofix Tool von dbt auf welches in der Schritt-für-Schritt Anleitung eingegangen wird.

Herausforderungen und Feature Abdeckung in DBT Fusion

Darüber hinaus ergibt es Sinn genau zu prüfen welche Features dbt Fusion aktuell noch nicht anbietet. Sollte hier etwas dabei sein, was für mein Projekt essenziell ist, können noch mögliche Workarounds auf Praktikabilität geprüft werden. Hier folgt eine Liste der aus meiner Sicht wichtigsten Dinge, die man betrachtet haben sollte. Dbt Fusion unterstützt noch nicht alle materialization Typen. Der Typ microbatch incremental wird aktuell noch nicht unterstützt. Dies ist nicht zu verwechseln mit incremental, welches genauso wie table und view bereits unterstützt wird ​[9]​. Außerdem ist Vorsicht geboten, wenn mein Projekt Python Modelle aufweist. Diese werden noch nicht vollständig unterstützt. Hier ist aktuell sehr viel Bewegung in der Entwicklung, so dass zum aktuellen Zeitpunkt eine Alpha Version auf Snowflake verfügbar ist ​[10]​. Weitere Dinge, die es zu beachten gilt, die aber sehr wahrscheinlich kein Show-Stopper sein sollten, sind: Die Verwendung von SQL Fluff für Linting ist auf Fusion so nicht mehr möglich. Ein nativer Linter für Fusion ist aber von dbt in der Planung ​[11]​. Ebenfalls bietet dbt Fusion noch keine Dokumentationsfeatures ​[12]​. In beiden Fällen kann aber einfach auf dbt Core zurückgegriffen werden. Ein weiteres, durchaus häufig genutztes Feature ist das –store-failures flag, um Testergebnisse in der Datenbank zu speichern. Dieses ist in Fusion so noch nicht verfügbar, allerdings gibt es einen dokumentierten Workaround ​[13]​. Eine weitere Auflistung, was sich geändert hat oder so noch nicht verfügbar ist, findest du hier ​[14]​ und hier ​[15]​. Dies sollte vor einer Migration einmal geprüft werden, um potenzielle Herausforderungen der Migration für das eigene Projekt aufzudecken.

Schritt-für-Schritt Migration Guide

Wenn ich mich nach den initialen Prüfungen der Kompatibilität und des Feature Umfanges dafür entscheide von dbt Core nach Fusion zu migrieren, ist der eigentliche Prozess sehr einfach. Vor allem, wenn ich vorab Deprecation Warnungen beseitigt habe. Initial muss ich Fusion erst einmal installieren. Das geht sehr einfach über die Command Line (CL) ​[16]​. Im Anschluss kann ich optional die dbt VS Code Extension über den VS  Code Marketplace installieren ​[17]​. Die Extension muss innerhalb von 14 Tagen registriert werden. Dies ist für Organisationen mit bis zu 15 Nutzern kostenlos.

Wenn ich mich für die Verwendung der VS Code Extension entschieden habe, kann ich mich von ihr durch den Migrationsprozess leiten lassen. Dies geschieht durch das Klicken auf den „Get Started“ Button, der mir in der Extension oben links angezeigt wird.

Abbildung 1 – Start des Migrationsprozesses in der VS Code Extension 

Der Button löst aber nichts anderes aus als ein dbt init–fusion-upgrade. Ich kann also auch sehr einfach diesen Befehl in der CL ausführen. Im Anschluss triggert dbt eine Reihe an Befehlen, die ich auch zu Gunsten der Übersichtlichkeit selberselbst einzeln ausführen kann anstelle des dbt init. Im Folgenden werden diese Befehle einzeln gelistet und erklärt: 

  • dbtf init: Dies würde eine profile.yml Datei erzeugen. Da es sich um ein bereits existierendes lauffähiges Projekt handelt, welches wir migrieren möchten, sollte diese bereits vorhanden sein. Es kann ganz einfach selektiert werden, dass die existierende profile.yml verwendet werden soll. 
  • dbtf debug: Vergleichbar mit dem alten debug aus DBT Core, wird hier die Verbindung zur Datenbank geprüft. 
  • dbtf parse: Dies ist das erste interessante Kommando für die Migration. Es kontrolliert die Modelle auf Kompatibilität. Haben wir vorher sauber gearbeitet, sollten hier keine Fehler angezeigt werden. 

Hier ist der richtige Zeitpunkt für einen Exkurs zu dbt-autofix ​[18]​. Nach Installation dieses Tools, kann ich es dazu verwenden, Korrekturen automatisiert vorzunehmen. Dies sind die Befehle dbt-autofix –debug deprecations. Es repariert also automatisch alles, was mir in dbt Core > v1.10 als deprecation Warunung angezeigt wurde (–debug für besseren Konsolen Output). Es ist keine partielle Anwendung möglich ist. Verwende ich dieses Tool, wird es alle Stellen, die es findet nach bestem Wissen und Gewissen automatisch korrigieren. Es liegt an mir selbst zu entscheiden, ob ich diese Kontrolle aus der Hand geben möchte. In meinem kleinen Testprojekt für diesen Artikel, wollte ich die Kompatibilität von dbt Fusion mit dem automateDV Package ​[19]​, welches wir zur Data Vault 2.0 Implementierung verwenden, testen. Ich habe die Migration also auf einem kleinen Subset unserer Modelle durchgeführt. Fehler, die mir dabei untergekommen sind, waren zum einen fehlerhaft beschriebene Tests, weil wir noch nicht den arguments Parameter im entsprechenden yaml File verwendet haben (Beispiel für ignorierte Deprecations Warnungen): 

Schema-Datei mit dbt Data Test Konfiguration ab Version 1.10.5. Die Test-Parameter sind unter dem Schlüssel arguments zusammengefasst.

Abbildung 2- Ab dbt Core v1.10.5 sollten Konfigurationen des Data Tests unter arguments zusammengefasst werden [19].

Außerdem trat ein für die Migration typischer Fehler bei der Verwendung von custom config keys in den Modellen auf [21]. In meinem Fall war es eine Konfiguration für die automateDV Makros. Dies ist ein sehr häufiger Fehler und die meisten Package Maintainer haben sich bereits damit auseinandergesetzt. Auch hier habe ich automatisiert korrigiert mit dbt-autofix:

Abbildung 3 zeigt einen Deprecation Warning in dbt Core größer Version 1.10. Ursache ist die inkorrekte Verwendung von custom config keys in einem Modell. Die Abbildung verdeutlicht, dass diese Konfigurationen nicht mehr zulässig sind und im Zuge der Migration angepasst werden müssen.

Abbildung 3 – Fehler durch inkorrekte Verwendung der custom config keys. Auch dies steht unter den Deprecation Warnings beim Wechsel auf dbt Core >v1.10 [22]

Bei mir hat die automatisierte Korrektur also sehr gut funktioniert. Auch wenn man sich gegen die automatisierte Korrektur der Modelle entscheidet, sei an dieser Stelle sei aber zusätzlich erwähnt, dass mindestens das dbt-autofix –debug packages Kommando sehr hilfreich sein kann, weil es mir anzeigt welche meiner verwendeten Packages kompatibel sind. So konnte ich z.B. in meinem Fall sehr schnell, die im Team diskutierte Frage, ob automateDV (in seiner neusten Version v0.11.4) kompatibel ist, mit positivem Ergebnis klären:

Abbildung 4 zeigt die Ausgabe der Package-Prüfung mit dbt-autofix im Terminal. Das Tool identifiziert installierte dbt-Packages und prüft deren Kompatibilität mit dbt Fusion. Die Ausgabe weist aus, welche Packages unverändert bleiben, bereits kompatibel sind oder deren Version trotz fehlender Deklaration als Fusion-kompatibel bestätigt wurde.

Abbildung 4 – Ergebnis der Package Prüfung durch dbt-autofix. 

Habe ich alle Fehler behoben und dbtf parse läuft sauber durch, kann ich mit den weiteren benötigten Kommandos fortfahren:

  • dbtf compile -static-analysis off: Dies ist praktisch die Vorstufe. Es kompiliert einmal ohne die static analysis und imitiert damit dbt Core.
  • dbtf compile: Kompiliert den Code komplett wie in Fusion also mit static analysis. Läuft das sauber durch, ist das Projekt migriert und dbt Fusion kann von nun an genutzt werden.
Abbildung 5 zeigt die Konsolenausgabe nach einer erfolgreichen Migration von dbt Core zu dbt Fusion. Die Meldung bestätigt, dass das Projekt fehlerfrei kompiliert wurde und in der Zielumgebung lauffähig ist. Zusätzlich werden empfohlene nächste Schritte angezeigt, darunter die Vorschau von Modellergebnissen, die Nutzung von Lineage-Tools sowie weiterführende Dokumentationslinks zu dbt Fusion.

Abbildung 5 – Meldung nach erfolgreicher Migration von dbt Core nach dbt Fusion 🚀.

Migration in der Praxis. Schnell umgesetzt, messbarer Effekt

Die eigentliche Migration ist also nach sinnvoller Vorarbeit eher eine Sache von Minuten. Für mein Testprojekt kann ich auf jeden Fall die von dbt aufgestellte Behauptung, dass die Fusion Engine schneller läuft als dbt Core bestätigen. Nach erfolgreicher Migration erfolgte das build Kommando mit Fusion mehr als doppelt so schnell im Vergleich zu vorher.