Data Mesh: Eine dezentrale Datenarchitektur entwerfen

Von Zhamak Dehghani

Data Mesh = verteile Architekturen auch für das Datenmanagement!

• Aus erster Hand: Die Autorin ist die Begründerin des innovativen Data-Mesh-Konzepts
• Von traditionellen Data Warehouses und Data Lakes hin zum dezentralen Data Mesh
• Das Buch zeigt, wie Data-Mesh-Architekturen sowohl organisatorisch als auch technisch implementiert werden

Wir befinden uns an einem Wendepunkt im Umgang mit Daten. Unser bisheriges Datenmanagement wird der Komplexität der Organisationsstrukturen, der immer zahlreicheren Datenquellen und dem steigenden Interesse am Einsatz von künstlicher Intelligenz nicht mehr gerecht. In diesem praxisorientierten Buch führt die Autorin Zhamak Dehghani in Data Mesh ein, ein dezentrales soziotechnisches Paradigma basierend auf Konzepten moderner verteilter Architekturen. Data Mesh ist ein neuer Ansatz für die Beschaffung, Bereitstellung, den Zugriff und die Verwaltung analytischer Daten, der auch skaliert.
Zhamak Dehghani begleitet Softwarearchitekt:innen, Entwickler:innen und Führungskräfte auf ihrem Weg von einer traditionellen, zentralen Big-Data-Architektur hin zu einer verteilten, dezentralen Organisationsstruktur für die Verwaltung analytischer Daten. Dabei behandelt Data Mesh Daten als Produkt, ist stark domänengetrieben und zielt auf eine Self-Serve-Datenplattform ab. Das Buch erläutert technische Migrationsstrategien, aber auch den organisatorischen Wandel hin zu neuen Teamstrukturen, Rollen und Verantwortlichkeiten, die mit dezentralen Architekturen einhergehen.

• Sprache: Deutsch
• Herausgeber: O'Reilly
• Erscheinungsdatum: 11. Feb. 2023
• ISBN: 9783960107255

Buchvorschau

TEIL I

Was ist Data Mesh?

Die einzige Einfachheit, der man vertrauen kann, ist die Einfachheit, die man auf der anderen Seite der Komplexität findet.

– Alfred North Whitehead

Wenn man sich die Umsetzung von Data Mesh anschaut, wie im Beispiel von Daff, Inc. zu Beginn des Buchs, bekommt man einen Eindruck von der technischen und organisatorischen Komplexität, die für die Implementierung erforderlich ist. Wir könnten wahrscheinlich eine ganze Weile über diese komplexen und komplizierten Teile der Data-Mesh-Implementierung sprechen. Um Data Mesh zu verstehen, möchte ich es stattdessen ausgehend von seinen Grundprinzipien diskutieren. Sobald wir die wesentlichen Elemente verstanden haben, können wir sie von Grund auf neu zusammensetzen, um die Implementierungen zu erstellen.

Auf diese Weise werde ich Ihnen in diesem Teil des Buchs Data Mesh vorstellen, wobei ich mich auf die Grundprinzipien und ihre Wechselwirkung untereinander konzentriere.

Bei diesen Grundprinzipien handelt es sich um Leitlinien und Werte, die das Verhalten, die Struktur und die Entwicklung der Implementierungen bestimmen. Meine Absicht für diesen Teil des Buchs ist es, eine Grundlage zu schaffen, die eine Basis für zukünftige Verfeinerungen von Praktiken und Technologien bietet.

Man sollte bedenken, dass dieses Buch zu einer Zeit geschrieben wird, in der sich Data Mesh zweifellos noch in der Innovations- und Early-Adopter-Phase des Innovationszyklus befindet.¹ Es ist in einer Phase, in der risikofreudige Innovatoren es aufgegriffen haben und bereits dabei sind, Tools und Technologien dafür zu entwickeln, und prominente Early Adopters passen ihre Datenstrategie und -architektur nach dem Vorbild von Data Mesh an. Daher finde ich es angemessen, zunächst die Prinzipien und den architektonischen Stil von Data Mesh zu erläutern und die spezifischen Implementierungsdetails und Technologien im Laufe der Zeit zu verfeinern und zu entwickeln. Ich gehe davon aus, dass jeder spezifische Implementierungsentwurf oder Tooling-Vorschlag zu dem Zeitpunkt, zu dem Sie dieses Buch lesen werden, bereits überholt sein wird.

