Microsoft Fabric oder Databricks? Die Plattform muss zum Team passen

Welche Datenplattform würdet ihr empfehlen: Microsoft Fabric oder Databricks? Diese Frage begegnet uns in unseren Projekten immer wieder.

Die Frage lässt sich nicht pauschal beantworten. Mit beiden Plattformen können leistungsfähige analytische Datenarchitekturen aufgebaut werden. Der Unterschied liegt vor allem darin, welche Arbeitsweisen sie unterstützen und welche Anforderungen sie an die beteiligten Teams stellen.

Die Wahl der Datenplattform beeinflusst deshalb auch, wie Entwicklung, Governance und Betrieb innerhalb einer Organisation gestaltet werden. Um diese Unterschiede greifbar zu machen, betrachten wir die Plattformen anhand ihrer Entwicklungsansätze, Governance-Funktionen, BI-Integration und Kostenmodelle.

Wer eine Datenplattform aufbaut, entscheidet auch darüber, wie künftig auf ihr entwickelt wird. Ein zentrales Data-Engineering-Team mit etablierten Entwicklungsstandards stellt andere Anforderungen an seine Werkzeuge als Fachbereiche, die eigene Datenlösungen erstellen und weiterentwickeln möchten.

Hier zeigen sich die unterschiedlichen Wurzeln von Microsoft Fabric und Databricks. Fabric bringt zahlreiche Funktionen in einer gemeinsamen SaaS-Oberfläche zusammen und ermöglicht einen vergleichsweise einfachen Einstieg über grafische Werkzeuge. Databricks ist stärker aus dem Software- und Data-Engineering gewachsen und orientiert sich entsprechend an codebasierten Entwicklungsprozessen.

Beide Plattformen unterstützen inzwischen grafische und codebasierte Arbeitsweisen. Der Unterschied liegt vor allem darin, welche Ansätze im jeweiligen Produkt besonders stark verankert sind. Die wichtigsten technischen Möglichkeiten zeigt die folgende Übersicht.

Beim Deployment wird die unterschiedliche Ausrichtung besonders deutlich. Fabric bietet mit den integrierten Deployment Pipelines einen unkomplizierten Weg, um Artefakte zwischen Entwicklungs-, Test- und Produktivumgebungen zu übertragen. Gerade bei kleineren Anwendungen können damit ohne umfangreiche zusätzliche Infrastruktur strukturierte Deploymentprozesse etabliert werden.

Databricks verfolgt mit den Declarative Automation Bundles (ehemals Databricks Asset Bundles) einen stärker konfigurations- und codebasierten Ansatz. Neben den eigentlichen Skripten lassen sich auch Jobs, Pipelines und weitere Ressourcen als Teil eines versionierbaren Projekts definieren und automatisiert bereitstellen. Dieser Ansatz ist stark durch Ideen aus Infrastructure as Code geprägt.

Mit zunehmender Größe einer Datenlandschaft steigen die Anforderungen an die Verwaltung von Berechtigungen und Verantwortlichkeiten. Wenn zahlreiche Teams Daten bereitstellen und nutzen, müssen Zugriffsregeln konsistent umgesetzt werden. Die Plattformarchitektur beeinflusst, wie viel Aufwand dafür erforderlich ist.

Databricks bündelt viele Governance-Funktionen zentral im Unity Catalog. Besonders interessant ist die Möglichkeit, attributbasierte Zugriffsregeln zu definieren. Über Tags und Policies lassen sich beispielsweise Maskierungsregeln festlegen, die automatisch für bestimmte Daten gelten. Zentral verwaltete Regeln können von einzelnen Tabellenverantwortlichen nicht eigenständig umgangen werden.

Diese Flexibilität erzeugt zunächst administrativen Aufwand, da Tags und Policies eingerichtet und gepflegt werden müssen. Bei Hunderten Tabellen kann die zentrale Verwaltung den Aufwand jedoch erheblich reduzieren.

Fabric verfolgt einen stärker auf mehrere Komponenten verteilten Ansatz. Berechtigungen werden unter anderem über Rollen auf Artefaktebene und OneLake Security verwaltet. Ergänzende Governance-Funktionen stehen innerhalb der Plattform und über Microsoft Purview zur Verfügung.

Die Unterschiede zeigen sich insbesondere bei der zentralen Regelverwaltung und der automatisierten Data Lineage:

Für Organisationen mit vielen Datenbeständen und unterschiedlichen Verantwortlichen bietet Unity Catalog umfangreiche Möglichkeiten zur zentralen Durchsetzung von Governance-Regeln. Fabric überzeugt durch die Integration in das Microsoft-Ökosystem und einen vergleichsweise einfachen Einstieg in die Berechtigungsverwaltung.

Welche Lösung besser passt, hängt auch davon ab, wie die Verantwortung für Daten im Unternehmen verteilt ist. Eine zentral gesteuerte Datenplattform stellt andere Anforderungen als eine Umgebung, in der Fachbereiche weitgehend eigenständig arbeiten.

Die Integration einer semantischen Schicht funktioniert in Fabric durch Microsoft Power BI nahtlos. Semantische Modelle können zentral definiert und für unterschiedliche Berichte wiederverwendet werden. Mit Direct Lake lassen sich Delta-Tabellen aus OneLake performant analysieren, ohne sie zuvor vollständig in ein Importmodell laden zu müssen.

Dadurch bietet Fabric eine eng integrierte Umgebung von der Datenaufbereitung über die semantische Modellierung bis zur Visualisierung. Gerade für Unternehmen, die Power BI bereits umfangreich einsetzen, ist dies ein relevanter Vorteil.

