Microsoft Fabric-Architektur verständlich erklärt: Lakehouse vs. Warehouse

Von Mirko Peters · 2026-08-27

Willkommen zurück im Blog! Wenn Sie unsere letzten Podcast-Folgen verfolgt haben, wissen Sie, dass wir tief in die Welt der Datenplattformen, der modernen Analytik und der Unternehmensarchitektur eintauchen. Der Entwurf einer Analytik-Landschaft ist nie ein Einheitskonzept gewesen. Mit Microsoft Fabric erhalten Organisationen jedoch eine einheitliche Umgebung, die Data Engineering, Data Warehousin

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Willkommen zurück im Blog! Wenn Sie unsere letzten Podcast-Folgen verfolgt haben, wissen Sie, dass wir tief in die Welt der Datenplattformen, der modernen Analytik und der Unternehmensarchitektur eintauchen. Der Entwurf einer Analytik-Landschaft folgt nie einem Schema „eine Lösung für alle“. Mit der Einführung von Microsoft Fabric erhalten Organisationen jedoch eine einheitliche Umgebung, die Data Engineering, Data Warehousing, Business Intelligence und KI unter einem gemeinsamen Betriebsdach zusammenführt. Eine einheitliche Plattform bedeutet aber nicht, dass Sie keine architektonischen Entscheidungen mehr treffen müssen. Eine der allerersten Entscheidungen, vor denen Data Architects und Engineering-Teams zu Beginn ihrer Microsoft-Fabric-Reise stehen, ist die Wahl zwischen einem Lakehouse und einem Data Warehouse.

Diese Architekturentscheidung bildet das Fundament dafür, wie Ihre Organisation Daten speichert, verarbeitet und bereitstellt. Sollten Sie die Flexibilität und den Open-Source-Charakter eines Lakehouse nutzen oder bei der strukturierten, relationalen Leistungsfähigkeit eines klassischen Data Warehouse bleiben? Um diese Wahl wirklich zu beherrschen, müssen wir die Ebenen des Speichers in Microsoft Fabric freilegen, analysieren, wie unterschiedliche Teamkompetenzen in die Gleichung einfließen, und betrachten, wie moderne Datenformate wie Delta Lake die Lücke zwischen beiden Ansätzen schließen. Lassen Sie uns die Architektur von Microsoft Fabric entmystifizieren und herausfinden, wie Sie den richtigen Weg für Ihre Organisation wählen.

Einführung in die Speicheroptionen von Microsoft Fabric

Vor Microsoft Fabric bedeutete der Aufbau einer umfassenden Datenplattform oft, verschiedene Dienste in Azure zusammenzufügen: Azure Data Lake Storage einrichten, dedizierte SQL-Pools bereitstellen, Azure-Databricks-Cluster verwalten und Power-BI-Arbeitsbereiche anbinden. Dieser Ansatz war zwar leistungsfähig, führte aber häufig zu Datensilos, redundanten Datenkopien und einem hohen Verwaltungsaufwand, wenn Sicherheit und Rechenressourcen über unterschiedliche Dienste hinweg gesteuert werden mussten.

Microsoft Fabric löst diese Fragmentierung mit OneLake, einem einheitlichen, SaaS-basierten Multi-Tenant-Data-Lake, der für die Daten Ihrer Organisation als eine Art OneDrive fungiert. Alles in Fabric, ob Lakehouse, Data Warehouse, KQL-Datenbank oder Power-BI-Semantikmodell, liegt auf OneLake. Innerhalb dieser einheitlichen Speicherschicht können Organisationen festlegen, wie sie ihre analytischen Daten strukturieren und damit arbeiten. Die beiden zentralen Engines für die Speicherung und Abfrage analytischer Daten in Fabric sind das Lakehouse und das Data Warehouse. Beide teilen zwar grundlegende Technologien, sind aber für unterschiedliche Workloads, Benutzerrollen und Betriebsmodelle konzipiert.

Das Microsoft-Fabric-Lakehouse verstehen

Das Microsoft-Fabric-Lakehouse ist ein Architekturmuster, das die besten Elemente von Data Lakes und Data Warehouses in einer einzigen Umgebung vereint. Es ist sowohl für dateibasierte Data-Engineering-Workloads als auch für strukturierte analytische Abfragen optimiert und deshalb bei Data Engineers und Data Scientists sehr beliebt.

Im Kern verwaltet ein Lakehouse in Fabric Dateien und Ordner wie ein klassischer Data Lake, ergänzt diesen jedoch um eine entscheidende transaktionale Schicht auf Basis des Open-Source-Formats Delta Parquet. Dadurch können Sie unstrukturierte Daten wie Bilder, PDFs, Audiodateien und rohe JSON-Logs direkt neben strukturierten und semistrukturierten tabellarischen Daten speichern. Darüber hinaus ist das Lakehouse nativ in Apache Spark integriert. Wenn Ihr Team auf PySpark-Notebooks, verteilte Datentransformationen und anspruchsvolles Data Engineering im großen Maßstab setzt, bietet das Lakehouse die ideale Umgebung. Data-Professionals können damit komplexe Transformationen ausführen, Machine-Learning-Modelle trainieren und robuste Datenpipelines mit codezentrierten Methoden aufbauen.

