Ein Data Mesh ist ein Architektur- und Organisations-Framework, das Daten als Produkt behandelt (in diesem Dokument als Datenprodukte bezeichnet). In diesem Framework werden Datenprodukte von den Teams entwickelt, die diese Daten am besten verstehen und die einem organisationsweiten Satz von Data-Governance-Standards folgen. Sobald Datenprodukte im Data Mesh bereitgestellt wurden, können verteilte Teams in einer Organisation Daten schneller und effizienter ermitteln und darauf zugreifen, die für ihre Anforderungen relevant sind. Um ein solches gut funktionierendes Data-Mesh-Netzwerk zu erhalten, müssen Sie zuerst die übergeordneten Architekturkomponenten und organisatorischen Rollen einrichten, die in diesem Dokument beschrieben werden.
Dieses Dokument ist Teil einer Reihe, in der beschrieben wird, wie ein Data Mesh in Google Cloud implementiert wird. Dabei wird davon ausgegangen, dass Sie die Konzepte kennen, die unter Ein modernes verteiltes Data Mesh mit Google Cloud erstellen beschrieben werden.
Die Reihe besteht aus folgenden Teilen:
- Architektur und Funktionen in einem Data Mesh (dieses Dokument)
- Self-Service-Datenplattform für ein Data Mesh entwerfen
- Datenprodukte in einem Data Mesh erstellen
- Datenprodukte in einem Data Mesh ermitteln und nutzen
In dieser Reihe ist das beschriebene Data Mesh innerhalb einer Organisation intern. Obwohl es möglich ist, Data-Mesh-Architekturen so zu erweitern, dass Datenprodukte Dritten bereitgestellt werden können, wird dieser erweiterte Ansatz nicht in diesem Dokument besprochen. Die Erweiterung eines Data-Mesh-Netzwerks umfasst zusätzliche Aspekte, die über die Nutzung in einem Unternehmen hinausgehen.
Architektur
Die folgenden Schlüsselbegriffe werden zur Definition der in dieser Serie beschriebenen architektonischen Komponenten verwendet:
- Datenprodukt: Ein Datenprodukt ist ein logischer Container oder eine Gruppierung einer oder mehrerer zugehöriger Datenressourcen.
- Datenressource: Eine Datenressource ist ein physisches Asset in einem Speichersystem, das strukturierte Daten enthält oder eine Abfrage speichert, die strukturierte Daten ergibt.
- Datenattribut: Ein Datenattribut ist ein Feld oder Element in einer Datenressource.
Das folgende Diagramm bietet einen Überblick über die wichtigsten Architekturkomponenten eines in Google Cloud implmentierten Data-Mesh-Netzwerks.
Das obige Diagramm zeigt Folgendes:
- Zentrale Dienste ermöglichen das Erstellen und Verwalten von Datenprodukten, einschließlich Organisationsrichtlinien, die sich auf die Data Mesh-Teilnehmer auswirken, Zugriffssteuerungen (über Identitäts- und Zugriffsverwaltungsgruppen) und die infrastrukturspezifischen Artefakte. Beispiele für solche Zusicherungen und Reservierungen sowie der Infrastruktur, die die Funktion des Data-Mesh-Netzwerks ermöglicht finden sich unter Plattformkomponenten und -lösungen erstellen.
- Zentrale Dienste stellen hauptsächlich den Data Catalog für die verschiedenen Datenprodukte im Data-Mesh-Netzwerk und den Erkennungsmechanismus für potenzielle Kunden dieser Produkte bereit.
- Datendomains machen Teilmengen ihrer Daten als Datenprodukte über klar definierte Datennutzungsschnittstellen verfügbar. Diese Datenprodukte könnten Tabellen, Ansichten, strukturierte Dateien, Themen oder Streams sein. In BigQuery wäre dies ein Datenset, in Cloud Storage wäre es ein Ordner oder Bucket. Es können verschiedene Schnittstellentypen als Datenprodukt bereitgestellt werden. Ein Beispiel für eine Schnittstelle ist eine BigQuery-Ansicht einer BigQuery-Tabelle. Die am häufigsten für Analysezwecke verwendeten Oberflächentypen werden in Datenprodukte in einem Data-Mesh-Netzwerk erstellen diskutiert.
Referenzimplementierung für Data Mesh
Eine Referenzimplementierung dieser Architektur finden Sie im data-mesh-demo
-Repository.
Die in der Referenzimplementierung verwendeten Terraform-Scripts demonstrieren Data-Mesh-Konzepte und sind nicht für den Produktionseinsatz vorgesehen. Wenn Sie diese Skripte ausführen lernen Sie Folgendes:
- Trennen der Produktdefinitionen von den zugrunde liegenden Daten.
- Erstellen Sie Data Catalog-Vorlagen zum Beschreiben von Produktoberflächen.
- Taggen von Produktoberflächen mit diesen Vorlagen.
- Produktnutzern Berechtigungen gewähren.
Bei Produktoberflächen erstellt und verwendet die Referenzimplementierung die folgenden Oberflächentypen:
- Autorisierte Ansichten über BigQuery-Tabellen
- Datenstreams basierend auf Pub/Sub-Themen
Weitere Informationen finden Sie in der README-Datei im Repository.
Funktionen in einem Data Mesh
Damit ein Data Mesh gut funktioniert, müssen Sie klare Rollen für die Personen definieren, die Aufgaben im Data Mesh ausführen. Eigentümerschaft wird Team-Archetypen oder Funktionen zugewiesen. . Diese Funktionen erlauben das wichtigste Nutzerverhalten für Personen, die im Data Mesh arbeiten. Um Kundenerfahrungen klar zu beschreiben, wurden diese Nutzerrollen zugeordnet. Diese Nutzerrollen können je nach Situation des jeweiligen Unternehmens geteilt oder kombiniert werden. Sie müssen die Rollen nicht direkt Mitarbeitern oder Teams in Ihrer Organisation zuweisen.
Eine Datendomain ist an einer Geschäftseinheit (Business Unit) oder einer Funktion innerhalb eines Unternehmens ausgerichtet. Gängige Beispiele für Unternehmensbereiche sind die Hypothekenabteilung in einer Bank oder die Kunden-, Vertriebs-, Finanz- oder Personalabteilung eines Unternehmens. Konzeptionell gibt es in einem Data Mesh zwei bereichsbezogene Funktionen: die Teams Datenersteller und Datennutzer. Es ist wichtig zu verstehen, dass in der Regel beide Funktionen gleichzeitig von einer einzigen Datendomain bedient werden. Ein Datendomain-Team erstellt Datenprodukte aus eigenen Daten. Das Team nutzt außerdem Datenprodukte für geschäftliche Einblicke und um zu erstellen abgeleitete Datenprodukte für die Verwendung anderer Domains.
Neben den domainbasierten Funktionen hat ein Data Mesh auch eine Reihe Funktionen, die von zentralisierten Teams im Unternehmen ausgeführt werden. Diese zentralen Teams ermöglichen den Betrieb des Data Mesh, indem sie domainübergreifende Einsichten, Services und Governance bereitstellen. Sie reduzieren den operativen Aufwand für Datendomains bei der Erstellung und Nutzung von Datenprodukten und erleichtern die domainübergreifenden Beziehungen, die für den Betrieb des Data Mesh erforderlich sind.
In diesem Dokument werden nur Funktionen mit einer Data Mesh-spezifischen Rolle beschrieben. Es gibt noch einige weitere Rollen, die in jedem Unternehmen erforderlich sind, unabhängig von der für die Plattform eingesetzte Architektur. Diese anderen Rollen werden jedoch in diesem Dokument nicht behandelt.
Die vier Hauptfunktionen in einem Data Mesh sind:
- Domainbasierte Daten-Erstellerteams: Sie erstellen und verwalten Datenprodukte über ihren gesamten Lebenszyklus hinweg. Diese Teams werden oft als Datenersteller bezeichnet.
- Domainbasierte Daten-Nutzerteams: Ermitteln Sie Datenprodukte und verwenden Sie sie in verschiedenen Analyseanwendungen. Diese Teams können Datenprodukte aufnehmen, um neue Datenprodukte zu erstellen. Diese Teams werden oft als Datennutzer bezeichnet.
- Zentrales Data-Governance-Team: Definiert und erzwingt Data-Governance-Richtlinien unter Datenerstellern, was eine hohe Datenqualität und Vertrauenswürdigkeit der Daten für Verbraucher sichert. Dieses Team wird oft als Data-Governance-Team bezeichnet.
- Zentrales Team für die Self-Service-Dateninfrastrukturplattform: Bietet eine Self-Service-Datenplattform für Datenersteller. Dieses Team stellt auch Tools für die zentrale Datenerkennung und die Beobachtbarkeit von Datenprodukten bereit, die sowohl von Datennutzern als auch von Datenerstellern verwendet werden. Dieses Team wird oft als Datenplattformteam bezeichnet.
Eine optionale Zusatzfunktion, die Sie berücksichtigen sollten, ist die eines Kompetenzzentrums (Center of Excellence, COE) für das Data Mesh. Der Zweck eines COE besteht darin, die Datenverwaltung im Data Mesh zu ermöglichen. Das COE ist auch das vorgesehene Schiedgerichts-team, das Konflikte löst, die durch eine der anderen Funktionen ausgelöst wurden. Diese Funktion ist nützlich, um die anderen vier Funktionen zu verbinden.
Domainbasiertes Daten-Erstellerteam
In der Regel basieren Datenprodukte auf einem physischen Daten-Repository (ein oder mehrere Data Warehouses, Data Lakes oder Streams). Eine Organisation benötigt traditionelle Datenplattformrollen, um diese physischen Repositories zu erstellen und zu erhalten. Diese traditionellen Rollen für Datenplattformen sind jedoch in der Regel nicht identisch mit den Personen, die das Datenprodukt erstellen.
Zum Erstellen von Datenprodukten aus diesen physischen Repositories benötigt eine Organisation eine Mischung aus Datenexperten wie Data Engineers und Datenarchitekten. In der folgenden Tabelle sind alle domainspezifischen Nutzerrollen aufgeführt, die von Daten-Produzententeams benötigt werden.
Rolle |
Verantwortlichkeiten |
Erforderliche Kenntnisse |
Gewünschte Ergebnisse |
---|---|---|---|
Produktinhaber für Daten |
|
Datenanalyse Datenarchitektur Produktmanagement |
|
Technischer Leiter für Datenprodukte |
|
Data Engineering Datenarchitektur Softwaretechnik |
|
Unterstützung für Datenprodukte |
|
Softwareentwicklung Site Reliability Engineering (SRE) |
|
Experte (KMU) für Datendomain |
|
Datenanalyse Datenarchitektur |
|
Dateninhaber |
|
|
|
Domainbasierte Daten-Nutzerteams
In einem Data Mesh sind die Personen, die ein Datenprodukt nutzen, in der Regel Datennutzer, die sich außerhalb der Datenproduktdomain befinden. Diese Datenkonsumenten nutzen einen zentralen Data Catalog, um Datenprodukte zu finden, die für ihre Anforderungen relevant sind. Da es möglich ist, dass mehr als ein Datenprodukt ihre Anforderungen erfüllt, kann es passieren, dass Datennutzer mehrere Datenprodukte abonnieren.
Wenn Datennutzer das erforderliche Datenprodukt für einen Anwendungsfall nicht finden können, liegt es in ihrer Verantwortung, sich direkt an das Data-Mesh-COE zu wenden. Während dieser Beratung können Datennutzer ihre Datenanforderungen ansprechen und sich darüber informieren, wie sie diese Anforderungen von einer oder mehreren Domains erfüllen lassen können.
Bei der Suche nach einem Datenprodukt suchen Datennutzer nach Daten, mit denen sie verschiedene Anwendungsfälle wie nichtflüchtige Analyse-Dashboards und Berichte, einzelne Leistungsberichte und andere Leistungsmesswerte für Unternehmensleistung erreichen können. Alternativ suchen Datennutzer vielleicht nach Datenprodukten, die in Anwendungsfällen von künstlicher Intelligenz (KI) und maschinellem Lernen (ML) verwendet werden können. Um diese verschiedenen Anwendungsfälle zu erreichen, benötigen Datennutzer eine Mischung aus Datenexperten, die so aussieht:
Rolle |
Verantwortlichkeiten |
Erforderliche Kenntnisse |
Gewünschte Ergebnisse |
---|---|---|---|
Datenanalyst |
Sucht, identifiziert, evaluiert und abonniert Einzeldomain- oder domainübergreifende Datenprodukte, um eine Grundlage für den Betrieb von Business Intelligence-Frameworks zu schaffen. |
Analyse Engineering Geschäftsanalysen |
|
App-Entwickler |
Entwicklung eines Anwendungs-Frameworks für die Nutzung von Daten über einen oder mehrere Datenprodukte, innerhalb oder außerhalb der Domain. . |
Anwendungsentwicklung Data Engineering |
|
Spezialist für Datenvisualisierung |
|
Anforderungenanalyse Datenvisualisierung |
|
Data Scientist |
|
ML Entwicklung Analyseentwicklung |
|
Zentrales Data-Governance-Team
Dank dem Data Governance-Team können Datenersteller und -Nutzer Daten eigenständig sicher freigeben, aggregieren und berechnen, ohne Compliance-Risiken für das Unternehmen zu verursachen.
Um die Compliance-Anforderungen der Organisation zu erfüllen, besteht das Data-Governance-Team aus einer Mischung von Datenexperten, die so aussieht:
Rolle |
Verantwortlichkeiten |
Erforderliche Kenntnisse |
Gewünschte Ergebnisse |
---|---|---|---|
Data-Governance-Spezialist |
|
Recht KMU Sicherheit KMU Datenschutz KMU |
|
Datenverwalter (d. h. innerhalb jeder Domain) |
|
Datenarchitektur Data Stewardship |
|
Data Governance Engineer |
|
Softwaretechnik |
|
Zentrales Team für die Self-Service-Dateninfrastrukturplattform
Das Self-Service-Dateninfrastrukturplattform-Team, oder nur das Datenplattformteam genannt, ist für die Erstellung einer Reihe von Komponenten der Dateninfrastruktur verantwortlich. Verteilte-Datendomain-Teams verwenden diese Komponenten, um ihre Datenprodukte zu erstellen und bereitzustellen. Das Datenplattformteam fördert auch Best Practices und führt Tools und Methoden ein, mit denen die kognitive Belastung für verteilte Teams reduziert werden kann, wenn neue Technologien eingeführt werden.
Die Plattforminfrastruktur sollte eine einfache Einbindung von Betriebstools ermöglichen, um globale Beobachtbarkeit, Instrumentierung und Complianceautomatisierung zu ermöglichen. Alternativ sollte die Infrastruktur eine solche Integration erleichtern, um verteilte Teams erfolgreich zu machen.
Das Datenplattform-Team nutzt ein Modell der gemeinsamen Verantwortung zusammen mit dem Team für verteilte Domains und dem Team der zugrunde liegenden Infrastruktur. Das Modell zeigt, welche Verantwortlichkeiten von den Nutzern der Plattform erwartet werden und welche Plattformkomponenten das Datenplattformteam unterstützt.
Da die Datenplattform selbst ein internes Produkt ist, unterstützt sie nicht alle Anwendungsfälle. Stattdessen veröffentlicht das Datenplattform-Team kontinuierlich neue Dienste und Funktionen gemäß einer priorisierten Roadmap.
Das Datenplattformteam verfügt möglicherweise über einen Standardsatz an Komponenten, die sich an Ort und Stelle und in der Entwicklung befinden. Data Domain-Teams können jedoch einen anderen, eindeutigen Satz von Komponenten verwenden, wenn die Anforderungen eines Teams nicht mit denen der Datenplattform übereinstimmen. Wenn Datendomainteams einen anderen Ansatz wählen, müssen sie sicherstellen, dass jede von ihnen erstellte und verwaltete Plattforminfrastruktur den organisationsweiten Richtlinien und Leitlinien für die Sicherheit und Data Governance entspricht. Bei der Datenplattform-Infrastruktur, die außerhalb des zentralen Datenplattformteams entwickelt wurde, kann das Datenplattformteam entweder seine eigenen Entwickler in die Domainteams ausleihen oder in die Domainteams einbetten. Ob das Team der Datenplattform sich für Ausleihen oder Einbetten von Entwicklern entscheidet, hängt möglicherweise von der strategischen Bedeutung der Datendomain-Plattforminfrastruktur für das Unternehmen ab. Über die Einbindung der Infrastruktur von Datendomainteams können Organisationen die erforderliche Ausrichtung und das technische Fachwissen einbringen, um alle neuen Infrastrukturinfrastrukturen zu verpacken, die für die zukünftige Wiederverwendung entwickelt werden.
In den frühen Phasen der Erstellung eines Data Mesh müssen Sie möglicherweise die Autonomie einschränken, wenn es Ihr anfängliches Ziel ist, die Genehmigung der Stakeholder für die Vergrößerung des Data Mesh einzuholen. Das Einschränken der Autonomie birgt jedoch Risiken, einen Engpass im zentralen Datenplattform-Team zu schaffen. Dieser Engpass kann die Skalierung des Data Mesh beeinträchtigen. Zentralisierungsentscheidungen sollten sorgfältig getroffen werden. Für Datenersteller ist es möglicherweise besser, ihre technischen Auswahlen aus einer begrenzten Anzahl verfügbarer Optionen zu treffen, als selbst eine unbegrenzte Liste von Optionen zu evaluieren und auszuwählen. Die Autonomie der Datenersteller zu fördern, bedeutet nicht, dass eine unregulierte Technologielandschaft geschaffen wird. Stattdessen besteht das Ziel darin, die Compliance und die Plattformakzeptanz zu fördern, indem das richtige Gleichgewicht zwischen Wahlfreiheit und Standardisierung gefunden wird.
Ein gutes Datenplattformteam ist eine zentrale Quelle für die Weiterbildung und Best Practices für den Rest des Unternehmens. Einige der Aktivitäten mit den größten Auswirkungen, die wir für zentrale Datenplattformteams empfehlen, sind:
- Regelmäßige Überprüfung des Architekturdesigns für neue funktionale Projekte vorantreiben und Vorschlagen gängiger Entwicklungsmethoden über Entwicklungsteams hinweg
- Wissen und Erfahrungen teilen und Best Practices und Architekturrichtlinien gemeinsam definieren
- Sorgen Sie dafür, dass Entwickler die richtigen Tools haben, um gängige Stolperfallen und Probleme mit Code, Programmfehler und Leistungseinbußen zu validieren und darauf hin zu prüfen.
- Das Organisieren interner Hackathons, damit Entwicklungsteams ihre Anforderungen für interne Toolanforderungen publik machen können.
Beispielrollen und -Verantwortlichkeiten für das zentrale Datenplattformteam können Folgendes umfassen:
Rolle | Verantwortlichkeiten | Erforderliche Kenntnisse |
Gewünschte Ergebnisse |
---|---|---|---|
Produktinhaber der Datenplattform |
|
Datenstrategie und -betrieb Produktmanagement Stakeholder-Management |
|
Daten Platform Entwickler |
|
Data Engineering Softwaretechnik |
|
Platform and Security Engineer (ein Vertreter des zentralen IT-Teams, z. B. im Bereich Netzwerk oder Sicherheit, der in das Datenplattformteam eingebunden ist) |
|
Infrastrukturtechnik Softwaretechnik |
|
Unternehmensarchitekt |
|
Datenarchitektur Lösungsiteration und Problemlösung Konsensbildung |
|
Weitere Überlegungen zum Data Mesh
Es gibt mehrere Architekturoptionen für eine Analysedatenplattform, die jeweils unterschiedliche Voraussetzungen haben. Wir empfehlen, dass Ihre Organisation bei allen Data-Mesh-Architekturen die in diesem Abschnitt beschriebenen Best Practices befolgt. .
Plattformfinanzierung einwerben
Wie im Blogpost „If you want to transform start with finance“ erläutert, ist die Plattform nie abgeschlossen: Sie basiert immer auf einer priorisierten Roadmap. Entsprechend muss die Plattform als Produkt und nicht als Projekt mit einem festen Endpunkt finanziert werden.
Der erste Nutzer des Data Mesh trägt die Kosten. Normalerweise werden die Kosten zwischen dem Unternehmen, das die erste Datendomain bildet, um das Data Mesh zu initiieren, und dem zentralen Technologieteam geteilt, in dem in der Regel das zentrale Datenplattformteam untergebracht ist.
Damit Finanzteams die Finanzierung für die zentrale Plattform genehmigen, empfiehlt es sich, für den Mehrwert der zentralisierten Plattform zu argumentieren, der im Laufe der Zeit realisiert werden wird. Dieser Wert ergibt sich aus der Neu-Implementierung der gleichen Komponenten in einzelnen Bereitstellungsteams.
Minimale funktionsfähige Plattform für das Data Mesh definieren
Damit Sie die minimal funktionsfähige Plattform für das Data Mesh definieren können, empfehlen wir Ihnen, einen oder mehrere Geschäftsfälle als Pilotprojekt durchzuführen und zu iterieren. Suchen Sie für Ihr Pilotprojekt nach benötigten Anwendungsfällen und für die es einen Kunden gibt, der bereit ist, das resultierende Datenprodukt zu übernehmen. Die Anwendungsfälle sollten bereits Finanzierung für die Entwicklung der Datenprodukte haben, aber es sollte ein Bedarf an Beiträgen von technischen Teams bestehen.
Das Team, das das Pilotprojekt implementiert, muss das Data Mesh-Betriebsmodell verstehen, das nun erläutert:
- Das Unternehmen (d. h. das Datenerstellerteam) ist Inhaber des Rückstands, des Supports und der Wartung.
- Das zentrale Team definiert die Self-Service-Muster und unterstützt das Unternehmen bei der Erstellung des Datenprodukts, übergibt dieses nach Abschluß der Erstellung aber an da Unternehmen, das es dann ausführt und besitzt.
- Das Hauptziel ist der Beweis für das Geschäftsmodell (Domains erstellen, Domains konsumieren). Das sekundäre Ziel besteht darin, das technische Betriebsmodell zu bestätigen (Self-Service-Muster, die vom zentralen Team entwickelt wurde).
- Da die Ressourcen des Plattformteams begrenzt sind, verwenden Sie das Modell Trunk- und Branch-Teams, um Wissen zu bündeln, aber dennoch die Entwicklung spezialisierter Plattformdienste und -produkte zu ermöglichen.
Außerdem empfehlen wir Folgendes:
- Planen Sie Roadmaps, anstatt Dienstleistungen und Features auf natürliche Weise weiterzuentwickeln.
- Definieren Sie minimalen Funktionen für eine funktionsfähige Plattform, die Datenaufnahme, Speicherung, Verarbeitung, Analyse und ML umfassen.
- Betten Sie Data Governance in jeden Schritt ein, nicht als separaten Workstream.
- Bestimmen Sie die Mindestfunktionen für Governance, Plattform, Wertstrom und das Veränderungsmanagement. Mindestfunktionen sind diejenigen, die 80 % der Geschäftsfälle erfüllen.
Die parallele Bereitstellung des Data Mesh mit einer bestehenden Datenplattform planen
Viele Organisationen, die ein Data Mesh implementieren möchten, haben wahrscheinlich bereits eine Datenplattform, z. B. einen Data Lake, ein Data Warehouse oder eine Kombination aus beiden. Bevor ein Data Mesh implementiert wird, müssen diese Organisationen einen Plan für die Weiterentwicklung ihrer vorhandenen Datenplattform erstellen, wenn das Data Mesh dann wächst.
Diese Unternehmen sollten unter anderem die folgenden Faktoren berücksichtigen:
- Die Datenressourcen, die im Data Mesh am effektivsten sind.
- Assets, die auf der vorhandenen Datenplattform verbleiben müssen.
- Ob Assets verschoben werden müssen oder ob sie auf der vorhandenen Plattform verwaltet werden können und dennoch Teil des Data Mesh sind.
Nächste Schritte
- Weitere Informationen zum Entwerfen und Betreiben einer Cloud-Topologie finden Sie unter Google Cloud-Architektur-Framework.
- Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.