dbt und Microsoft Fabric – modulares Data Engineering für die moderne Datenplattform

dbt (Data Build Tool) ist ein Open-Source-Framework, das Datentransformationen in reinem SQL abbildet – modular, versioniert und automatisch getestet. Microsoft Fabric ist Microsofts integrierte Daten- und Analyseplattform, die Data Lake, Data Warehouse, Data Engineering und Power BI unter einem Dach vereint.

Die Kombination beider Tools löst ein konkretes Problem: Wie bringe ich Rohdaten aus ERP, Sensorik, Ticketing oder Betriebssystemen in eine saubere, analysierbare Struktur – ohne fragile ETL-Skripte, die nur eine Person versteht?

In diesem Artikel erklären wir, wie die Integration funktioniert, warum das Medallion-Modell die richtige Transformationslogik liefert und wie wir diesen Stack in der Praxis einsetzen.

Was ist dbt – und warum braucht man es?

Viele Unternehmen transformieren Daten mit Python-Skripten, Stored Procedures oder manuellen SQL-Abfragen. Das funktioniert – bis das Team wächst, die Komplexität steigt oder jemand das Unternehmen verlässt. Dann bricht die Pipeline, und niemand weiss warum.

dbt löst dieses Problem durch drei Prinzipien:

SQL-basierte Modelle. Jede Transformation ist eine SQL-Datei mit klarer Abhängigkeitsstruktur. Statt eines monolithischen Skripts gibt es hunderte kleine, verständliche Bausteine, die dbt automatisch in der richtigen Reihenfolge ausführt.

Automatisierte Tests. Für jede Tabelle lassen sich Tests definieren: Ist die Spalte kunden_id eindeutig? Enthält umsatz keine Null-Werte? Sind alle Fremdschlüssel gültig? dbt prüft das bei jedem Durchlauf und schlägt Alarm, bevor fehlerhafte Daten ins Dashboard fliessen.

Dokumentation als Code. Jedes Modell wird direkt im Code beschrieben: Was berechnet diese Tabelle? Welche Quellen fliessen ein? dbt generiert daraus automatisch eine durchsuchbare Dokumentationswebsite – das ist gelebte Data Governance.

Versionierung. Alle Modelle, Tests und Dokumentation liegen in Git. Jede Änderung ist nachvollziehbar, jeder alte Zustand wiederherstellbar. Das ist besonders wichtig für regulierte Umgebungen in der öffentlichen Verwaltung und im öffentlichen Verkehr.

Was ist Microsoft Fabric – und was bringt es mit?

Microsoft Fabric ist eine All-in-One-Plattform, die mehrere Dienste unter einer einheitlichen Oberfläche bündelt:

OneLake – Ein zentraler Data Lake, in dem alle Daten landen – unabhängig davon, ob sie aus einem ERP, einer SPS, einem IoT-Hub oder einer REST-API stammen. OneLake ist das Dateisystem von Fabric und ersetzt den bisherigen Azure Data Lake Storage.

Fabric Warehouse – Ein vollwertiges Data Warehouse für analytische Abfragen (OLAP), das direkt auf OneLake-Daten arbeitet.

Fabric Lakehouse – Eine Kombination aus Data Lake und Data Warehouse (das sogenannte «Lakehouse-Konzept»), die sowohl strukturierte als auch unstrukturierte Daten verarbeiten kann.

Power BI – Direkt integriert für Dashboards und Reports, ohne Daten exportieren zu müssen.

Fabric Pipelines – Orchestrierung von Datenflüssen, vergleichbar mit Azure Data Factory.

Für Unternehmen, die bereits im Microsoft-Ökosystem arbeiten (Azure, Microsoft 365, Power BI), ist Fabric der natürliche nächste Schritt. Wir haben Fabric unter anderem im Datenmanagement für Verkehrsunternehmen im Detail beschrieben.

Architektur: So funktioniert dbt + Fabric in der Praxis

Die Integration folgt einem klaren Datenfluss:

1. Daten laden (Ingestion)

Rohdaten fliessen aus Quellsystemen in OneLake. Das kann über verschiedene Wege geschehen: Azure Event Hub für Streaming-Daten (z.B. Sensordaten, IoT), Fabric Pipelines für Batch-Loads (z.B. ERP-Exporte), oder direkte Konnektoren für Cloud-Dienste. Die Daten landen als Dateien (Parquet, Delta) in OneLake oder als Tabellen im Lakehouse.

2. Daten transformieren (dbt)

Hier kommt dbt ins Spiel. dbt core verbindet sich über den Fabric SQL-Endpunkt mit dem Warehouse oder Lakehouse und führt SQL-basierte Transformationen aus. Die Transformationen folgen typischerweise dem Medallion-Modell:

Bronze (Rohdaten) – 1:1-Kopie der Quelldaten, minimale Bereinigung. Alles wird aufbewahrt, nichts geht verloren. Das ist die «Single Source of Truth» für die Rohdaten.

Silver (Bereinigt) – Datentypen korrigiert, Duplikate entfernt, Spalten umbenannt, Beziehungen zwischen Tabellen hergestellt. Hier entstehen saubere, verknüpfbare Entitäten wie maschine, sensor_messung, wartungsauftrag.

Gold (Business-ready) – Aggregierte, auf konkrete Anwendungsfälle zugeschnittene Tabellen: OEE pro Linie und Tag, Energieverbrauch pro Fahrzeug und Monat, Verspätungsstatistiken pro Strecke. Diese Tabellen sind direkt für Power BI optimiert.

