Was ist Microsoft Fabric – und wann passt die Plattform?
Microsoft Fabric bringt Datenintegration, Engineering, Warehouse, Echtzeit und Power BI unter ein Dach. Das kann Übergaben vereinfachen. Es macht Architektur, Capacity und Betrieb aber nicht automatisch richtig.
Wenn die Datenplattform aus Übergaben besteht.
Viele Analytics-Landschaften scheitern nicht an einem einzelnen Werkzeug. Sie scheitern an den Lücken dazwischen.
Ein Dienst bewegt Daten, ein anderer speichert sie, ein dritter verarbeitet sie und Power BI bildet die letzte Schicht. Jede Komponente kann für sich funktionieren. Trotzdem entstehen Kopien, getrennte Berechtigungen, manuelle Deployments und mehrere Orte für Monitoring. Eine Änderung am Quellsystem wandert dann durch Tickets, Exporte und Zuständigkeiten, bevor sie im Bericht ankommt.
Microsoft Fabric setzt genau dort an. Die Plattform bündelt Datenintegration, Data Engineering, Data Warehouse, Real-Time Intelligence, Data Science, Datenbanken und Power BI in einer gemeinsamen SaaS-Umgebung. Die Bausteine arbeiten über OneLake, gemeinsame Workspaces, Identitäten und eine geteilte Capacity.
Fabric verkürzt technische Übergaben. Es entfernt aber nicht die Verantwortung für Datenmodell, Qualität, Kosten und Betrieb.
Fabric ist eine Analytics-Plattform, kein einzelnes Produkt.
Die Workloads sehen unterschiedlich aus, teilen aber zentrale Grundlagen: OneLake, Workspaces, Identität, Governance und Capacity.
OneLake ist der logische Datensee eines Fabric-Tenants. Lakehouses, Warehouses und weitere Fabric-Objekte speichern oder referenzieren dort Daten. Tabellen können in offenen Formaten wie Delta Parquet oder Iceberg liegen. Shortcuts binden Daten aus anderen Bereichen oder Speichern ein, ohne für jeden Zugriff eine weitere Kopie anzulegen.
Darüber liegen spezialisierte Erfahrungen. Data Factory nimmt Daten auf und orchestriert Abläufe. Data Engineering verarbeitet sie mit Lakehouse, Spark und Notebooks. Warehouse bietet eine SQL-orientierte Arbeitsweise. Real-Time Intelligence verarbeitet Ereignisse, Data Science entwickelt Modelle und Power BI stellt semantische Modelle und Berichte bereit.
Das ist ein Orientierungsfluss, keine Pflichtarchitektur. Nicht jeder Anwendungsfall braucht jeden Workload oder eine weitere Kopie der Daten.
Data Factory
Pipelines und Dataflows für Aufnahme, Transformation und Orchestrierung.
Data Engineering
Lakehouse, Spark und Notebooks für skalierbare Datenverarbeitung.
Data Warehouse
T-SQL, relationale Modelle und kontrollierte SQL-Bereitstellung.
Real-Time Intelligence
Ereignisströme, Eventhouse und zeitnahe operative Analysen.
Data Science und Datenbanken
Modelle, Experimente sowie operative Datenbank-Szenarien innerhalb der Plattform.
Power BI
Semantische Modelle, Kennzahlen, Berichte und die Nutzung kuratierter Daten.
Wann Microsoft Fabric sinnvoll ist – und wann nicht.
Die Plattform passt nicht deshalb, weil bereits Power BI genutzt wird. Sie passt, wenn die gemeinsame Betriebs- und Datenbasis reale Reibung reduziert.
Fabric passt häufig, wenn …
- Datenintegration, Engineering und BI heute unnötig getrennt betrieben werden.
- Power BI bereits wichtig ist und semantische Modelle enger an die Datenplattform rücken sollen.
- SQL-, Spark- und Low-Code-Teams auf denselben kontrollierten Daten arbeiten müssen.
- OneLake und Shortcuts tatsächlich Kopien und Übergaben reduzieren können.
- eine zentrale Capacity bewusst geplant, überwacht und verantwortet wird.
Fabric ist kein Automatismus, wenn …
- ein einzelnes, stabiles Warehouse das Problem bereits gut löst.
- bestehende Plattformen nur ohne fachlichen Nutzen nachgebaut würden.
- strikte Cloud-, Netzwerk- oder Betriebsanforderungen nicht zur SaaS-Plattform passen.
- Capacity, Mandant, Workspaces und Verantwortlichkeiten ungeklärt bleiben.
- jede neue Funktion sofort verwendet werden soll, nur weil sie verfügbar ist.
Eine ehrliche Bewertung beginnt deshalb bei Datenwegen, Nutzern, Sicherheitsanforderungen, vorhandenen Fähigkeiten und Betriebskosten. Erst danach folgt die Frage, welche Fabric-Workloads gebraucht werden.
Drei Entscheidungen prägen fast jede Fabric-Lösung.
Produktnamen sind schnell gewählt. Tragfähig wird die Architektur erst, wenn Speicherform, Qualitätsstufen und Zugriffsweg zum tatsächlichen Anwendungsfall passen.
Lakehouse oder Warehouse?
Spark und offene Dateien, kontrolliertes T-SQL – oder eine bewusste Kombination? Team, Schreibpfad und Betrieb entscheiden.
Speicherform vergleichen →
Bronze, Silver und Gold?
Schichten helfen nur, wenn jede einen klaren Qualitätszustand und eine betriebliche Aufgabe beschreibt.
Medallion pragmatisch einordnen →
Direct Lake, Import oder DirectQuery?
Aktualität allein reicht nicht. Datenort, Modellgröße, Performance, Capacity und Fehlerverhalten gehören zur Entscheidung.
Zugriffsmodus entscheiden →Die beste Fabric-Architektur verwendet nicht möglichst viele Workloads. Sie macht möglichst wenige Übergaben nötig und jede verbleibende Übergabe nachvollziehbar.
Shared Capacity macht Kosten sichtbar – und Engpässe gemeinsam.
Fabric-Workloads verbrauchen Capacity Units aus einem gemeinsamen Ressourcenpool. Pipelines, Spark-Jobs, Warehouse-Abfragen, semantische Modelle und Berichte können sich dadurch gegenseitig beeinflussen. Kurzzeitige Spitzen werden teilweise geglättet. Dauerhafte Überlastung kann zu Verzögerungen, Throttling und abgewiesenen Vorgängen führen.
Capacity ist deshalb keine spätere Lizenzfrage. Sie ist Teil der Architektur: Welche Last läuft wann? Welche Arbeitsbereiche teilen eine Capacity? Was ist interaktiv, was im Hintergrund? Welche Auslastung und welche Drosselung zeigt die Capacity Metrics App?
Auch der Lebenszyklus muss früh geklärt sein. Git-Integration, Deployment Pipelines, variable Umgebungswerte und getrennte Entwicklungs-, Test- und Produktivbereiche vermeiden, dass Änderungen nur manuell im Portal nachvollziehbar sind.
Woran eine belastbare Fabric-Lösung erkennbar wird.
Nicht die Zahl der Workspaces oder Notebooks zeigt den Reifegrad, sondern das Verhalten bei Last, Fehlern und Änderungen.
Workspace Monitoring kann Logs und Metriken verschiedener Fabric-Objekte in einem Eventhouse sammeln. Die Funktion ist laut aktueller Microsoft-Dokumentation weiterhin als Preview gekennzeichnet. Für produktive Betriebsversprechen sollten deshalb zusätzlich die stabilen Monitoring-Möglichkeiten des jeweiligen Workloads und die Capacity Metrics App berücksichtigt werden.
Woran Fabric-Einführungen unnötig schwer werden.
Jeder Workload bekommt eine Aufgabe
Die Plattform wird zum Produktkatalog. Zusätzliche Übergaben und Betriebsflächen entstehen, obwohl ein einfacherer Datenweg gereicht hätte.
OneLake wird mit „eine Kopie“ verwechselt
Shortcuts und offene Formate können Kopien reduzieren. Unkontrollierte Tabellen, Exporte und semantische Modelle vervielfachen Logik trotzdem.
Capacity wird erst bei Drosselung untersucht
Lastprofile, Zeitfenster und interaktive Nutzung werden nicht geplant. Erst langsame Berichte machen den gemeinsamen Ressourcenpool sichtbar.
Medallion wird zum Pflichtformular
Bronze, Silver und Gold werden angelegt, ohne dass Schichtgrenzen, Verbraucher und Qualitätszustände definiert sind.
Power BI bleibt außerhalb der Architektur
Semantische Modelle, Aktualität, RLS und der Zugriffsmodus werden spät entschieden, obwohl sie Capacity und Nutzererlebnis wesentlich prägen.
Produktiv bedeutet „im selben Workspace“
Ohne getrennte Umgebungen, Versionsverwaltung und wiederholbare Deployments werden Änderungen zur Portal-Handarbeit.
Mit einem Datenprodukt beginnen, nicht mit dem ganzen Tenant.
Ein guter Fabric-Einstieg prüft den vollständigen Datenweg an einem relevanten Anwendungsfall – inklusive Capacity und Betrieb.
Nutzung und Qualitätsziel festlegen
Welche Entscheidung oder welcher Prozess soll besser werden? Welche Aktualität, Vollständigkeit und Genauigkeit sind nötig?
Bestehenden Datenweg aufnehmen
Quellen, Kopien, Transformationen, Berechtigungen und manuelle Übergaben sichtbar machen, bevor sie migriert werden.
Speicher und Verarbeitungsweg entscheiden
Lakehouse, Warehouse oder eine Kombination nach Datenform, Team, Schreibpfad und Nutzung auswählen.
Ein End-to-End-Datenprodukt bauen
Aufnahme, Qualität, Modell, semantische Schicht und einen real genutzten Bericht vollständig umsetzen.
Fehler, Deployment und Last testen
Wiederanlauf, Schemaänderung, Umgebungswechsel und Capacity-Spitzen nicht erst nach dem Produktivstart kennenlernen.
Bewährtes standardisieren
Erst aus dem funktionierenden Datenprodukt Standards für Workspaces, Benennung, CI/CD, Monitoring und Governance ableiten.
Ein kleiner, vollständig betriebener Fabric-Datenweg ist wertvoller als ein großer Tenant voller vorbereiteter Arbeitsbereiche.
Die Grundlage dafür ist solides Data Engineering: Datenwege, Qualität und Betrieb bleiben wichtiger als der Produktname. Der Hub Datenstrategie & Business Intelligence klärt den fachlichen Rahmen aus Entscheidungen, Kennzahlen und Verantwortung.
Offizielle Grundlagen und aktuelle Einordnung.
Die Produktbeschreibung und versionsabhängigen Aussagen wurden am 15. August 2026 gegen aktuelle Microsoft-Learn-Primärquellen geprüft. Empfehlungen und Wertungen sind redaktionelle Einordnungen von Keckteck.
- Microsoft Learn: What is Microsoft Fabric?
- Microsoft Learn: What is OneLake?
- Microsoft Learn: Fabric decision guide – choose a data store
- Microsoft Learn: Direct Lake overview
- Microsoft Learn: Fabric Capacity Metrics app
- Microsoft Learn: Fabric capacity throttling policy
- Microsoft Learn: Fabric CI/CD concepts and best practices
- Microsoft Learn: Workspace monitoring (Preview)
Ihr prüft, ob Fabric zu eurem Datenweg passt?
Beschreibe kurz Quellen, Nutzung, heutige Plattform und den größten Engpass. Ich ordne ein, welche Fabric-Bausteine helfen – und welche ihr wahrscheinlich nicht braucht.
Ausgangslage schildern