Ich habe diesen Teil in fünf Kapitel gegliedert. Kapitel 1, »Data Mesh im Überblick«, gibt Ihnen einen kurzen Überblick über die vier Grundprinzipien und ihr Zusammenspiel. Die folgenden Kapitel konzentrieren sich dann jeweils auf eines der Prinzipien: Kapitel 2, »Das Prinzip Domain Ownership«, Kapitel 3, »Das Prinzip Data as a Product«, Kapitel 3, »Das Prinzip Self-Serve Data Platform«, und Kapitel 5, »Das Prinzip Federated Computational Governance«.

Die Reihenfolge, in der die Prinzipien eingeführt werden, ist wichtig, da sie aufeinander aufbauen. Die domänenorientierte Aufteilung von Data Ownership und Architektur ist das Herzstück des Ansatzes. Alles andere ergibt sich daraus. Data Mesh besteht aus allen vier Prinzipien.

Ich schlage vor, dass alle, die daran interessiert sind, Data Mesh zu verstehen oder anzuwenden, diesen Teil lesen. Ich hoffe, dass das, was dieser Teil bietet, jedes Gespräch über Data Mesh bereichern wird.

KAPITEL 1

Data Mesh im Überblick

»Think in simples«, wie mein alter Meister zu sagen pflegte – das bedeutet, das Ganze in einfachsten Worten auf seine Teile zu reduzieren und zu den Grundprinzipien zurückzukehren.

– Frank Lloyd Wright

Data Mesh ist ein dezentraler soziotechnischer Ansatz für die Bereitstellung, den Zugriff und die Verwaltung von analytischen Daten in komplexen und großen Umgebungen – innerhalb eines Unternehmens oder organisationsübergreifend.

Data Mesh ist ein neuer Ansatz für die skalierbare Beschaffung, Verwaltung und den Zugriff auf Daten für analytische Anwendungsfälle. Diese Art von Daten bezeichnen wir als analytische Daten. Analytische Daten werden für Voraussagen oder Diagnosen verwendet. Sie bilden die Grundlage für Visualisierungen und Berichte, die Einblicke in das Unternehmen geben. Sie werden verwendet, um Machine-Learning-Modelle für fachliche Entscheidungen zu trainieren. Sie sind die wesentliche Voraussetzung dafür, dass Unternehmen weg von Intuition und Bauchgefühl hin zu objektiven und datengestützten Entscheidungen gelangen. Analytische Daten sind die Grundlage für die Software und die Technologie der Zukunft. Sie ermöglichen einen technologischen Wandel von regelbasierten Algorithmen, die von Menschen entwickelt wurden, hin zu datenbasierten Machine-Learning-Modellen. Analytische Daten werden zu einer immer wichtigeren Komponente der Technologielandschaft.

Ergebnisse

Um aus Daten in komplexen und großen Organisationen einen Mehrwert erzielen zu können, zielt Data Mesh darauf ab, die folgenden Ergebnisse zu erreichen:

Auf Veränderungen reagieren: Komplexität, Volatilität und Ungewissheit.

Agilität trotz Wachstum erhalten.

Das Kosten-Nutzen-Verhältnis von Daten und Investitionen verbessern.¹

Veränderungen

Data Mesh bringt mehrdimensionale technische und organisatorische Veränderungen gegenüber früheren Ansätzen für analytisches Datenmanagement mit sich.

Abbildung 1-1 fasst die Veränderungen im Vergleich zu früheren Ansätzen zusammen.

Data Mesh erfordert einen grundlegenden Wandel in den Annahmen, der Architektur, den technischen Lösungen und der sozialen Struktur unserer Organisationen in der Art und Weise, wie wir analytische Daten verwalten und nutzen:

