Share via


Szenario „Data Mesh für Finanzinstitut“

Dieses Szenario ist für Kunden gedacht, die Cloud-Analysen für Skalierbarkeit und Datenvernetzungsarchitekturen nutzen möchten. Es demonstriert ein komplexes Szenario mit Landezonen, Datenintegrationen und Datenprodukten.

Kundenprofil

Ein fiktives Unternehmen, die Woodgrove Bank, ist ein großes Finanzdienstleistungsunternehmen mit weltweiter Präsenz. Die Daten der Woodgrove Bank befinden sich in Systemen vor Ort und in der Cloud. Innerhalb der Architektur der Woodgrove-Bank gibt es mehrere Data Warehouse-Systeme für konsolidiertes Marketing und eine integrierte Berichterstellung. Diese Architektur umfasst mehrere Data Lakes für Ad-hoc-Analysen und Datenermittlung. Viele Anwendungen der Woodgrove-Bank sind über Anwendungsintegrationsmuster miteinander verbunden, die größtenteils API- oder ereignisbasiert sind.

Aktuelle Situation

Für die Woodgrove Bank ist es aufgrund der Komplexität des Data Warehousing eine Herausforderung, Daten an verschiedene Standorte zu verteilen. Die Integration neuer Daten ist zeitaufwändig und begünstigt das Duplizieren von Daten. Für die Woodgrove Bank ist es aufgrund der Punkt-zu-Punkt-Konnektivität schwierig, die End-to-End-Datenlandschaft zu überblicken. Die Bank hat die Nachfrage nach intensivem Datenkonsum unterschätzt. Neue Anwendungsfälle werden schnell und sukzessive eingeführt. Die Datengovernance (z. B. Datenbesitz und -qualität) sowie die Kosten lassen sich kaum steuern. Die kontinuierliche Einhaltung aktueller Vorschriften ist schwierig, da die Woodgrove-Bank nicht genau weiß, wo sich ihre Daten befinden.

Architekturlösung: Data Mesh

In den letzten Jahren haben Unternehmen erkannt, dass Daten das absolute Herzstück sind. Daten ermöglichen neue effiziente Lösungen, fördern Innovationen, eröffnen neue Geschäftsmodelle und erhöhen die Kundenzufriedenheit. Es ist eine oberste Priorität für Unternehmen, datengesteuerte Methoden wie Daten im großen Stil zu verwenden.

Es ist eine Herausforderung, ein Stadium zu erreichen, in dem der tiefere Wert der Daten allen Mitgliedern des Unternehmens zugänglich ist. Ältere und eng miteinander verbundene Systeme, zentrale monolithische Plattformen und komplexe Governance können erhebliche Hindernisse für die Generierung von Mehrwert aus Daten sein.

Informationen zu Data Mesh

Das Data Mesh-Konzept (ein von Zhamak Dehghani geprägter Begriff) umfasst Daten, Technologie, Prozesse und Organisation. Konzeptionell handelt es sich um einen barrierefreien Ansatz für die Verwaltung von Daten, bei denen verschiedene Domänen ihre eigenen Daten verwenden. Datengitter stellen die Idee der herkömmlichen Zentralisierung von Daten in Frage. Anstatt Daten als ein riesiges Repository zu betrachten, berücksichtigt Data Mesh die Zerlegung in unabhängige Datenprodukte. Diese Umstellung vom zentralisierten zum Verbundbesitz stützt sich auf eine moderne Self-Service-Datenplattform, die in der Regel mithilfe cloudnativer Technologien gestaltet wird.

Beim Aufschlüsseln des Data Mesh-Konzepts in Einzelbausteine sind einige wichtige Punkte zu berücksichtigen:

  • Daten als Produkt (Data-as-a-Product): Jede (organisationsbezogene) Domäne verwaltet ihre Daten von Anfang bis Ende selbst. Die Verantwortlichkeit liegt innerhalb der Domäne beim Datenbesitzer. Insofern werden Pipelines zum vorrangigen Anliegen der Domänen selbst.
  • Computergestützte Datenverwaltung im Verbund: Um sicherzustellen, dass jeder Dateneigentümer den anderen vertrauen und seine Datenprodukte gemeinsam nutzen kann, muss ein Gremium für die Datenverwaltung im Unternehmen eingerichtet werden. Das Governance-Gremium implementiert Datenqualität, zentrale Sichtbarkeit des Datenbesitzes, Datenzugriffsverwaltung und Datenschutzrichtlinien.
  • Domänenorientiertes Dateneigentum: Das Unternehmen sollte idealerweise durch Anwenden des domänenorientierten Designs jeden Datendomänenknoten innerhalb des Netzes definieren und modellieren.
  • Self-Serve-Datenplattform: Ein Datennetz erfordert eine Datenplattform zur Selbstbedienung, die es den Benutzern ermöglicht, die technische Komplexität zu beseitigen und sich auf ihre individuellen Datenverwendungszwecke zu konzentrieren.

