Data Mesh - ein Überblick

Seit dem ersten Blogpost von Zhamak Dehghani hat die Idee, eine dezentralisierte Datenplattform anstelle einer einzigen zentralen zu schaffen, viel Anklang gefunden. Der Paradigmenwechsel, den sie vorstellte, wurde durch die Beobachtung ausgelöst, dass die Art und Weise, wie wir operative Systeme entwerfen, stark vom domänenorientierten Design beeinflusst wird, während zentrale Datenplattformen weiterhin als zentralisierte Monolithen entwickelt werden. In diesem Blogpost werde ich einen Überblick über die beiden Blogposts von Zhamak geben und meine eigenen Gedanken zu ihrer Idee mitteilen, nachdem ich die Blogposts gelesen habe.

Architektonische Fehlermöglichkeiten einer zentralisierten Datenplattform

Zhamak führt in das "Warum" von Data Mesh ein, indem er die drei wichtigsten architektonischen Fehlermöglichkeiten einer monolithischen Datenplattform beschreibt. Die erste Art des Scheiterns ist"zentralisiert und monolithisch", d.h. eine einzige Plattform, die Daten aus allen Ecken des Unternehmens aufnehmen, diese Daten in etwas Vertrauenswürdiges umwandeln und schließlich die Daten an eine Vielzahl von Verbrauchern weitergeben muss. In kleineren Organisationen mag das funktionieren, aber in größeren Organisationen wird die schiere Menge an Datensätzen und der Bedarf an schnellen Experimenten einen enormen Druck auf die zentralisierte Datenplattform ausüben. Eine zentralisierte und monolithische Datenplattform

Der nächste Fehlermodus ist die"gekoppelte Pipeline-Zerlegung", bei der eine einzelne Pipeline auf mehrere Teams aufgeteilt wird, um die Entwicklung skalierbarer zu machen. Dies ermöglicht zwar eine gewisse Skalierung, verlangsamt aber auch die Entwicklung neuer Daten, da die Phasen stark gekoppelt sind. Und sie können nur wie ein Wasserfall bearbeitet werden.

Und schließlich"siloed and hyper-specialized ownership", was Teams von Datenplattform-Ingenieuren beschreibt, die versuchen, brauchbare Daten zu erstellen, während sie nur sehr wenig von den Quellsystemen verstehen, auf denen sie basieren. In der Realität führt dies dazu, dass die Datenplattformteams überfordert sind, während die Kunden um den "ersten Platz" im Auftragsbuch kämpfen.

Die große Datenkluft

In ihrem zweiten Blogpost hebt Zhamak zusätzlich die Unterschiede zwischen operativen und analytischen Daten hervor. Erstere sind Daten, die in Datenbanken gespeichert werden, die operative Systeme (z.B. Microservices) unterstützen. Letztere sind Daten, die genutzt werden, um einen Einblick in die Leistung des Unternehmens im Laufe der Zeit zu geben. Die Kluft zwischen den beiden Datentypen wird durch den Einsatz von ETL/ELT-Pipelines überwunden.

Die Unterschiede zwischen operativen und analytischen Daten führen auch zu Unterschieden bei den Zugriffsmustern, den Anwendungsfällen, den Personas der Datennutzer und der zur Verwaltung dieser Datentypen verwendeten Technologie. Diese Unterschiede in der verwendeten Technologie sollten jedoch nicht zu einer Trennung der Organisation, der Teams und der Menschen, die daran arbeiten, führen. Wie es bei einer zentralisierten Datenplattform der Fall ist.

Der Paradigmenwechsel

Durch die Anwendung von Prinzipien aus dem Buch Domain-Driven Design von Eric Evans stellte Zhamak in ihrem ersten Blogpost das Data Mesh-Konzept vor. Ein Data Mesh ist eine dezentralisierte Datenplattform, bei der das Eigentum an den Daten bei den Domänen verbleibt.

Zhamak beschreibt dieses Konzept als das Gegenteil einer zentralisierten Datenplattform. Bei diesem Konzept dreht sich alles um die Lokalisierung und den Besitz von Daten. Die Daten fließen nicht außerhalb einer Domäne in eine zentralisierte Plattform, sondern werden von den Domänen selbst gehostet und bereitgestellt.

Ein erfolgreiches Data Mesh

Um eine beliebige Größenordnung zu erreichen, erklärt Zhamak, dass jede Data Mesh-Implementierung vier grundlegende Prinzipien implementieren sollte: 1) bereichsorientiertes dezentrales Dateneigentum und -architektur, 2) Daten als Produkt, 3) eine sich selbst bedienende Dateninfrastruktur als Plattform und 4) eine föderale Computerverwaltung. Diese Prinzipien sollten gemeinsam als notwendig und ausreichend betrachtet werden.

Domaininhaberschaft

Wie bereits erwähnt, basiert Data Mesh auf der Überzeugung, dass das Eigentum an der Domäne entscheidend ist, um kontinuierliche Veränderungen und Skalierbarkeit zu unterstützen. Data Mesh erreicht dies, indem es die Verantwortung an Personen überträgt, die den Daten am nächsten sind. Indem Data Mesh den Nahtstellen der Organisation folgt, lokalisiert es die Auswirkungen von Änderungen an der Domäne.

