Data Intelligence

Die Migration zu Data Mesh - Teil 3 - Erstellen Ihrer ersten Datenprodukte

Actian Germany GmbH

22. April 2024

Die Literatur zum Thema Datenvernetzung ist zwar umfangreich, beschreibt aber oft einen Endzustand und selten, wie dieser in der Praxis erreicht werden kann. Es stellt sich also die Frage:

Welcher Ansatz sollte gewählt werden, um das Datenmanagement zu transformieren und ein Datennetz zu implementieren?

In dieser Artikelserie erhalten Sie einen Auszug aus unserem Practical Guide to Data Mesh, in dem wir einen Ansatz vorschlagen, um eine Data Migration in Ihrem Unternehmen einzuleiten. Dieser Ansatz basiert auf den vier Prinzipien von Data Mesh (bereichsorientiertes dezentrales Dateneigentum und -architektur, Daten als Produkt, Self-Service-Dateninfrastruktur als Plattform und föderierte Computer-Governance) und nutzt die vorhandenen personellen und technischen Ressourcen.

Zur Veranschaulichung dieses Ansatzes für den Aufbau eines erfolgreichen Datennetzes werden wir uns in dieser Artikelserie auf ein Beispiel stützen: das des fiktiven Unternehmens Premium Offices - einer gewerblichen Immobiliengesellschaft, deren Tätigkeit darin besteht, Immobilien zu erwerben und an Unternehmen zu vermieten.

In den ersten Artikeln dieser Reihe haben wir die Bereiche identifiziert, einen ersten use case definiert und das für die Entwicklung zuständige Team zusammengestellt. Nun ist es an der Zeit, zum zweiten Grundsatz des Datennetzes, "Daten als Produkt", überzugehen und die ersten Datenprodukte zu entwickeln.

Der produktorientierte Ansatz des Mesh

In den letzten zehn Jahren haben Domänen oft eine Produktkultur rund um ihre betrieblichen Funktionen entwickelt. Sie bieten ihre Produkte dem Rest des Unternehmens als APIs an, die genutzt und zusammengestellt werden können, um neue Dienste und Anwendungen zu entwickeln. In einigen Organisationen bemühen sich die Teams, den Entwicklern die bestmögliche Erfahrung bei der Nutzung ihrer Bereichs-APIs zu bieten: Suche in einem globalen Katalog, umfassende Dokumentation, Codebeispiele, Sandbox-Umgebungen, garantierte und überwachte Service-Levels usw.

Diese APIs werden dann als Produkte verwaltet, die geboren werden, sich im Laufe der Zeit weiterentwickeln (ohne Kompatibilitätsbrüche), erweitert werden und schließlich veraltet sind und in der Regel durch eine neuere, modernere und leistungsfähigere Version ersetzt werden.

Das Datennetz schlägt vor, diesen Ansatz des Produktdenkens auch auf die von den Bereichen gemeinsam genutzten Daten anzuwenden.

Daten Produkte Merkmale

In einigen Unternehmen ist diese produktorientierte Kultur bereits gut etabliert. In anderen muss sie erst noch entwickelt oder eingeführt werden. Aber wir sollten uns nicht täuschen:

Ein Datenprodukt ist kein neues digitales Artefakt, das neue technische Funktionen erfordert (wie ein API-Produkt). Es ist einfach das Ergebnis eines bestimmten Datenmanagement , der von einer Domäne für den Rest der Organisation offengelegt wird.

Die Verwaltung von APIs als Produkt erforderte keinen technologischen Durchbruch: Die bestehende Middleware erfüllte diese Aufgabe problemlos. In ähnlicher Weise können Datenprodukte auf bestehenden Dateninfrastrukturen bereitgestellt werden, unabhängig davon, wie diese aussehen. Technisch gesehen kann ein Datenprodukt eine einfache Datei in einem Daten-Lake mit einer SQL-Schnittstelle sein; ein kleines Star-Schema, ergänzt durch einige Ansichten zur Erleichterung der Abfrage, instanziiert in einer relationalen Datenbank; oder sogar eine API, ein Kafka-Stream, eine Excel-Datei usw.

Ein Datenprodukt wird nicht dadurch definiert, wie es zustande kommt, sondern dadurch, wie es konzipiert, verwaltet und gesteuert wird, und durch eine Reihe von Merkmalen, die seine Nutzung in großem Umfang innerhalb des Unternehmens ermöglichen.

