Glossar
Data

Data Mesh

Auch: Data Mesh architecture, decentralized data architecture

Data Mesh ist ein dezentraler Ansatz für Datenarchitektur und Organisation, bei dem Domänenteams ihre Daten besitzen und als Produkte bereitstellen, geregelt durch gemeinsame Standards.

Was es ist

Data Mesh ist ein soziotechnischer Ansatz für das Management analytischer Daten im großen Maßstab. Statt alle Daten in einem einzigen Warehouse oder Lake unter der Verantwortung eines einzelnen Teams zu zentralisieren, verteilt Data Mesh die Ownership auf die Fachdomänen, die die Daten am besten kennen. Eingeführt wurde der Ansatz von Zhamak Dehghani, er beruht auf vier Kernprinzipien:

  • Domänenorientierte Ownership: Jede Fachdomäne (zum Beispiel Payments, Marketing, Logistik) besitzt die Daten, die sie erzeugt und bereitstellt.
  • Data as a Product: Datensätze werden wie Produkte behandelt, mit klaren Ownern, Dokumentation, Qualitätszusagen und Blick auf die Consumer.
  • Self-Serve-Datenplattform: Eine gemeinsame Infrastruktur erlaubt es Domänenteams, Datenprodukte zu bauen, zu veröffentlichen und zu nutzen, ohne tiefe Platform-Engineering-Kenntnisse.
  • Federated Computational Governance: Globale Regeln (Security, Privacy, Interoperabilitätsstandards) werden zentral definiert, aber automatisch und lokal durchgesetzt.

Warum das wichtig ist

Zentrale Datenteams werden oft zum Engpass. Eine einzelne Plattformgruppe kann nicht den Kontext jeder Domäne verstehen, also wachsen die Backlogs und die Datenqualität leidet. Data Mesh setzt hier an, indem es Daten-Ownership mit Domänenexpertise zusammenbringt und so Skalierbarkeit, Verantwortlichkeit und Time to Insight verbessert. Am relevantesten ist das für große Organisationen mit vielen Domänen und hohem Volumen an Datenanfragen.

Wie es in der Praxis eingesetzt wird

  • Domänen definieren und klare Data Product Owner benennen.
  • Datenprodukte bauen mit auffindbaren Metadaten, definierten Service Level Objectives und standardisierten Zugriffsschnittstellen (oft APIs oder Tabellen in einem Katalog).
  • Eine Self-Serve-Plattform bereitstellen, die Storage, Pipelines, Zugriffskontrolle und Observability abdeckt.
  • Eine föderierte Governance-Gruppe aufsetzen, die domänenübergreifende Standards festlegt (Naming, Privacy-Tags, Interoperabilität).

Konkretes Beispiel

Ein Händler hat getrennte Teams für Orders, Inventory und Customer. Jedes Team veröffentlicht ein Datenprodukt: Orders stellt einen sauberen Datensatz "order_events" bereit, Customer stellt "customer_profile" bereit. Eine Marketing-Analystin findet beide Produkte in einem gemeinsamen Katalog, joint sie über standardisierte Customer IDs und baut ein Churn-Modell, ohne ein Ticket bei einem zentralen Datenteam einzureichen. Governance-Regeln maskieren automatisch personenbezogene Daten, für die sie keine Berechtigung hat.

Data Mesh ist ebenso sehr eine organisatorische wie eine technische Veränderung, der Erfolg hängt also von Kultur und Anreizen ab, nicht nur vom Tooling.

Data Mesh: Domains Own Data ProductsOrders Domainorder_eventsCustomer DomainprofilesInventory Domainstock_levelsSelf-Serve Platform + Shared CatalogFederated Governance (privacy, standards)
Domains publish data products onto a shared self-serve platform under federated governance.

Häufige Fragen

Was ist Data Mesh einfach erklärt?

Data Mesh ist ein dezentraler Ansatz für analytische Daten, bei dem jede Fachdomäne ihre eigenen Daten besitzt und als Produkt veröffentlicht, statt alles über ein zentrales Datenteam zu leiten. Eingeführt wurde er von Zhamak Dehghani und beruht auf vier Prinzipien: domänenorientierte Ownership, Data as a Product, eine Self-Serve-Datenplattform und Federated Computational Governance. Die Idee ist, Daten-Ownership bei den Leuten anzusiedeln, die den Kontext der Daten verstehen.

Welche Organisationen brauchen wirklich ein Data Mesh?

Data Mesh zahlt sich vor allem in großen Organisationen mit vielen Fachdomänen und hohem Volumen an Datenanfragen aus, wo ein einzelnes Plattformteam zum Engpass geworden ist. Wenn ein Team den Backlog abarbeiten kann und den Kontext jedes Datensatzes versteht, bleibt Zentralisierung einfacher und günstiger. Das Signal, auf das man achten sollte: eine wachsende Warteschlange an Anfragen bei gleichzeitig sinkender Datenqualität.

Was ist der Unterschied zwischen Data Mesh und einem Data Warehouse oder Data Lake?

Ein Data Warehouse oder Data Lake ist eine technische Entscheidung über Speicherung und Verarbeitung, Data Mesh ist ein Organisationsmodell dafür, wer Daten besitzt und bereitstellt. Ein Unternehmen kann Warehouses und Lakes behalten und trotzdem Data Mesh einführen, die Änderung besteht darin, dass jede Domäne ihren eigenen Teil betreibt und ihn als dokumentiertes Produkt bereitstellt, statt dass ein zentrales Team eine monolithische Plattform besitzt. Der Unterschied liegt in Ownership und Verantwortlichkeit, nicht in der Speichertechnologie.

Was macht aus einem Datensatz ein echtes Datenprodukt?

Ein Datenprodukt hat einen benannten Owner, auffindbare Metadaten in einem Katalog, Dokumentation, definierte Service Level Objectives und eine standardisierte Zugriffsschnittstelle, in der Regel eine API oder eine Tabelle. Data as a Product heißt, für die Consumer zu designen, statt eine Tabelle abzulegen und weiterzuziehen. Ohne Owner, Dokumentation und Qualitätszusagen haben Sie einen Datensatz, kein Datenprodukt.

Wie verhindert föderierte Governance, dass daraus Chaos wird?

Federated Computational Governance legt globale Regeln zentral fest, zu Security, Privacy und Interoperabilitätsstandards, und setzt sie dann automatisch in der Plattform jeder Domäne durch. Naming Conventions, Privacy-Tags und standardisierte Identifier machen domänenübergreifende Joins möglich, die Zugriffskontrolle maskiert personenbezogene Daten, für die ein Consumer keine Berechtigung hat. Domänen behalten Autonomie über die Inhalte, nicht über die Regeln.