Für alle, die Power BI kennen und jetzt verstehen wollen, was Microsoft Fabric darunter aufbaut — von OneLake über Lakehouse, Warehouse, Pipelines und Notebooks bis zum Direct-Lake-Modell im Power-BI-Bericht. Mit einem End-to-End-Beispiel und Tiefenfokus auf Direct Lake und Snowflake-Integration.
Dieser Guide ist kein Buch, das du von vorn nach hinten liest. Es ist eine Klick-Erkundung: sechs Sektionen, je 6–10 anklickbare Karten, jede führt zu einem Detail-Fenster mit Erklärung, Schritt-für-Schritt und Original-Screenshots aus Microsoft Learn.
Wenn du aus der Power-BI-Welt kommst, ist der rote Faden: Sektion 1 → 2 → 3 baut das mentale Modell (Was ist Fabric? → Welche Bausteine gibt es? → Wie kommt daraus ein Power-BI-Bericht?). Sektion 4 macht es einmal komplett praktisch durch. Sektion 5 (Snowflake) und 6 (Architektur-Entscheidungen) sind Vertiefung für konkrete Projektfragen.
Wenn du eine Karte anklickst, öffnet sich ein Modal. Mit Esc schließen, oder neben das Fenster klicken.
Sechs Etappen, von der Einordnung bis zur Architektur-Entscheidung. Klick führt direkt zur Sektion.
Microsoft Fabric ist kein weiteres Azure-Tool, sondern der Versuch, den kompletten Analytics-Stack — Integration, Engineering, Warehousing, Streaming, BI — als eine SaaS-Plattform zu bündeln. Wer versteht, warum es Fabric gibt und wie Power BI hineinpasst, kann jede weitere Detail-Frage einsortieren.
Das Kernversprechen von Fabric: Eine SaaS-Plattform statt vieler einzeln zu konfigurierender PaaS-Dienste, ein logischer Data Lake (OneLake) für den ganzen Tenant, und eine einzige Kopie der Daten, auf der alle Engines arbeiten — Spark, T-SQL, KQL und Power BI.
Vorher: Azure Data Factory für Integration, Synapse für Warehouse und Spark, Event Hubs + Stream Analytics für Streaming, Power BI für Reporting — vier Dienste, vier Sicherheitsmodelle, viele Datenkopien.
Mit Fabric: dieselben Fähigkeiten als Workloads einer Plattform, mit gemeinsamem Speicher (OneLake), gemeinsamer Governance (Purview) und gemeinsamer Abrechnung (Capacity Units).
Alles in Fabric folgt demselben Muster: Daten liegen einmal in OneLake (Delta Parquet), verschiedene Engines rechnen darauf, und Shortcuts holen externe Daten dazu, ohne sie zu kopieren. Wer diese Bausteine kennt, kann jede Fabric-Architektur lesen.
Das semantische Modell ist die Brücke zwischen Fabric und Power BI: Measures, Beziehungen und Business-Logik über den Delta-Tabellen. Neu in Fabric ist Direct Lake — ein Storage Mode, der Import-Performance mit DirectQuery-Frische kombiniert, weil er Delta-Dateien direkt aus OneLake liest. Und weil Copilot, Fabric Data Agents und MCP-Clients ihre Antworten aus genau diesen Modellen ziehen, ist ein sauberes Modell heute auch die Grundlage für KI.
Direct Lake importiert nichts: Das Modell lädt Spalten bei Bedarf direkt aus den Delta-Parquet-Dateien in OneLake in den Speicher. Ein „Refresh" ist nur noch eine Metadaten-Operation (Framing) — Sekunden statt Stunden, auch bei Milliarden Zeilen.
Warum das funktioniert: Delta-Parquet mit V-Order-Kompression ist so organisiert, dass die VertiPaq-Engine die Daten fast direkt verarbeiten kann (Transcoding statt Import). Abfragen laufen In-Memory wie im Import Mode.
Der Haken: Guardrails pro F-SKU (Zeilen, Dateien, Row Groups, Speicher) — bei Direct Lake on SQL ein möglicher Fallback auf DirectQuery, bei Direct Lake on OneLake ein fehlschlagendes Framing. Details in den Karten.
Einmal komplett durch: Beispieldaten nach OneLake bringen, mit Pipeline oder Notebook transformieren, im Lakehouse strukturieren, ein semantisches Modell bauen, einen Power-BI-Bericht veröffentlichen. Die Karten folgen dem offiziellen Lakehouse-Tutorial von Microsoft (Wide World Importers) — mit einer Fabric-Trial-Kapazität komplett kostenlos nachbaubar.
Viele Unternehmen haben ihr Warehouse in Snowflake und ihr Reporting in Power BI. Fabric bietet dafür drei sehr unterschiedliche Integrationswege: Mirroring (Replikation nach OneLake), Iceberg-Interoperabilität (Zero-Copy — per Shortcut oder mit dem Item „Snowflake database“, das Iceberg-Tabellen direkt in OneLake ablegt) und den klassischen Connector (Import/DirectQuery). Die Wahl bestimmt Architektur, Latenz, Kosten und Governance.
Am Ende laufen alle Fabric-Fragen auf wenige Entscheidungen zusammen: Lakehouse oder Warehouse? Copy, Dataflow oder Spark? Import oder Direct Lake? Microsoft dokumentiert dafür offizielle Decision Guides — diese Sektion fasst sie zusammen und zeigt typische Referenzarchitekturen.
Dieser Guide stützt sich auf die offizielle Microsoft-Learn-Dokumentation zu Microsoft Fabric und auf etablierte Community-Quellen (SQLBI/Marco Russo, Chris Webb, Sandeep Pawar, Nikola Ilic, James Serra u. a.). Jede zitierte Zahl ist hier rückverfolgbar. Quellen-Validierung Oktober 2026: F-SKU-Staffelung (F2–F8192), Trial (F4/F64), P-SKU-Auslauf (30 Tage Grace, dann Drosselung, ab Tag 91 Sperre), Direct-Lake-Guardrails inkl. Row Groups, Direct Lake on OneLake vs. on SQL samt DirectLakeBehavior, V-Order-Default (in neuen Workspaces für Spark aus), Snowflake-Mirroring (Iceberg-Tabellen, kostenpflichtige Extended Capabilities), Snowflake database item, Copilot/Data-Agent-Voraussetzungen, MCP-Server und die Decision-Guide-Kriterien wurden gegen Microsoft Learn verifiziert. Screenshots: Die in den Modal-Karten eingebetteten Abbildungen stammen direkt vom Microsoft-Learn-CDN und stehen unter der Microsoft-Dokumentations-Lizenz (CC BY 4.0) zur Nutzung mit Quellenangabe. Fabric entwickelt sich monatlich weiter — im Zweifel die jeweils verlinkte Quell-Seite konsultieren.