Data Mesh: Entwicklungsteams heben Datenschätze

Jochen Christ

This article is also available in English

In den Daten operativer IT-Systeme liegen wertvolle Informationen, die Aussagen zum Verhalten der Nutzerinnen und Nutzer zulassen und helfen können, das Softwaresystem genauer zu verstehen. Softwareentwicklerinnen und -entwickler verzichten aber oft auf Datenanalysen im Rahmen ihrer Projekte. Auch für viele Projektmanager und Product Owner spielen Daten bei der Bewertung von Features und User Stories eine untergeordnete Rolle, vor allem, weil diese kaum in analytisch aufbereiteter Form vorliegen.

Daten werden traditionell bereits im großen Stil von Daten-Teams in Data-Warehouse-Systemen und Data Lakes gesammelt und ausgewertet. Doch bei deren Auswertung sind meistens Unternehmenssteuerung und Marketing im Blick, eher selten jedoch die Teams, die neue Features entwickeln. Die Ergebnisse dieser Auswertungen sind zudem häufig enttäuschend. Ursachen dafür dürften meist die unzureichende Datenqualität der angeschlossenen Quellsysteme und mangelnde Fachkenntnisse zur Interpretation dieser Daten durch zentral organisierte Daten-Teams sein. Zudem skalieren solche zentralen Systeme und Teams nicht ausreichend schnell mit den stetig wachsenden Datenanalyseanforderungen.

Data Mesh ist ein relativ neuer, dezentraler Datenarchitekturansatz, der es Entwicklungsteams ermöglichen soll, selbstständig domänenübergreifende Datenanalysen durchzuführen und so das Verhalten ihrer Nutzerinnen und Nutzer und der Systeme besser zu verstehen. Mit dem Bereitstellen kuratierter Daten für andere Teams entsteht ein wertvolles dezentrales Datennetzwerk.

Modularisierung auch in der Datenarchitektur

In der Softwareentwicklung sind in den letzten Jahren maßgebliche Fortschritte zu verzeichnen: strategisches Domain-Driven Design (DDD) hilft, die fachliche Funktionalität in einem System zu organisieren und abzubilden. Es lassen sich klare Verantwortlichkeiten einzelner Domänen bestimmen und beispielsweise mittels Context Mapping die soziotechnischen Zusammenhänge und Schnittstellen erkennen und beschreiben.

Autonome Produktteams in der Aufbauorganisation übernehmen die Verantwortung für genau eine abgegrenzte Domäne und erhalten im Gegenzug ein hohes Maß an Freiheiten, von der Wahl der Programmiersprachen bis hin zum Team-Staffing. Diese Teams bauen folglich Softwaresysteme, die den fachlichen Scope ihres Bounded Context abbilden. Sie nutzen dazu modulare Softwarearchitekturansätze wie Microservices (in dem von Sam Newman bereits 2015 formulierten Sinne) oder Self-contained Systems, um monolithische Systeme zu vermeiden und Qualitätsziele, etwa nach Zuverlässigkeit und Wartbarkeit, bestmöglich umzusetzen. Das Zusammenspiel mit anderen Domänen erfolgt über klar definierte Schnittstellen, möglichst asynchron als Domain Events, beispielsweise über Apache Kafka oder HTTP-Feeds.

Das Aufsplitten monolithischer Strukturen in getrennte fachliche Domänen lässt sich nach dem Data-Mesh-Prinzip nun auch für Datenarchitekturen anwenden. Voraussetzung dafür ist eine Aufteilung der Teams anhand der fachlichen Grenzen. Anstelle eines zentralen Data Warehouse, das alle Daten zusammenführt und von einem Data Team verwaltet wird, führen Domänen-Teams analytische Auswertungen für ihre spezifische Domäne selbst durch und greifen auf Datensätze anderer Domänen über klar definierte Schnittstellen zu.

Die Prinzipien des Data Mesh

Den Begriff Data Mesh prägte 2019 erstmals Zhamak Dehghani in ihrem Beitrag “How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh”. Die Definition umfasst typischerweise die folgenden vier Prinzipien:

• Domain Ownership
• Data-as-a-Product
• Self-serve Platform
• Federated Governance

