In modernen Datenplattformen entsteht Komplexität selten über Nacht. Sie wächst schleichend durch immer neue Anforderungen, zusätzliche Reports, kurzfristige Workarounds und SQL-Logik, die direkt an Tabellen geknüpft wird.

Was zunächst funktioniert, entwickelt sich über die Zeit zu einer fragmentierten Transformationsebene, in der Abhängigkeiten verborgen sind, Geschäftslogik dupliziert wird und Transparenz verloren geht. Die Folge sind fragile Datenpipelines, schwer nachvollziehbare Ergebnisse und ein steigender Aufwand für Wartung, Qualitätssicherung und Analyse.

Gerade weil Daten heute die Grundlage für operative Entscheidungen, Reports und KI-gestützte Modelle bilden, ist diese Situation nicht tragbar.

Das Open-Source-Werkzeug „dbt“ greift genau dieses Problem auf und überführt über die Zeit gewachsene, unübersichtlich gewordene Datentransformationen in eine klar strukturierte und transparente Modelllandschaft.

Dass dbt längst kein Nischentool mehr ist, zeigt sich seit Jahren im internationalen Einsatz in vielen Unternehmen. In vielen modernen Datenplattformen ist es inzwischen ein fester Bestandteil des Daten-Toolsets und hat vielfach seine Zuverlässigkeit und Robustheit in der Datentransformation bewiesen.

In diesem Blogartikel werfen wir einen kleinen praxisnahen Blick auf dbt und prüfen, wie wir Ordnung und Struktur in unsere Datenprojekte bringen können und wie aufwendig die Umsetzung tatsächlich ist.

Vom SQL-Chaos zur klaren Modelllandschaft

Die Grundidee besteht darin, ein über Jahre gewachsenes Data Warehouse (DWH) mit einer Vielzahl an Tabellen, Views, Mappings/Skripten in eine klare, strukturierte und wartbare Modelllandschaft zu überführen. Dabei kommen die bewährten Methodiken von dbt zum Einsatz.

Zunächst werden harte Tabellenabhängigkeiten konsequent in der Modellierung vermieden und durch explizite Referenzen (ref()) ersetzt. Daraus entsteht eine automatische Build-Reihenfolge.

