Modernes Data Lakehouse auf Azure: Architektur-Entscheidungsleitfaden
Microsoft Fabric, Databricks und Synapse im Vergleich — Kosten, Governance und Architektur-Trade-offs für Ihr Data Lakehouse.
Das Data Lakehouse hat die klassische Debatte „Data Warehouse oder Data Lake" abgelöst. Durch die Kombination aus Struktur und Governance eines Warehouses mit der Flexibilität und dem Kostenprofil eines Lakes bieten Lakehouses einen pragmatischen Mittelweg. Auf Azure konkurrieren drei Plattformen um diese Rolle — und die Entscheidung zwischen ihnen gehört zu den wirkungsvollsten Architekturentscheidungen, die ein Data Leader in diesem Jahr trifft.
Dieser Leitfaden vergleicht die Optionen mit der Ehrlichkeit, die Herstellerdokumentation selten bietet.
Die Kernarchitektur: Medallion-Muster
Unabhängig von der Plattformwahl hat sich die Medallion-Architektur als Standard-Schichtenmodell etabliert:
- Bronze (Rohdaten) — Eingelesene Daten im Originalformat. Append-only, unveränderlich. Das ist Ihr System of Record.
- Silver (bereinigt) — Dedupliziert, schemavalidiert, quellenübergreifend verknüpft. Hier steckt der Großteil des Data-Engineering-Aufwands.
- Gold (Business) — Aggregierte, geschäftsorientierte Datensätze, optimiert für Analysten und ML-Modelle.
Alle drei Azure-Plattformen unterstützen dieses Muster. Die Unterschiede liegen in der Implementierung, den Kosten und den Reibungspunkten.
Plattformvergleich
Microsoft Fabric
Microsofts einheitliche Analytics-Plattform, aufgebaut auf OneLake (einer Single-Copy-Datenschicht auf ADLS Gen2).
Stärken:
- Eine Oberfläche für alles. Data Engineering, Data Science, Echtzeit-Analytics und BI in einer Plattform mit gemeinsamer Governance
- OneLake Shortcuts. Daten über Workspaces hinweg referenzieren, ohne sie zu kopieren — echte Reduzierung von Datenduplikation
- Tiefe Power-BI-Integration. Direct-Lake-Modus macht Datenimporte in Power-BI-Datasets überflüssig
- Kapazitätsbasierte Preise. Vorhersagbare Kosten bei gleichmäßiger Auslastung; Auto-Pause bei Inaktivität
Schwächen:
- Reifegrad. Fabric ist jünger als Databricks. Einige Features (z. B. Git-Integration für Pipelines, feingranulare RBAC) entwickeln sich noch weiter
- Herstellerabhängigkeit. OneLake ist proprietär. Die Daten liegen zwar als Delta/Parquet vor, aber Orchestrierung und Compute sind tief Microsoft-spezifisch
- Eingeschränktes Open-Source-Ökosystem. Fabric-Notebooks unterstützen PySpark, aber die breitere Ökosystem-Integration (MLflow, Custom Libraries) ist eingeschränkter als bei Databricks
Geeignet für: Organisationen mit starker Verankerung im Microsoft-365-/Power-BI-Ökosystem, die eine konsolidierte Plattform wollen und Feature-Lücken tolerieren können.
Databricks auf Azure
Die ursprüngliche Lakehouse-Plattform, heute nativ auf Azure mit enger Integration in Azure AD und Netzwerk.
Stärken:
- Technische Tiefe. Unity Catalog für Governance, Delta Sharing für organisationsübergreifenden Datenaustausch, MLflow für den ML-Lebenszyklus
- Performance. Die Photon Engine liefert konstant starke Query-Performance. Databricks führt regelmäßig TPC-Benchmarks an.
- Offene Standards. Delta Lake, MLflow und Apache Spark sind Open Source. Ihre Investition in Code und Skills ist portabel.
- Community und Ökosystem. Größte Spark-Community, umfangreiche Partner-Integrationen, ausführliche Dokumentation
Schwächen:
- Kostenkomplexität. DBU-basierte Preise mit unterschiedlichen Tarifen pro Workload-Typ. Kosten können ohne sorgfältiges Cluster-Management und Auto-Termination-Policies schnell eskalieren.
- Zwei Steuerungsebenen. Man verwaltet sowohl das Azure-Portal als auch den Databricks-Workspace. Das RBAC-Mapping zwischen beiden erfordert sorgfältiges Design.
- Power-BI-Integration. Funktional, aber nicht nahtlos. Direct-Lake-Modus ist nicht verfügbar; man benötigt Import oder DirectQuery.
Geeignet für: Organisationen mit starken Data-Engineering-Teams, die maximale Flexibilität, erstklassige ML-Unterstützung und offene Standards bevorzugen.
Azure Synapse Analytics
Microsofts Pre-Fabric-Analytics-Dienst, weiterhin verfügbar und supported.
Unsere ehrliche Einschätzung: Synapse befindet sich faktisch im Wartungsmodus. Microsofts Investitionen fließen in Fabric. Bestehende Synapse-Deployments funktionieren weiterhin, aber wir würden 2026 kein neues Greenfield-Projekt auf Synapse starten.
Wann es noch Sinn ergibt: Wenn Sie signifikante Synapse-Investitionen haben und keinen unmittelbaren Migrationsbedarf, betreiben Sie die Plattform weiter. Planen Sie eine Migration zu Fabric in Ihrem eigenen Tempo.
Entscheidungsmatrix
| Kriterium | Fabric | Databricks | Synapse |
|---|---|---|---|
| Time-to-Value | Schnell (assistentengestützt) | Mittel (mehr Setup) | Mittel |
| Engineering-Flexibilität | Mittel | Hoch | Mittel |
| ML/KI-Unterstützung | Wachsend | Erstklassig | Eingeschränkt |
| Governance | OneLake + Purview | Unity Catalog | Purview-Integration |
| Kostenvorhersagbarkeit | Hoch (Kapazitäts-SKU) | Niedriger (DBU-basiert) | Mittel |
| Power-BI-Integration | Hervorragend | Gut | Gut |
| Offene Standards | Teilweise | Stark | Teilweise |
| Greenfield-Empfehlung | Ja | Ja | Nein |
Delta Lake: Das gemeinsame Fundament
Unabhängig von der Plattform hat Delta Lake das Speicherformat-Rennen auf Azure gewonnen. Sowohl Fabric als auch Databricks nutzen es nativ. Die wichtigsten Enterprise-Features:
- ACID-Transaktionen — Keine beschädigten Datensätze durch fehlgeschlagene Schreibvorgänge mehr
- Time Travel — Frühere Versionen Ihrer Daten abfragen. Unverzichtbar für Debugging und Audit
- Schema-Enforcement und -Evolution — Fehlerhafte Daten aus der Silver-Schicht fernhalten, bei gleichzeitig kontrollierter Schemaänderung
- Z-Ordering und Data Skipping — Physische Optimierung, die Abfragezeiten bei großen Tabellen um das 10- bis 100-Fache reduzieren kann
Praxistipp: Implementieren Sie von Tag eins eine VACUUM-Policy. Ohne sie wächst die Time-Travel-Historie, und die Speicherkosten steigen unbemerkt. Unsere Empfehlung: 30 Tage Retention für Bronze, 7 Tage für Silver und Gold.
Governance: Der echte Differenzierungsfaktor
Daten-Governance ist der Bereich, in dem die Plattformwahl die tiefgreifendsten langfristigen Auswirkungen hat:
Microsoft Purview + Fabric
- Automatisches Metadaten-Scanning über OneLake
- Klassifizierung und Sensitivitäts-Labeling aus Microsoft 365 übernommen
- Lineage-Tracking über Fabric-Artefakte hinweg
- Lücke: Plattformübergreifendes Lineage (z. B. Datenfluss von Fabric zu Nicht-Microsoft-Tools) ist eingeschränkt
Databricks Unity Catalog
- Feingranulare Zugriffssteuerung auf Tabellen-, Spalten- und Zeilenebene
- Attributbasierte Zugriffskontrolle für dynamisches Data Masking
- Workspace-übergreifende Governance mit einem einzelnen Metastore
- Delta Sharing für governanten Datenaustausch mit externen Partnern
- Lücke: Erfordert Databricks Premium Tier; erhöht die Kosten deutlich
Kostenvergleich: Ein realistisches Szenario
Für eine mittelgroße Datenplattform (10 TB Rohdaten, 50 gleichzeitige Nutzer, 8 Stunden aktiv täglich):
| Komponente | Fabric (F64 Capacity) | Databricks + ADLS |
|---|---|---|
| Compute | ~6.000 €/Monat | ~8.000–12.000 €/Monat |
| Storage | In Kapazität enthalten | ~200 €/Monat (ADLS) |
| BI-Schicht | Enthalten (Power BI) | Power-BI-Pro-Lizenzen separat |
| Governance | Purview (separat) | Unity Catalog (Premium Tier) |
| Geschätzte Gesamtkosten | 7.000–8.000 €/Monat | 10.000–15.000 €/Monat |
Einschränkung: Dies sind Richtwerte. Die tatsächlichen Kosten hängen stark von Workload-Mustern, Cluster-Dimensionierung und Auto-Scaling-Konfiguration ab. Wir empfehlen dringend einen vierwöchigen Proof of Concept mit realistischen Workloads vor der Festlegung.
Unsere Empfehlungen
- Wenn Sie ein Microsoft-First-Haus mit starker Power-BI-Nutzung sind: Starten Sie mit Fabric. Die Integrationsvorteile sind real, und die Plattform reift schnell.
- Wenn Sie komplexe ML/KI-Workloads oder Multi-Cloud-Anforderungen haben: Wählen Sie Databricks. Die Engineering-Flexibilität und das Bekenntnis zu offenen Standards rechtfertigen die Mehrkosten.
- Wenn Sie heute auf Synapse sind: Beginnen Sie mit der Migrationsplanung zu Fabric. Das Migrationstooling verbessert sich, und je länger Sie warten, desto größer wird die Kluft zwischen den Plattformen.
- Unabhängig von der Plattform: Investieren Sie von Tag eins in Governance. Datenklassifizierung und Zugriffssteuerung nachzurüsten ist um ein Vielfaches aufwendiger, als sie von Anfang an einzubauen.
Erste Schritte
Bevor Sie sich für eine Plattform entscheiden, beantworten Sie diese Fragen:
- Wie viel Prozent Ihrer Analytics-Nutzer arbeiten mit Power BI vs. Notebooks vs. SQL?
- Haben Sie vorhandene Spark-/Python-Kompetenzen im Team?
- Ist Multi-Cloud eine aktuelle Anforderung oder ein theoretischer zukünftiger Bedarf?
- Wie sieht Ihre Positionierung zu Datenresidenz und -souveränität aus?
Die Antworten weisen klar auf eine Plattform hin. Falls nicht, sprechen Sie mit uns — Plattformauswahl gehört zu unseren häufigsten Beratungsmandaten, und in einem einwöchigen Assessment können wir in der Regel eine fundierte Empfehlung erarbeiten.