Databricks + dbt: wie der moderne Stack für Transformationen arbeitet

dbt macht aus Anweisungen im SQL SELECT getestete, versionierte und dokumentierte Pipelines für Transformationen. Databricks liefert die Rechenmaschine und den Speicher in Delta Lake. Zusammen geben sie den Analytics Engineers einen Arbeitsablauf, in dem Transformationen wie Software im Review gelesen, bei jedem Lauf getestet und automatisch dokumentiert werden.

Diese Kombination ist zur voreingestellten Architektur für Teams geworden, die Praktiken des Software Engineering auf Daten anwenden wollen, ohne SQL zu verlassen. Sie schreiben ein SELECT, dbt übersetzt es in DDL, und Databricks führt es in großem Maßstab aus. Das Ergebnis ist eine Tabelle in Delta, registriert im Unity Catalog und bereit für nachgelagerte BI-Werkzeuge, ML-Modelle oder Reverse ETL.

Warum Databricks + dbt zum Standard wurden

Vor dbt haben die meisten Datenteams ihre Daten mit eigenen Skripten in Python transformiert, orchestriert über Airflow. Die Skripte waren schwer zu testen, selten dokumentiert und für neue Teammitglieder schwer zu lesen. Wenn um 3 Uhr nachts etwas kaputtging, hieß Fehlersuche, sich durch Hunderte Zeilen PySpark oder pandas zu arbeiten.

dbt hat den Arbeitsablauf verändert, indem es SQL zur Einheit der Transformation gemacht hat. Jedes Modell ist eine SELECT-Anweisung in einer eigenen Datei. Abhängigkeiten zwischen Modellen werden mit Aufrufen von ref() erklärt, und dbt löst sie automatisch zu einem gerichteten azyklischen Graphen (DAG) auf. Tests werden in YAML neben den Modellen festgelegt. Die Dokumentation entsteht aus demselben YAML und aus den Kommentaren im SQL.

Databricks hat die Schicht der Rechenleistung verändert, indem es SQL Warehouses bereitstellt: serverlose, automatisch skalierende Endpunkte, die auf Lasten in SQL optimiert sind. Statt Spark-Cluster hochzufahren und JVM-Konfigurationen zu verwalten, richten Analytics Engineers dbt auf ein SQL Warehouse und überlassen Databricks den Rest. Die Ergebnisse landen als Tabellen in Delta Lake, mit ACID-Transaktionen, Time Travel und erzwungenem Schema von Haus aus.

Die Kombination hat den Bedarf an getrennten Werkzeugen für Orchestrierung und Transformation aufgelöst. Ein Datenteam, das vorher 40 Airflow-DAGs mit eigenen Operatoren in Python gepflegt hat, kann sie durch 200 dbt-Modelle auf einem einzigen SQL Warehouse ersetzen, mit besseren Tests, besserer Dokumentation und geringerem Aufwand im Betrieb.

Die Architektur: wie die Teile zusammenpassen

Der Stack aus dbt und Databricks hat vier Stufen. Die Rohdaten kommen aus den Quellsystemen über Werkzeuge zur Beladung wie Fivetran oder Airbyte und landen als Staging-Tabellen in Delta Lake. dbt liest diese Staging-Tabellen, wendet Transformationen an, die in die Schichten Staging, Intermediate und Marts gegliedert sind, und schreibt die Ergebnisse als neue Tabellen oder Views in Delta zurück. Ein SQL Warehouse führt jede Anweisung aus. Der Unity Catalog steuert durchgehend Zugriff und Metadaten.

Das Muster der Schichtung hält die Transformationen geordnet. Staging-Modelle (stg_) benennen Spalten um, wandeln Typen und bereinigen die Rohdaten, je ein Modell pro Quelltabelle. Intermediate-Modelle (int_) verbinden Staging-Modelle und wenden die fachliche Logik an. Mart-Modelle (fct_, dim_) erzeugen die fertigen, für die Analyse bereiten Tabellen, geordnet nach fachlichen Domänen.

