Microsoft Fabric Architektur: So baut ihr eure Datenplattform
Geschrieben von:
Hanna Schwab
Data & AI Lead
Viele Unternehmen starten mit Microsoft Fabric und stolpern nach den ersten Wochen. Das Problem liegt selten an der Plattform. Es liegt an der Architektur, die niemand von Anfang an durchgedacht hat. Ohne eine klare Microsoft Fabric Architektur entstehen dieselben Probleme wie vorher: Datensilos, unklare Verantwortlichkeiten und Reports, denen niemand wirklich vertraut.
Der Aufbau einer soliden Fabric-Architektur ist keine rocket science. Er folgt klaren Prinzipien – wer diese von Anfang an umsetzt, spart sich später aufwändige Umbauten.
Dieser Artikel zeigt Euch, wie eine tragfähige Microsoft Fabric Architektur aussieht: OneLake als zentraler Speicher, Medallion Architecture als Datenstruktur, Lakehouse vs. Warehouse als Abfrageparadigmen, typische Szenarien aus der Mittelstandspraxis und die häufigsten Fehler beim Architektur-Design.
Was ist die Microsoft Fabric Architektur?
Microsoft Fabric ist seit November 2023 allgemein verfügbar. Die Plattform vereint Datenintegration, Data Engineering, Data Science, Data Warehousing, Echtzeit-Analysen und Business Intelligence in einem einzigen SaaS-Service. Das klingt nach einem weiteren Tool-Bundle, ist in Wirklichkeit aber eher eine strukturelle Vereinfachung von Arbeitsprozessen.
Die Fabric-Architektur folgt einem zentralen Prinzip: ein Datenspeicher, viele Dienste. Statt dass jedes Team mit eigenen Systemen, eigenen Schnittstellen und eigenen Datenkopien arbeitet, greifen alle Fabric-Dienste auf denselben logischen Speicher zu. Dieser Speicher heißt OneLake.
Das verändert, wie Datenplattformen gebaut werden. Ihr braucht keine aufwändigen ETL-Strecken mehr, die Daten zwischen Systemen bewegen. Keine Synchronisation von Datenbankversionen. Keine widersprüchlichen Reports aus verschiedenen Quellen.
Für Unternehmen, die bisher mit fragmentierten Stacks aus Azure Data Lake, Azure Synapse, separaten Power BI-Kapazitäten und eigenem SQL-Server gearbeitet haben, ist das ein echter Strukturwechsel. Kein kosmetischer.
OneLake: Der zentrale Datenspeicher in Fabric
OneLake ist der logische Datenspeicher von Microsoft Fabric. Jeder Fabric-Tenant hat genau einen OneLake. Alle Dienste – ob Lakehouse, Warehouse, Data Factory oder Power BI – lesen und schreiben in diesen einen Speicher.
Was das in der Praxis bedeutet:
- Keine Datenkopien zwischen Diensten
- Keine unterschiedlichen Speicherformate pro Team
- Einheitliche Zugriffskontrolle über alle Workloads hinweg
- Daten im offenen Delta-Parquet-Format, auf das auch externe Tools direkt zugreifen können
OneLake einrichten ist technisch kein komplexer Schritt.
Der Speicher ist automatisch Teil jedes Fabric-Tenants und muss nicht separat provisioniert werden. Die Herausforderung liegt in der Strukturierung dahinter: Wie organisiert ihr Workspace-Grenzen? Wer hat Lese- und Schreibrechte auf welche Daten? Wie trennt ihr Entwicklungs-, Test- und Produktionsdaten?
Genau hier setzt eine durchdachte Fabric-Architektur an. OneLake ist das Fundament – aber ohne Struktur bleibt es ein leerer See.
Ein weiteres wichtiges Feature sind OneLake Shortcuts: Damit könnt ihr auf Daten in externen Speichern wie Azure Data Lake Storage Gen2 oder Amazon S3 verweisen, ohne diese physisch nach OneLake zu kopieren. Besonders relevant, wenn Ihr bestehende Infrastruktur schrittweise in Fabric überführen wollt.
Medallion-Architektur (Bronze / Silver / Gold) – wie sie in Fabric funktioniert
Das bewährteste Strukturierungsmodell für Daten in OneLake ist die Medallion Architektur. Sie teilt Daten in drei Schichten:
- Bronze: Rohdaten, exakt so wie sie aus den Quellsystemen kommen. Unverändert, vollständig, mit vollem Historienstand. Fehler in Quelldaten bleiben hier sichtbar – damit nichts verloren geht.
- Silver: Bereinigte, validierte und standardisierte Daten. Duplikate entfernt, Formate vereinheitlicht, Referenzwerte geprüft. Diese Schicht ist die Basis für alle weiteren Auswertungen.
- Gold: Angereicherte Datenprodukte, direkt nutzbar für Reporting, KI-Modelle oder operative Prozesse.
Jede Schicht hat eine klare Verantwortlichkeit. Bronze dient zur Sicherung der Rohdaten. Silver-Layer ist für Data Engineering und bildet die Grundlage für Datenqualitätsregeln, für die fachliche Teams Verantwortung übernehmen. Gold ist das, was Dashboards und Berichte sehen.
In unseren Projekten sehen wir regelmäßig, was passiert, wenn dieser Schichtenansatz fehlt: Data Scientists arbeiten auf Rohdaten, die sich täglich ändern und keine stabile Basis bieten. Reports spiegeln unterschiedliche Bereinigungslogiken wider, weil jedes Team eigene Regeln anwendet. Und wenn ein Fehler auftritt, weiß niemand, wo er entstanden ist – in der Quelle, in der Transformation oder im Report selbst.
Die Medallion Architecture bringt Klarheit, ohne neue Komplexität hinzuzufügen.
Governance direkt in der Architektur: Mit RBAC (Role-Based Access Control) legt ihr auf Workspace- und Itemebene fest, wer auf welche Schicht zugreifen darf. Die Integration mit Microsoft Purview ergänzt das: Sensitivity Labels klassifizieren Daten nach Schutzbedarf, Datenlineage dokumentiert jeden Transformationsschritt.
Lakehouse vs. Warehouse in Microsoft Fabric
Microsoft Fabric bietet zwei Paradigmen für Datenspeicherung und Abfrage.
Das Lakehouse basiert auf dem offenen Delta-Lake-Format und unterstützt SQL und Apache Spark. Es eignet sich für große, heterogene Datensätze, explorative Analysen und maschinelles Lernen. Das Schema muss nicht beim Laden feststehen – gut für Data Engineering und Data Science-Szenarien.
Das Warehouse folgt dem klassischen relationalen Modell, abfragbar mit T-SQL. Es ist auf strukturierte, wiederholte Abfragen ausgelegt, bei denen das Datenmodell vorab festgelegt wird. Teams mit SQL-Erfahrung aus Synapse oder SQL Server finden sich schnell zurecht.
Die Frage ist nicht, welches besser ist. Die Frage ist, was Ihr damit tun wollt und welche Skills Euer Team mitbringt.
In den meisten unserer Projekte landen wir bei einem Hybridansatz: Lakehouse für Bronze und Silver, in dem Daten geladen, bereinigt und transformiert werden. Warehouse für Gold, auf das Power BI direkt zugreift und in dem das fachliche Datenmodell gepflegt wird. Beide teilen sich OneLake als Speicher – der Wechsel zwischen ihnen ist keine Infrastrukturfrage, sondern eine Abfragestrategie.
Fabric Architektur im Mittelstand: Typische Szenarien
Wie sieht eine Fabric-Architektur in der Praxis aus? Aus unseren Projekten mit mittelständischen Unternehmen im DACH-Raum kennen wir drei typische Ausgangssituationen:
Szenario 1 – Zentrales Reporting:
Ein Unternehmen mit SAP, CRM und mehreren Excel-Datenquellen will eine einheitliche Reporting-Basis.
Fabric lädt alle Quellen in OneLake (Bronze), bereinigt und vereinheitlicht sie in Silver, und stellt Gold-Tabellen direkt für Power BI bereit. Kein separates Data Warehouse. Keine Datenkopien.
Szenario 2 – KI-ready Data Platform:
Ein Fertigungsunternehmen will Produktionsdaten für KI-Modelle nutzen.
Die Medallion Architecture strukturiert die Rohdaten aus dem ERP-System (Bronze), bereinigt Messwerte und ergänzt Referenzdaten (Silver), und stellt angereicherte Datensätze für Predictive-Maintenance-Modelle bereit (Gold).
Szenario 3 – Schrittweise Migration:
Ein Unternehmen hat bereits Azure Data Lake Storage Gen2 im Einsatz. Mit OneLake Shortcuts werden bestehende Daten eingebunden, ohne sie zu bewegen. Migration ohne Big-Bang-Risiko.
Was diese Szenarien gemeinsam haben:
Fabric wird nicht als Experiment eingeführt, sondern als produktive Plattform.
Das bedeutet klare Umgebungstrennung (Entwicklung, Test, Produktion), ein Governance-Konzept vor der ersten Datenpipeline und ein Monitoring-Setup, das Kosten und Kapazitätsnutzung von Anfang an sichtbar macht.
Häufige Fehler beim Architektur-Design – und wie Ihr sie vermeidet
Aus unserer Arbeit mit Unternehmen im DACH-Raum kennen wir die Stolperfallen, die immer wieder auftreten:
- Kein Workspace-Konzept. Entwicklung und Produktion teilen sich einen Workspace. Testläufe berühren produktive Daten. Deployments werden zu einem Risiko. Die Lösung: separate Workspaces für Entwicklung, Test und Produktion, mit eigenen Berechtigungskonzepten.
- Medallion übersprungen. Teams laden Daten direkt in Gold-Tabellen, ohne Bronze- und Silver-Schicht. Das spart anfangs Zeit – bis zum ersten Qualitätsproblem. Dann fehlt die Grundlage, um Fehler einzugrenzen.
- Lakehouse-Warehouse-Entscheidung aufgeschoben. Teams starten im Lakehouse und wechseln nach sechs Monaten zum Warehouse. Das erzeugt doppelte Datenmodellierung und Migrationsaufwand.
- Kein Monitoring von Anfang an. Capacity Metrics und Monitoring-Dashboards werden nicht eingerichtet. Kosten laufen unkontrolliert. Wenn die erste Fabric-Rechnung eintrifft, fehlt jede Grundlage für Analyse und Optimierung.
Nächste Schritte: Mit teccle zur produktionsreifen Fabric-Plattform
Die Architekturentscheidungen, die Ihr in den ersten Wochen trefft, bestimmen, wie gut Eure Datenplattform in zwei Jahren skaliert – und wie viel Aufwand Ihr investiert, um sie auf einem sauberen Stand zu halten.
Wir begleiten mittelständische Unternehmen beim Aufbau ihrer Microsoft Fabric-Architektur. Von der ersten Strukturierungsentscheidung bis zur produktiven Umsetzung. Kein PoC, der im Regal landet. Kein Konzept ohne Umsetzung.
Unser Team bringt acht Fabric-Spezialist:innen mit Erfahrung aus Implementierungen in Fertigung, Handel und Dienstleistung im DACH-Raum in die Projekte. Wir setzen Medallion-Architektur, RBAC-Governance und produktionsreife Datenpipelines um. Nicht nur als Proof-of-Concept, sondern auch als betreibbare Plattform.
Ein typisches Ergebnis nach drei Wochen: eine Fabric-Umgebung mit funktionierender Medallion-Struktur, angebundenen Datenquellen, Power BI-Reports auf Gold-Basis und einem Governance-Konzept, das Compliance-Anforderungen erfüllt. Keine offenen Konzeptpapiere. Kein Rückstand beim nächsten Audit.
Fazit: Architektur entscheidet, ob Fabric funktioniert
Microsoft Fabric gibt Euch die technischen Voraussetzungen für eine moderne Datenplattform. Aber die Plattform allein reicht nicht.
Wer Fabric ohne Architektur einführt, tauscht alte Probleme gegen neue. Datensilos entstehen wieder – diesmal innerhalb der Plattform. Zugriffsrechte bleiben ungeklärt. Reports widersprechen sich.
Und die KI-Use-Cases, für die man eigentlich gestartet ist, warten weiter.
Wer zu Beginn die richtigen Strukturentscheidungen trifft, baut auf einem Fundament, das mitwächst: OneLake als zentraler Speicher, Medallion Architecture als Datenstruktur, RBAC und Purview als Governance-Rahmen.
Häufig gestellte Fragen zur Microsoft Fabric Architektur
Whitepaper, Blogs und Webinare
Bleibt auf dem Laufenden mit unseren aktuellen Webinaren und Whitepapern rund um Microsoft Fabric. Wir teilen regelmäßig praxisnahe Einblicke, Best Practices und die neuesten Entwicklungen der Plattform mit Euch.
Fragen zu eurer Architektur? Schreibt uns.
teccle News
Mit den teccle News seid Ihr immer einen Schritt voraus und auf dem neuesten Stand rund um die spannendsten Innovationen. Wir verpacken für Euch die aktuellsten IT-Themen aus der Branche, exklusive Events, Tipps & Tricks und vieles mehr und stellen sie Euch kostenlos gesammelt bereit.
Nichts mehr verpassen: jetzt die teccle news abonnieren.