Das Warum, Was und Wie des Data Mesh Paradigmas

Seitdem die erster Blogpost von Zhamak Dehghani hat die Idee, eine dezentralisierte Datenplattform anstelle einer einzigen zentralen zu schaffen, viel Anklang gefunden. Der damit eingeleitete Paradigmenwechsel wurde durch die Beobachtung ausgelöst, dass, während das domänenorientierte Design die Art und Weise, wie wir operative Systeme entwerfen, stark beeinflusst, zentrale Datenplattformen weiterhin als zentralisierte Monolithen entwickelt werden. In diesem Artikel werden zwei Blogs von Zhamak Dehghani sowie ein On-Demand-Webinar besprochen, in dem das Paradigma eines Datennetzes eingehend behandelt wird.

Das Warum, Was und Wie des Data Mesh Paradigmas

Kürzlich haben wir in einem Webinar einige unserer Erkenntnisse und Gedanken über das Paradigma der Datenvernetzung geteilt. Sehen Sie sich dieses On-Demand-Webinar mit Steven Nooijen, Guillermo Sánchez Dionis und Niels Zeilemaker an:

Architektonische Fehlermodi 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 für eine Vielzahl von Nutzern bereitstellen muss. In kleineren Unternehmen mag das funktionieren, aber in größeren Unternehmen 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 Skalierbarkeit, verlangsamt aber auch die Bereitstellung neuer Daten, da die Phasen stark gekoppelt sind. Und es kann nur in einer wasserfallartigen Weise gearbeitet werden.

Und schließlich beschreibt"siloed and hyper-specialized ownership" Teams von Datenplattform-Ingenieuren, 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 Blogbeitrag, Zhamak weist außerdem auf die Unterschiede zwischen operativen und analytischen Daten hin. Erstere sind Daten, die in Datenbanken gespeichert werden, die operative Systeme (z.B. Microservices) unterstützen. Bei letzteren handelt es sich um Daten, die dazu dienen, 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 dazu führen, dass die Organisation, die Teams und die Menschen, die daran arbeiten, voneinander getrennt werden. Wie es bei einer zentralisierten Datenplattform der Fall ist.

Der Paradigmenwechsel

Durch die Anwendung von Prinzipien aus dem Buch von Eric Evans Domänenorientiertes Design In ihrem ersten Blogbeitrag stellte Zhamak das Konzept des Data Mesh vor. Ein Data Mesh ist eine dezentralisierte Datenplattform, bei der das Eigentum an den Daten in den Domänen bleibt.

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 erfolgreicher Datennetzplan

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.

Domain-Besitz

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  podcasts Domain, 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.

Sie werden auf dem Markt mehr Analytik-Ingenieure als Daten-Ingenieure finden, auch wenn diese vielleicht nicht wissen, dass sie Analytik-Ingenieure sind.

Guillermo Sánchez Dionis

Diese Selbstbedienungs-Datenplattform implementiert eine oder mehrere Plattformebenen, mit denen die Endbenutzer interagieren, um ihr Datenprodukt einzusetzen. Zhamak beschreibt  drei Ebenen: Dateninfrastruktur-Bereitstellungsebene, Datenproduktentwickler-Erfahrungsebene und die Datengitter-Überwachungsebene. 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 Computergovernance

Das letzte Prinzip ist das der Governance. Hierin beschreibt Zhamak, dass einige globale/Standardisierungen im Netz durchgesetzt werden müssen und was den Domänen überlassen werden soll, zu entscheiden. Diese Gruppe hat eine schwierige Aufgabe, denn sie muss ein Gleichgewicht zwischen Zentralisierung und Dezentralisierung finden. In ihrem  zweiter Blogpost hat sie eine Tabelle, in der sie zentralisierte und 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 vertrauenswürdige 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 die desjenigen, der ein Produkt entwickelt, anstatt Daten bereitzustellen.
• Die Governance wird durch die Definition der Standardisierung von Inputs/Outputs aufrechterhalten. Ermöglicht einen einheitlichen Zugang zu dezentralen Daten.

Es bleiben aber auch einige zusätzliche Fragen, die wir in Zukunft untersuchen werden:

• 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.