/Logo%202023%20final%20dunkelgrau.png?width=221&height=97&name=Logo%202023%20final%20dunkelgrau.png)
Datenteams suchen zunehmend nach Möglichkeiten, Datenmodellierung und Governance auf einer einheitlichen, skalierbaren Plattform zu vereinen. Databricks hat sich mit seiner leistungsfähigen Lakehouse-Architektur als zentraler Player am Markt etabliert. Sie verbindet Data Engineering, Data Science und Analytics auf einer gemeinsamen Grundlage.
Im Gegensatz zu klassischen Data-Warehouse-Lösungen, die als fertige Anwendungen von Anbietern wie SAP oder Oracle verkauft werden, ist Databricks eine Plattform, auf der Sie ein SQL-basiertes Warehouse selbst aufbauen können. Dazu muss ein Team ein passendes Design-Pattern und ein logisches Rahmenwerk wählen und darin das eigene Datenmodell implementieren.
Das Open-Source-Tool dbt (data build tool) hat sich dabei als De-facto-Standard für SQL-zentrierte Transformationen und Datenmodellierung etabliert – und ist eine ideale Ergänzung zum Aufbau eines Enterprise Data Warehouse auf Databricks.
Die Kombination beider Technologien ermöglicht es Analysten und Data Engineers, Rohdaten direkt auf der Databricks-Plattform in verlässliche, produktionsreife Datensätze zu transformieren – und dabei Best Practices aus der Softwareentwicklung zu nutzen. Mit der Integration von dbt in Databricks Jobs lässt sich die volle Leistungsfähigkeit der Plattform ausschöpfen: dbt-Workflows können direkt orchestriert, überwacht und automatisiert ausgeführt werden.
In diesem Beitrag zeigen wir, wie Sie dbt und Databricks kombinieren, um skalierbare, performante und nachvollziehbare Datentransformationen aufzubauen.
Anhand eines konkreten Beispiels für einen Data-Warehouse-Workflow demonstrieren wir, wie Daten aus verschiedenen Quellsystemen importiert, in einer Medallion-Architektur (Bronze–Silver–Gold) verfeinert und für Analyse und Wiederverwendung bereitgestellt werden.
Dabei führen wir Sie durch folgende Schritte:
• Initialisierung eines dbt-Projekts und Integration in Databricks via Git-Repository
• Definition der Modellierungsstufen in dbt
• Einrichtung eines Databricks-Clusters für die Ausführung
• Konfiguration eines Databricks Jobs zur Orchestrierung der dbt-Pipelines
• Umgang mit sich ändernden Daten und Schemaänderungen
Projekteinrichtung: Von lokal zu Databricks
Bevor dbt-Jobs auf Databricks laufen können, muss ein dbt-Projekt initialisiert und mit der Databricks-Umgebung verbunden werden. In der Regel geschieht das lokal, bevor der Code über Git in Databricks deployt wird.
dbt lokal initialisieren
Zunächst wird das Projekt in einer lokalen Entwicklungsumgebung erstellt. Mit dem dbt-Databricks-Adapter funktioniert das wie folgt:
pip install dbt-core dbt-databricks
dbt init my_dbt_project
code>
1. dbt Project Root erstellen
Während der Einrichtung wählen Sie Databricks als Ziel-Adapter und hinterlegen die Verbindungsdaten sowie ein Access Token. Anschließend wird die typische dbt-Verzeichnisstruktur (models/, seeds/, tests/ etc.) samt Konfigurationsdatei dbt_project.yml erstellt.
2. Projekt nach Databricks übertragen
Nachdem das Projekt lokal funktioniert, wird es in ein Git-Repository übertragen und mit Databricks verbunden. Git sorgt für Versionierung, ermöglicht kollaboratives Arbeiten und garantiert Nachvollziehbarkeit, welche Version in der Produktion läuft.
Sichern Sie sich jetzt Ihren Platz für unser Webinar am 11. November!
Datenmodellierung mit dbt
An diesem Punkt verfügen Sie über ein funktionsfähiges Grundgerüst Ihres dbt-Projekts: Es lässt sich lokal für Entwicklungszwecke ausführen und steht nun auch in Ihrer Databricks-Umgebung für den produktiven Einsatz bereit.
Die nächsten Schritte bestehen darin, das eigentliche Datenmodell zu implementieren und anschließend einen Databricks Job einzurichten, um die dbt-Ausführungen zu orchestrieren. So können Ihre Transformationen automatisch geplant, überwacht und bei Bedarf skaliert werden.
Beginnen wir mit dem Datenmodell: In unserem Anwendungsfall möchten wir die weit verbreitete Medallion-Architektur umsetzen – ein von Databricks etabliertes Design-Pattern.
Dabei werden Daten in drei Schichten strukturiert: Bronze (Rohdaten), Silver (bereinigte und strukturierte Daten), Gold (angereicherte Daten).
Jede Schicht baut auf der vorherigen auf, um schrittweise konsistente, aussagekräftige Datensätze zu erzeugen, aus denen sich Metriken und fachliche Erkenntnisse für Analysen und Reporting ableiten lassen.
Um die Vernetzung moderner Datenlandschaften realitätsnah abzubilden, stammen die Quelldaten in unserem Beispiel aus mehreren Systemen:
Eine Tabelle wird aus einer PostgreSQL-Datenbank über die Lakehouse Federation mit dem Databricks Unity Catalog verbunden, während eine weitere Tabelle als Delta-Tabelle direkt im Databricks Catalog gespeichert ist.
Bronze Layer – Rohdaten sammeln
Der erste Schritt bei der Implementierung der Medallion-Architektur besteht darin, die Rohdaten in Bronze-Schicht-Tabellen zu replizieren. Ziel ist es, alle Daten zentral im selben System und am gleichen Speicherort verfügbar zu machen. In dieser Phase erfolgen keine logischen Transformationen oder Anreicherungen der Daten – sie werden lediglich unverändert übernommen.
An dieser Stelle kommen die dbt-Modelle ins Spiel. Hier werden sowohl die Datenquellen als auch die Zieltabellen inklusive eventueller Transformationen definiert.
Dies geschieht über die Datei sources.yml im Verzeichnis /models sowie über die zugehörigen .sql-Dateien innerhalb der dbt-Modellstruktur. In diesem Bereich können Sie Ihr Datenmodell außerdem hierarchisch strukturieren, um es den Anforderungen Ihrer Architektur und Ihres Teams anzupassen.
Die Definition der Quellen in unserem Beispiel erfolgt in der Datei sources.yml:
version: 2
sources:
- name: sap_erp_file_export
database: nextlytics
schema: nextlytics-demo
tables:
- name: raw_planvorgaben
- name: external_postgres
database: ext_nly_demo_postgres
schema: public
tables:
- name: raw_maschinendaten
Für unsere Bronze-Tabellen möchten wir lediglich die Quelldaten in Delta-Tabellen mit einem festgelegten Namen klonen
Dazu erstellen wir für jedes Ziel eine eigene .sql-Datei, wobei der Dateiname den Namen der zu erzeugenden Zieltabelle festlegt.
Zum Beispiel wollen wir alle Daten aus unserer externen PostgreSQL-Tabelle raw_maschinendaten in eine Tabelle mit dem Namen b_maschinendaten importieren. Das Präfix b_ zeigt dabei an, dass es sich um eine Tabelle der Bronze-Schicht handelt.
Wir erstellen also eine Datei namens b_maschinendaten.sql mit folgendem Inhalt:
Das hier verwendete dbt-Tag „bronze“ wird später relevant, wenn wir die Jobs orchestrieren.
Nachdem wir dieselbe Logik auch auf unsere andere Datenquelle angewendet haben, verfügen wir über zwei Datenmodelle auf Bronze-Ebene: b_maschinendaten und b_planvorgaben.
Silver Layer: Verfeinern und Bereinigen der Daten
Für unsere Silver-Schicht möchten wir beide Tabellen zu einer einzigen zusammenführen.
Da eine der Tabellen Informationen über Produktionsmaschinen enthält und die andere Daten über geplante Maschinenoperationen, lassen sich diese beiden Datensätze problemlos per SQL verknüpfen.
Die Transformationslogik in SQL wird direkt im Modell für unsere Silver-Tabelle s_machine_output angewendet:
Beachten Sie, dass unsere Silver-Schicht-Tabelle in diesem Beispiel weiterhin deutschsprachige Spaltennamen enthält, die weitgehend aus der Datenquelle übernommen wurden.
Wenn Sie mit internationalen Teams arbeiten, ist es in einem Enterprise Data Warehouse übliche Best Practice, die Spaltennamen ins Englische zu übersetzen – idealerweise bereits in der Bronze- oder Silver-Schicht.
Später im Beitrag zeigen wir, wie dbt solche Änderungen auch nachträglich elegant unterstützt.
Gold Layer: Aggregation und KPI-Berechnung
In der Gold-Schicht wollen wir aussagekräftige Kennzahlen für Reporting und Dashboards bereitstellen.
Dazu berechnen wir zentrale KPIs auf Basis der vorhandenen Daten – in diesem Fall die OEE (Overall Equipment Effectiveness, deutsch: Gesamtanlageneffizienz), um Einblicke in die Effektivität unserer simulierten Produktionsvorgänge zu gewinnen.
Das Modell für unsere Gold-Tabelle g_oee_performance sieht daher wie folgt aus:
Damit ist die Datenmodellierung abgeschlossen. Im nächsten Schritt implementieren wir die Orchestrierung der Ausführungen über Databricks Jobs.
Vorbereitung der Databricks-Compute-Umgebung
Bevor wir den Job konfigurieren, sind einige Vorbereitungen am Cluster erforderlich – denn Databricks-Jobs laufen auf Spark-Clustern.
In unserem Fall benötigen wir einen Cluster, der folgende Anforderungen erfüllt:
1. Die Python-Bibliothek dbt-databricks muss installiert sein (über den Tab Libraries in der Clusterkonfiguration).
2. Der Cluster muss Zugriff auf ein gültiges Databricks Access Token besitzen, um die Databricks-API für das Erstellen der Tabellen verwenden zu können.
Dies lässt sich über Umgebungsvariablen in Kombination mit dem Secrets Management von Databricks konfigurieren.
Konfiguration und Ausführung des Databricks Jobs
Nachdem die Modelldefinitionen abgeschlossen und der Cluster vorbereitet sind, konfigurieren wir die Pipeline für Beladung und Transformation über die Databricks Jobs-Oberfläche.
Der Job wird in diesem Beispiel in drei Subtasks unterteilt – jeweils für eine Schicht des Datenmodells – sowie in einen zusätzlichen Task, der den SQL-Code als Datei für Debugging-Zwecke generiert (falls ein Verarbeitungsschritt fehlschlagen sollte).
Hier kommen die zuvor definierten Tags zum Einsatz:
Durch diese logische Gruppierung können wir gezielt Teilbereiche der dbt-Transformationen mit einem einzigen Aufruf ausführen.
Wichtig ist dabei, den korrekt vorkonfigurierten Cluster für die Pipeline-Ausführung auszuwählen.
Sobald alles konfiguriert ist, lässt sich der Job über den Tab „Runs“ starten.
Dort können Sie zeitgesteuerte Ausführungen einrichten, die Data Lineage nachvollziehen und den Status jeder Pipeline überwachen.
Verfolgung von Datenänderungen und Schemaänderungen
Die Zeit schreitet unaufhaltsam voran und damit können sich auch die von Ihrem Unternehmen erzeugten und genutzten Daten verändern. Sei es durch ein Versionsupdate in einem der Quellsysteme, eine Migration zu einer anderen Quelldatenbank oder neue Geschäftsanforderungen, die eine Anpassung Ihrer etablierten Datenstruktur erfordern. Hier wollen wir kurz beleuchten, wie ein Setup wie solche Schema-Evolution (die Änderung von Datenstrukturen) und Datenzusammenführungen handhaben kann.
Betrachten wir, dass wir für unsere Silver-Layer-Transformation die deutschen Spaltennamen durch aussagekräftigere und einheitliche englische Übersetzungen ersetzen möchten.
In diesem Fall können wir einfach die SELECT-Anweisung in der Modelldefinition leicht anpassen, z. B.:
Beim nächsten Lauf der Aufgabe, die die Silver-Layer-Tabelle aktualisiert, wird das neue Spaltenschema automatisch von dbt angewendet. Nun bleibt nur noch, die Referenzen in der SELECT-Anweisung der Gold-Level-Tabelle anzupassen, und schon ist die Transformation abgeschlossen. Dies funktioniert, weil das Modell so konfiguriert, dass bei jedem Datenladen ein kompletter Tabellen-Refresh erfolgt.
Natürlich hat diese Full-Replace-Strategie, obwohl sie einfach umzusetzen ist, signifikante Nachteile, wenn die Datenmenge wächst oder Schemaänderungen häufiger werden. Dafür bietet dbt die Möglichkeit, inkrementelle Modelle zu verwenden. Damit können nur neue Daten geladen werden, die noch nicht verarbeitet wurden, über ein automatisches Merge-Verfahren. Dafür muss die Konfiguration in der Modelldefinition hinterlegt werden.
Dies eröffnet eine Vielzahl neuer Ansätze, z. B. können innerhalb der SELECT-Anweisung des Modells bedingte Operationen implementiert werden, die nur bei einem inkrementellen Lauf eines bereits bestehenden Modells ausgelöst werden. Das könnte z. B. so aussehen, dass ein Datums-/Zeitwert aus der Datenquelle mit dem entsprechenden Wert aus der Modell-Tabelle verglichen wird, um festzustellen, ob neue Daten zwischen zwei Pipeline-Durchläufen hinzugekommen sind:
Diese Anwendungsfälle kratzen nur an der Oberfläche dessen, was mit dbt möglich ist. Es gibt unzählige weitere nützliche Funktionen, um komplexe Szenarien oder performanceintensive Datenladeprozesse zu bewältigen, die den Rahmen dieses Artikels sprengen würden.
Von SQL zum Enterprise Data Warehouse mit dbt: unser Fazit
Mit dbt auf Databricks verwandeln Sie ein Greenfield-SQL-Warehouse in ein verlässliches Betriebsmodell: klare Medallion-Struktur, explizite Quell- und Modelldefinitionen sowie reproduzierbare Pipelines über Git und Databricks Jobs. Tags ermöglichen die abschnittsweise Ausführung von Prozessen, inkrementelle Modelle halten die Kosten im Griff, und Data Lineage sowie Monitoring bieten Transparenz von Bronze bis Gold Layer für Kennzahlen wie OEE.
Kurz gesagt: ein reibungsloser Weg vom lokalen Prototyp zur produktionsreifen Datenlogistik – versioniert, testbar und skalierbar. Wenn Sie Ihr Lakehouse mit dbt und Databricks aufbauen oder modernisieren möchten, unterstützen wir Sie bei Architektur, Implementierung und betriebssicherer Umsetzung – praxisnah und auf den Punkt.
Wenn Sie mehr darüber erfahren möchten, wie Sie mit dbt das volle Potenzial moderner Data-Warehousing-Lösungen in Databricks ausschöpfen können, kontaktieren Sie uns gerne!