Organisatorisch gesehen, erfolgt eine Veränderung von einer zentralen Data Ownership durch Spezialisten, die auch die Datenplattform betreiben, hin zu einem dezentralen Modell, das die Verantwortung für die Daten in die Domänen zurückverlagert, aus denen sie stammen oder in denen sie verwendet werden.

Architektonisch gesehen, erfolgt eine Veränderung von der Speicherung von Daten in monolithischen Data Warehouses und Data Lakes hin zur Verknüpfung von Daten über ein verteiltes Mesh von Datenprodukten, auf die über standardisierte Protokolle zugegriffen werden.

Technologisch gesehen, erfolgt eine Veränderung von Lösungen, bei denen die Daten als Nebenprodukt der Pipelines betrachtet werden, hin zu Lösungen, die die Daten und den Code als eine zusammengehörige autonome Einheit verstehen.

Operativ gesehen, erfolgt eine Veränderung von einem zentralisierten, operativen Top-down-Modell mit menschlichen Eingriffen hin zu einem föderalen Modell, bei dem automatisierte Policies in das Mesh eingebettet sind.

Konzeptionell gesehen, erfolgt eine Veränderung unseres Wertesystems weg von Daten als Assets, die gesammelt werden, hin zu Daten als Produkte, die internen und externen Datennutzern zur Verfügung stehen und sie glücklich machen.

Infrastrukturell gesehen, erfolgt eine Veränderung von zwei getrennten und kaum integrierten Infrastrukturdiensten (einmal für Datenanalysen und einmal für operative Systeme) hin zu einer integrierten Infrastruktur für sowohl operative als auch analytische Systeme.

Abbildung 1-1: Dimensionen der Veränderung