Analysen auf Cloudebene

Das Denken in Daten als Produkt und ein Selbstbedienungsplattformmodell sind für Microsoft nicht neu. Microsoft beobachtet seit vielen Jahren die bewährten Praktiken von verteilten Plattformen, domänenübergreifenden Pipelines, föderiertem Eigentum und selbsterklärenden Daten.

Die Woodgrove Bank kann durch den Einsatz von Cloud-Analysen zur Datenvernetzung übergehen. Analyse auf Cloudebene ist ein quelloffener und präskriptiver Entwurf für die Entwicklung und schnelle Bereitstellung moderner Datenplattformen. Es ist mit den Best Practices und Designprinzipien von Azure gekoppelt und auf das Azure Well-Architected Framework abgestimmt. Die Cloud-Analytik bietet Unternehmen eine zu 80 Prozent vorgeschriebene Sichtweise, und die restlichen 20 Prozent sind anpassbar.

Die Analyse auf Cloudebene eröffnet Unternehmen einen strategischen Entwurfspfad in Richtung Data Mesh und kann zum schnellen Einrichten einer solchen Architektur verwendet werden. Es bietet eine Blaupause, die auch die wichtigsten Datenplattformdienste für die Datenverwaltung enthält.

Auf oberster Ebene verwendet die Analyse auf Cloudebene eine Datenverwaltungsfunktion, die durch die Datenverwaltungszielzone aktiviert wird. Diese Zone ist für die Verbunddatengovernance einer Organisation der (Self-Service)-Plattform sowie für die Datendomänen verantwortlich, die durch Datenprodukte den Geschäftswert steigern. Der Vorteil dieses Ansatzes besteht darin, dass er die technische Komplexität beseitigt und gleichzeitig dieselben Standards beibehält. Dadurch wird eine Zunahme von Technologien verhindert. Dieser Ansatz bietet Unternehmen zudem die Möglichkeit, modular mit einem kleinen Fußabdruck zu beginnen und dann mit der Zeit zu wachsen.

Die im folgenden Diagramm abgebildete Datenverwaltungszielzone umfasst alle Datendomänen. Sie verknüpft alle Domänen miteinander und stellt die Überwachungsmöglichkeiten bereit, die sich die Woodgrove-Bank wünscht.

Das Diagramm zeigt, wie das Data Mesh-Konzept die Datenprodukte intelligent zwischen den Datendomänen verteilt.

Die Analyse auf Cloudebene fördert auch die Anwendung einer einheitlichen Governance, die beim Verteilen von Datenprodukten eine gemeinsame Architektur nutzt. Das Framework ermöglicht die direkte Kommunikation zwischen Domänen. Es behält die Kontrolle, indem es den Schwerpunkt auf eine zentrale Katalogisierung und Klassifizierung legt, um Daten zu schützen und es Gruppen zu ermöglichen, Daten zu finden. Es spannt sozusagen einen Schirm über Ihrem Datenbestand auf.

Datendomänen

Wenn Sie die Analyse auf Cloudebene als strategischen Pfad verwenden, müssen Sie über die Aufgliederung Ihrer Architektur und die daraus resultierende Granularität nachdenken. Data Mesh zerlegt Daten, indem es sich nicht an den Grenzen von Technologien orientiert. Stattdessen werden die Prinzipien des domänengesteuerten Designs (Domain-Driven Design, DDD) angewendet, ein Ansatz für die Softwareentwicklung, der komplexe Systeme für größere Organisationen umfasst. DDD ist wegen seiner Auswirkungen auf moderne Software- und Anwendungsentwicklungspraktiken wie Microservices beliebt.