Diese Merkmale werden häufig unter dem Akronym DATSIS (Discoverable, Addressable, Trustworthy, Self-describing, Interoperable, Secure) zusammengefasst.

Darüber hinaus erfordert die Erstellung eines DATSIS-Datenprodukts keine großen Investitionen. Es geht darum, eine Reihe von globalen Konventionen zu definieren, die die Domänen befolgen müssen (Namensgebung, unterstützte Protokolle, Zugangs- und Berechtigungsmanagement, Qualitätskontrollen, Metadaten usw.). Die betriebliche Umsetzung dieser Konventionen erfordert in der Regel keine neuen technologischen Funktionen - bestehende Lösungen reichen in der Regel aus, um loszulegen.

Eine Ausnahme bildet jedoch der Katalog. Er spielt eine zentrale Rolle bei der Deployment des Datennetzes, indem er es Domänen ermöglicht, Informationen über ihre Datenprodukte zu veröffentlichen, und Verbrauchern, diese Datenprodukte kennenlernen, zu suchen, zu verstehen und zu nutzen.

Bewährte Praktiken für die Gestaltung von Datenprodukten

Die Entwicklung eines Datenprodukts ist sicherlich keine exakte Wissenschaft - es könnte nur ein Produkt sein, oder drei oder vier. Als Orientierungshilfe für diese Wahl ist es wieder einmal nützlich, einige bewährte Verfahren aus verteilten Architekturen zu nutzen - ein Datenprodukt muss:

  • Sie haben eine einzige, klar definierte Verantwortung.
  • über stabile Schnittstellen verfügen und Abwärtskompatibilität gewährleisten.
  • in verschiedenen Kontexten verwendbar sein und somit Polyglottismus unterstützen.

Erfahrung als Entwickler von Datenprodukten

Die Erfahrung der Entwickler ist ebenfalls ein grundlegender Aspekt des Datennetzes, wobei das Ziel darin besteht, die Entwicklung von Datenprodukten und die Entwicklung von Diensten oder Softwarekomponenten zusammenzuführen. Es geht nicht nur darum, Ingenieuren entgegenzukommen, sondern auch darum, einer gewissen wirtschaftlichen Rationalität gerecht zu werden:

Die Dezentralisierung des Datenmanagement bedeutet, dass die einzelnen Bereiche über eigene Ressourcen zur Entwicklung von Datenprodukten verfügen. In vielen Organisationen ist das zentrale Datenteam nicht groß genug, um verteilte Teams zu unterstützen. Um den Erfolg des Datennetzes zu gewährleisten, ist es unabdingbar, auf den oft größeren Pool von Softwareingenieuren zurückgreifen zu können.

Der Stand der Technik in der Software-Entwicklung beruht auf einem hohen Automatisierungsgrad: deklarative Zuweisung von Infrastruktur-Ressourcen, automatisierte Unit- und Integrationstests, orchestriertes Build und Deployment über CI/CD-Tools, Git-Workflows für die Quell- und Versionsverwaltung, automatische Veröffentlichung der Dokumentation usw.

Die Entwicklung von Datenprodukten sollte sich diesem Stand der Technik annähern - und je nach Reifegrad des Unternehmens, seiner Teams und seines Technologie-Stacks wird diese Annäherung mehr oder weniger Zeit in Anspruch nehmen. Der richtige Ansatz besteht darin, so viel wie möglich mit vorhandenen und beherrschten Tools zu automatisieren und dann die nicht automatisierten Vorgänge zu identifizieren, um schrittweise zusätzliche Tools zu integrieren.

In der Praxis sieht es so aus, dass es sich um ein Datenprodukt handelt:

  1. Code zuerst - Für Pipelines, die das Datenprodukt mit Daten aus verschiedenen Quellen oder anderen Datenprodukten füttern; für alle Verbrauchs-APIs des Datenprodukts; zum Testen von Pipelines und zur Kontrolle der Datenqualität; usw.
  2. Daten, natürlich - Aber in den meisten Fällen sind die Daten in Systemen vorhanden und werden von Pipelines einfach extrahiert und umgewandelt. Daher sind sie nicht im Quellcode enthalten (mit Ausnahmen).
  3. Metadaten - Einige davon dokumentieren das Datenprodukt: Schema, Semantik, Syntax, Qualität, Abstammung, usw. Andere sollen die Produkt-Governance auf der Ebene des Netzes sicherstellen - Verträge, Zuständigkeiten, Zugriffsrichtlinien, Nutzungsbeschränkungen usw.
  4. Infrastruktur - Genauer gesagt, die Angabe der physischen Ressourcen, die für die Instanziierung des Datenprodukts erforderlich sind: Deployment und Ausführung von Code, Deployment von Metadaten, Ressourcenzuweisung für die Speicherung, usw.