dbt verwaltet die Reihenfolge der Abhängigkeiten automatisch. Wenn Sie dbt build fahren, übersetzt es das SELECT jedes Modells in DDL, löst den DAG auf und führt die Anweisungen in der richtigen Reihenfolge aus. Ändert sich ein Staging-Modell, weiß dbt, welche Intermediate- und Mart-Modelle davon abhängen, und baut sie ebenfalls neu.

Materialisierungen auf Databricks

dbt bietet vier Strategien der Materialisierung an, und die richtige Wahl hängt an der Größe der Tabelle, an den Mustern der Abfragen und an den Anforderungen an die Aktualität.

View ist die leichteste Möglichkeit. dbt legt eine View in SQL an: Es werden keine Daten gespeichert, es ist kein Neubau nötig, und das Ergebnis ist immer frisch. Views passen gut zu Staging-Modellen und einfachen Transformationen. Der Preis dafür ist, dass jede Abfrage das darunterliegende SQL erneut ausführt.

Table materialisiert bei jedem Lauf das vollständige Ergebnis als Tabelle in Delta. Die Abfragen sind schnell, weil die Daten vorberechnet sind, doch die Dauer des Neubaus wächst mit dem Datenvolumen. Tabellen passen zu Modellen der Mart-Schicht bis etwa 10 Millionen Zeilen.

Incremental verarbeitet nur neue oder geänderte Zeilen. dbt ergänzt eine WHERE-Klausel, die auf einen Zeitstempel oder eine ID-Spalte filtert, und führt die Ergebnisse in die bestehende Tabelle zusammen. Für große Faktentabellen ist das unverzichtbar: Eine Ereignistabelle mit 500 Millionen Zeilen, deren voller Neubau 45 Minuten dauert, ist inkrementell womöglich in 2 Minuten fertig.

Snapshot hält langsam veränderliche Dimensionen vom Typ 2 fest. dbt vergleicht den aktuellen Stand einer Quelltabelle mit ihrem vorigen Snapshot und legt historische Datensätze mit Zeitstempeln in valid_from und valid_to an. Nutzen Sie Snapshots, wenn Sie verfolgen müssen, wie sich Attribute einer Dimension über die Zeit ändern, etwa die Preisstufe eines Kunden oder die Abteilung einer Mitarbeiterin.

Eine praktische Regel: Wechseln Sie auf Incremental, sobald Ihre Tabelle 10 Millionen Zeilen überschreitet oder ein voller Neubau länger als 5 Minuten dauert. Unterhalb dieser Schwelle lohnt sich die zusätzliche Komplexität der inkrementellen Logik (Schlüssel für den Merge, Filter auf Zeitstempel, der Umgang mit verspätet eintreffenden Daten) meist nicht.

Tests und Datenqualität

Das Rahmenwerk für Tests in dbt fährt nach jedem Build Zusicherungen gegen Ihre Daten. Die Tests werden in Schemadateien in YAML neben den Modellen festgelegt, die sie prüfen.

Eingebaute Tests auf das Schema decken die häufigsten Prüfungen ab: unique (keine Dubletten in einer Schlüsselspalte), not_null (Pflichtfelder sind gefüllt), accepted_values (Statusfelder enthalten nur bekannte Werte) und relationships (Fremdschlüssel verweisen auf bestehende Datensätze in der übergeordneten Tabelle). Sie erklären sie in wenigen Zeilen YAML, und dbt erzeugt das SQL, das sie prüft.

Eigene Tests auf die Daten decken fachliche Regeln ab. Sie schreiben eine Abfrage in SQL, die die Zeilen zurückgibt, welche die Regel verletzen. Gibt die Abfrage Zeilen zurück, ist der Test fehlgeschlagen. Ein Beispiel ist ein Test, der Bestellungen mit negativem Umsatz findet:

SELECT order_id, revenue FROM fct_orders WHERE revenue < 0