Mit Jinja wird eine Automatisierungsebene in die Modellierung gezogen, die wiederverwendbare Patterns, Parametrisierung und einfache Schleifen ermöglicht und so das DRY-Prinzip (Don't Repeat Yourself) konsequent unterstützt.

Mithilfe von YAML-Dateien werden die Modelle zentral konfiguriert. Sie dienen als Speicherort für Metadaten, Tests, Abhängigkeiten/Dokumentation und Parameter. Diese Struktur erlaubt es, das Verhalten und die Qualitätssicherung der Modelle unabhängig von den SQL-Dateien zu steuern und zu kontrollieren.

Darüber hinaus bietet dbt die Möglichkeit, Tests, Automatisierungen und Dokumentation als zentrale Bestandteile des Build-Prozesses zu integrieren. Wie sich diese Möglichkeiten konkret nutzen lassen, erfahrt ihr im nächsten Blogbeitrag.

Entkopplung von Abhängigkeiten

Kommen wir nun zum praktischen Teil. In einem fiktiven DWH wird mithilfe eines Medallion-ähnlichen Ansatzes ein dbt-Projekt entwickelt (Jaffle Shop von dbt-Labs). Die benötigten Daten werden entweder direkt aus den Quelldatenbanken abgeholt oder liegen bereits auf der Datenplattform vor. In der dbt_project.yml sind die Modelle entsprechend konfiguriert, sodass die Daten in einem eigenen Schema wie STAGING materialisiert werden.

Im Modell marts/order_items.sql wird aus den STAGING-Modellen direkt ein MART-Modell zur Demonstration aufgebaut. Dabei kommt konsequent die ref()-Funktion zum Einsatz:

Anstatt Tabellen oder Views hart zu codieren (zum Beispiel analytics.stg_orders), wird stets {{ ref('stg_order_items') }} verwendet. Dadurch entkoppelt man die fachliche Logik von physischen Datenbankobjekten.

Dabei bleibt SQL die zentrale Sprache in dbt und die bestehende SQL-Logik kann grundsätzlich weiterverwendet und schrittweise in die dbt-Modellierung überführt werden. Der verwendete SQL-Dialekt richtet sich dabei nach der zugrunde liegenden Datenbank bzw. Plattform.

Empfohlen wird, mithilfe von Common Table Expressions (CTEs) im Modell order_items.sql (s. Abbildung 2) fachlich relevante Kennzahlen und Daten an einer zentralen Stelle zusammenzuführen und zu transformieren. Dieses MART-Modell stellt unternehmensweite Kennzahlen bereit, die anschließend von verschiedenen Use Cases und Datenprodukten einheitlich genutzt werden können.

Das dbt-Tool erstellt dabei automatisch einen gerichteten azyklischen Graphen (DAG), der alle Modellabhängigkeiten abbildet. Auf Basis dieses Graphen bestimmt dbt die korrekte Build-Reihenfolge und stellt sicher, dass Staging-Modelle vollständig aufgebaut sind, bevor darauf aufbauende Stage- bzw. Mart-Modelle starten. Abhängige Modelle werden zuverlässig nacheinander erstellt, sodass Reihenfolgekonflikte von vornherein vermieden werden.

Das DRY Prinzip: Dynamische Logik mit Jinja

Oft müssen wir die gleiche Logik auf viele Spalten anwenden (z. B. das Aggregieren von verschiedenen Zahlungsarten). Statt den Code zu kopieren, nutzen wir Jinja.

Beispiel: models/core/int_payment_pivoted.sql (s. Abbildung 3)

In diesem Modell nutzen wir eine Schleife, um Spalten basierend auf einer Liste dynamisch zu erstellen:

Hier generiert dbt automatisch drei Summen-Spalten, eine für jede Zahlungsart. Das hält den Code sauber und einfach erweiterbar, falls später weitere Zahlungsmethoden hinzukommen. 

Konfigurieren der Modelle in YAML

Im Modell orders.yml werden Eigenschaften wie Beschreibung, Datentests und Spaltenmetadaten direkt definiert. dbt prüft so automatisch Summen, Fremdschlüssel sowie Not‑Null/Unique‑Constraints. Außerdem lassen sich semantische Informationen wie Primärschlüssel, Zeitdimensionen und Measures hinterlegen, die später für Metriken oder gespeicherte Queries genutzt werden können. Dokumentation und Lineage werden dabei von dbt automatisch mit erstellt.

Fazit

dbt ist eine enorme Hilfe, um Datenprojekte strukturiert, nachvollziehbar und wartbar zu gestalten. Gleichzeitig erfordert es viel Handarbeit, aber bietet eine steile Lernkurve und liefert schnell positive Resultate. Neben SQL können Python-Modelle genutzt werden, die für KI-Entwicklung enorm interessant sind. Für bestehende, stark gewachsene Data Warehouses kann die Migration zu dbt je nach Umfang sehr aufwendig sein. Bei der Einführung neuer Datenplattformen sollte dbt jedoch definitiv als Werkzeug in Betracht gezogen werden. Es bietet eine robuste und flexible Umgebung für Datentransformationen, automatisches Testing, Deployment, Versionierung und Dokumentation. Bei einer großen Anzahl von Modellen kann es zwar schnell unübersichtlich werden, die Vorteile überwiegen jedoch deutlich: eine klare Build-Reihenfolge, die Wiederverwendbarkeit von Logik und eine transparente Modelllandschaft.

Weitere Beiträge rund um dbt folgen. Folgt unserem Blog und unseren Kanälen, um auch zukünftige Artikel nicht zu verpassen.

Jetzt passende Seminare finden