Auf der Infrastrukturseite erfordert das Datennetz keine neuen Funktionen - die große Mehrheit der Organisationen verfügt bereits über eine Datenplattform. Die Implementierung des Datennetzes erfordert auch keine zentralisierte Plattform. Einige Unternehmen haben bereits in eine gemeinsame Plattform investiert, und es erscheint logisch, die Funktionen dieser Plattform zu nutzen, um das Netz zu entwickeln, aber andere haben mehrere Plattformen, einige Einheiten oder bestimmte Bereiche mit ihrer Infrastruktur. Es ist durchaus möglich, das Datennetz auf diesen hybriden Infrastrukturen einzusetzen: Solange die Datenprodukte gemeinsame Standards für Adressierbarkeit, Interoperabilität und Zugangskontrolle einhalten, sind die technischen Modalitäten ihrer Ausführung von geringer Bedeutung.

Beispiel Premium Offices:

Um einen ersten Framework für die Verwaltung seines Datennetzes zu schaffen, hat Premium Offices die folgenden Regeln aufgestellt:

  • Ein Datenprodukt wird in BigQuery als dediziertes Projekt angelegt - dies ermöglicht die Festlegung von Zugriffsregeln auf Projektebene oder, falls erforderlich, auf einer feineren Ebene. Diese Projekte werden in einem Verzeichnis "Datenprodukte" und einem Unterverzeichnis mit dem Namen der Domäne, zu der sie gehören, abgelegt (in unserem Beispiel "Brokerage").
  • Datenprodukte müssen Ansichten für den Zugriff auf Daten bieten - diese Ansichten bieten eine stabile Schnittstelle für die Nutzung und ermöglichen möglicherweise die Weiterentwicklung des internen Modells des Produkts, ohne dass sich dies auf die Nutzer auswirkt.
  • Alle Datenprodukte müssen Daten mit gemeinsamen Referenzen für gemeinsame Daten (Kunden, Produkte, Lieferanten, Mitarbeiter usw.) identifizieren - dies vereinfacht die Querreferenzierung von Daten aus verschiedenen Datenprodukten (LEI, Produktcode, UPC, EAN, E-Mail-Adresse usw.).
  • Der Zugriff auf Datenprodukte erfordert eine starke Authentifizierung auf Basis der Funktionen von GCP - die Verwendung eines Dienstkontos ist möglich, aber jeder Nutzer eines Datenprodukts muss dann über ein eigenes Dienstkonto verfügen. Wenn Zugriffsrichtlinien von Benutzern abhängen, muss die Identität des Nutzerüber OAuth2-Authentifizierung verwendet werden.
  • In der Regel wird der Zugriff nur auf Ansichten gewährt, nicht aber auf das interne Modell.
  • Zugriffsanfragen werden vom Product Owner über in ServiceNow eingerichtete Workflows bearbeitet.
  • DBT ist die bevorzugte ETL für die Implementierung von Pipelines - jedes Datenprodukt hat ein eigenes Lager für seine Pipeline.
  • Ein Datenprodukt kann entweder über das JDBC-Protokoll oder über BigQuery-APIs (schreibgeschützt) konsumiert werden.
  • Für ein Datenprodukt muss ein Vertrag geschlossen werden, der die Häufigkeit der Datenaktualisierung, die Qualitätsstufen, die Klassifizierung der Informationen, die Zugriffsrichtlinien und die Nutzungsbeschränkungen festlegt.
  • Das Datenprodukt muss seine Metadaten und Dokumentation auf einem Marktplatz veröffentlichen - in Ermangelung eines bestehenden Systems beschließt Premium Offices, seine ersten Datenprodukte in einem eigenen Bereich auf dem Wiki des Unternehmens zu dokumentieren.