Das Microsoft-Fabric-Data-Warehouse verstehen

Auf der anderen Seite des Spektrums steht das Microsoft-Fabric-Data-Warehouse. Wenn Ihre Organisation seit Jahren auf klassische Enterprise-Data-Warehouses, SQL Server oder dedizierte Analysedatenbanken setzt, wird sich das Fabric-Data-Warehouse sofort vertraut anfühlen.

Anders als das Lakehouse, das verschiedene Speicherformate kombiniert und unstrukturierte Dateien aufnimmt, konzentriert sich das Fabric Data Warehouse streng auf relationale Daten und strukturierte Tabellen. Es ist für leistungsstarke T-SQL-Abfragen ausgelegt. Wenn Sie in Fabric ein Warehouse bereitstellen, erhalten Sie ein entkoppeltes Modell für Speicher und Rechenleistung, das für relationale Operationen, komplexe Joins und Business-Intelligence-Berichte optimiert ist. Datenbankadministratoren, SQL-Entwickler und Datenanalysten können Standard-T-SQL-Skripte schreiben, Datenbankschemata verwalten, Sichten erstellen und gespeicherte Prozeduren anwenden, ohne Spark lernen oder Clusterkonfigurationen verwalten zu müssen. Das Warehouse bietet die planbare Governance, Sicherheit und transaktionale Konsistenz, die traditionelle Datenteams in Unternehmen von einem Data Warehouse dieser Klasse erwarten.

Zentrale architektonische Unterschiede: Lakehouse vs. Warehouse

Wenn Sie das Microsoft Fabric Lakehouse und das Data Warehouse direkt gegenüberstellen, gehen die Unterschiede über die Frage hinaus, ob Sie Spark oder T-SQL verwenden. Diese architektonischen Unterschiede zu verstehen, hilft Teams dabei, überdimensionierte Architekturen zu vermeiden und kein Speichermodell zu wählen, das ihren betrieblichen Gewohnheiten widerspricht.

Betrachten Sie zunächst die Datentypen, auf die sich die jeweilige Option konzentriert. Ein Lakehouse verarbeitet alles, von unstrukturierten Rohdokumenten bis zu strukturierten Delta-Tabellen. Ein Data Warehouse ist streng auf strukturierte und semistrukturierte relationale Daten optimiert. Zweitens sollten Sie die Compute-Engines vergleichen. Das Lakehouse setzt für die Datenverarbeitung stark auf Apache Spark, während das Data Warehouse eine massiv parallele (MPP-)SQL-Engine nutzt. Drittens ist entscheidend, wie die Daten verwaltet werden. Das Lakehouse bietet offenen Zugriff auf die zugrunde liegenden Dateien, sodass Data Scientists Parquet-Dateien direkt mit externen Tools oder Python-Bibliotheken lesen können. Das Warehouse abstrahiert den darunterliegenden Speicher stärker und stellt eine übersichtliche relationale SQL-Datenbankschnittstelle bereit, die für analytische Berichte und die gleichzeitige Abfrageleistung optimiert ist.

Teamkompetenzen und Speicherentscheidungen aufeinander abstimmen

Eine architektonische Entscheidung sollte niemals im luftleeren Raum getroffen werden. Sie muss die praktischen Gegebenheiten der vorhandenen Kompetenzen Ihres Teams berücksichtigen. Technologie ist nur so wirksam wie die Menschen, die sie einsetzen.

Wenn Ihre Organisation überwiegend mit Power-BI-Entwicklern, klassischen Datenbankadministratoren und SQL-Analysten besetzt ist, die mit T-SQL täglich arbeiten, kann ein Zwang zu einer Spark-lastigen Lakehouse-Architektur unnötige Einarbeitungszeit verursachen und die Bereitstellung verlangsamen. In diesem Szenario bietet das Fabric Data Warehouse einen leichten Einstieg, sodass Ihr vorhandenes SQL-Know-how sofort genutzt werden kann. Umgekehrt gilt: Wenn Ihre Organisation Data Engineers und Data Scientists beschäftigt, die sich mit Python, Scala und verteilten Rechenframeworks auskennen, bietet das Lakehouse die programmatische Flexibilität und die Rechenskalierung, die sie für anspruchsvolle Transformationspipelines und KI-Lösungen benötigen. Die richtige Speicheroption für Fabric zu wählen bedeutet, die Fähigkeiten Ihres Teams ehrlich zu bewerten und eine Architektur zu entwerfen, die Ihr Team stärkt, statt es zu entfremden.

