Was ist dbt und was bietet mir das Tool?
Data Build Tool (dbt), ist ein Open-Source-Framework, das entwickelt wurde, um den Prozess der Datenmodellierung, -transformation und -pflege in modernen Data Warehouses zu vereinfachen und zu optimieren. Es basiert auf SQL und ermöglicht es Datenanalysten und Data Engineers, einfache bis komplexere Datenpipelines zu gestalten. Das Hauptziel von dbt ist es, die Kluft zwischen Datenanalyse und Datenentwicklung zu überbrücken, indem es eine strukturierte Umgebung schafft, in der Transformationen nachvollziehbar dokumentiert, getestet und wiederverwendet werden können.
Hier einige zentrale Vorteile:
Automatisierte Daten-Transformationen: Mit dbt kannst du deine Datenmodelle in SQL definieren, die dann automatisiert ausgeführt werden. Das reduziert manuelle Eingaben, minimiert Fehler und sorgt für konsistente Ergebnisse.
Transparenz und Nachvollziehbarkeit: Alle Transformationen werden dokumentiert, was eine klare Übersicht über den Datenfluss ermöglicht. Dadurch kannst du jederzeit nachvollziehen, wie Daten entstehen und sich entwickeln.
Qualitätssicherung durch Tests: dbt unterstützt die Implementierung von Tests, um die Integrität und Korrektheit deiner Daten sicherzustellen. Fehler werden frühzeitig erkannt, was die Zuverlässigkeit deiner Analysen erhöht.
Modularität und Wiederverwendbarkeit: Datenmodelle können in Komponenten aufgebaut werden, die leicht wiederverwendet und angepasst werden können. Das erleichtert die Pflege und Weiterentwicklung deiner Datenpipelines erheblich.
Integration in moderne Data-Stacks: dbt lässt sich nahtlos in gängige Data-Warehouse-Lösungen wie Snowflake, Databricks, BigQuery, Redshift und andere integrieren, was eine flexible Nutzung in verschiedenen Umgebungen ermöglicht.
Aktive Community und kontinuierliche Weiterentwicklung
Als Open-Source-Projekt profitiert dbt von einer lebendigen Community, die regelmäßig neue Funktionen, Best Practices und Support bereitstellt. Aber auch eine kostenpflichtige Cloud Version ist verfügbar und nicht nur ein Tool zur Datenmodellierung, sondern eine umfassende SaaS-Plattform, die den gesamten Datenentwicklungsprozess in der Cloud vereinfacht, beschleunigt und absichert. Für Unternehmen, die auf Skalierbarkeit, Zusammenarbeit und Automatisierung setzen, kann die kostenpflichtige Version eine wertvolle Investition.
Kurz gesagt: dbt ist ein Tool für moderne Datenprojekte, das dir helfen kann, saubere, nachvollziehbare und wartbare Datenpipelines zu erstellen. Es fördert eine Kultur der Transparenz und Qualität in der Datenentwicklung und trägt dazu bei, datengetriebene Entscheidungen effizienter zu treffen.
Einrichtung der Verbindung zwischen dbt und Databricks
Für unser Projekt haben wir eine Verbindung zwischen dbt und Databricks eingerichtet. Die Entwicklung und Strukturierung der Datenmodelle erfolgt dabei in dbt, während Databricks als skalierbare Ausführungsumgebung für die Transformationen dient.
Technisch wird die Integration über den dbt-databricks-Adapter realisiert. Dieser ermöglicht es dbt, SQL-Modelle in Databricks auszuführen und dort Tabellen oder Views im jeweiligen Lakehouse zu materialisieren.
Für die Authentifizierung haben wir in Databricks einen Personal Access Token erstellt. Dieser Token dient ausschließlich zur Authentifizierung und ermöglicht es dbt, sich gegenüber Databricks zu legitimieren und eine Verbindung aufzubauen.
Alternativ stehen weitere Authentifizierungsmethoden zur Verfügung, beispielsweise:
-
Azure Active Directory (Azure AD) Authentifizierung
-
Service Principal mit OAuth 2.0
-
JDBC/ODBC-Verbindungen mit entsprechenden Zugangsdaten
Welche Methode geeignet ist, hängt von der jeweiligen Infrastruktur, den Sicherheitsanforderungen und organisatorischen Vorgaben ab. Auf eine detaillierte Gegenüberstellung verzichten wir an dieser Stelle und konzentrieren uns im Folgenden auf die tokenbasierte Authentifizierung in unserem Beispiel.
Vorbereitungen für dbt
Als erstes haben wir den dbt-Adapter für Databricks installiert. Dieser installiert auch gleichzeitig das Grundpaket von dbt mit, sollte dies noch nicht vorhanden sein. Als nächsten Schritt haben wir die Verbindungen aus Databricks in unsere profiles.yml eingetragen:
Abbildung 1: Profiles
Zur Überprüfung der eingerichteten Verbindung kann im Terminal der Befehl dbt debug ausgeführt werden. Dieser prüft, ob die Konfiguration korrekt ist und ob sich dbt erfolgreich mit Databricks verbinden kann.
Nach erfolgreicher Validierung konnten wir mit der Entwicklung und Ausführung unserer Datenmodelle beginnen.
Unser Projekt und die Umsetzung
Allgemeiner Überblick
In unserem Projekt setzen wir auf eine automatisierte Datenpipeline, die vom Rohdatenimport im Bronze Layer bis zur finalen Verarbeitung im Gold Layer reicht. Hierbei versuchen wir auf die einzelnen Funktionen und Grenzen von dbt einzugehen. Auch nicht benutze Funktionen innerhalb der Demonstration haben wir uns angeschaut und werden dies im Blog beschreiben. Für unser Projekt lassen wir 5 verschieden CSV-Dateien laden und verarbeiten diese in den bekannten Layer Bronze, Silver und Gold. Anschließend schauen wir uns das Einbinden in Databricks-Workflows an, da diese Funktion in dbt nicht zur Verfügung steht.
Abbildung 2: Metallion – Architektur
Wir starten mit dem Bronze Layer und möchten die Dateien so weit wie möglich automatisiert in den Bronze Layer 1:1 importieren.
In dbt lässt sich die effektive Funktion Auto-Loader nicht nutzen, weshalb wir auf die Funktion „COPY INTO“ zurückgreifen mussten. Diese kopiert die Daten aus einem Verzeichnis oder auch von einem Volumen direkt in eine Delta-Tabelle und übergeht bereits geladene Dateien. Hierfür legen wir die zu verarbeitenden CSV-Dateien in unser Volumen, von dem wir die Daten anschließend laden können. Da dbt den Befehl „COPY INTO“ in SQL nicht direkt unterstützt, müssen wir uns stattdessen mit einem Makro behelfen. Dieses sorgt im ersten Schritt für die Erstellung der Tabelle, bevor der Befehl „COPY INTO“ ausgeführt wird.
Abbildung 3: Macro
Für die Schicht laden wir die Daten dann nicht direkt aus dem Code, der für den Bronze-Layer vorgesehen ist, sondern nutzen den Vorgang als Teil der Beladung im Vorfeld des Silver-Layer, der als PreHook gestartet wird. Der Aufruf dazu sieht folgendermaßen aus:
Abbildung 4: Beladung Bronze
In der ersten Zeile „materialized“ wird angegeben, dass die Tabelle im Silver-Layer als Tabelle angelegt werden soll. Die zweite Zeile erstellt die Tabelle im Bronze-Layer und importiert mit der dritten Zeile die Daten in die Tabelle. Die Spalten beim Erstellen der Tabelle mussten wir nicht angeben und wurden bei der ersten Beladung automatisch gesetzt.
Im Silver-Layer erfolgt die weitere Verarbeitung: Hier werden die Daten formatiert, die Datentypen angepasst und die Tabellenstrukturen festgelegt (s. Bild-Beispiel Bestellungen).
Abbildung 5: Beispiel Bestellung
Für jede Tabelle im Bronze- und Silver-Layer erstellen wir in dbt eine eigene SQL-Datei, die die Transformationslogik in Form eines SELECT-Statements definiert.
Ergänzend dazu pflegen wir eine YAML-Datei, in der Metadaten wie Spaltenbeschreibungen, Tests (z. B. not_null oder unique) sowie zusätzliche Modellkonfigurationen hinterlegt sind.
Während die SQL-Datei die eigentliche Datenverarbeitung steuert, dient die YAML-Datei der Dokumentation, Qualitätssicherung und strukturierten Verwaltung der Modelle. Eine automatische Generierung von SQL-Statements erfolgt dabei nicht – vielmehr ergänzt die YAML-Konfiguration die fachliche Logik aus der SQL-Datei.
Während der Erstellung ist uns aufgefallen, dass strukturelle Änderungen an einer bereits materialisierten Tabelle nicht immer automatisch übernommen werden. Insbesondere bei grundlegenden Anpassungen – etwa an bestehenden Spalten – ist häufig ein erneuter vollständiger Aufbau erforderlich.
Dies kann über den Befehl dbt run --full-refresh erfolgen, der die betroffene Tabelle löscht und vollständig neu erstellt. Für unseren Anwendungsfall ist das unproblematisch, da wir im Rahmen unseres Beispiels ausschließlich eine Vollbeladung durchführen.
Kleinere Schemaänderungen – wie das Hinzufügen neuer Spalten – lassen sich je nach Materialisierung und Konfiguration (z. B. bei inkrementellen Modellen über on_schema_change) teilweise auch ohne vollständigen Neuaufbau umsetzen. Dennoch sind strukturelle Anpassungen insbesondere bei inkrementellen oder historisierten Tabellen mit zusätzlichem Aufwand verbunden.
Bei einer inkrementellen Lösung oder einer historisierten Variante müssten bestehende Daten gegebenenfalls gesichert oder Migrationsstrategien eingeplant werden, um Datenverluste zu vermeiden.
Anschließend setzen wir unsere Arbeit im Gold-Layer fort und beginnen als erstes die Tabellen für Kunde und Bestellungen in eine historisierte Dimensionstabelle nach SCD 2 zu erstellen. Hierzu nutzen wir die Funktion Snapshot von dbt, um dies automatisiert erstellen zu lassen. Mit wenig Aufwand ist hier sichergestellt, dass bei einer Änderung der Daten der alte Satz geschlossen wird und ein neuer Satz mit „Gültig von“ und „Gültig bis“ erstellt wird.
Abbildung 6: Gold Layer
Nachfolgend haben wir die weiteren Dimensionstabellen mithilfe von klassischen Modellen mit SQL- und YAML-Dateien erstellt. Abschließend wurde dann die Faktentabelle generiert, in die wir die jeweiligen IDs der Dimensionen integriert haben. Damit war unser Star-Schema-Modell erfolgreich fertiggestellt.
Abbildung 7: Star Modell
Für einen vollständigen Datenladeprozess reicht es jedoch nicht aus, nur den Befehl „dbt run“ auszuführen, da dieser lediglich die Modelle verarbeitet, aber keine Snapshots erstellt. Stattdessen empfiehlt sich die Verwendung von „dbt build“, da dieser Befehl automatisch erkennt, welche Komponenten als nächstes verarbeitet werden müssen und sowohl Modelle als auch Snapshots in der richtigen Reihenfolge berücksichtigt.
Ein weiterer wichtiger Aspekt betrifft die Verwaltung der Abhängigkeiten bei der Datenbeladung sowie die Möglichkeit, die Data Lineage transparent darzustellen. Hierbei ist es essenziell, dass die Aufrufe der zu ladenden Tabellen nicht direkt über die Tabellen selbst erfolgen, sondern ausschließlich über Referenzierung und Quellen. Das bedeutet, dass die Entwickler vor Beginn der Entwicklung sorgfältig planen sollten, wie die Referenzen und Abhängigkeiten gestaltet werden, um eine klare, nachvollziehbare und wartbare Datenpipeline zu gewährleisten.
Während der Entwicklung haben wir festgestellt, dass die Data Lineage in unserem aktuellen Tool nur die Modelle (Tabellen) in der Datenkette visualisiert. Es wird jedoch nicht angezeigt, welche Quellspalte in welche Zielspalte geladen wird.
Abbildung 8: Data Lineage in dbt
Im Gegensatz dazu bietet Databricks eine umfassendere Übersicht der Data Lineage bis auf die Spaltenebene. Zusätzlich werden die Quellen der CSV-Dateien angezeigt, was eine detailliertere und genauere Nachverfolgung der Daten ermöglicht.
Abbildung 9: Data Lineage in Databricks
Ausführung und Workflows
Die Integration von dbt in einen Databricks-Workflow ist ein bewährter Ansatz, um analytische Transformationen reproduzierbar, versioniert und automatisiert auszuführen. Besonders leistungsfähig wird dieses Setup, wenn der gesamte Workflow direkt aus einem Git-Repository gestartet wird und Ausführungsdetails wie Logs und Status transparent sichtbar sind.
Im Kern basiert der Ansatz darauf, dass das dbt-Projekt vollständig in einem Git-Repository (z. B. auf GitHub oder GitLab) liegt. Dieses Repository enthält neben den dbt-Modellen auch Konfigurationsdateien wie profiles.yml (oder entsprechende Umgebungsvariablen), Tests und Dokumentation. Databricks selbst wird mit dem Repository verbunden, sodass der Code direkt im Workspace verfügbar ist oder bei jeder Ausführung frisch ausgecheckt wird. Damit ist sichergestellt, dass jeder Lauf exakt auf einem definierten Commit basiert – ein zentraler Punkt für Nachvollziehbarkeit und Governance.
Die eigentliche Ausführung erfolgt über einen Databricks-Job, der als Workflow definiert ist. In diesem Job wird ein Task angelegt, der auf einem Job-Cluster läuft. Das Cluster wird meist schlank konfiguriert und nur für die Dauer der dbt-Ausführung gestartet, was Kosten spart und eine saubere Trennung von Entwicklung und Produktion ermöglicht. Innerhalb des Tasks wird dbt entweder über ein init script installiert oder – noch robuster – über ein vorbereitetes Docker-Image bzw. eine Wheel-/Library-Installation bereitgestellt. Die Verbindung zu Databricks SQL-Warehouses oder Clustern erfolgt dabei über das dbt-databricks-Adapterprofil.
Abbildung 10: Workflow
Der Startpunkt des Workflows ist bewusst das Git-Repository: Der Job referenziert einen bestimmten Branch oder Tag (z. B. main oder ein Release-Tag). Änderungen an dbt-Modellen werden somit automatisch Teil des nächsten Laufs, ohne dass manuell Code in Databricks kopiert werden muss. Für CI/CD-Szenarien lässt sich dieser Job zusätzlich über externe Trigger (z. B. Merge in den Main-Branch) anstoßen.
Ein entscheidender Aspekt für den produktiven Einsatz ist die Sichtbarkeit der Ausführung. Databricks bietet hier mehrere Ebenen von Transparenz. Auf Job-Ebene sind Status, Laufzeit, verwendetes Cluster und Exit-Code sofort ersichtlich. Innerhalb des Tasks werden die Standardausgaben von dbt – also dbt run, dbt test oder dbt build – vollständig in den Driver-Logs angezeigt. Diese Logs enthalten Informationen zu gestarteten Modellen, Ausführungszeiten, Warnungen und Fehlern und sind direkt im Databricks-UI abrufbar.
Zusätzlich lassen sich dbt-Logs gezielt strukturieren. Durch die Nutzung von JSON-Logs oder durch das Persistieren der target/run_results.json und manifest.json in einem Storage (z. B. DBFS oder Cloud Object Storage) können Ausführungsergebnisse weiterverarbeitet oder visualisiert werden. In Kombination mit Databricks-Notebooks oder Dashboards entsteht so ein Reporting über dbt-Runs, Fehlerraten oder Modelllaufzeiten.
Für erweiterte Transparenz können einzelne dbt-Kommandos als separate Tasks modelliert werden, etwa ein Task für „dbt deps“, einer für „dbt run“ und ein weiterer für „dbt test“. Dadurch wird im Workflow auf einen Blick sichtbar, in welchem Schritt ein Lauf fehlschlägt. Auch Parameter wie Zielumgebung (dev, prod) oder dbt-Selektoren lassen sich als Job-Parameter definieren und beim Start variabel setzen.
Insgesamt entsteht durch die Kombination aus Git-Repository, dbt und Databricks-Workflows eine saubere, nachvollziehbare und skalierbare Architektur. Transformationen sind versioniert, automatisiert ausführbar und durch Logs sowie Job-Metadaten jederzeit transparent. Genau diese Eigenschaften machen den Ansatz besonders attraktiv für moderne Analytics- und Lakehouse-Architekturen auf Basis von Databricks und dbt Labs.
Weiter dbt-Funktionen
Im Rahmen der Entwicklung des Projekts habe wir uns noch weiteren Optionen von dbt angeschaut. Hierzu zählen:
Tests in dbt
Tests in dbt sind automatisierte Prüfungen, die sicherstellen, dass die Daten den erwarteten Qualitätsstandards entsprechen. Sie helfen dabei, Fehler frühzeitig zu erkennen und die Integrität der Daten zu gewährleisten. Hierbei bietet dbt zwei Arten von Tests an:
Schema-Tests: Diese prüfen grundlegende Eigenschaften der Daten, z.B. ob eine Spalte nicht null ist (not_null), ob Werte innerhalb eines bestimmten Bereichs liegen (accepted_values) oder ob eine Spalte eindeutig ist (unique).
Benutzerdefinierte Tests: Für spezielle Anforderungen können eigene SQL-Tests geschrieben werden, um komplexe Validierungen durchzuführen wie zum Beispiel Regressionstest.
Tests werden in dbt meist in YAML-Dateien definiert, die den jeweiligen Modellen oder Spalten zugeordnet sind. Bei der Ausführung von „dbt test“ werden alle definierten Tests automatisch ausgeführt. Falls ein Test fehlschlägt, erhält das Team eine Fehlermeldung, sodass Probleme schnell behoben werden können.
Dokumentation in dbt
Die Dokumentation in dbt umfasst die Beschreibung der Modelle, Spalten, Quellen und Transformationen innerhalb des Data-Warehouse. Sie schafft Transparenz und erleichtert das Verständnis der Datenstrukturen für alle Beteiligten. dbt ermöglicht es, Dokumentationen direkt in den Modell- und Spaltendefinitionen zu hinterlegen. Diese werden in YAML-Dateien gepflegt und können mit Beschreibungen, Metadaten und Beispielen versehen werden. Zudem können zusätzliche Markdown-Dokumente eingebunden werden. Mit dem Befehl „dbt docs generate“ wird eine interaktive HTML-Dokumentation erstellt, die alle Modelle, Spalten und deren Beschreibungen übersichtlich darstellt. Diese Dokumentation kann anschließend im Browser eingesehen werden und ist stets aktuell, wenn die Modelle neu gebaut werden.
Seeds in dbt
Seeds sind statische Datensätze, die in Form von CSV-Dateien im Projekt gespeichert werden. Sie dienen dazu, kleine, unveränderliche Datenmengen in das Data-Warehouse zu laden, z.B. Lookup-Tabellen, Konfigurationsdaten oder Referenzinformationen. Seeds ermöglichen es, wichtige Referenzdaten versioniert im Projekt zu verwalten. Sie können mit „dbt seed“ in das Ziel-Data-Warehouse geladen werden. Da Seeds in CSV-Format vorliegen, sind sie leicht zu erstellen, zu bearbeiten und zu pflegen.
Fazit
dbt ermöglicht eine strukturierte, transparente und automatisierte Entwicklung von Datenpipelines. In Kombination mit Databricks lassen sich Transformationen effizient ausführen, Datenqualität sichern und Workflows nachvollziehbar orchestrieren. Unser Beispiel zeigt, wie dbt Teams bei modernen Analytics-Projekten unterstützt, zuverlässige Daten aufzubereiten und datengetriebene Entscheidungen zu erleichtern.
Ausblick auf die Blogserie
Teil 3 hat gezeigt, wie dbt und Databricks gemeinsam Datenpipelines strukturiert, transparent und reproduzierbar umsetzen. Bronze-, Silver- und Gold-Layer, Transformationen und Tests bilden so eine solide Basis für Analytics-Projekte.
Im nächsten Beitrag gehen wir ins Detail und stellen die Ansätze gegenüber:
-
Teil 1: Medaillon-Architektur, Delta Live Tables und dbt in der Praxis
-
Teil 4: Gegenüberstellung der Ansätze und Fazit
- Teil 5: Delta Live Tables und der Übergang zu SDP
Es lohnt sich also dran zu bleiben!
