Fabric Data Warehouse vs Lakehouse: Wann nutzt du welches Modell?

Definition

Ein Data Warehouse in Microsoft Fabric ist ein relationaler Analysespeicher mit T-SQL-Fokus für strukturierte, modellierte Daten und standardisiertes Reporting. Ein Data Lakehouse in Microsoft Fabric kombiniert Data-Lake-Speicher mit Analysefähigkeiten für strukturierte und unstrukturierte Daten und ist kein reines SQL-Warehouse.

Einleitung

„Fabric Data Warehouse vs Lakehouse“ ist keine Tool-Frage, sondern eine Betriebsfrage: Wie schnell sollen Fachbereiche auf verlässliche Daten zugreifen, und wie viel Flexibilität braucht ihr für neue Datenquellen? Fabric bietet beide Modelle in einer Plattform, sodass du je nach Use Case sauber trennen oder gezielt kombinieren kannst.

Die Hauptunterschiede: Architektur, Endpunkte, Datentypen

Der Kernunterschied ist weniger der Speicher (beides landet in OneLake), sondern wie Daten aufbereitet und konsumiert werden. Ein Warehouse ist auf klar modellierte Tabellen und wiederholbares BI optimiert. Ein Lakehouse ist der flexiblere Arbeitsraum für Datenaufbereitung, Exploration und Data-Science-Workloads.

• Architektur: Warehouse eher „BI-ready“ (klare Struktur), Lakehouse eher „ingest first“ (mehr Freiraum).
• Endpunkte: Warehouse nutzt primär T-SQL; Lakehouse bietet zusätzlich Apache Spark/Notebooks und einen SQL Analytics Endpoint.
• Datentypen: Warehouse hauptsächlich strukturierte Tabellen; Lakehouse auch Dateien/Logs/Text und Delta-Tabellen (Delta-Parquet) für ACID-ähnliche Konsistenz.

Endpunkte erklärt: Wie Teams wirklich arbeiten

Endpunkte sind die „Eingänge“ für Nutzer und Tools. Im Fabric Data Warehouse arbeiten SQL-affine Teams direkt mit T-SQL: Abfragen, Views, Datenbereitstellung für BI. Das senkt die Hürde für Controlling und BI-Teams, die schnell zu stabilen KPIs kommen wollen.

Im Lakehouse gibt es zwei typische Arbeitsweisen: Datenengineering und Data Science über Apache Spark (z. B. Python in Notebooks) sowie klassischer Zugriff über den SQL Analytics Endpoint. Praktischer Nutzen: Du kannst Rohdaten und neue Datenquellen aufnehmen, ohne sofort alles perfekt zu modellieren, und trotzdem BI-Teams über SQL/Power BI anbinden.

Welche Daten liegen typischerweise wo?

Im Warehouse landen meist „geschäftlich eindeutige“ Daten: Faktentabellen, Dimensionen, harmonisierte Stammdaten, sauber definierte Kennzahlenlogik. Typische Quellen sind ERP/Finance/CRM-Extrakte, die regelmäßig aktualisiert werden und konsistente Berichte brauchen.

Im Lakehouse landen oft zusätzlich „wilde“ Daten: Logfiles, Events, Sensordaten, Textfelder, Dateien (z. B. CSV/Parquet), auch Zwischenstände aus Transformationen. Der Vorteil ist operativ: Teams können iterativ verbessern, ohne dass jede Änderung sofort das Reporting-Rückgrat beeinflusst.

Architekturmuster: Medallion Architecture als gemeinsame Sprache

Die Medallion Architecture (Bronze/Silver/Gold) ist in Fabric ein sehr pragmatisches Muster, um Chaos zu vermeiden und Ergebnisse messbar zu machen. Sie funktioniert sowohl im Lakehouse als auch in einer kombinierten Warehouse/Lakehouse-Architektur.

• Bronze: Rohdaten, nachvollziehbar abgelegt (für Reproduzierbarkeit).
• Silver: bereinigt und harmonisiert (weniger Fehler, weniger Excel-Nacharbeit).
• Gold: kuratierte Business-Tabellen (für Power BI, Excel und Self-Service).

OneLake wird damit zum Nutzwert-Hebel: Nicht-IT-affine Nutzer greifen auf Gold-Daten zu, statt sich durch Rohdaten oder Excel-Schattenwelten zu kämpfen.

Use Cases: Analytics, BI, ML/AI

Warehouse-Use Cases sind meist standardisiert: Monatsreporting, KPI-Dashboards, Finance/Controlling, Management-Reports mit klarer Definition von „Umsatz“, „Marge“ oder „Cashflow“. Lakehouse-Use Cases sind oft explorativ: Datenanreicherung, Data Science, Feature-Engineering, Analysen über große Eventdaten, Vorbereitung für ML/AI-Workloads.

Mini-Beispiel aus der Praxis: Ein Unternehmen startet mit einem Lakehouse, um Daten aus ERP, CRM und File-Exports schnell zusammenzuführen (Bronze/Silver). Sobald die KPI-Logik steht, wird eine stabile Gold-Schicht für Power BI aufgebaut, die Fachbereiche täglich nutzen, während Data Engineers im Lakehouse weiter neue Quellen testen.

Entscheidungskriterien: Wann welches Modell?

Wähle das Fabric Data Warehouse, wenn verlässliches BI und SQL-first im Fokus stehen und du schnelle Akzeptanz im Business brauchst. Wähle das Lakehouse, wenn neue Datenquellen, Mischdaten und Data-Science-Fähigkeiten entscheidend sind oder die Datenmodellierung noch „in Bewegung“ ist. Kombiniere beides, wenn du Rohdaten flexibel sammeln willst, aber im Reporting eine stabile, klar versionierte Wahrheit brauchst.

• Team-Skills: T-SQL-lastig → eher Warehouse; Spark/Python → eher Lakehouse.
• Datenvielfalt: stark strukturiert → Warehouse; heterogen → Lakehouse.
• Stabilität: feste KPI-Definitionen → Warehouse; hohe Änderungsrate → Lakehouse.

Best Practices: Von Planung bis Betrieb

Eine funktionierende Lösung entsteht nicht durch „mehr Daten“, sondern durch klare Produktisierung der Daten. Bewährt hat sich ein schrittweises Vorgehen: erst ein priorisierter Use Case, dann skalieren.

• Planung: KPI-Definitionen, Datenverantwortung, Zielbild (Gold-Schicht als Produkt).
• Umsetzung: Medallion-Struktur, automatisierte Pipelines, getrennte Dev/Test/Prod-Logik.
• Betrieb: Monitoring der Refreshes, klare Ownership, dokumentierte Datenherkunft/Lineage.

So wird messbar, ob Aufwand sinkt: weniger manuelle Konsolidierung, weniger Rückfragen zu Zahlen, schnellere Closing- und Forecast-Zyklen.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung lohnt sich, wenn ihr schnell zu einer belastbaren Zielarchitektur kommen müsst, euer Team zwar Power BI kann, aber Datenplattform-Betrieb (Pipelines, Governance, OneLake-Struktur) noch nicht sitzt, oder wenn laufende Refresh-Probleme und Datenchaos das Business blockieren. Besonders hilfreich ist ein Partner, der Warehouse und Lakehouse nicht gegeneinander verkauft, sondern als Route mit klaren Etappen aufsetzt.