Domain Ownership bedeutet, dass die für die operativen Systeme verantwortlichen Teams auch ihre analytischen Daten bereitstellen. Die Kernidee dahinter ist, dass Daten nur innerhalb ihres Bounded Context eine klar definierte Bedeutung haben und die jeweiligen Teams ihre eigenen Daten am besten kennen. Jedes Team entscheidet daher individuell, welche Daten von Bedeutung sind und wie diese für analytische Zwecke aufbereitet werden. Jedes Team übernimmt die volle Verantwortung für seine Daten.

Gemäß dem Prinzip Data-as-a-Product sollten analytisch relevante Daten so verwaltet und zugänglich sein, dass andere Teams einfach darauf zugreifen können. Die Daten unterliegen dabei dem üblichen Entwicklungsprozess innerhalb des Teams, von der Beschreibung einer User Story durch den Product Owner und einer verständlichen Dokumentation über den Datenzugriff und die Bedeutung der einzelnen Felder bis zur operativen Verantwortung, die beispielsweise das Monitoring einschließt. Das Team liefert mit seinen Daten dann einen Wertbeitrag für andere Teams.

Die Self-serve Data Platform beschreibt eine Datenplattform, die den Teams zum Bereitstellen analytischer Daten, Datenauswertungen und Visualisierungen sowie für den einfachen Zugriff auf Daten aus anderen Domänen dient. Dabei steht der Self-Service-Charakter im Vordergrund: Alle Aktivitäten sollen durchführbar sein, ohne dass ein anderes Team eingreifen muss.

Unter Federated Governance versteht man domänenübergreifende Vereinbarungen, die regeln, wie sich das Zusammenwirken effizient gestalten und die Qualität der Datenlandschaft langfristig gewährleisten lässt. Vertreter der Domänen definieren dazu gemeinsam die notwendigen Global Policies (vergleiche Makro-Architektur-Richtlinien), die für Interoperabilität und Sicherheit erforderlich sind. Auf einer höheren Ausbaustufe lässt sich das Einhalten dieser Regeln auch automatisiert durch die Plattform sicherstellen.

Diese Prinzipien sind geeignet, um die Verantwortung in dezentralen Datenarchitekturen zu beschreiben, aber was bedeuten sie für Softwareentwicklerinnen und -entwickler in den Domänen-Teams?

Domänen-spezifische Datenanalysen mit Blick auf das Gesamtergebnis

Aus Sicht der Domänen-Teams ist zunächst vor allem die Self-serve Data Platform spannend. Entwicklerinnen und Entwickler operativer Systeme haben auf Datenanalysen bisher meist verzichtet, da die sich in der Regel auf operativen Datenbanken nicht effizient ausführen lassen und Auswirkungen auf die Performance der produktiven Anwendung hatten. Die Bereitstellung einer einfach zu nutzenden Datenplattform befähigt die Teams nun jedoch, Daten analytisch aufzubereiten und selbstständig Datenanalysen durchzuführen.

Eine Datenplattform wird in der Regel von einem eigenen Data-Platform-Team verwaltet und umfasst die Funktionen Speicherung, Dateneingang (Ingestion), Verarbeitung, Analyse, Visualisierung und das Verwalten der Metadaten und Berechtigungen. Ein Data Catalog dient dazu, Datenprodukte – in der Regel eine Kombination aus Daten, einem KI-Modell und der Darstellung der Ergebnisse – zu dokumentieren, aufzufinden und vereinbarte Richtlinien einzuhalten.

Mit der beschriebenen Datenplattform sind die Teams nun in der Lage, Daten für analytische Zwecke bereitzustellen. Sind die Daten in die Plattform überführt, müssen sie noch aufbereitet und bereinigt werden. Dazu empfiehlt es sich, Daten zunächst im Quellformat (z. B. JSON) in ein CLOB-Feld (Character Large Object) zu importieren, um sich noch keine Gedanken über das Datenbankschema machen zu müssen. Im nächsten Schritt sollten Entwicklerinnen und Entwickler die Daten in ein strukturiertes SQL-Tabellenformat überführen, deduplizieren und gegebenenfalls strukturelle Veränderungen und Nullwerte entschärfen. Im Hinblick auf Datenschutzanforderungen sollten sie außerdem sensible Informationen (personenbezogene Daten, Kreditkarteninformationen) so früh wie möglich entfernen oder zumindest anonymisieren, am besten schon vor dem Speichern in der Plattform. Diese Bereinigung können Domain-Teams, die ihre operativen Daten gut kennen, viel effektiver durchführen als zentrale Daten-Teams, denen der fachliche Kontext fehlt. Dermaßen fokussiertes Aufbereiten der Daten trägt zu einer höheren Datenqualität bei.

