Fabric OneLake: Was es ist, was es löst und wie du sinnvoll startest

Definition

Fabric OneLake ist der zentrale, tenantweite Datenspeicher in Microsoft Fabric, aufgebaut auf Azure Data Lake Storage Gen2. Es ist kein separates BI-Tool und kein einzelnes Lakehouse oder Warehouse, sondern der gemeinsame Speicher-Ort, in dem Fabric-Workloads Daten ablegen und nutzen.

Einleitung

Wenn Reporting bei euch an Excel-Konsolidierung, Datei-Chaos oder widersprüchlichen KPIs hängt, ist „fabric onelake“ ein sehr praktischer Hebel: Daten werden an einem Ort gespeichert, verwaltet und auffindbar gemacht. Damit können auch weniger IT-affine Nutzer auf saubere Gold-Daten zugreifen und direkt in Power BI, Excel oder Fabric weiterarbeiten, statt immer wieder Exporte zu bauen.

Was ist Microsoft Fabric OneLake und wie passt es in Fabric?

Microsoft Fabric bündelt mehrere Workloads (z. B. Lakehouse, Data Warehouse, Real-Time) in einer Plattform. OneLake ist darunter der gemeinsame Lake: Daten liegen nicht pro Abteilung in getrennten Speichern, sondern zentral im Fabric-Tenant und werden über Workspaces organisiert.

Für Anwender heißt das: weniger „Wo ist die richtige Datei?“, mehr „Welche freigegebene Tabelle nutze ich?“. Analytics und BI werden einfacher, weil dieselben Daten von unterschiedlichen Teams wiederverwendet werden können, ohne dass sie mehrfach kopiert werden.

Warum Datensilos teuer sind und zentrale Speicherung hilft

Datensilos entstehen typischerweise durch lokale SQL-Datenbanken, SharePoint/Fileserver-Ordner, Excel-Listen oder abteilungsspezifische Exporte. Der Schaden ist selten „nur technisch“: Zeit geht in Abstimmung und Fehlerkorrektur verloren, und Entscheidungen werden langsamer, weil Zahlen diskutiert werden.

• Mehrfach gespeicherte Daten (jeder baut seinen eigenen „einzigen“ Stand)
• Manuelle Konsolidierung (Copy/Paste, Mapping, Versionskonflikte)
• Keine klare Governance: Wer darf was sehen, was ist „gold“?

Wie OneLake Datensilos auflöst: Shortcuts, OneCopy und Data Mesh

Das Kernprinzip heißt OneCopy: Ein Datensatz liegt einmal im Lake und wird von vielen genutzt. Das wird in der Praxis vor allem durch Shortcuts erreichbar: Statt Daten physisch zu duplizieren, wird in Fabric logisch auf Daten an anderer Stelle verwiesen (innerhalb OneLake oder zu angebundenen Quellen). Das spart Speicher, reduziert Pflegeaufwand und verhindert KPI-Divergenz.

Organisatorisch passt OneLake gut zu einem Data-Mesh-Ansatz: Domänen-Teams (z. B. Finance, Sales, Operations) verantworten ihre Datenprodukte, aber alle arbeiten im gleichen Rahmen (Workspaces, Namenskonventionen, Freigaben). So entsteht ein zentraler Ort, ohne dass alles bei einem zentralen Team hängen bleibt.

Unterschiede: OneLake vs. Lakehouse vs. Data Warehouse

Die Begriffe werden oft vermischt. In Fabric ist es sinnvoll, so zu trennen:

• OneLake: der zentrale Storage-Layer (der „Lake“ für den gesamten Tenant)
• Lakehouse: Daten und Verarbeitung mit Spark, typischerweise auf Delta Lake / Delta-Parquet
• Data Warehouse (Warehouse): relationaler Analytik-Store mit T-SQL und SQL Analytics Endpoint

Wichtig für BI: Mit Direct Lake / Direct Lake Mode kann Power BI auf Daten im OneLake-Format zugreifen, ohne den klassischen Import/Refresh-Umweg. Das ist oft der Unterschied zwischen „läuft irgendwie“ und „nutzt die Fachabteilung wirklich“.

Wichtige Bausteine: Format, Explorer, Hub und Governance

Ein paar Elemente machen OneLake in der Umsetzung konkret nutzbar:

• Delta-Parquet: offenes Format (Parquet) mit Delta-Logik für Versionierung, Performance und zuverlässige Tabellen
• OneLake File Explorer: Zugriff wie ein Ordnerbaum (Windows Explorer), hilfreich für Verständnis und schnelle Checks
• OneLake Data Hub: Auffindbarkeit im Tenant, damit Teams Daten nicht „neu erfinden“, sondern wiederverwenden

Ergänzend gehören Integration (z. B. Dataflows Gen2, Pipelines, Mirroring) und sauber definierte Ebenen (Bronze/Silver/Gold Layer) dazu, damit aus Rohdaten echte Analytics-Daten werden.

Governance, Sicherheit und Compliance im OneLake-Kontext

OneLake ist nur dann ein Gewinn, wenn Zugriff und Verantwortung klar sind. In Fabric wird das primär über Workspaces, Rollen und Freigaben gesteuert. Für Compliance und Transparenz ist Microsoft Purview relevant: Data Lineage, Katalogisierung, Klassifizierung und Nachvollziehbarkeit, woher Zahlen kommen.

Praxisnutzen: Ein Controller kann eine „Certified“/„Promoted“ Gold-Tabelle nutzen, ohne vorher die gesamte Pipeline zu verstehen. Die IT behält trotzdem Kontrolle über Berechtigungen, Tenant-Regeln und Auditing.

Praxis-Check: Lohnt sich OneLake für mittelständische Unternehmen?

OneLake lohnt sich meist dann, wenn ihr mehr als eine relevante Datenquelle habt und Reporting nicht mehr „nebenbei“ funktioniert. Typische Signale: Excel-„Monster“, viele manuelle Schritte, unterschiedliche KPI-Definitionen, oder mehrere Teams bauen parallel ähnliche Datensätze.

Mini-Beispiel: Finance konsolidiert DATEV, CRM und Excel-Listen monatlich. Mit OneLake wird ein Gold-Datensatz (z. B. Umsatz, Kostenstellen, Cashflow) zentral gespeichert; Power BI und Excel greifen auf dieselbe Basis zu. Ergebnis: weniger Abstimmung, schnellere Analysen, klare Drilldowns bis zur Quelle.

Implementierung, Integration und Migration: pragmatische Schritte

Ein sinnvoller Start ist selten „alles migrieren“. Besser ist ein klar abgegrenzter Use Case mit messbarem Effekt, dann skalieren:

• 1) Workspace-Setup, Namens- und Berechtigungskonzept, Zielbild (Gold-Daten definieren)
• 2) Ingestion per Pipelines/Dataflows Gen2 oder Mirroring, Rohdaten nach Bronze
• 3) Transformation nach Silver/Gold (Delta-Parquet), Bereitstellung an Power BI (Direct Lake) oder Warehouse (T-SQL)

Migration gelingt am besten iterativ: erst die wichtigsten Berichte/Tabellen, dann weitere Domains. So bleibt der Zeitaufwand kontrollierbar und der ROI früh sichtbar.

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn ihr schnell von „wir testen Fabric“ zu „wir betreiben verlässlich“ kommen wollt. Typische Fälle: mehrere Quellsysteme, Security/Compliance-Anforderungen, fehlende Kapazität für End-to-End-Pipelines oder der Wunsch nach einer klaren Zielarchitektur (Lakehouse vs. Warehouse) statt Tool-Basteln.