Dieser Test hat bei einem Team, das den Stack fährt, einen echten Fehler gefunden: 2 % der Bestellungen wiesen einen negativen Umsatz aus, weil Datensätze zu Erstattungen bei einer Migration vom alten ERP doppelt gezählt wurden. Der Test hat das beim ersten produktiven Lauf gemeldet, bevor irgendein Dashboard die verdorbenen Zahlen zeigte.

Die Tests laufen als Teil von dbt build. Ein Fehlschlag hält die Pipeline an und verhindert, dass nachgelagerte Modelle materialisiert werden. Das ist der entscheidende Unterschied zum herkömmlichen ETL, wo Tests, sofern es sie überhaupt gibt, meist ein getrennter, abgehängter Schritt sind, den niemand ansieht, bis etwas sichtbar kaputtgeht.

Die Leistung optimieren

dbt übernimmt die Logik der Transformation, doch die Leistung hängt daran, wie die darunterliegenden Tabellen in Delta aufgebaut sind und wie das SQL Warehouse von Databricks konfiguriert ist.

OPTIMIZE und Z-ORDER sind die wirksamsten Optimierungen. OPTIMIZE verdichtet kleine Dateien zu größeren und senkt damit die Zahl der Dateizugriffe je Abfrage. Z-ORDER legt zusammengehörige Daten anhand ihrer Spaltenwerte nebeneinander in dieselben Dateien: Wenn Dashboards immer nach region und date filtern, kann ein Z-ORDER auf diesen Spalten die Zeit für den Scan um 50 bis 80 % senken. Fahren Sie OPTIMIZE wöchentlich auf Tabellen über 100 GB und nutzen Sie Z-ORDER auf Ihren am häufigsten gefilterten Spalten.

Liquid Clustering ist die neuere Alternative zu Z-ORDER und zur Partitionierung. Es ordnet die Daten selbstständig an und ordnet sie inkrementell neu, sobald neue Daten eintreffen. Nutzen Sie es für neue Tabellen; bei bestehenden Tabellen mit eingeführten Partitionsschemata verlangt die Migration ein vollständiges Neuschreiben.

Die Größe des SQL Warehouse zählt mehr, als die meisten Teams annehmen. Ein zu kleines Warehouse lässt Abfragen anstehen und auf die Platte auslagern. Ein zu großes verschwendet Ausgaben für DBU. Beginnen Sie mit einem Warehouse der Größe Medium, beobachten Sie die Laufzeiten der Abfragen und die Länge der Warteschlange in der Historie des SQL Warehouse und skalieren Sie von dort. Schalten Sie Photon ein: Es beschleunigt die Ausführung von SQL über eine Maschine in C++, die neben Spark läuft, und senkt die Laufzeiten der Abfragen typischerweise um 30 bis 50 %.

Die Strategien inkrementeller Modelle wirken ebenfalls auf die Leistung. Die Strategie merge behandelt Upserts sauber, verlangt auf der Zielseite aber einen vollen Scan der Tabelle. Die Strategie append ist schneller, funktioniert aber nur für unveränderliche Daten aus Ereignissen. Bei sehr großen Tabellen verbinden Sie inkrementelle Modelle mit dem Beschneiden von Partitionen: Filtern Sie die Quelldaten auf die Partitionen, die neue Datensätze überhaupt enthalten können.

CI/CD und Deployment

Projekte in dbt nutzen denselben Ablauf in Git wie Anwendungscode: Feature-Branches, Pull Requests, Code Review und automatische Tests vor dem Merge.

Der Schritt der CI fährt dbt build --select state:modified+ und baut damit nur die geänderten Modelle und die von ihnen abhängigen nachgelagerten Modelle. Das hält die CI schnell: Ein Projekt mit 300 Modellen baut bei einem typischen PR womöglich nur 5 bis 10 davon neu. Die Tests laufen als Teil des Builds. Schlägt ein Test fehl, ist der PR blockiert.