Mit den bereinigten Daten können die Teams eigenständig Analysen durchführen. Das sind zunächst in der Regel einfach SQL-Queries. Mittels JOIN-Operationen lassen sich Datensätze aus verschiedenen Quellsystemen (beispielsweise unterschiedliche Microservices) zusammenführen und mit Aggregationsfunktionen verdichten. Besonders hilfreich sind zudem Window-Funktionen, um partitionierte zeilenübergreifende Auswertungen durchzuführen. Visualisierungen helfen, Trends und Anomalien zu erkennen. Domänen-Teams können ihre eigenen Daten nutzen, um das bisherige Systemverhalten zu erklären und Nutzerverhalten nachzuvollziehen. Das ist insbesondere dann hilfreich, wenn es gilt, aus den Erkenntnissen neue Features abzuleiten und den Nutzen von User Stories frühzeitig zu bewerten, anstatt nur nach Bauchgefühl zu priorisieren. Auch Systemfehler lassen sich leichter erkennen, beispielsweise solche, die immer kurz nach einem bestimmten Event auftreten. Auswertungen kann ein Domänen-Team mit Data Mesh selbstständig durchführen, und schneller Erkenntnisse in operative Verbesserungen einbringen.

Was jetzt noch fehlt, ist der Blick auf das Gesamtergebnis, also beispielsweise die Auswirkungen einer UI-Änderung auf der Startseite eines Webshops auf einen späteren Kaufabschluss. Ein weiteres Beispiel aus dem E-Commerce könnte die Conversion Rate betreffen. Sie misst die Zahl der tatsächlich getätigten Käufe – interessant, aber zunächst unberücksichtigt bleibt dabei die Frage, ob Kunden einen bestellten Artikel wieder zurückgeschickt haben. Hier kommt die Vernetzung der Daten aus unterschiedlichen Domänen ins Spiel: Wenn sowohl die Kaufabschluss-Domäne das Ergebnis einer Session als auch die Retoure-Domäne die zurückgeschickten Artikel als Datensatz auf der Plattform zur Verfügung stellen, lassen sich Korrelationen – und beispielsweise mittels A/B-Testing sogar aussagefähige Kausalitäten – unmittelbar erkennen. Dieser Ansatz entspricht dem Data-Mesh-Prinzip des Data-as-a-Product. Eine Domäne stellt bestimmte relevante Datensätze in zugreifbarer und dokumentierter Form zur Verfügung. Das Nutzen und Verknüpfen domänenübergreifender Daten führt so zu immer aussagekräftigeren Analysen.

Bei der domänenübergreifenden Datenverknüpfung tritt jedoch das Problem auf, dass die Daten und Begriffe einer Domäne nur innerhalb ihres Bounded Context gültig sind. Hier hilft die Methode des Context Mapping aus dem Domain-driven Design, um die Beziehungen zwischen den Domänenmodellen zu beschreiben. Ein Datensatz, der dem Open-Host-Service-Pattern folgt, muss somit beispielsweise genauer beschrieben werden als ein Datensatz, der aufgrund einer bilateralen Customer/Supplier-Abstimmung entstanden ist.

Gemeinsame Vereinbarungen helfen, die technische und semantische Interoperabilität sicherzustellen, indem sich alle Beteiligten beispielsweise auf ein Format (SQL, JSON, etc.), eine Sprache (Deutsch, Englisch usw.) und die Bezeichnung und Form fachlicher Schlüssel einigen. Vertreter der Domänen-Teams und des Plattform-Teams treffen die notwendigen Vereinbarungen gemeinsam und dokumentieren sie als Global Policies.

Data-as-a-Product geht sogar noch weiter: Steht ein Datensatz für andere Teams bereit, lässt er sich mit einer produktiven API vergleichen. Entsprechend muss das Team auch die Verfügbarkeit und Qualität der Daten kontinuierlich sicherstellen. Sämtliche Datensätze müssen klar dokumentiert und auffindbar sein. Änderungen am Datenmodell sind dann aber nicht mehr ohne weiteres möglich. Ein Monitoring ist notwendig, um die Verfügbarkeit, Qualität und Vollständigkeit der Daten zu überwachen. Analytische Daten rücken damit in die Riege der Schnittstellen einer Domäne – ähnlich wie bereits UI und APIs.