Umgang mit unterschiedlichen Datentypen und Workloads

Workload-Anforderungen und die Vielfalt der Daten sind oft die entscheidenden Faktoren bei der Wahl zwischen einem Lakehouse und einem Data Warehouse in Microsoft Fabric. Nicht alle Daten liegen ordentlich in relationalen Tabellen vor, und nicht alle Analysen sehen gleich aus.

Wenn Ihre Ingestion-Pipelines große Mengen an Rohtelemetrie, IoT-Sensordatenströme, unstrukturierte Textdateien und Systemprotokolle einlesen, ist das Lakehouse die natürliche Landezone. Es ermöglicht Ihnen, Rohdaten schnell in der Bronze-Schicht einer Medallion-Architektur abzulegen, sie mit Spark-Notebooks zu verarbeiten und in bereinigte analytische Tabellen zu überführen. Wenn Ihr Hauptworkload dagegen darin besteht, stark frequentierte Business-Intelligence-Dashboards mit sauberen, stark strukturierten dimensionalen Datenmodellen zu versorgen, spielt das Data Warehouse seine Stärken aus. Seine T-SQL-Engine ist fein darauf abgestimmt, komplexe analytische Abfragen mit geringer Latenz auszuführen. So erhalten Geschäftsanwender schnelle und verlässliche Antworten aus ihren Power-BI-Semantikmodellen.

Delta-Format für einheitlichen Speicher nutzen

Eine der wirkungsvollsten architektonischen Entscheidungen, die Microsoft beim Aufbau von Fabric getroffen hat, ist die Verwendung des Open-Source-Formats Delta Parquet für alle strukturierten Tabellen. Diese Entscheidung verwischt auf wirkungsvolle Weise die Grenzen zwischen Lakehouses und Warehouses.

Ob Daten in einem Fabric Lakehouse mit PySpark aufgenommen und verarbeitet oder mit T-SQL in ein Fabric Data Warehouse geladen werden, die zugrunde liegenden physischen Dateien in OneLake liegen in beiden Fällen als Delta-Tabellen vor. Dieser offene Speicherstandard bringt ACID-Transaktionen, Time Travel und hohe Leistung in beide Umgebungen. Da sowohl das Lakehouse als auch das Warehouse Delta-Tabellen lesen und schreiben können, müssen Unternehmen sich nicht mehr um proprietäre Bindung an einen Speicher sorgen. Das bedeutet: Ein Data Engineer kann Daten mit Spark in einem Lakehouse aufbereiten, und ein SQL-Entwickler kann dieselben Tabellen mit T-SQL in einem Warehouse abfragen, ohne physische Duplikate der Daten anzulegen.

Das Wichtigste bei der Wahl des richtigen Ansatzes für Ihre Organisation

Wenn Sie Ihre Microsoft Fabric-Bereitstellung planen, stellt sich die Frage: Wie entscheiden Sie, ob Sie ein Lakehouse, ein Warehouse oder eine Kombination aus beiden einsetzen? Erfolgreiche Organisationen folgen bei der Gestaltung ihrer Fabric-Umgebungen in der Regel einigen zentralen Best Practices.

Setzen Sie erstens bei Bedarf auf einen hybriden Ansatz. Microsoft Fabric ist so konzipiert, dass Sie Lakehouses und Warehouses innerhalb derselben Mandanten- und Workspace-Struktur nebeneinander nutzen können. Ein Lakehouse eignet sich etwa für die Aufnahme von Rohdaten, aufwendige Data-Engineering-Transformationen und Data-Science-Workloads, während nachgelagerte Reporting-Marts oder unternehmensweit einheitliche Dimensionen in einem Data Warehouse liegen können. Zweitens sollten Sie OneLake-Verknüpfungen (Shortcuts) nutzen, um unnötige Datenbewegungen und Duplikate über Ihre Domänen hinweg zu vermeiden. Drittens sollten Sie immer die Verbraucher im Blick behalten: Bewerten Sie die Datentypen, die Sie erfassen, die Fähigkeiten der Personen, die die Daten transformieren, und die Leistungsanforderungen der Fachanwender, die die finalen Erkenntnisse nutzen.

Eine praxisnahe Aufschlüsselung, wie diese Architekturbausteine von der Rohdatenaufnahme bis zu unternehmerischen Entscheidungen zusammenspielen, bietet unsere passende Podcast-Episode Microsoft Fabric End-to-End: From Raw Data to Business Decisions with Amit Chandak [MVP]. Hören Sie unbedingt rein. In dieser Episode zeigt Amit, wie Organisationen OneLake nutzen, die Entscheidung zwischen Lakehouse und Warehouse treffen, Transformationen optimieren und skalierbare Analytics-Lösungen aufbauen können, die sowohl menschliche Entscheidungsträger als auch KI-gestützte Erlebnisse stärken.