In der Praxis wird dies dazu führen, dass Domänen nicht nur eine operative, sondern auch eine analytische API bereitstellen. Zhamak gibt ein Beispiel für eine Podcast-Domäne, die eine API zum "Erstellen einer neuen Podcast-Episode" (eine operative API) bereitstellt, aber auch eine API, die die Anzahl der Hörer eines Podcasts im Laufe der Zeit liefert (eine analytische API). Beide werden von derselben Domäne/demselben Team verwaltet.

Domaindaten als Produkt

Damit Daten als Produkt betrachtet werden können, skizziert Zhamak einige grundlegende Eigenschaften, die jedes Produkt aufweisen sollte. Ein Datenprodukt sollte auffindbar, adressierbar, vertrauenswürdig, selbstbeschreibend, interoperabel und schließlich sicher sein. Die Nutzer dieser Daten sollten wie Kunden behandelt werden.

Die Unternehmen sollten eine neue Rolle einführen, die "Domain Data Product Owner" genannt wird. Dieser ist für objektive Messgrößen (KPIs) verantwortlich, die die Leistung eines Datenprodukts beschreiben. Zum Beispiel für die Messung der Zufriedenheit seiner Kunden. Anhand der KPIs sollten sich die Domain Data-Teams bemühen, ihre Produkte so gut wie möglich zu machen. Mit klaren APIs, verständlicher Dokumentation und der genauen Verfolgung von Qualitäts- und Akzeptanz-KPIs.

Architektonisch gesehen ist ein Datenprodukt ähnlich wie ein architektonisches Quantum. Z.B. die kleinste Einheit, die unabhängig eingesetzt werden kann. Um dies zu erreichen, ist ein Datenprodukt die Kombination aus Code, Daten und Metadaten sowie Infrastruktur. Und damit ein Data Mesh eine einzelne einsatzfähige Einheit ist, sollte es Teams mit den entsprechenden Fähigkeiten ermöglichen, dies zu tun.

Datenplattform zur Selbstbedienung

Das führt zur Selbstbedienungs-Datenplattform. Für den Betrieb eines Datenprodukts ist eine ganze Menge Infrastruktur erforderlich. Das Wissen, das für den Aufbau und die Pflege dieser Infrastruktur erforderlich ist, lässt sich nur schwer über alle Bereiche hinweg replizieren. Zhamak geht dieses Problem mit dem Prinzip der Self-Serve-Datenplattform an.

Diese Selbstbedienungs-Datenplattform implementiert eine oder mehrere Plattformebenen, mit denen die Endbenutzer interagieren, um ihr Datenprodukt einzusetzen. Zhamak beschreibt drei Ebenen: die Ebene für die Bereitstellung der Dateninfrastruktur, die Ebene für die Erfahrung der Entwickler von Datenprodukten und die Ebene für die Überwachung des Datennetzes. Auf der Infrastrukturebene können Benutzer neue Infrastrukturen bereitstellen. Die Datenproduktebene implementiert Standardlösungen zur Ausführung von Datenprodukten. Eq ermöglicht es Benutzern, eine SQL-Abfrage als Datenprodukt bereitzustellen. Die Datenüberwachungsebene stellt globale Dienste bereit. Z.B. Tools, mit denen Benutzer neue Datenprodukte entdecken können, die Governance implementieren, die Datenqualität überwachen usw.

Föderierte Computerverwaltung

Das letzte Prinzip ist das der Governance. Hier beschreibt Zhamak, dass eine gewisse globale/Standardisierung im Netz durchgesetzt werden muss, und was den Domänen überlassen werden soll. Diese Gruppe hat eine schwierige Aufgabe, denn sie muss ein Gleichgewicht zwischen Zentralisierung und Dezentralisierung finden. In ihrem zweiten Blogpost hat sie eine Tabelle, in der sie die zentralisierte und die Data Mesh Governance vergleicht.

Vorwärts gehen

Das von Zhamak vorgestellte Konzept ist sehr überzeugend. Die Höhepunkte sind für mich:

• Das/die Team(s) der zentralen Datenplattform versucht/versuchen, ein unlösbares Problem zu lösen. Sie stellen den Verbrauchern stichhaltige Daten zur Verfügung, ohne selbst über ein begrenztes Fachwissen zu verfügen.
• Das Eigentum an den Daten bleibt in den Domänen. Lokalisierung der Auswirkungen von Änderungen.
• Eine Self-Service-Datenplattform ermöglicht es Teams, Datenprodukte unabhängig voneinander bereitzustellen. Die Rolle des zentralen Datenplattformteams ändert sich in eine Rolle, die ein Produkt entwickelt, anstatt Daten bereitzustellen.
• Die Governance wird durch die Definition der Standardisierung von Input/Outputs aufrechterhalten. Ermöglicht einen einheitlichen Zugang zu dezentralen Daten.

Aber es wirft auch einige zusätzliche Fragen auf:

• Wie klein sollte ein Datenprodukt sein? Kann es so klein sein wie eine einzelne SQL-Transformation?
• Auf der Überwachungsebene sollten Funktionen wie die Überwachung der Datenqualität, Katalogisierung und Zugriffsverwaltung implementiert werden. Aber wer sollte das tun?
• Schema-Änderungen. Wie geht man damit um? Wird eine Schemaänderung zu einem neuen Datenprodukt führen?
• Sollten alternative Implementierungen eines Datenprodukts (Engine) erlaubt sein? Oder grundsätzlich: Was sollten Sie zentral regeln/entscheiden und was sollten Sie den Domänen überlassen.