Ein Muster des domänengesteuerten Designs wird als Kontextgrenzen bezeichnet. Kontextgrenzen werden verwendet, um die logischen Grenzen des Lösungsraums einer Domäne festzulegen und die Komplexität besser verwalten zu können. Es ist wichtig, dass die Teams verstehen, welche Aspekte, einschließlich der Daten, sie ändern können und welche Abhängigkeiten mit anderen koordiniert werden müssen. Das Datengitter umfasst einen begrenzten Kontext. Dieses Muster wird verwendet, um zu beschreiben, wie Organisationen datendomänenübergreifend koordinieren und sich auf die Bereitstellung von Daten als Produkt konzentrieren können. Jede Datendomäne besitzt und betreibt mehrere Datenprodukte mit ihrem eigenen Technologie-Stack, der von den anderen unabhängig ist.

Diagramm mit der Data Mesh-Architektur.

Datenprodukte

Wenn Sie sich die innere Architektur einer solchen Datendomäne genauer anschauen, erwarten Sie, darin Datenprodukte zu finden.

Datenprodukte erfüllen in Unternehmen, die Daten verwenden, einen bestimmten Bedarf. Datenprodukte dienen der domänenübergreifenden Verwaltung, Organisation und Auswertung von Daten und präsentieren anschließend die gewonnenen Erkenntnisse. Ein Datenprodukt ist das Ergebnis von Daten aus einer oder vielen Datenintegrationen und anderen Datenprodukten. Datenprodukte sind eng mit Datendomänen ausgerichtet und erben dieselbe konstruierte, formalisierte Sprache. Es wird von Projektbeteiligten und Designern vereinbart und dient den Anforderungen des Entwurfs. Jede Domäne, die Daten generiert, ist dafür verantwortlich, diese Datenprodukte für die anderen Domänen verfügbar zu machen.

Um die schnelle Bereitstellung von Datenprodukten zu unterstützen, bietet die Cloud-Analytik Vorlagen für die Datenverteilung und Integrationsmuster. Das Framework stellt Datenbatch, Streaming und Analysen bereit, um die Anforderungen einer Vielzahl von Kunden zu erfüllen.

Ein wichtiger Punkt bei der Analyse auf Cloudebene ist die Organisation der Domänen und Datenprodukte. Jede Datendomäne ist auf eine Datenlandezone ausgerichtet, die ein logisches Konstrukt und eine Skalierungseinheit in der Cloud-Analysearchitektur ist. Es ermöglicht die Datenaufbewahrung und Die Ausführung von Datenworkloads, wodurch Erkenntnisse und Wert generiert werden. Jedes Datenprodukt ist auf eine Ressourcengruppe innerhalb der Datenzielzone abgestimmt, und alle Datenzielzonen und Verwaltungszonen sind auf Abonnements ausgerichtet. Dieser Ansatz erleichtert die Implementierung und Verwaltung.

Alle Vorlagen für die Analyse auf Datenebene erben denselben Richtliniensatz von der Datenverwaltungszielzone. Die Vorlagen liefern automatisch die notwendigen Metadaten für die Auffindbarkeit von Daten, Governance, Sicherheit, Kostenmanagement und operative Exzellenz. Sie können neue Datendomänen schnell einbinden, ohne dass ein komplexes Einbinden, Integrieren und Testen erforderlich ist.

Aus dem folgenden Diagramm geht hervor, wie ein Datenprodukt aussehen kann:

Diagramm einer Datendomäne mit einem Datenprodukt.

Ein pragmatischer Ansatz beim Erstellen von Datenprodukten besteht entweder in der Ausrichtung an der Quelle, dem Ursprung der Daten, oder dem konsumierenden Anwendungsfall. In beiden Fällen müssen Sie eine abstrakte Ansicht des zugrunde liegenden (komplexen) Anwendungsdatenmodells bereitstellen. Sie müssen versuchen, die technischen Details auszublenden und eine Optimierung für eine intensive Datennutzung vorzunehmen. Eine Azure Synapse-Ansicht oder eine Parquet-Datei, die Daten logisch zusammenfasst, ist ein Beispiel dafür, wie ein Datenprodukt über verschiedene Datendomänen hinweg gemeinsam genutzt werden kann.

Als Nächstes müssen Sie an Auffindbarkeit, Ursprung, Nutzung und Herkunft der Daten arbeiten. Die Nutzung eines Datengovernance-Diensts (z. B. Azure Purview) ist ein bewährter Ansatz zum Registrieren aller Daten. Die Datenintegration in der Cloud-Analytik verbindet die Punkte perfekt, da sie die Erstellung dieser Datenprodukte ermöglicht, während sie gleichzeitig die Registrierung von Metadaten durchführt.

