Beim Betrieb eines Data Warehouse oder eines Data Lake (oder beidem), stehen Unternehmen regelmäßig vor Herausforderungen aufgrund von steigenden Datenmengen und steigenden Anforderungen. Ich habe die typischen Herausforderungen und wie der Data Mesh-Ansatz diesen begegnet, im vorherigen Blog-Post beschrieben.
ZUM 1. TEIL DATA MESHWenn ein Unternehmen die Entscheidung getroffen hat, dass der Data Mesh-Ansatz der richtige ist, dann ist die nächste Frage, wie man mit der Umsetzung startet. Diese Frage werde ich im Folgenden beantworten. Ausgehend von den in Teil 1 beschriebenen Kernelementen eines Data Mesh, zeigt dieser zweite Teil, wie sich die Kernelemente konkret umsetzen lassen. Im Zuge dessen zeige ich an einem Beispiel, wie ein bestehendes DWH auf Basis von Snowflake genutzt werden kann, um mit einem Data Mesh zu starten.
Kernelement 1: Neuverteilung der Verantwortung
Um eine Neuverteilung der Verantwortung im Sinne einer Dezentralisierung vorzunehmen, ist es von Vorteil, wenn die Organisation bereits bei der Anwendungsentwicklung eine ähnliche Bewegung vorgenommen hat.
Denn wenn Domain-driven Design und DevOps bereits etabliert sind, ist es einfacher, diesen Schritt auch bei den Daten durchzuführen. Ist dies nicht der Fall sollte zunächst ein entsprechender organisatorischer und kultureller Wandel vollzogen werden, bevor die Einführung eines Data Mesh begonnen wird.
Wenn die Einführung eines Data Mesh begonnen wird, ist die Einführung neuer Rollen in den Domänen sinnvoll, um dadurch klare Zuständigkeiten für die Datenprodukte der Domäne zu schaffen. Zhamak Dehghani schlägt in Ihrem Buch1 die folgenden zwei Rollen vor:
Der Data Product Owner, der den Schnitt der Datenprodukte sowie die hierfür geltenden Governance-Regeln und Qualitätsanforderungen verantwortet und außerdem die Anforderungen für neue Datenprodukte oder Anpassungen daran aufnimmt, strukturiert und priorisiert. Hierfür sind Kenntnisse im Bereich Datensicherheit, Datenschutz, Data Governance und Datenqualität ebenso wichtig wie Erfahrungen als Product Owner.
Der Data Product Developer ist für die Entwicklung, den Betrieb und die Wartung der Datenprodukte zuständig. Jemand mit dieser Rolle sollte somit Skills im Bereich der Software-Entwicklung, DevOps, aber auch des Data Engineerings, der Datenmodellierung sowie der Analyse mit Hilfe von Machine Learning-Methoden mitbringen.
Die für die Rollen aufgeführten Daten-bezogenen Kenntnisse, Skills und Erfahrungen sind bisher meist nicht in den Domänen verfügbar, aber im bisherigen zentralen Team, welches bis dahin für die Integration von Daten ins Data Warehouse zuständig war. Dieses Team kann somit als Enabler-Team die Domänen zeitweise unterstützen und befähigen, ihre Datenprodukte langfristig selbst zu verantworten. Begleitend sollten Lernangebote zur Verfügung stehen, um die beiden Rollen gezielt mit dem nötigen Wissen zu versorgen.
Kernelement 2: Produkt-Denken
Auch für das zweite Kernelement, das Produktdenken, ist der Aufbau der oben aufgeführten Daten-Skills notwendig. Die Einrichtung eines oben bereits beschriebenen Enabler-Teams sowie begleitende Lernangebote sind somit auch für die Schaffung des Product-Mindsets ein wichtiger Baustein.
Um den Konsumenten und seine Bedürfnisse im Blick zu haben sollte außerdem die Möglichkeit geschaffen werden, dass sich Data Product Owner und Konsumenten miteinander austauschen. Dies kann über die Einplanung neuer Datenprodukte bilateral zwischen zwei Domänen stattfinden, es zeigt sich aber auch, dass zusätzliche Meetingformate, indem alle Domänen zusammenkommen, sinnvoll sind.
Zusätzlich braucht es eine Plattform, die die Domänen bei der Bündelung der verschiedenen Bestandteile eines Datenprodukts in einer einheitlichen Form mit möglichst viel Automatisierung unterstützt und den Data Product Ownern auch Einblicke in die Nutzung und Bewertung ihrer Datenprodukte durch die Konsumenten verschafft, um die Orientierung am Konsumenten stetig verbessern zu können. Dies bringt uns direkt zu Kernelement 3, der Plattform-Architektur.
Kernelement 3: Plattform-Architektur
Es gibt verschiedene Tools, die genutzt werden können, um eine Plattform für ein Data Mesh aufzusetzen. Da in den meisten Firmen bereits Data Lake- oder Data Warehouse- Architekturen existieren, stelle ich an dieser Stelle ein Beispiel vor, wie auf einer bestehenden Architektur aufgesetzt werden kann, um mit einem Data Mesh zu starten.
Es gibt zum Beispiel einige Unternehmen, die bereits Snowflake als Cloud-Data Warehouse im Einsatz haben. Da Snowflake bereits eine verteilte Umgebung ist, ist es möglich, dass die vielen Domänen eines Unternehmens auf dieser Plattform selbst Ihre Datenprodukte entwickeln und zur Verfügung stellen.
Mit dem Snowgrid funktioniert Snowflake mit den verschiedenen Cloud-Plattformen (z.B. Amazon Web Services, Google, Azure) und es ist nicht erforderlich, sich innerhalb der Organisation auf eine Cloud-Plattform zu committen, sondern die Domänen können unabhängig voneinander, den für sie passenden Cloud-Anbieter wählen. Das Snowgrid sorgt dafür, dass unternehmensweit gültige Governance-Regeln auf allen verwendeten Cloud-Plattformen ausgeführt werden. Mit diesem Feature wird also der Neuverteilung der Verantwortung Rechnung getragen, indem zum einen die Domänen die volle Kontrolle und Verantwortung über ihre Datenprodukte und die Tools haben, die für die Entwicklung verwendet werden. Zum anderen ist gleichzeitig auch die föderative, automatisierte Data Governance mit dem Snowgrid gewährleistet.
Datenprodukte können mit Snowflake weitgehend per Self-Service erstellt werden. Typischerweise werden die Daten eines Datenprodukts durch die Nutzung eines Schemas pro Datenprodukt bereitgestellt. In diesem Schema kann auch auf den zugehörigen Code des Datenprodukts (für Pipelines, Transformationslogik und auch Policies) verwiesen werden. SLOs werden bei der Erstellung des Datenprodukts ebenfalls durch Snowflake abgefragt. Für die Input und Output Ports eines Datenprodukts bietet Snowflake zahlreiche Konnektoren an, die bei der Entwicklung des Datenprodukts verwendet werden können (Kafka, Spark, Dataframe API, Cloud Storage Buckets, SQL API, JDBC, REST API, .NET, diverse Dateiformate).
Als weiteres Feature beinhaltet Snowflake Marketplace-Funktionen, damit Datenprodukte im Data Mesh gesucht und gefunden werden können. Darüber hinaus ist es auch möglich, einen Data Catalog eines Drittanbieters anzubinden.
Snowflake interagiert außerdem mit diversen weiteren Tools, die zum Aufbau einer Data-Mesh-Plattform in Frage kommen, so dass man mit einem bestehenden Snowflake Data Warehouse sehr gute Voraussetzungen hat, auf denen man aufsetzen kann, um erste Schritte in Richtung Data Mesh zu gehen.
Abschließend bleibt zu erwähnen, dass alle drei Kernelemente in der Kombination betrachtet werden sollten, um den vier Prinzipien eines Data Mesh (siehe Blog-Post 1) zu folgen. Fokussiert sich ein Unternehmen zu sehr auf ein oder zwei Elemente und lässt die anderen außer Acht, wird es im Nachhinein schwierig, dies wieder zu korrigieren.
Quellen für weiterführende Infos:
https://www.snowflake.com/resource/how-to-knit-your-data-mesh-on-snowflake/?utm_cta=website-data-mesh-featured-content
https://www.datamesh-architecture.com/tech-stacks/dbt-snowflake
https://www.snowflake.com/webinar/thought-leadership/master-class-deploying-data-mesh-and-dataops-on-snowflake/
https://www.snowflake.com/en/solutions/use-cases/data-mesh/
https://www.snowflake.com/blog/empower-data-teams-with-a-data-mesh-built-on-snowflake/