Struktur schaffen für Transformation

In vielen Datenprojekten stellt sich früher oder später die Frage, wie dbt-Modelle sinnvoll organisiert werden können: nach Quellsystem? Nach Fachbereich? Nach Use Case? Das von drjve entwickelte Schichtenmodell bietet einen pragmatischen Rahmen für die Strukturierung von ELT-Prozessen – flexibel, nachvollziehbar und in der Praxis erprobt.

Da wir die Modelldateien beliebig in Ordner einteilen können stellt sich die Frage wie wir unsere Modelle strukturieren sollen. In diesem Blog möchte ich das Standard Schichtenmodell der drjve vorstellen, dass sich in unserer Praxis bewährt hat. 

Dieses Schichtenmodell bietet einen Rahmen für die Strukturierung der ELT Prozesse. Abweichungen, Durchbrechungen und Anpassungen sind erlaubt. Was die optimale Art ist, seine Modelle zu strukturieren, hängt sowohl von den Daten, den Anforderungen, als auch dem Datenteam ab. Ich hoffe aber hier zum Einen einen Startpunkt für eine bewusste Strukturierung zu geben, als auch wertvolle Ideen zu liefern.

Beispiel

Nehmen wir mal an, wir haben zwei Quellsysteme, System A und System B.

Auf Basis dieser Daten wird ein Power BI Reporting für die Finance- und die Marketingabteilung erstellt, welches in zwei semantischen Modelle implementiert ist. Außerdem benötigt noch ein Kundenportal (Web- und mobile App) Daten dieser Systeme.

Überblick über das Schichtenmodell

Das Drjve Schichtenmodell besteht aus 7 Schichten unterhalb des model Ordners.

Die ersten 6 Schichten stellen den Fluss der Daten von den dbt Sources bis zu den dbt Exposures da. Die letzte Schicht (60_legacy) ist optional und wird nur bei Migrationen von anderen BI Systemen zu dbt benötigt. 

Die Source Schicht

dbt Sources sind Tabellen, die die Quelldaten für das dbt Projekt / DWH enthält. Hier beginnen die Transformationen. Jedes Quellsystem wird als eigene Sourcedatei angelegt.

Die Base Schicht

Die Base Schicht enthält die Base Modelle. Ein Base Modell ist ein Modell, das alle Spalten einer Source Tabelle auflistet, und einzig Umbenennungen und Typkonvertierungen enthält. Das Basemodell ist das einzige Modell, dass auf die Sourcetabelle geht, alle weiteren Modelle, die die Daten aus der Source benötigen, referenzieren die Base.

In der Praxis behalten wir die Spaltennamen aus der Source fast immer bei, und haben nur Typkonvertierungen.

So kommt es z. B. häufig vor, dass eine Datums- oder Integerspalte als String in die Sourcetabelle geschrieben wird. Das Basemodell wäre der Ort, wo man die Typkonvertierung einbaut, damit der gesamte Rest des Projekts den korrekten Datentyp nutzt.

In der Base Schicht erhält jedes Quellsystem seinen eigenen Ordner, der die zum System gehörenden Basemodelle enthält. In unserem Beispiel sieht das so aus:

Die Persistent Staging Area

Eine PSTA (oft auch PSA genannt) speichert und historisiert alle Rohdaten. In unserer Architektur werden alle Sourcetabellen in die PSTA geschrieben. Zur Begründung verweise ich auf die beiden Blogartikel von Roelant Vos über die Vorteile einer PSTA und die Idee, die PSTA als Grundlage für das gesamte DWH zu nutzen.

Hier finden sich die Tabellen der Quellsysteme, angereichert mit Metadaten wie einem Load Timestamp, der angibt, wann die jeweilige Zeile in das DWH geladen wurde.

Auch in dieser Schicht trennen wir die Quellsysteme über Ordner, so dass unser Beispiel so aussieht.

Die Core Schicht

In dieser Schicht werden die Businesslogiken implementiert und der DWH Core aufgebaut. Hier würden also, wenn man klassisch dimensional modellieren möchte, die gestageten Quelltabellen zu Fakt- und Dimensionstabellen transformiert.

Natürlich ließe sich hier auch eine andere Core Architektur, wie z. B. der Data Vault 2.0, verfolgen.

Die Mart Schicht

In der Mart Schicht werden Data Marts für externe Datenkonsumenten bereit gestellt. Jeder Data Mart bekommt seinen eigenen Ordner in dem die spezifischen Transformationen als Modelle implementiert werden.

In unserem Beispiel würden wir für jedes der drei Systeme, Finance- sowie Marketingmodell und das Kundenportal, einen Data Mart bereitstellen, und folgende Ordnerstruktur erhalten:

Die Exposures Schicht

Eine dbt Exposure beschreibt ein externes System, dass die Daten des DWHs konsumiert. 

In der Regel kriegt jede Exposure ihren eigenen Mart. Deshalb sieht unser Exposure Ordner in unserem Beispiel folgendermaßen aus:

Die Legacy Schicht

Oft beginnt eine dbt Einführung damit, ein bestehendes System in ein dbt Projekt zu migrieren.

Um die Migration möglichst einfach durchführen zu können bietet es sich an, auf dieses Schichtenmodell zunächst zu verzichten, und die Struktur des alten Systems einfach beizubehalten.

Alle Modelle, die zum alten System gehören, kommen in den Legacy Ordner, bis sie irgendwann (oder nie) durch ein neues System im Schichtenmodell abgelöst sind.

Fazit: dbt-Modelle strukturiert und skalierbar organisieren mit dem Schichtenmodell

Das Schichtenmodell bietet eine klare, skalierbare und praxiserprobte Struktur für die Organisation von dbt-Modellen in modernen ELT-Prozessen. Durch die Trennung in sieben logische Schichten – von der Source über Core und Mart bis hin zur Exposure – lassen sich Datenmodelle transparent und wartbar gestalten.

Ob für kleine dbt-Projekte oder komplexe Data-Warehouse-Landschaften: Dieses Modell liefert eine flexible Basis, die sich an bestehende Anforderungen anpassen lässt – ohne an Klarheit zu verlieren. Besonders in Kombination mit Plattformen wie Databricks, Snowflake oder Microsoft Fabric ermöglicht die saubere Strukturierung in dbt eine effiziente, nachvollziehbare Datenmodellierung.

Wer langfristig erfolgreiche dbt-Projekte aufbauen möchte, sollte frühzeitig in eine durchdachte Modellstruktur investieren – das Schichtenmodell ist dafür ein bewährter Startpunkt.
 

Über den Autor
 

Benjamin Konrad ist seit 2016 als BI Berater im Microsoft Umfeld tätig und seit 2022 Teil der drjve AG. Seine Kerngebiete umfassen Power BI, Azure Data Platform und Infrastruktur, Big Data Systeme sowie Datenmodellierung. Mit langjähriger, branchenübergreifender sowie internationaler Projekterfahrung bietet er umfassende Expertise in den Bereichen Business Intelligence, Datentransformation- und analyse, und Architektur.