Durch das Abstimmen von Datendomänen und Azure Purview-Sammlungen erfassen Sie automatisch alle Datenursprungs-, Herkunfts-, Datenqualitäts- und Verbrauchsinformationen aus den einzelnen Domänen. Mit diesem Ansatz können Sie mehrere Datendomänen und Produkte zu einer zentralen Governancelösung verbinden, die alle Metadaten aus jeder Umgebung speichert. Der Vorteil besteht in der zentralen Integration aller Metadaten und dem einfachen Zugriff für verschiedene Kunden. Sie können diese Architektur erweitern und neue Datenprodukte registrieren.

Das folgende Diagramm zeigt eine domänenübergreifende Data Mesh-Architektur, für welche die Analyse auf Cloudebene verwendet wurde.

Diagramm der Datenintegration.

Der Netzwerkentwurf ermöglicht es, Datenprodukte domänenübergreifend zu nutzen, indem minimale Kosten anfallen und single point of failure und Bandbreiteneinschränkungen vermieden werden. Um die Sicherheit zu gewährleisten, können Sie das Sicherheitsmodell Zero Trust von Microsoft verwenden. Die Analyse auf Cloudebene schlägt die Verwendung der Netzwerkisolation über private Endpunkte und die private Netzwerkkommunikation vor. Das ist ein identitätsgesteuertes Datenzugriffsmodell, das verwaltete Identitäten (MIs), benutzerseitig zugewiesene verwaltete Identitäten (UMIs) und geschachtelte Sicherheitsgruppen verwendet und dem Prinzip des Zugriffs mit den geringsten Rechten folgt.

Mithilfe von verwalteten Identitäten können Sie ein Modell des Zugriffs mit den geringsten Rechten gewährleisten. Anwendungen und Dienste in diesem Modell haben eingeschränkten Zugriff auf Datenprodukte. Mit den kommenden Datenrichtlinien werden Azure-Richtlinien für die Self-Service-Lösung und für das bedarfsgerechte Erzwingen konformer Ressourcen in allen Datenprodukten verwendet. Mit diesem Design verfügen Sie über einen einheitlichen Datenzugriff und haben weiterhin volle Kontrolle über die zentrale Datengovernance und -überwachung.

Diagramm mit der Abbildung eines Datenvertrags.

Weiterentwicklung in Richtung Zukunft

Die Analyse auf Cloudebene ist auf die Vernetzung von Daten ausgerichtet. Die Analyse auf Cloudebene bietet einen bewährten Ansatz, mit dem Unternehmen Daten über viele Datendomänen hinweg gemeinsam nutzen können. Dieser Rahmen ermöglicht es Domänen, autonom Entscheidungen zu treffen, und regelt die Architektur, indem er sie mit Datenverwaltungsdiensten umgibt.

Wenn Sie ein Datennetz implementieren, sollten Sie Ihre Domänen logisch gruppieren und organisieren. Dieser Ansatz erfordert eine unternehmensweite Sichtweise und bedeutet wahrscheinlich einen kulturellen Wandel für Ihr Unternehmen. Die Umstellung setzt voraus, dass Sie den Datenbesitz zwischen Datendomänen und Besitzern, die für die Bereitstellung ihrer Daten als Produkte verantwortlich sind, in einem Verbund zusammenfassen. Außerdem müssen Teams sich an zentrale Funktionen anpassen, die von der Datenverwaltungszielzone angeboten werden. Mit diesem neuen Ansatz verlieren möglicherweise einzelne Teams ihre aktuellen Mandate, was zu Widerstand führen kann. Sie werden wahrscheinlich bestimmte politische Entscheidungen treffen und einen Ausgleich zwischen zentralen und dezentralen Ansätzen finden müssen.

Sie können eine Data Mesh-Architektur skalieren, indem Sie der Architektur weitere Zielzonen für einzelne Domänen hinzufügen. Diese Zielzonen stellen über das Peering virtueller Netzwerke eine Verbindung mit der Datenverwaltungszielzone und allen anderen Zielzonen her. Mit diesem Muster können Sie Datenprodukte und Ressourcen zonenübergreifend gemeinsam nutzen. Wenn Sie sich in separate Zonen aufteilen, können Sie Arbeitslasten über Azure-Abonnements und Ressourcen verteilen. Mit diesem Ansatz können Sie die Data Mesh-Lösung organisch implementieren.

Erfahren Sie mehr

Microsoft-Ressourcen:

Artikel von Zhamak Dehghani, Erfinderin des Data Mesh-Konzepts: