Lakehouse oder Warehouse? Nicht jeder Datensatz braucht ein Haus am See.

Die Frage klingt einfacher, als sie in Fabric ist. Ein Warehouse liegt nicht mehr in einer abgeschotteten SQL-Welt, und ein Lakehouse ist nicht bloß ein Ordner voller Parquet-Dateien. Beide teilen sich OneLake, Delta und Teile derselben SQL-Technik. Wer nur auf das Speicherformat schaut, findet deshalb keine Antwort.

Die bessere Frage lautet: Wie kommen Daten hinein, wer verändert sie und mit welchen Werkzeugen soll das Team arbeiten?

Erst einmal: Was beide gemeinsam haben

Fabric legt tabellarische Daten sowohl im Lakehouse als auch im Warehouse als Delta-Tabellen in OneLake ab. Das ist wichtig, weil die Entscheidung dadurch weniger endgültig ist als bei klassischen Plattformen. Power BI kann Direct-Lake-Modelle auf beide Varianten aufsetzen. Andere Fabric-Komponenten können dieselben offenen Daten nutzen, ohne dass für jede Analyse eine proprietäre Kopie entstehen muss.

Die Entscheidungsmatrix

Die folgende Matrix ist absichtlich praktisch. Ein einzelner Haken entscheidet selten alles. Wenn eine Spalte deutlich häufiger passt, ist das aber ein starkes Signal.

Wann das Lakehouse passt

Das Lakehouse spielt seine Stärke aus, wenn Daten noch nicht ausschließlich aus sauberen Tabellen bestehen. JSON, CSV, Bilder, Logs oder größere Rohdatenmengen können im Files-Bereich landen und später mit Spark verarbeitet werden. Verwaltete Tabellen liegen im Delta-Format im Tables-Bereich.

Der SQL Analytics Endpoint macht diese Delta-Tabellen für T-SQL-Abfragen sichtbar. Das ist hervorragend für Exploration, Reporting und lesenden Zugriff. Er ist aber kein verstecktes Warehouse: Daten lassen sich dort nicht per INSERT, UPDATE oder DELETE verändern. Views, Inline-Tabellenfunktionen, Prozeduren für lesende Logik und SQL-Berechtigungen sind möglich, der vollständige T-SQL-Umfang eines Warehouse aber nicht.

Typische Lakehouse-Signale

• Transformationen laufen bereits in PySpark oder Spark SQL.
• Rohdaten und kuratierte Tabellen sollen nah beieinander liegen.
• Data Engineers und Data Scientists arbeiten auf derselben Datenbasis.
• Shortcuts sollen Daten ohne zusätzliche Kopie verfügbar machen.
• Bronze, Silver und gegebenenfalls Gold werden als Delta-Tabellen aufgebaut.

Eine Medallion-Architektur ist dabei eine Option, kein Naturgesetz. Für einen kleinen, bereits sauberen Datenbestand sind drei Schichten oft nur drei Orte, an denen etwas kaputtgehen kann.

Wann das Warehouse passt

Ein Warehouse ist die bessere Wahl, wenn strukturierte Daten und SQL-zentrierte Entwicklung im Mittelpunkt stehen. Das gilt besonders für Stern- und Snowflake-Schemata, kuratierte Data Marts und Teams, die Geschäftslogik mit Views, Funktionen, Prozeduren und T-SQL-Ladeprozessen abbilden.

Der entscheidende Unterschied ist der schreibende SQL-Pfad. Fabric Warehouse unterstützt DDL und DML sowie Transaktionen über mehrere Tabellen. Das ist relevant, wenn zusammengehörige Änderungen entweder vollständig oder gar nicht sichtbar werden sollen.

Typische Warehouse-Signale

• Das Team entwickelt und debuggt hauptsächlich mit T-SQL.
• Die Zieldaten sind klar strukturiert und dimensional modelliert.
• Mehrere Tabellen müssen gemeinsam konsistent geändert werden.
• BI-Entwickler sollen ohne Spark-Umweg laden und modellieren.
• SQL-Werkzeuge und TDS-Verbindungen gehören zum bestehenden Arbeitsablauf.

Wann beides sinnvoll ist

Lakehouse und Warehouse zusammen sind sinnvoll, wenn sie zwei reale Verantwortungen trennen. Ein verbreitetes Muster verarbeitet heterogene Rohdaten mit Spark im Lakehouse und stellt ausgewählte, strukturierte Daten anschließend einem SQL-Team im Warehouse bereit.

Was ich vermeiden würde: Daten nur deshalb vom Lakehouse ins Warehouse kopieren, weil ein Referenzbild beide Kästen zeigt. Jede zusätzliche Grenze braucht einen Besitzer, ein Ladefenster, Monitoring und einen Wiederanlaufplan.

Betrieb, Performance und Kosten

Es gibt keine seriöse Pauschalantwort darauf, welches Objekt „schneller“ oder „billiger“ ist. Beide verbrauchen dieselbe Fabric-Kapazität, aber mit unterschiedlichen Engines und Lastmustern. Ein Spark-Job, eine große SQL-Abfrage und ein Direct-Lake-Modell konkurrieren letztlich um Capacity Units.

Beim Lakehouse im Blick behalten

• Dateigrößen, Partitionierung und Kompaktierung beeinflussen Spark- und SQL-Abfragen.
• Nur Delta-Tabellen erscheinen automatisch im SQL Analytics Endpoint; beliebige Dateien nicht.
• Metadaten zwischen Lakehouse und SQL Endpoint werden synchronisiert. Das kann bei ungünstigen Mustern zeitversetzt sichtbar werden.
• Ein Notebook, das erfolgreich endet, ist noch kein belastbarer Produktionsprozess. Idempotenz, Wiederanlauf und Datenqualitätsprüfungen bleiben deine Aufgabe.

Beim Warehouse im Blick behalten

• Fabric übernimmt viel physische Optimierung, aber schlechtes SQL wird dadurch nicht gut.
• Statistiken, Abfragemuster, Datenbewegung und Nebenläufigkeit müssen mit realistischen Daten geprüft werden.
• Transaktionen sollten kurz bleiben und immer sauber mit COMMIT oder ROLLBACK enden.
• Vorhandener SQL-Server-Code kann an nicht unterstützten Anweisungen oder Datentypen scheitern.

Fünf Fehlentscheidungen, die sich vermeiden lassen

Die sechs Fragen vor dem Bau

1. Welche Datenformen kommen wirklich an? Nur klar strukturierte Tabellen oder auch Dateien und semistrukturierte Daten?
2. Wer baut die Transformationen? Ein Spark-orientiertes Engineering-Team oder SQL- und BI-Entwickler?
3. Muss T-SQL Daten verändern? Lesende SQL-Abfragen reichen im Lakehouse. Schreibende SQL-Logik spricht für das Warehouse.
4. Brauchen Änderungen mehrere Tabellen gleichzeitig? Dann ist die Transaktionsunterstützung des Warehouse ein starkes Argument.
5. Was muss wieder anlaufen können? Notebooks, Pipelines und SQL-Ladevorgänge brauchen jeweils ein konkretes Betriebsmodell.
6. Warum wären zwei Objekte besser als eins? Wenn darauf keine klare Antwort kommt, beginne mit einem.

Transparenz: Die Architekturentscheidungen und Bewertungen sind redaktionelle Einordnung. Produktfunktionen und Einschränkungen sind mit den verlinkten Microsoft-Quellen belegt. Es wurden keine allgemeinen Performancewerte erfunden oder aus unpassenden Benchmarks übernommen.