Fabric Lakehouse: Was es ist, wann du es brauchst und wie du es aufbaust

Definition

Ein Fabric Lakehouse ist ein Datenobjekt in Microsoft Fabric, das Daten im OneLake speichert und sie gleichzeitig für SQL-Analysen und Data Engineering bereitstellt.

Es ist kein reines Dateiverzeichnis und auch kein klassisches relationales Data Warehouse, sondern eine Brücke zwischen Data Lake (Dateien/Delta) und BI-Abfragewelt.

Einleitung

Wenn ihr Daten aus ERP, CRM, SharePoint und Excel ständig manuell zusammenkopiert, ist ein Fabric Lakehouse ein sehr direkter Hebel: eine gemeinsame Datenbasis, auf die Power BI und SQL zugreifen können. Du bekommst schneller stabile Zahlen, weniger Pflegeaufwand und eine Grundlage, auf der Fachbereiche sicher Self-Service machen können – ohne Wildwuchs.

Was ist ein Fabric Lakehouse (und warum OneLake dazugehört)?

In Microsoft Fabric liegt ein Lakehouse physisch im OneLake. Der praktische Nutzen: Daten werden einmal zentral abgelegt, und unterschiedliche Rollen können darauf arbeiten, ohne neue Kopien anzulegen. Data Engineers laden und bereinigen Daten, Analysten nutzen denselben Datenbestand für Auswertungen, und nicht-IT-affine Nutzer bauen auf „Gold“-Daten in Power BI oder sogar Excel auf, statt neue Schatten-Tabellen zu pflegen.

Wichtig: OneLake ist nicht nur „ein Speicher“. Es ist der Ort, an dem ihr Daten standardisiert bereitstellt, sodass Teams nicht mehr diskutieren müssen, welche Datei „die richtige“ ist.

Lakehouse vs. Data Warehouse: wann welches?

Ein Fabric Data Warehouse (in Fabric) ist stark, wenn ihr primär sauber modellierte, relationale Daten für standardisierte KPIs und stabile Berichte braucht. Ein Lakehouse ist stark, wenn eure Datenquellen heterogen sind, Rohdaten anfallen oder ihr flexibel iterieren wollt, bevor alles final modelliert ist.

• Lakehouse: viele Quellsysteme, Rohdaten/Dateien, schnelle Iteration, Data Engineering mit Notebooks (Apache Spark Runtime) und Delta Tables
• Data Warehouse: stark relational, klare BI-Schicht, T-SQL-getriebene Modelle, stabile Reporting-Workloads
• Praxis: häufig Lakehouse für „Bronze/Silver“ und Warehouse oder semantisches Modell für „Gold“

Entscheidungsregel: Wenn ihr heute noch viel Datenchaos habt, startet oft das Lakehouse. Wenn ihr bereits bereinigte, klar strukturierte Daten habt, kann das Warehouse der schnellere Weg zu sauberen KPI-Reports sein.

Zugriff: SQL-Endpunkte, APIs und Power BI

Ein Lakehouse bietet Zugriff über den SQL Analytics Endpoint (SQL-Endpunkt). Damit können Analysten mit SQL (T-SQL-ähnlich) auf Tabellen zugreifen, Joins bauen und Daten prüfen, ohne jedes Mal ein neues Dataset zu importieren. Für BI ist das wichtig, weil Power BI denselben Datenbestand nutzen kann – besonders effizient über Direct Lake, wenn es zum Modell passt.

Zusätzlich sind Zugriffe über APIs und Fabric-Objekte wie Pipelines oder Notebooks üblich, z. B. um Daten automatisiert zu laden oder Transformationslogik als wiederholbaren Prozess zu betreiben.

Schritt-für-Schritt: Fabric Lakehouse aufbauen

Ein pragmatischer Start sieht so aus:

• Workspace erstellen: Team- und Berechtigungsrahmen festlegen (Entwickler, Viewer, Admin)
• Lakehouse anlegen: neues Lakehouse erstellen, Namen vergeben, Struktur vorbereiten
• Daten laden: per Data Factory Pipelines/Copy Job, Power Query oder Dataflows Gen2; Rohdaten erst mal „landen“ lassen

