Data Mesh auf Databricks: Domänen, Governance und Data Products
Die Kernaussagen auf einen Blick.
- Data Mesh ist weniger eine technische Architektur als eine Entscheidung darüber, wie Verantwortung für Daten in der Organisation verteilt wird. Databricks stellt mit Unity Catalog, Delta Sharing und getrennten Catalogs oder Workspaces die passenden technischen Bausteine bereit.
- Voraussetzung sind eine funktionierende Governance, klar benannte Verantwortliche und ein gemeinsames Verständnis davon, was ein Data Product ausmacht.
- Für die meisten Unternehmen ist ein schrittweiser Einstieg sinnvoll: zunächst zwei oder drei Domänen über eigene Unity-Catalog-Catalogs trennen und den Datenaustausch zwischen ihnen etablieren.
- Separate Workspaces sollten erst dann eingeführt werden, wenn organisatorische, regulatorische oder technische Gründe eine stärkere Isolation erfordern.
Inhaltsverzeichnis
Sieben Domain-Teams, eine zentrale Plattform: wo das Mesh-Thema aufkommt
Im Steering-Termin sitzen das Plattform-Team, die Datenverantwortlichen und Vertreter aus Vertrieb, Marketing und Finance. Die Fragen sind seit Monaten dieselben: Warum dauert es so lange, bis Marketing eine neue Customer-Sicht nutzen kann? Warum kopiert der Vertrieb Daten in ein eigenes Snowflake-System, weil der Zugriff über die zentrale Plattform zu aufwendig ist? Und warum existieren inzwischen drei unterschiedliche Definitionen des Umsatzes?
Solche Probleme entstehen häufig, wenn ein zentrales Datenteam mehr Fachbereiche betreuen soll, als es organisatorisch und technisch bewältigen kann. Die Alternative, Verantwortung vollständig an die Fachbereiche abzugeben, führt allerdings oft zu uneinheitlichen Standards und parallelen Lösungen.
Data Mesh versucht, zwischen diesen beiden Extremen einen praktikablen Weg zu schaffen: Die Fachdomänen übernehmen Verantwortung für ihre Daten und Datenprodukte, während ein zentrales Plattform-Team die gemeinsame technische und organisatorische Grundlage bereitstellt.
Für Databricks-Plattformen stellen sich dabei vor allem folgende Fragen:
Ist die Organisation bereits groß und dezentral genug für ein Data-Mesh-Modell? Sollten Domänen über Schemas, Catalogs oder separate Workspaces getrennt werden? Wer verantwortet ein Data Product fachlich und technisch? Welche Regeln werden zentral vorgegeben, und welche Entscheidungen treffen die Domänen selbst? Wie lassen sich Daten zwischen Domänen bereitstellen, ohne weitere Kopien zu erzeugen?
Data Mesh ist damit keine Funktion, die in Databricks aktiviert wird. Es ist ein Organisationsmodell, das mit den technischen Möglichkeiten der Plattform umgesetzt werden kann.
Was ist Data Mesh auf Databricks?
Data Mesh ist ein Organisationsmodell für Datenplattformen, das auf vier Grundprinzipien basiert: Domain Ownership (jede Fachdomäne besitzt ihre Daten), Data-Product-Denken (Daten werden wie Produkte mit Schema, SLA und Owner geliefert), Self-Service-Plattform (eine zentrale Foundation, die Domänen selbst nutzen) und Federated Governance (gemeinsame Regeln, dezentrale Umsetzung). Der Begriff stammt aus Zhamak Dehghanis Data Mesh Principles and Logical Architecture von 2020 und beschreibt zunächst ein organisatorisches Konzept.
Auf Databricks lässt sich dieses Organisationsmodell mit vier zentralen Komponenten umsetzen. Unity Catalog bildet die gemeinsame Governance-Schicht: ein zentrales Permission-Modell, eine durchgehende Lineage, Tag-basierte Policies (ABAC, also attributbasierte Zugriffskontrolle) und eine Catalog-Aufteilung pro Domäne. Delta Sharing ermöglicht den Austausch von Datenprodukten zwischen Catalogs, Workspaces oder sogar Cloud-Accounts. Domänen können über Workspaces oder Unity-Catalog-Catalogs voneinander getrennt werden. Mit Lakeflow Jobs und Asset Bundles können die Domänen ihre Pipelines selbst entwickeln und betreiben. Fehlen zentrale Plattformfunktionen, lässt sich das Modell nur eingeschränkt umsetzen. Ohne Unity Catalog entstehen beispielsweise schnell separate Berechtigungsmodelle und zusätzliche Datenkopien.
Eine einzelne Domäne folgt dabei immer demselben Grundriss: Quelldaten fließen über eine domäneneigene Self-Service-Compute- und Orchestrierungs-Schicht in zwei Ausgaben: Insights für Business-Nutzer und ein Data Product für andere Domänen. Die gesamte Domäne unterliegt dabei der Federated Governance über Unity Catalog, unabhängig davon, wie viele Domänen später im Mesh zusammenspielen.
Data Mesh wird auf Databricks durch das gezielte Zusammenspiel der vorhandenen Plattformkomponenten umgesetzt. Wie diese Komponenten in der Gesamtarchitektur zusammenspielen, ordnen wir in der Databricks Data Intelligence Platform ein.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Wann passt ein Data Mesh?
Data Mesh ist nicht für jede Plattform sinnvoll. Es lohnt sich, sobald drei Bedingungen zusammenkommen: Das zentrale Datenteam kann die Anforderungen der Fachdomänen nicht mehr zeitnah bearbeiten, die Domänen haben eigene Datenkompetenz und tragen ihre Daten ohnehin schon teilweise selbst, und die technische Plattform ist stabil genug, um von mehreren Teams parallel genutzt zu werden.
| Plattform-Situation | Mesh-Eignung |
|---|---|
| Ein bis zwei Domänen, ein Datateam, alles übersichtlich | Ein zentrales Modell ist in dieser Situation meist einfacher und schneller |
| Drei bis fünf Domänen, zentrales Datateam wird Engpass | Koordiniertes Modell: zentrale Plattform mit getrennten Schemas und schrittweise verteilter Verantwortung |
| Sechs und mehr Domänen, jede mit eigener Datenkompetenz | Federated Mesh: Domain-Catalogs in UC, Delta Sharing zwischen ihnen |
| Konzern mit eigenständigen Geschäftsbereichen, Multi-Cloud-Setup | Vollständiges Mesh: Multi-Workspace oder Multi-Account, Cross-Account Delta Sharing |
| Plattform ohne aktiven Unity Catalog | Mesh nicht starten, UC-Foundation zuerst |
| Domänen ohne Datenkompetenz, kein Data-Product-Owner-Modell | Die organisatorischen Voraussetzungen für Data Mesh sind noch nicht erfüllt, zuerst Datenkompetenz aufbauen |
Wird Data Mesh ohne diese Voraussetzungen eingeführt, entstehen häufig isolierte Teilplattformen und zusätzliche Abstimmungsprobleme. Gleichzeitig müssen nicht alle Voraussetzungen von Anfang an vollständig erfüllt sein. Ein koordiniertes Modell ist häufig ein sinnvoller Zwischenschritt.
Innerhalb der Coordinated- und Federated-Stufen unterscheidet Databricks zwei Grundmuster, beschrieben im Databricks-Leitfaden zum Mesh auf der Lakehouse-Plattform. Beim Harmonized Data Mesh tauschen die Domänen ihre Data Products direkt untereinander aus: Jede Domäne betreibt eigene Catalogs und eigene Pipelines, veröffentlicht Daten und Metadaten an einen zentralen Unity Catalog und konsumiert die Data Products der anderen Domänen direkt peer-to-peer, während die Plattform nur Standards und Templates vorgibt. Das passt, wenn die Domänen ähnlich erfahren sind und sich an die vereinbarten Standards halten. Beim Hub & Spoke Data Mesh gibt es dagegen einen zentralen Data Hub mit eigenem Unity Catalog, der die veröffentlichten Data Products mehrerer Domänen hält: Die Domänen-Spokes veröffentlichen Daten und Metadaten an den Hub und konsumieren von ihm, während in den Spokes selbst zunächst unveröffentlichte Data Products aus den Quelldaten entstehen. Federated Governance gilt in diesem Modell für Hub und Spokes gleichermaßen. Das Hub-&-Spoke-Muster passt, wenn die Domänen unterschiedlich weit sind oder das Plattform-Team zentrale Datasets wie Wetter, Wechselkurse oder Stammdaten selbst pflegt. In der Regel mischen Plattformen beide Modelle.
Workspaces, Catalogs oder Schemas?
Eine zentrale Frage ist, auf welcher Ebene die Domänen voneinander getrennt werden. Eine klare organisatorische und technische Abgrenzung der Domänen ist dabei grundsätzlich erforderlich. Databricks bietet dafür drei Ebenen mit unterschiedlich starker Isolation.
| Aufteilungs-Ebene | Was wird getrennt | Vorteil | Grenze | Wann passend |
|---|---|---|---|---|
| Workspaces | Compute, Workspace-Konfiguration, Benutzeroberfläche, optional UC-Metastore | Starke technische und organisatorische Trennung, eigene Compute-Policies, eigene Berechtigungen | Hoher operativer Aufwand, Cross-Workspace-Governance braucht UC-Federation oder Account-Level-Setup | Konzern-Domänen, regulierte Bereiche, Multi-Cloud-Setup |
| UC-Catalogs | Tabellen-Namespace, Permissions, Tags, Lineage-Sicht | Logische Trennung der Domänen im selben Workspace, einfaches Cross-Domain-Sharing über UC | Compute bleibt geteilt, Catalog-Berechtigungen müssen sauber modelliert sein | Geeignete Standardlösung für viele Databricks-Plattformen |
| Schemas innerhalb eines Catalogs | Tabellen-Namespace innerhalb der Domäne | Minimaler Aufwand, gute Übersicht | Nur begrenzte Trennung zwischen den Domänen, Permissions auf Schema-Ebene sind eine schwache Grenze | Sub-Domänen innerhalb einer Domäne, nicht für die Mesh-Aufteilung selbst |
Für viele Databricks-Plattformen ist eine Trennung über Catalogs der sinnvollste Ausgangspunkt: jede Domäne bekommt einen oder mehrere Catalogs, die Berechtigungen, Tags und Lineage darüber laufen über Unity Catalog. Workspaces bleiben als zusätzliche Trennungs-Ebene für Compute- oder Compliance-Trennung verfügbar; die Trennung über Catalogs sollte in der Regel vor einer Aufteilung auf mehrere Workspaces geprüft werden. Schemas eignen sich vor allem zur Strukturierung innerhalb einer Domäne.
Wie die Catalog-Aufteilung und die zugehörigen Berechtigungen konkret modelliert werden, ordnen wir im Überblick zu Unity Catalog ein.
Welche Rolle spielt Unity Catalog im Data Mesh?
Unity Catalog bildet die gemeinsame Governance-Grundlage für ein Data-Mesh-Modell auf Databricks. Berechtigungen, Lineage und Tags werden zentral verwaltet, während die Verantwortung für die Daten bei den einzelnen Domänen liegt. Ohne Unity Catalog fehlt eine gemeinsame Grundlage für domänenübergreifende Governance; die Domänen würden jede eigene Governance bauen. Dadurch würden schnell unterschiedliche Berechtigungsmodelle in den einzelnen Domänen entstehen.
Drei Funktionen von Unity Catalog sind für die Umsetzung besonders relevant:
Catalog-Hierarchie pro Domäne. Jede Domäne bekommt ein eigenes Catalog (z. B. marketing_prod, sales_prod, finance_prod), darin die Schemas für Bronze-, Silver- und Gold-Tabellen. Permissions werden auf Catalog- oder Schema-Ebene vergeben. Damit können die Domänen ihre Berechtigungen innerhalb des vorgegebenen Rahmens selbst verwalten, ohne dass die Plattform-Organisation jedes einzelne Datenobjekt freigeben muss.
Tags und ABAC für domänenübergreifende Zugriffsregeln. Über Tags werden Datenklassifikationen (PII, Finanzdaten, Customer-360-Quelle) auf Tabellen oder Spalten gesetzt. Attribute-Based Access Control (ABAC, also Zugriffsentscheidungen auf Basis dieser Tags) erlaubt domänenübergreifende Regeln, ohne dass die zentrale Plattform-Organisation jede neue Tabelle einzeln freischalten muss.
System Tables und Lineage über Domain-Grenzen. Unity Catalog ermöglicht eine gemeinsame Lineage-Sicht über mehrere Catalogs hinweg, auch wenn die Daten zwischen Domänen über Delta Sharing fließen. Das System-Tables-Schema gibt die zentrale Observability-Sicht auf Compute-Verbrauch, Audit-Events und Tabellen-Aktivität pro Domäne.
Lakehouse Federation ergänzt die Architektur um den direkten Lesezugriff auf externe Datenquellen: Tabellen aus Snowflake, BigQuery oder MySQL erscheinen lesbar im Catalog, ohne dass Daten kopiert werden müssen. Databricks dokumentiert für Lakehouse Federation die unterstützten Quellsysteme und die Authentifizierungs-Pfade. Für Mesh-Domänen, die historisch in einer anderen Plattform liegen, ermöglicht dies den Zugriff, ohne die Daten zunächst kopieren zu müssen.
Delta Sharing als Data-Product-Austausch zwischen Domänen
Ein Datenprodukt sollte sechs grundlegende Eigenschaften erfüllen: discoverable (über den Catalog auffindbar), addressable (eindeutige Adresse für programmatischen Zugriff), trustworthy (Schema, SLA und Datenqualität dokumentiert), self-describing (Semantik, Beispiele und Owner-Information sind Teil des Produkts), interoperable (folgt plattformweiten Standards für Schema-Konventionen und Tags) und secure (Zugriff über UC-Permissions und ABAC-Policies). Fehlen diese Eigenschaften, handelt es sich eher um eine technisch bereitgestellte Tabelle als um ein verlässlich nutzbares Datenprodukt.
Datenprodukte werden über geregelte Lesezugriffe zwischen den Domänen bereitgestellt. Zusätzliche Datenkopien können dadurch vermieden werden. Delta Sharing ist dafür der zentrale Bereitstellungsmechanismus auf Databricks: Delta Sharing ist ein offener Protokoll-Layer, mit dem eine Domäne (der Provider) Tabellen oder Views an andere Domänen (die Recipients) freigibt, ohne dass eine Kopie entsteht.
In der Praxis kann dies beispielsweise so aussehen: Wenn die Marketing-Domäne eine kuratierte Customer-360-Tabelle hat, gibt sie diese als Delta Share an die Vertriebs- und die Service-Domäne frei. Beide konsumierenden Domänen greifen auf dieselbe freigegebene Datenquelle zu, sehen die gleiche Lineage, und die erwartete Struktur des Datenprodukts (Spalten, Datentypen, Nullability) sollte zusätzlich verbindlich dokumentiert werden. Aktualisiert die Marketing-Domäne das Data Product, stehen Änderungen den konsumierenden Domänen unmittelbar zur Verfügung.
Delta Sharing funktioniert auf drei Reichweiten:
Innerhalb eines Workspaces zwischen Catalogs. Einfachste Variante für den Datenaustausch innerhalb einer gemeinsamen Plattform. Permissions laufen über UC, ohne extra Setup.
Zwischen Workspaces im selben Account. Sinnvoll bei harter Workspace-Trennung pro Domäne. Provider und Recipient sind beide in Databricks, Setup über UC-Metastore-Verbindung.
Cross-Account oder Open Sharing. Data Product geht an einen Recipient außerhalb des eigenen Databricks-Accounts (Partner, Tochterfirma, andere Cloud). Hier kommt der offene Delta-Sharing-Standard zum Tragen.
Ohne einen geregelten Sharing-Mechanismus entstehen schnell mehrere Kopien desselben Datenbestands: jede Domäne pflegt eigene Replikate der Customer-360-Sicht, die verschiedenen Kopien entwickeln sich mit der Zeit auseinander, und das Mesh produziert genau das Problem, das es lösen sollte. Delta Sharing ermöglicht einen kontrollierten Zugriff auf das Datenprodukt; Anforderungen an Schema, Qualität und Änderungen müssen zusätzlich organisatorisch vereinbart werden.
Lakeflow und Asset Bundles
Für die Pipelines eines Datenprodukts muss eine klare Verantwortung bestehen. Lakeflow Jobs und Asset Bundles unterstützen die Domänen dabei, ihre Pipelines eigenständig zu entwickeln und zu betreiben. Lakeflow ist die Pipeline-Orchestrierungs-Schicht (Jobs, Pipelines, Trigger), Asset Bundles beschreiben die zugehörigen Ressourcen und Deployments als Code.
Im Mesh-Setup heißt das: Jedes Domänenteam kann seine Pipelines in einem eigenen Repository verwalten, mit eigenen CI/CD-Pipelines, eigenem Job-Cluster-Profil und eigener Verantwortung für Datenqualität, Tests und Deployment. Das Plattform-Team stellt dafür Standards, Vorlagen und Compute-Richtlinien bereit.
Drei Bausteine sind für die praktische Umsetzung besonders wichtig:
Pro Domäne ein Asset-Bundle-Repo. Jede Domäne hat ihr Git-Repo mit den Bundle-Definitionen für ihre Pipelines, Jobs, Notebooks und SQL-Queries. CI/CD läuft pro Domäne unabhängig.
Job-Cluster-Policies pro Domäne. Die Plattform-Organisation gibt Cluster-Policy-Klassen vor (Compute-Größe, Photon-Default, Library-Allowlist), die Domänenteams erstellen ihre Cluster auf Grundlage dieser Richtlinien. So bleibt Compute-Governance zentral, Pipeline-Bau dezentral.
Eigene Datenqualitäts-Schicht pro Domäne. Lakeflow erlaubt Expectations auf Tabellen-Ebene (fail, drop, warn). Jede Domäne definiert ihre eigenen Qualitäts-Schwellen für ihre Data Products. Innerhalb gemeinsamer Mindeststandards können die Domänen eigene Qualitätsregeln definieren.
Ohne klare Standards und Verantwortlichkeiten wird lediglich der Code verteilt, nicht aber die Verantwortung für den Betrieb. Das Ergebnis sind sonst verteilte Pipelines ohne einheitliche Governance.
Rollen und Verantwortung im Mesh
Ohne klar definierte Rollen bleibt Data Mesh eine technische Struktur ohne eindeutige Verantwortung. Drei Rollen sind für das Organisationsmodell besonders wichtig:
Domain Owner. Verantwortet die Fachlichkeit einer Domäne (Marketing, Vertrieb, Finance), entscheidet welche Daten als Data Products freigegeben werden und in welcher Qualität. Sitzt meist in der Fachorganisation.
Data-Product-Owner. Verantwortet ein konkretes Data Product innerhalb einer Domäne: Schema, SLA, Verfügbarkeit, Versionierung, Backward-Kompatibilität. Die fachliche und technische Verantwortung kann dabei auf zwei Personen verteilt sein: ein Fachvertreter (Was ist drin?) plus eine technische Person aus dem Engineering (Wie wird es geliefert?).
Plattform-Team. Verantwortet die Foundation: Unity Catalog Metastore, Compute-Policies, Bundle-Standards, Tag-Hierarchie, CI/CD-Vorlagen, Cost-Reporting. Liefert die Plattform, auf der Domänen ihre Pipelines bauen. Die Pipelines selbst bleiben bei den Domänen.
Entscheidend ist, wie Aufgaben und Entscheidungsbefugnisse zwischen Plattform-Team und Domänen verteilt werden: Das Plattform-Team definiert die verbindlichen Standards und Rahmenbedingungen (Governance, Compute-Policy, Bundle-Schema), Domänen entscheiden alles andere selbst. Sind diese Zuständigkeiten nicht eindeutig geregelt, entsteht entweder ein Plattform-Team, das erneut zum zentralen Engpass wird, oder Domänen, die voneinander unabhängige technische Lösungen entwickeln.
Asset Bundles, Cluster-Policies und Tag-Hierarchien sind die Werkzeuge, mit denen das Plattform-Team verbindliche Rahmenbedingungen umsetzt, ohne in die Domain-Arbeit einzugreifen. Wie diese Werkzeuge im Detail funktionieren, klären wir im Überblick zu Databricks Data Engineering.
Wie führt man ein Data Mesh schrittweise ein?
Eine vollständige Einführung in einem einzigen Schritt ist meist nicht sinnvoll. Ein schrittweises Vorgehen kann in vier Phasen erfolgen, jede mit klarem Erfolgskriterium:
Stufe 1: UC-Foundation prüfen. Unity Catalog muss aktiv sein, der Metastore steht, Tags und ABAC sind eingerichtet. System Tables liefern saubere Compute- und Audit-Daten. Ohne diese Foundation ist ein Data Mesh nicht tragfähig.
Stufe 2: Zwei Pilot-Domänen mit Catalog-Aufteilung. Zwei Fachdomänen bekommen eigene Catalogs, einen Domain Owner und einen Data-Product-Owner pro Domäne. Eine kuratierte Tabelle pro Domäne wird als Data Product definiert (Schema, SLA, Owner), Delta Sharing zwischen den beiden Domänen aufgesetzt. Erfolgskriterium: beide Domänen können ihre Pipelines unabhängig deployen und ihr Data Product austauschen.
Stufe 3: Coordinated Mesh über drei bis fünf Domänen. Die Pilot-Erkenntnisse werden in Bundle-Templates, Cluster-Policies und Tag-Standards überführt. Weitere Domänen werden mit demselben Muster onboardet. Die Plattform-Organisation stellt die Foundation, die Domänen die Pipelines.
Stufe 4: Federated Mesh mit Workspace-Trennung. Erst wenn die Plattform organisatorisch und technisch ausreichend ausgereift ist und einzelne Domänen Compute-Isolation oder Compliance-Trennung brauchen, wird die Aufteilung auf separate Workspaces eingeführt. Cross-Workspace-Governance läuft über UC-Metastore-Verbindung, Cross-Account Delta Sharing für externe Recipients.
Was Data Mesh auf Databricks allein nicht löst
Data Mesh adressiert vor allem die Verteilung von Verantwortung in wachsenden Datenorganisationen, aber nicht jede Plattform-Frage. Mehrere angrenzende Themen werden dadurch jedoch nicht automatisch gelöst:
- Den plattformneutralen Blick auf das Mesh-Konzept (Methodik der Domänen-Aufteilung, Data-Product-Definition, Operating-Model-Patterns ohne Databricks-Bezug) liefert der Überblick zu Data Mesh in der Governance-Strategie.
- Die Governance-Plane unter dem Mesh und wie Permissions, Lineage und ABAC im Detail laufen, vertiefen wir im Überblick zu Unity Catalog.
- Die Datenmodell-Frage unter dem Mesh (Bronze/Silver/Gold-Schichtung, Star-Schema, Pipeline-Aufteilung) ordnen wir im Überblick zu Databricks Data Engineering ein.
Data Mesh setzt eine stabile technische und organisatorische Grundlage voraus und ersetzt diese Foundation nicht. Diese Grundlage entsteht durch das Zusammenspiel der verschiedenen Databricks-Komponenten.
Grenzen
Data Mesh kann Organisationen dabei unterstützen, Verantwortung auf mehrere Domänen zu verteilen. Es kann Zuständigkeiten klarer regeln und entlastet das zentrale Datateam, wenn die Vorbedingungen stimmen. Für mehrere Plattform-Probleme reicht es allein nicht aus.
Es löst kein Datenkompetenz-Problem
Ein Data Mesh erfordert, dass jede Domäne mindestens einen Data-Product-Owner stellen kann, der Schema, SLA und Qualitäts-Schwellen verantwortet. Fehlende Datenkompetenz in den Fachdomänen lässt sich damit nicht ausgleichen. Der bisherige Engpass wird sonst lediglich vom zentralen Datenteam in die Fachdomänen verlagert.
Es ersetzt kein Plattform-Team
Auch in einem dezentralen Modell bleibt ein zentrales Plattform-Team erforderlich, für UC-Metastore, Cluster-Policies, Bundle-Standards, Cost-Reporting und Sicherheits-Audits. Sobald das Plattform-Team eingespart und die Verantwortung an die Domänen verteilt wird, entstehen sechs konkurrierende Plattform-Setups.
Es macht aus schlechten Datenmodellen keine Data Products
Ein ungeeignetes Datenmodell wird nicht allein durch einen Owner oder ein Label zu einem Datenprodukt. Schema-Stabilität, Backward-Kompatibilität, dokumentierte Semantik und definierte SLAs gehören dazu. Ohne verbindliche Qualitäts- und Dokumentationsstandards werden bestehende Rohdaten lediglich als Datenprodukte bezeichnet.
Es löst keine Cost-Allocation-Frage automatisch
Die System Tables zeigen Compute-Verbrauch pro Workspace, Cluster und Job. Auch die verursachungsgerechte Zuordnung der Plattformkosten muss separat geregelt werden, über konsistente Tag-Vergabe in den Cluster-Policies und ein aktives Cost-Reporting. Ohne diese Disziplin trägt das Plattform-Team die Compute-Rechnung, die eigentlich pro Domäne aufgeschlüsselt gehört.
Es ist keine Architektur-Entscheidung gegen zentrale Plattformen
Zentrale und dezentrale Organisationsformen lassen sich miteinander kombinieren. Coordinated Mesh (zentrale Foundation, dezentrale Pipelines, Catalog-Aufteilung ohne Workspace-Trennung) ist für die meisten mittelständischen Plattformen die richtige Position auf diesem Spektrum.
Das Modell funktioniert, wenn Verantwortlichkeiten, Datenkompetenz und technische Plattform aufeinander abgestimmt sind. Sobald die Plattform den ETL-Bestand systematisch klassifiziert und die Domain-Verantwortung an dafür geeignete Personen vergibt, lässt sich Data Mesh als klar geregeltes Organisationsmodell betreiben.
Sobald operative Maßnahmen daran hängen, gehört die Mesh-Entscheidung in einen quartalsweisen Plattform-Review: Welche Domänen sind onboardet, welche Datenprodukte werden zuverlässig genutzt und betrieben, an welchen Stellen funktionieren die gemeinsamen Governance-Regeln noch nicht, in welchen Bereichen steigen die Compute-Kosten stärker als erwartet.
Fazit
Data Mesh auf Databricks lohnt sich, sobald eine Plattform mehrere Domain-Teams mit eigener Datenkompetenz trägt und das zentrale Datenteam die Anforderungen der Fachdomänen nicht mehr zeitnah bearbeiten kann.
Besonders relevant ist das für mittelständische und Enterprise-Plattformen mit drei oder mehr produktiven Domänen, einer stabilen Unity-Catalog-Foundation und einer Organisation, die bereit ist, Verantwortung für Data Products in die Fachdomänen zu geben.
Gute Kandidaten für eine bewusste Mesh-Einführung sind:
Plattformen ohne aktive Unity-Catalog-Foundation, ohne Data-Product-Owner-Modell oder mit weniger als drei produktiven Domänen sollten Mesh nicht als nächstes Projekt priorisieren. Zentral bleibt in dieser Situation schneller, billiger und besser steuerbar.
Das Plattform-Team bleibt für die technische Grundlage und die gemeinsamen Standards verantwortlich, die Domänen für ihre Data Products. Wenn diese Verantwortlichkeiten eindeutig geregelt sind, wird Data Mesh zu einem praktisch umsetzbaren Organisationsmodell auf einer bereits stabilen technischen Plattform.
Empfehlenswert ist eine schrittweise Einführung: mit zwei Pilot-Domänen über UC-Catalogs starten, Delta Sharing für den kontrollierten Datenaustausch einsetzen, und separate Workspaces erst dann einführen, wenn eine stärkere Isolation tatsächlich erforderlich ist.
Ist Data Mesh das richtige Operating-Model für eure Plattform-Größe?
Ob Data Mesh für eure Plattform-Größe das richtige Operating-Model ist, lässt sich in einem ersten Data & AI Operating-Model Review gut einordnen.
- welche Domänen heute schon Datenkompetenz und Data-Product-Reife tragen
- welche Foundation-Lücken (UC-Setup, Cluster-Policies, Tag-Hierarchie) vor der Mesh-Aufteilung geschlossen werden müssen
- welcher Aufteilungs-Pfad (Catalog, Workspace, Coordinated, Federated) für eure Plattform trägt
FAQ
Data Mesh ist ein Operating-Model mit vier Prinzipien: Domain Ownership, Data-Product-Denken, Self-Service-Plattform und Federated Governance. Auf Databricks wird es über Unity Catalog als Governance-Plane, Delta Sharing als Data-Product-Austausch, Workspaces oder Catalogs als Domänen-Aufteilung und Lakeflow plus Asset Bundles als Pipeline-Ownership umgesetzt. Mesh ist eine bewusste Konfiguration der vorhandenen Plattform-Komponenten.