Seit der Einführung von Data Mesh in meinem ursprünglichen Blogpost (https://oreil.ly/1deXz) (freundlicherweise gehostet von Martin Fowler (https://oreil.ly/ybdAb)) ist mir aufgefallen, dass sich manche Menschen schwertun, das Konzept zu klassifizieren. Ist Data Mesh eine Architektur? Handelt es sich um eine Liste von Prinzipien? Ist es ein Betriebsmodell? Schließlich stützen wir uns auf die Klassifizierung von Mustern² als eine wichtige kognitive Funktion, um die Struktur unserer Welt zu verstehen. Daher habe ich mich entschlossen, Data Mesh als ein soziotechnisches Paradigma zu klassifizieren: ein Ansatz, der die Wechselwirkungen zwischen Menschen und der technischen Architektur mit den Lösungen in komplexen Organisationen betrachtet. Dies ist ein Ansatz für das Datenmanagement, der nicht nur die technische Exzellenz von Lösungen für die Bereitstellung von analytischen Daten optimiert, sondern auch die User Experience aller Beteiligten wie beispielsweise Datenanbietern und Datennutzern verbessert.

Data Mesh kann als Bestandteil einer unternehmensweiten Datenstrategie eingesetzt werden, die den Zielzustand sowohl der Unternehmensarchitektur als auch eines organisatorischen Betriebsmodells mit einem iterativen Vorgehensmodell beschreibt.

In der einfachsten Form kann es durch vier zusammenwirkende Prinzipien beschrieben werden. In diesem Kapitel werde ich eine sehr kurze Definition dieser Prinzipien und ihres Zusammenwirkens geben.

Prinzipien

Die Grundlage der logischen Architektur und des Betriebsmodells von Data Mesh lässt sich anhand von vier einfachen Prinzipien festmachen. Diese Prinzipien sollen uns helfen, die Ziele von Data Mesh zu erreichen: Mehrwert aus Daten in großen Unternehmen zu ziehen, die Agilität eines wachsenden Unternehmens zu erhalten und auf Veränderungen in einer komplexen und unbeständigen Geschäftswelt zu reagieren.

Im Folgenden finden Sie eine kurze Zusammenfassung der Prinzipien.

Domain Ownership

Das bezeichnet die Dezentralisierung der Ownership von analytischen Daten auf die fachlichen Domänen, die am besten mit den Daten vertraut sind – entweder die Datenquelle oder die Hauptnutzer der Daten. Die (analytischen) Daten werden logisch anhand der jeweiligen Domänengrenzen zerlegt und unabhängig verwaltet.

Die Architektur und Organisation von Fachlichkeit, Technologie und analytischen Daten werden angeglichen.

Die Motivationen für Domain Ownership sind:

Die Fähigkeit, die Bereitstellung von Daten entsprechend dem Unternehmenswachstum zu skalieren: immer mehr Datenquellen, immer mehr Datenkonsumenten und immer vielfältigere Anwendungsfälle für Daten.

Eine Optimierung für den kontinuierlichen Wandel durch Lokalisierung der Veränderungen in die Domänen.

Agilität durch weniger teamübergreifende Abstimmungen und Beseitigung zentralisierter Engpässe bei Datenteams, Warehouses und Data-Lake-Architekturen.

Bessere Datenqualität, da die Datenherkunft und Nutzung der Daten für analytische Anwendungsfälle näher zusammenrücken.

Erhöhung der Resilienz von Analyse- und Machine-Learning-Lösungen durch Abschaffung komplexer zwischengeschalteter Daten-Pipelines.

Data as a Product

Nach diesem Prinzip werden die domänenorientierten Daten als Produkt direkt den Datennutzenden (Data Analysts, Data Scientists usw.) zur Verfügung gestellt.

Ein Datenprodukt muss eine Reihe von Usability-Merkmalen erfüllen:

auffindbar

adressierbar

verständlich

vertrauenswürdig und wahrheitsgetreu

nativ zugreifbar

interoperabel und kombinierbar

eigenständig wertvoll

sicher

Ein Datenprodukt bietet eine Reihe von explizit definierten und einfach zu verwendenden Verträgen über die Bereitstellung von Daten. Jedes Datenprodukt ist autonom, und sein Lebenszyklus und sein Datenmodell werden unabhängig von anderen Datenprodukten verwaltet.

Das Prinzip Data as a Product führt ein neues Element der logischen Architektur ein: das Datenquantum. Ein Datenquantum steuert und kapselt alle strukturellen Komponenten, die für die gemeinsame Bereitstellung von Daten als Produkt erforderlich sind – Daten, Metadaten, Code, Policies und die Deklaration von Infrastrukturabhängigkeiten – auf autonome Weise.

Die Ziele des Prinzips Data as a Product sind:

Eine Änderung der Beziehung zwischen Teams und Daten. So soll die Entstehung von Datensilos innerhalb der Domänen verhindert werden. Daten werden zu einem Produkt, das die Teams für andere bereitstellen, anstatt sie lediglich in ihrem privaten Silo zu sammeln.

Die Schaffung einer datengetriebenen Innovationskultur. Das Finden und Nutzen hochwertiger Daten wird direkt und ohne Hindernisse ermöglicht.

Die Schaffung von Resilienz gegenüber Veränderungen. Durch die Isolierung von Datenprodukten während der Build- und Laufzeit und durch explizit definierte Verträge über die Bereitstellung von Daten führt die Änderung eines Datenprodukts nicht zu einer Destabilisierung der anderen Datenprodukte.

Die Erzielung eine höhere Wertschöpfung aus Daten. Daten werden über Organisationsgrenzen hinweg bereitgestellt und genutzt.

Self-Serve Data Platform

Dieses Prinzip führt zu einer neuen Generation von Diensten der Self-Service-Datenplattform, die es den Domänenteams ermöglichen, Daten bereitzustellen. Die Plattformdienste zielen darauf ab, Hindernisse bei der Bereitstellung von Daten zu beseitigen, von der Datenquelle bis zur Nutzung. Die Plattformdienste managen den gesamten Lebenszyklus der einzelnen Datenprodukte. Sie verwalten ein zuverlässiges Netz aus miteinander verbundenen Datenprodukten. Sie schaffen Mesh-inhärente Möglichkeiten, wie z.B. das Aufzeigen des entstehenden Wissensgraphen und der Lineage im Mesh. Die Plattform erleichtert Nutzerinnen und Nutzern das Auffinden, den Zugriff und die Nutzung von Datenprodukten. Sie vereinfacht die Erstellung, das Deployment und die Wartung von Datenprodukten durch die