Danach kommt der Teil, der den ROI macht:

• Tabellen anlegen: Rohdaten in Delta Tables überführen (Delta Parquet), Struktur und Spaltentypen stabilisieren
• Gold bereitstellen: bereinigte Tabellen/Views für Reporting und Semantic Models definieren, damit Power BI-Nutzer nicht auf Rohdaten arbeiten

Datenmodellierung: Delta Lake-Schema und relationale Objekte

Im Lakehouse speichert ihr Tabellen als Delta Tables. Vorteil: Schema kann kontrolliert werden, Änderungen sind nachvollziehbar (z. B. Time Travel), und ihr vermeidet „jede Datei hat andere Spalten“-Probleme. Für BI zählt am Ende: klare Fakten- und Dimensionstabellen, eindeutige Schlüssel, konsistente Datentypen.

Relationale Objekte (z. B. Views im SQL-Endpunkt) helfen, Fachlogik so zu kapseln, dass nicht jedes Power-BI-Modell die Transformation neu erfindet. Das reduziert Risiko, weil KPI-Logik an einer Stelle gepflegt wird.

Mini-Praxisbeispiel: SQL und Visual Query

Du kannst am SQL-Endpunkt direkt prüfen, ob die Daten stimmen, bevor ein Dashboard gebaut wird:

SELECT Region, SUM(Umsatz) AS Umsatz
FROM SalesGold
GROUP BY Region;

Für Teams ohne SQL-Fokus ist Visual Query hilfreich: Tabellen auswählen, filtern, joinen, Ergebnis prüfen. Damit wird Datenarbeit greifbar, ohne dass jede Frage sofort ein Notebook braucht.

Sicherheit, Governance und Berechtigungen

Ein Lakehouse wird schnell zum Unternehmensasset. Deshalb gehören diese Punkte früh auf die Packliste:

• Rollen & Rechte im Workspace: Wer darf laden, wer darf nur lesen?
• Row-Level-Security im Semantic Model: z. B. Regionen, Mandanten, Kostenträger trennen
• Data Lineage und Standards: z. B. über Microsoft Purview, damit klar ist, woher KPIs kommen

Der Nutzen: weniger „Zahlenkrieg“, weniger Shadow-IT, mehr Vertrauen in Berichte.

Kosten- und ROI-Überblick (ohne Preislisten)

Fabric läuft kapazitätsbasiert (Fabric Capacity). Kostentreiber sind typischerweise: Datenvolumen, Refresh-Frequenz, Transformationsaufwand (Spark/SQL) und Anzahl der parallel arbeitenden Teams. ROI entsteht vor allem durch weniger manuelle Excel-Konsolidierung, weniger Fehlerkorrekturen und schnellere Entscheidungen, weil „Gold“-Daten zentral verfügbar sind.

Messbar wird das, wenn ihr vorab festlegt, welche Reports heute wie viele Stunden pro Monat binden und welche Prozesse ihr automatisieren wollt (z. B. Monatsabschluss-Reporting, Liquiditätsplanung, Vertriebssteuerung).

Best Practices & häufige Stolpersteine

• Best Practice: Medallion-Logik (Bronze/Silver/Gold) wirklich trennen, damit Fachbereiche nicht auf Rohdaten bauen
• Stolperstein: zu früh „alles anbinden“ – lieber 1–2 Kernquellen sauber produktiv machen
• Stolperstein: KPI-Logik verteilt in DAX, SQL und Excel – besser eine Führungsquelle je Kennzahl definieren

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn ihr schnell eine belastbare Architekturentscheidung treffen müsst (Lakehouse vs. Warehouse vs. Mix), wenn es bei Governance/Berechtigungen politisch wird oder wenn ihr Datenpipelines und Betriebsprozesse (Refresh, Monitoring, Verantwortlichkeiten) sauber aufsetzen wollt. Auch bei Migrationsdruck oder knapper interner Zeit reduziert ein klarer, abgegrenzter Scope das Projektrisiko.