Die Strategie der Umgebungen trennt die Belange sauber. Jede Entwicklerin bekommt ein eigenes Schema (etwa dev_jane), damit Experimente andere Teammitglieder nicht treffen. Eine Umgebung für das Staging fährt den vollständigen Build gegen Daten in produktiver Größe als letzten Schritt der QA. Die produktive Umgebung bedient die Tabellen, aus denen BI-Werkzeuge und andere Data Consumer lesen.

Für die Ausführung wählen Teams zwischen dbt Cloud (verwaltete Zeitpläne, eingebaute IDE, Historie der Jobs) und dbt Core mit einem externen Orchestrator wie Airflow oder Dagster. dbt Cloud ist einfacher zu betreiben. dbt Core gibt mehr Kontrolle über die Umgebung der Ausführung und passt besser zu Teams, die Airflow ohnehin für Lasten außerhalb von dbt fahren.

Dokumentation, Lineage und die Anbindung an Dawiso

dbt erzeugt Dokumentation und Graphen der Lineage aus den Referenzen zwischen den Modellen. dbt docs generate erzeugt eine durchsuchbare Website, die jedes Modell, seine Spalten, Beschreibungen und Tests sowie den DAG der Abhängigkeiten zeigt. Die Konfiguration persist_docs schiebt diese Beschreibungen in die Kommentare der Tabellen und Spalten in Databricks, sodass sie in der Oberfläche des Unity Catalog sichtbar werden.

Doch die Dokumentation von dbt hat eine Grenze in ihrem Umfang: Sie kennt nur, was innerhalb des dbt-Projekts liegt. Sie sieht weder die vorgelagerten Pipelines der Beladung noch die nachgelagerten Berichte im BI, weder die Datei in Excel, die jemand von Hand hochlädt, noch die anderen Datenplattformen der Organisation. Für ein Team, das dbt neben Snowflake, einem alten Warehouse in Oracle und 50 Dashboards in Power BI betreibt, deckt die Dokumentation von dbt vielleicht 30 % der Datenlandschaft ab.

Genau hier fügt sich Dawiso ein. Der Datenkatalog erfasst dbt-Modelle neben Quellen außerhalb von dbt, neben Berichten im BI und neben externen Datensätzen. Das Business Glossary bildet die Spalten der dbt-Modelle auf fachliche Begriffe ab, sodass „fct_orders.revenue“ mit der maßgeblichen Definition von „Umsatz“ verknüpft ist, die in der ganzen Organisation gilt. Die Data Lineage verfolgt den vollständigen Weg: von der Quelldatenbank über das Werkzeug zur Beladung und das Staging-Modell in dbt bis zur Mart-Tabelle und zum Dashboard in Power BI.

Über das Model Context Protocol (MCP) können KI-Agenten Dawiso nach Definitionen von Spalten, nach der Aktualität der Daten, nach der Lineage und nach der Verantwortung für eine Kennzahl fragen, alles über ein einheitliches Protokoll. Ein KI-Copilot, der einer Analystin beim Schreiben eines dbt-Modells hilft, kann nachschlagen, ob eine Spalte existiert, wie sie definiert ist und welche nachgelagerten Berichte von ihr abhängen, ohne dass die Analystin ihre IDE verlassen muss.

Fazit

Der Stack aus dbt und Databricks funktioniert, weil er die Analytics Engineers dort abholt, wo sie ohnehin sind: im SQL. dbt bringt die Praktiken des Software Engineering mit, also Versionskontrolle, Tests, Dokumentation und CI/CD, und Databricks bringt Rechenleistung und Speicher. Das Ergebnis sind Pipelines für Transformationen, die sich schneller bauen und leichter debuggen lassen und sich an neue Teammitglieder übergeben lassen, ohne dass dafür mündlich überliefertes Wissen nötig wäre. Die verbleibende Lücke, die Sicht über Plattformen hinweg, schließt sich, wenn ein Katalog wie Dawiso die auf das Projekt begrenzte Dokumentation von dbt mit der übrigen Datenlandschaft verbindet.