Der Product Owner trägt die Verantwortung dafür, dass die Bereitstellung der Daten aus Domänen- und Unternehmenssicht wirtschaftlich sinnvoll bleibt. Da es in der Regel nicht effizient ist, sämtliche Domänen-Daten als Datenprodukt für andere Teams bereitzustellen (auch wenn sich das die konsumierenden Daten-Teams wünschen mögen), gilt es, eine klare Entscheidung zu treffen: Welche internen Daten sind lediglich für interne Analysezwecke notwendig und welche sollten als Datenprodukt auch anderen Teams bereitstehen? In der Regel sollten beispielsweise Domain Events und Stammdaten, die häufig referenziert werden, auch für andere Domänen-Teams verfügbar sein. Im Zweifel müssen sich die Teams untereinander absprechen und auf die erforderlichen Datenprodukte einigen.

Data Mesh in der Praxis

Data Mesh eignet sich meist als Bottom-Up-Ansatz mit einem gemeinsam definierten Ziel, doch wie setzt man es in der Praxis um? Vorzugsweise starten ein oder besser mehrere Teams, die Interesse an Datenanalysen bekunden. Sie einigen sich auf eine Datenplattform – dafür bieten sich heutzutage in der Regel Clouddienste wie Google BigQuery, AWS S3, Azure Synapse Analytics oder Snowflake an. Zum Einstieg kann auch eine PostgreSQL-Datenbank kombiniert mit einem Visualisierungstool wie Metabase oder Redash genügen. Jedes Team erhält einen eigenen Bereich (Projekt/Account/Workspace…), in dem es selbstständig Ressourcen wie Datenbanken und Tabellen anlegt. Eine logische Struktur definiert Bereiche, in denen die unterschiedlichen Arten analytischer Daten liegen sollen (vgl. Abb. 4).

Im nächsten Schritt fügt das Team dann Daten aus dem operativen System in die Datenplattform ein. Diese landen meist unstrukturiert in einem raw-Bereich. Hierfür lassen sich Integrationen wie Kafka Connect nutzen oder das Team implementiert einen eigenen Consumer, der die Streaming-Ingestion-API der jeweiligen Plattform aufruft. In der Regel eignen sich Domain Events, sofern vorhanden, sehr gut als primäre analytische Datengrundlage, da sie Fakten der Geschäftsprozesse repräsentieren. Datenbank-Exports via ETL-Batches hingegen sind möglichst zu vermeiden, um Echtzeit-Analysen zu ermöglichen, ohne das operative Datenbankschema zu exponieren.

Das Bereinigen der Daten erfolgt dann beispielsweise als eine SQL-Query auf die Rohdaten, die als View angelegt ist, wie das folgende Listing zeigt. Dabei werden Duplikate entfernt und JSON auf einzelne Felder abgebildet. Zur Strukturierung lassen sich gut Common Table Expressions verwenden.

-- Step 1: Deduplicate

WITH inventory_deduplicated AS (
   SELECT *
   EXCEPT (row_number)
   FROM (
            SELECT *,
                   ROW_NUMBER() OVER (PARTITION BY id ORDER BY time DESC) row_number
            FROM `datameshexample-fulfillment.raw.inventory`)
   WHERE row_number = 1
),
-- Step 2: Parse JSON to columns

inventory_parsed AS (
   SELECT
       json_value(data, "$.sku")                            AS sku,
       json_value(data, "$.location")                       AS location,
       CAST(json_value(data, "$.available") AS int64)      AS available,
       CAST(json_value(data, "$.updated_at") AS timestamp) AS updated_at,
   FROM inventory_deduplicated
)
-- Step 3: Actual Query

SELECT sku, location, available, updated_at
FROM inventory_parsed
ORDER BY sku, location, updated_at

Die bereinigten Datensätze bilden die Grundlage für die internen Datenanalysen des Teams. Dabei gilt es meist zwischen unveränderlichen Events und Stammdaten-Entities, die sich im Laufe der Zeit verändern, zu unterscheiden. Mittels SQL-Abfragen können die Teams diese nun analysieren. Häufig kommen dabei Jupyter Notebooks zum Einsatz, um explorativ Erkenntnisse aufzubauen und zu dokumentieren.