Dieses anfängliche Regelwerk wird sich natürlich weiterentwickeln, aber es setzt einen pragmatischen Framework , um die DATSIS-Merkmale von Datenprodukten zu gewährleisten, indem ausschließlich vorhandene Technologien und Fähigkeiten genutzt werden. Für das Pilotprojekt hat Premium Offices beschlossen, die Architektur in zwei Datenprodukte zu unterteilen:

  • Mietvertrags-Analytik - Dieses erste Datenprodukt bietet analytische Funktionen zu Mietverträgen - Unternehmen, Muttergesellschaft, Standort der Immobilie, Datum des Mietbeginns, Datum des Mietende, Art des Mietvertrags, Miethöhe usw. Es ist in Form eines kleinen Star-Schema modelliert, das Analysen entlang von zwei Dimensionen ermöglicht: Zeit und Mieter - dies sind die Analysedimensionen, die für die Erstellung der ersten Version des dashboard benötigt werden. Es enthält auch ein oder zwei Ansichten, die das Star-Schema nutzen, um voraggregierte Daten bereitzustellen - diese Ansichten bilden die öffentliche Schnittstelle des Datenprodukts. Schließlich enthält es eine Ansicht, um die aktuellste Liste der Mieter zu erhalten.
  • Entity Ratings - Dieses zweite Datenprodukt bietet historische Ratings von Entitäten in Form eines einfachen Datensatz und einer Spiegelansicht, die als Schnittstelle dient, in Übereinstimmung mit gemeinsamen Regeln. Die Ratings werden von einem spezialisierten Anbieter bezogen, der sie in Form von APIs zur Verfügung stellt. Um diese API aufzurufen, muss eine Liste von Entitäten zur Verfügung gestellt werden, die über die entsprechende Schnittstelle des Tenancy-Analytics-Produkts abgerufen wird.

Zusammenfassend lässt sich sagen, dass die Einstellung, Daten als Produkt zu behandeln, für Organisationen, die eine Dezentralisierung Datenmanagement vornehmen, von wesentlicher Bedeutung ist. Dieser Ansatz fördert eine Kultur der Verantwortlichkeit, Standardisierung und Effizienz im Umgang mit Daten in verschiedenen Bereichen. Durch die Betrachtung von Daten als wertvolles Gut und die Implementierung strukturierter Verwaltungsrahmen können Unternehmen Beständigkeit, Zuverlässigkeit und nahtlose Integration von Daten in ihren gesamten Betrieb gewährleisten.

In unserem letzten Artikel gehen wir auf das vierte und letzte Prinzip der Datenvernetzung ein: die föderale Verwaltung von Computern.

Der praktische Leitfaden für Data Mesh: Einrichten und Überwachen eines unternehmensweiten Datennetzes

Unser von Guillaume Bodet verfasster Leitfaden soll Ihnen praktische Strategien für die Implementierung von Datennetzen in Ihrem Unternehmen an die Hand geben und Sie dabei unterstützen:

  • Beginnen Sie Ihre Data Mesh Migration mit einem gezielten Pilotprojekt.
  • Entdecken Sie effiziente Methoden zur Skalierung Ihres Datennetzes.
  • Erkennen Sie die zentrale Rolle an, die ein interner Marktplatz bei der Erleichterung der effektiven Nutzung von Datenprodukten spielt.
  • Erfahren Sie, wie die Actian Data Intelligence Platform zu einem robusten Überwachungssystem wird, das ein unternehmensweites Datennetz orchestriert.

Holen Sie sich das eBook.

actian avatar logo

Über Actian Corporation

Actian macht Daten einfach. Unsere Datenplattform vereinfacht die Verbindung, Verwaltung und Analyse von Daten in Cloud-, Hybrid- und lokalen Umgebungen. Mit jahrzehntelanger Erfahrung in den Bereichen Datenmanagement und -analyse liefert Actian leistungsstarke Lösungen, die es Unternehmen ermöglichen, datengesteuerte Entscheidungen zu treffen. Actian wird von führenden Analysten anerkannt und wurde für seine Leistung und Innovation mit Branchenpreisen ausgezeichnet. Unsere Teams präsentieren bewährte Anwendungsfälle auf Konferenzen (z. B. Strata Data) und tragen zu Open-Source-Projekten bei. Im ActianBlog behandeln wir Themen wie Echtzeit-Dateneingabe, Datenanalyse, Data Governance, Datenmanagement, Datenqualität, Datenintelligenz und KI-gesteuerte Analysen.