Databricks bietet mit Dashboards mittlerweile ebenfalls eigene Möglichkeiten zur Visualisierung von Daten. Mit den Unity Catalog Metric Views steht zudem eine zentrale semantische Schicht zur Verfügung, über die Kennzahlen und Dimensionen definiert und wiederverwendet werden können.

Bei komplexeren Berichten zeigen sich allerdings Unterschiede. Während Power BI umfangreiche Möglichkeiten zur Modellierung und Wiederverwendung komplexer Datenmodelle bietet, konzentrieren sich Metric Views stärker auf die zentrale Definition und Bereitstellung von Kennzahlen. Databricks erweitert seine BI-Funktionen kontinuierlich, erreicht aus meiner Sicht aber noch nicht die Flexibilität und den Funktionsumfang von Power BI bei der Erstellung komplexer Berichte.

Für die Architekturentscheidung ist allerdings wichtig, dass eine Entscheidung für Databricks als Datenplattform keine Entscheidung gegen Power BI bedeuten muss. Beide Systeme lassen sich kombinieren, indem Databricks die Datenaufbereitung und -bereitstellung übernimmt, während Power BI für die semantische Modellierung und Visualisierung eingesetzt wird.

Auch eine gemeinsame Nutzung von Databricks und Fabric ist möglich. Azure Databricks kann Daten direkt in OneLake lesen und schreiben. Umgekehrt können Daten aus dem Databricks Unity Catalog über Mirroring und OneLake Shortcuts in Fabric verfügbar gemacht werden, ohne sie zusätzlich kopieren zu müssen.

Der parallele Betrieb erhöht allerdings die Anforderungen an die Abstimmung von Verantwortlichkeiten und Governance-Regeln. Besonders bei der gemeinsamen Nutzung von Daten muss sichergestellt werden, dass Berechtigungen plattformübergreifend konsistent umgesetzt werden.

Für Unternehmen mit bestehenden Datenplattformen lohnt es sich deshalb, die vorhandene Architektur in die Entscheidung einzubeziehen. Eine Kombination beider Plattformen kann sinnvoller sein als die vollständige Verlagerung aller Datenprozesse auf ein einzelnes Produkt.

Einer der wesentlichen Kostentreiber moderner Datenplattformen ist die benötigte Rechenleistung. Fabric und Databricks unterscheiden sich darin, wie diese bereitgestellt, abgerechnet und gesteuert wird.

Databricks verfolgt einen primär verbrauchsabhängigen Ansatz. Rechenressourcen können für unterschiedliche Workloads bereitgestellt und beispielsweise durch Compute Policies eingeschränkt werden. Die Abrechnung erfolgt über Databricks Units (DBUs). Beim klassischen Compute fallen zusätzlich Kosten für die zugrunde liegende Cloud-Infrastruktur an, während diese bei Serverless Compute bereits im DBU-Preis enthalten sind.

Fabric verwendet dagegen ein kapazitätsbasiertes Modell. Eine gebuchte Kapazität stellt eine bestimmte Anzahl an Capacity Units (CUs) bereit, die von unterschiedlichen Workloads gemeinsam genutzt werden. Durch Smoothing können Lastspitzen abgefangen werden. Bei dauerhafter Überlastung werden Prozesse gedrosselt oder verzögert.

Die unterschiedlichen Betriebsmodelle haben direkte Auswirkungen auf die Ressourcensteuerung:

Databricks ermöglicht durch dedizierte Compute-Ressourcen eine feingranulare Steuerung einzelner Workloads. Bei Fabric muss stärker auf die Gesamtauslastung der Kapazität geachtet werden, da sich unterschiedliche Anwendungen gegenseitig beeinflussen können.

Je nach Größe der Datenlandschaft empfehlen wir daher, bei Fabric unterschiedliche Kapazitäten für Datenverarbeitungsprozesse und Reporting der Fachbereiche zu prüfen. So lässt sich verhindern, dass rechenintensive oder unoptimierte Berichte die für alle Nutzer relevanten Ladeprozesse durch Überlastung behindern.

Das Kostenmodell beeinflusst damit auch die technische Organisation der Plattform. Welche Variante wirtschaftlicher ist, hängt von den konkreten Workloads und deren Auslastung ab. Eine pauschale Aussage lässt sich aus den unterschiedlichen Abrechnungsmodellen allein nicht ableiten.

Aus unserer Sicht lassen sich sowohl mit Microsoft Fabric als auch mit Databricks leistungsfähige analytische Datenplattformen aufbauen. Welche Plattform besser geeignet ist, hängt insbesondere von der Organisationsstruktur, den vorhandenen Kompetenzen und den Anforderungen an Entwicklung und Betrieb ab.

Die folgende Übersicht zeigt, welche Plattform bei typischen Ausgangssituationen besonders naheliegt:

Gerade im Mittelstand erleben wir häufig, dass pragmatische und schnell umsetzbare Lösungen einen hohen Stellenwert haben. Die Freiheiten innerhalb einzelner Fabric-Workspaces passen gut zu dieser Arbeitsweise. Teams können eigenständig Lösungen entwickeln, schnell erste Ergebnisse erzielen und den Mehrwert der Datenplattform frühzeitig aufzeigen.

Für zentral organisierte Data-Engineering-Teams mit hohen Anforderungen an einheitliche Entwicklungsprozesse und Governance bietet Databricks durch seinen code- und automatisierungsorientierten Ansatz Vorteile. Dies setzt entsprechende technische Kompetenzen und etablierte Entwicklungsstandards voraus.

Diese Zuordnung ist jedoch keine Frage der Unternehmensgröße allein. Auch mittelständische Unternehmen können komplexe Engineering-Anforderungen haben, während große Organisationen von den integrierten Möglichkeiten von Fabric profitieren.