Visualisierungen helfen, um Daten für Menschen einfacher greifbar zu machen. Die Datenplattform sollte ein dazu geeignetes Tool zur Verfügung stellen – Abbildung 6 zeigt beispielhaft Google Data Studio. Voraussetzung für die Visualisierung ist Zugriff auf die Tabellen oder die entsprechenden Queries, die Aggregation der Daten lässt sich hingegen auch direkt im Tool steuern.

Zu guter Letzt sollen Daten auch anderen Teams als Datenprodukte zur Verfügung gestellt werden. Hierbei empfiehlt es sich, eine View zu verwenden, um nach außen eine konstante Sicht auf die Daten zu gewährleisten, auch dann, wenn sich die zugrunde liegenden Datensätze ändern. Solche Migrationen lassen sich dann in der Query der View nachziehen. Andere Teams erhalten nun eine Berechtigung für diese View und können darauf per SQL-Query zugreifen. Darüber hinaus muss der Datensatz nach den vereinbarten Vorgehensweisen dokumentiert sein. Das kann im einfachsten Fall in einem Wiki oder Git-Repository erfolgen. In einer fortgeschrittenen Ausbaustufe sollte jedoch ein Data Catalog zum Einsatz kommen, der Metainformationen zum Datensatz sowie der Qualität liefert, und in dem einzelne Felder genau dokumentiert sind (Abb. 7).

Mit der Zeit entsteht so ein Geflecht (Mesh) aus Datenprodukten verschiedener Domänen, die sich übergreifend verwenden lassen. Im Idealfall ermutigt das Data Mesh andere Teams, die Plattform mit den bereitgestellten Daten ebenfalls zu nutzen und schließlich selbst analytische Daten bereitzustellen.

Die hier beschriebene Vorgehensweise ist für Softwareentwicklerinnen und -entwickler insofern pragmatisch, als sich im Wesentlichen mit SQL arbeiten lässt – ein Handwerkszeug, mit dem die meisten Informatiker vertraut sein sollten. Gegebenenfalls neu zu erlernen sind hingegen der Umgang mit Daten zur Visualisierung sowie statistische Methoden. Komplexere Werkzeuge zur Datenaufbereitung wie Apache Spark, Apache Beam oder NumPy sind zumindest für den Einstieg nicht unbedingt nötig.

Data Mesh als Innovationstreiber für neue Domänen

Bei Data Mesh geht es in erster Linie darum, dass Domain-Teams selbstständig Datenanalysen durchführen können. Was geschieht aber mit den zentralen Daten-Teams, die es in vielen Organisationen bereits gibt?

Das Daten-Team ist aufgrund seiner Kenntnisse prädestiniert, die oben beschriebene Datenplattform zu betreiben und zu verwalten, denn auch bei der Nutzung von Clouddiensten im Self-Service müssen Berechtigungen eingerichtet und Kosten kontrolliert werden. Das Team kann zudem als Enabler und Botschafter agieren, um weitere Domänen-Teams zu ermutigen, die Datenplattform zu nutzen und ihnen dabei zu helfen. Durch Bereitstellen von Vorlagen und Best Practices für häufige Anwendungsfälle machen sie die Plattform attraktiv. Experten können auch für begrenzte Zeit beratend in die Domänen-Teams wechseln, um dort notwendige Kenntnisse aufzubauen.

Bestehende Datenprodukte wie Reports, etwa für die Unternehmenssteuerung, müssen weiterhin bereitgestellt werden. Diese Aufgabe verbleibt zunächst bei den bisherigen Data Engineers. Deren Arbeit gestaltet sich aber deutlich leichter: Wenn Domänen-Teams bereinigte Datensätze in einem klar vereinbarten Format und in kontinuierlich hoher Qualität anbieten, entfallen mühsame Schritte zur Datenextraktion und Aufbereitung. Perspektivisch sollte erwogen werden, auch für datenintensive Domänen eigene Domänen-Teams zu gründen, etwa für die Unternehmenssteuerung oder das Marketing. Auch für Data-Science-Teams sind fachliche Domänen wie Customer Profiling oder Sales Predictions vorstellbar, die basierend auf Datenauswertungen und Machine-Learning-Modellen sowohl operative als auch analytische Dienste bereitstellen.