Jeder Layer wird in dbt als eigener Ordner mit eigenen Modellen, Tests und Dokumentation abgebildet. Das macht die Transformationslogik transparent und wartbar.

3. Ergebnisse nutzen (Power BI)

Die Gold-Tabellen stehen in Power BI als semantisches Modell (Dataset) zur Verfügung. Dashboards greifen direkt auf das Fabric Warehouse zu – ohne ETL, ohne Export, ohne Nachtjob. Datenänderungen sind nach dem nächsten dbt-Run sofort sichtbar.

4. Orchestrierung

dbt-Runs werden über Fabric Pipelines, Azure Data Factory oder ein CI/CD-Tool (z.B. GitHub Actions) getriggert. In der Praxis laufen die meisten Pipelines entweder nach Zeitplan (z.B. stündlich, täglich) oder eventgesteuert (z.B. wenn neue Daten im Event Hub eintreffen).

Praxisbeispiel: Datenplattform für Verkehrsunternehmen

Für die Basler Verkehrsbetriebe (BVB) haben wir genau diesen Stack implementiert:

Ausgangslage: BVB wollte Daten aus verschiedenen Quellen zentral zusammenführen und für Analysen in Power BI nutzbar machen. Der erste Use Case: Daten aus Weichensystemen von Trams.

Architektur: Die Sensordaten fliessen über Azure Event Hub in Microsoft Fabric. Dort werden sie mit dbt core nach dem Medallion-Modell transformiert (Bronze → Silver → Gold) und anschliessend in Power BI visualisiert.

Ergebnis: Eine dynamische, erweiterbare Datenplattform, die schrittweise um weitere Datenquellen wachsen kann – ohne die bestehende Architektur umbauen zu müssen.

Auch bei SIPRO Steel Solutions haben wir eine vergleichbare Architektur umgesetzt: ERP-Daten werden auf eine Azure-Plattform geladen, mittels Medallion-Modell transformiert und in Power BI bereitgestellt. Das Ergebnis: deutlich schnellere Analysen und reduzierte Wartungskosten.

dbt + Fabric vs. Alternativen

Natürlich gibt es andere Wege, Daten zu transformieren. Hier die Einordnung:

dbt ist nicht immer die richtige Wahl. Für komplexe Machine-Learning-Pipelines, Bildverarbeitung oder Streaming-Transformationen ist PySpark in Fabric Notebooks besser geeignet. Aber für den klassischen Data-Pipeline-Anwendungsfall – Rohdaten bereinigen, verknüpfen, aggregieren und für BI aufbereiten – ist dbt + Fabric eine der effizientesten Kombinationen am Markt.

Wann lohnt sich dbt + Fabric?

Die Kombination ist besonders wertvoll, wenn:

• Sie bereits Power BI nutzen oder planen – Fabric ist die natürliche Erweiterung.
• Ihr Data-Engineering-Team SQL beherrscht – dbt erfordert kein Python.
• Sie mehrere Datenquellen zusammenführen müssen (ERP, Sensorik, Ticketing, CRM …).
• Sie Wert auf Nachvollziehbarkeit und Tests legen – etwa in regulierten Umgebungen.
• Sie Ihre Transformationen dokumentieren und versionieren wollen, statt sie in Stored Procedures zu verstecken.
• Sie die Grundlage für eine skalierbare Datenplattform legen wollen, die mit dem Unternehmen wächst.

Wenn Sie noch keinen klaren Überblick über Ihre Datenquellen haben, ist eine Datenlandkarte ein guter erster Schritt. Und wenn Sie sich fragen, ob Ihr Unternehmen bereit für eine solche Plattform ist, hilft unsere Datenmaturitätsanalyse als Standortbestimmung.

Wie wir Sie unterstützen

Unser BI- und Data-Platform-Team setzt dbt + Fabric in Kundenprojekten ein – von der initialen Architektur über die Implementierung der Medallion-Modelle bis zum Go-live der Power-BI-Dashboards. Wir arbeiten mit Unternehmen aus Industrie, öffentlichem Verkehr und öffentlicher Verwaltung.

Typische Projektdauer: 4–8 Wochen für eine erste produktive Datenplattform mit 2–3 angebundenen Quellen und einem Satz Power-BI-Dashboards.

Sie möchten Ihre Datenpipelines modernisieren? Kontaktieren Sie uns – wir zeigen Ihnen, wie dbt + Fabric in Ihrem Kontext aussehen kann.

Weiterführende Glossar-Einträge

• Microsoft Fabric für Verkehrsunternehmen – Fabric im ÖV-Kontext
• Was ist ein Data Warehouse? – Grundlagen der analytischen Datenhaltung
• Was ist ein Data Lake? – Rohdatenspeicher und Lakehouse-Konzept
• Was ist eine Data Pipeline? – Daten von A nach B bewegen
• OLAP und OLTP – Operative vs. analytische Verarbeitung
• Data Governance – Datenqualität organisatorisch sicherstellen
• Excel ablösen – Der Weg weg von manuellen Tabellen
• Datenstrategie erstellen – Der strategische Rahmen
• Big Data – Wenn Datenmengen und -quellen explodieren
• Vom Shopfloor zum Insight – Produktionsdaten analysierbar machen

‍