🌗 👨‍👩‍👧‍👦 🚐 Migration von einem nahtlosen Data Lake zu einem verteilten Data Mesh 👳 💾 🕍

Hallo Habr! Ich präsentiere Ihnen die Übersetzung des Artikels „Wie man sich über einen monolithischen Datensee hinaus zu einem verteilten Datennetz bewegt “ von Zhamak Dehghani (Zhamak Degani) (alle Bilder stammen aus demselben Artikel).

Alle großen Unternehmen versuchen nun, riesige zentralisierte Data Warehouses zu bauen. Oder noch größere Cluster-Data Lakes (in der Regel auf einem HDUP). Ich kenne jedoch kein einziges Beispiel für den erfolgreichen Aufbau einer solchen Datenplattform. Überall sind Schmerzen und Leiden sowohl für diejenigen, die eine Datenplattform aufbauen, als auch für Benutzer. Im folgenden Artikel bietet der Autor (Zhamak Degani) einen völlig neuen Ansatz zum Aufbau einer Datenplattform. Dies ist die Architektur der Datenplattform der vierten Generation namens Data Mesh. Der Originalartikel in englischer Sprache ist sehr umfangreich und ehrlich gesagt schwer zu lesen. Die Übersetzung erwies sich auch als ziemlich groß und der Text ist nicht sehr einfach: lange Sätze, eher trockener Wortschatz. Ich habe die Gedanken des Autors nicht neu formuliert, um die Richtigkeit des Wortlauts zu gewährleisten.Ich empfehle Ihnen jedoch dringend, diesen schwierigen Text noch durchzuarbeiten und den Artikel zu lesen. Für diejenigen, die sich mit Daten beschäftigen, wird es sehr nützlich und sehr interessant sein.

Evgeny Cherny

Viele Unternehmen investieren in die nächste Generation von Data Lake in der Hoffnung, den unternehmensweiten Datenzugriff zu vereinfachen, geschäftliche Erkenntnisse zu liefern und automatisch qualitativ hochwertige Entscheidungen treffen zu können. Gegenwärtige Ansätze zum Aufbau von Datenplattformen weisen jedoch ähnliche Probleme auf, die es uns nicht ermöglichen, unsere Ziele zu erreichen. Um diese Probleme zu lösen, müssen wir das Paradigma eines zentralisierten Data Lake (oder seines Vorgängers, des Data Warehouse) aufgeben. Und gehen Sie zu einem Paradigma über, das auf einer modernen verteilten Architektur basiert: Betrachten Sie Geschäftsdomänen als Priorität der ersten Ebene, wenden Sie Plattformdenken an, um eine Infrastruktur mit der Fähigkeit zur Selbstbedienung und Wahrnehmung von Daten als Produkt zu schaffen.

Bild

Inhalt

Die aktuelle Architektur der Datenplattform in einem großen Unternehmen
- Problematische architektonische Ansätze
- domain driven
  - -
  - (data pipelines),
- - - (discoverable)
    - (addressable)
    - ,
- data- -
- Zentralisierte Dateninfrastruktur als Plattform
Paradigmenwechsel in Richtung Data Mesh

Der Aufbau einer datengesteuerten Organisation bleibt eines der wichtigsten strategischen Ziele vieler Unternehmen, mit denen ich zusammenarbeite. Meine Kunden sind sich der Vorteile bewusst, Entscheidungen auf der Grundlage hochwertiger Daten zu treffen: Gewährleistung der höchsten Qualität des Kundendienstes, Hyperpersonalisierung, Reduzierung der Betriebskosten und der Zeit aufgrund von Optimierungen, Bereitstellung von Analyse- und Geschäftsanalysetools für die Mitarbeiter. Sie investieren viel in den Aufbau moderner Datenplattformen. Trotz wachsender Anstrengungen und Investitionen in den Aufbau solcher Plattformen sehen viele Unternehmen die Ergebnisse als mittelmäßig an.

Unternehmen stehen bei der Umwandlung in ein datengesteuertes Unternehmen vor vielen Schwierigkeiten: Migration von Legacy-Systemen und jahrzehntelangen Entwicklungssystemen, Widerstand aus der bestehenden Kultur und starker Wettbewerb zwischen verschiedenen Geschäftsprioritäten. Wie dem auch sei, ich möchte Ihnen einen architektonischen Ansatz vorstellen, der die Gründe für das Scheitern vieler Initiativen im Bereich des Aufbaus von Datenplattformen berücksichtigt. Ich werde zeigen, wie wir die Lehren des letzten Jahrzehnts beim Aufbau verteilter Architekturen im Datenbereich anpassen und anwenden können. Ich habe diesen neuen architektonischen Ansatz Data Mesh genannt .

Bevor Sie weiterlesen, bitte ich Sie, beim Lesen dieses Artikels zu versuchen, die Vorurteile abzubauen, die durch das aktuelle Paradigma der traditionellen Datenplattformarchitektur entstanden sind. Seien Sie offen für die Möglichkeit, von zentralisierten Data Lakes zu einer bewusst verteilten Data Mesh-Architektur zu wechseln. Akzeptieren Sie, dass Daten von Natur aus verteilt und allgegenwärtig sind.

Die aktuelle Architektur der Datenplattform in einem großen Unternehmen

Lassen Sie uns über die zentralisierte, monolithische und geschäftsunabhängige Bedeutung von Data Lake-Daten sprechen.

Fast jeder Kunde, mit dem ich zusammenarbeite, plant oder baut bereits seine Datenplattform der dritten Generation. Die Fehler früherer Generationen erkennen.

Erste Generation: proprietäre Enterprise Data Warehouses und Business Intelligence-Plattformen. Dies sind Entscheidungen für große Geldsummen, bei denen Unternehmen ebenso große technische Schulden hatten. Technische Schulden sind in Tausenden von nicht unterstützten ETL-Jobs, Tabellen und Berichten enthalten, die nur eine kleine Gruppe von Spezialisten versteht, was zu einer Unterschätzung der positiven Auswirkungen dieser Funktionalität auf das Geschäft führt.
Zweite Generation: Big Data-Ökosysteme mit Data Lake als Silberkugel. Ein komplexes Ökosystem aus Big Data und lang laufenden Batch-Jobs, das von einem zentralen Team hochspezialisierter Dateningenieure unterstützt wird. Bestenfalls für F & E-Analysen verwendet.

Datenplattformen der dritten Generation sind früheren Generationen mehr oder weniger ähnlich, jedoch mit einer Tendenz zu

Streaming, um Datenverfügbarkeit in Echtzeit mit einer Architektur wie Kappa bereitzustellen ,
Kombinieren der Stapel- und Streaming-Verarbeitung zur Transformation von Daten mithilfe von Frameworks wie Apache Beam ,
Nutzung von Cloud-Diensten zur Datenspeicherung und -verarbeitung sowie von Cloud-Plattformen für maschinelles Lernen.

Die Datenplattform der dritten Generation beseitigt einige der Probleme früherer Generationen, wie z. B. die Echtzeit-Datenanalyse, und senkt auch die Kosten für die Verwaltung einer Big-Data-Infrastruktur. Viele zugrunde liegende Merkmale, die zum Versagen früherer Generationen geführt haben, bleiben jedoch erhalten.

Bild

Abbildung 1: Drei Generationen von Datenplattformen

Problematische architektonische Ansätze

Um die grundlegenden Einschränkungen aufzudecken, die alle Generationen von Datenplattformen für sich haben, schauen wir uns ihre Architektur und Funktionen an. In diesem Artikel werde ich das Geschäft mit dem Streaming von Internetmedien (wie Spotify, SoundCloud, Apple iTunes) als Beispiel verwenden, um einige Konzepte zu erläutern.

Zentralisiert und monolithisch

Aus einer Höhe von 10.000 Metern sieht die Architektur der Datenplattform wie in Abbildung 2 unten aus.
Bild

Abbildung 2: Ansicht aus einer Höhe von 10.000 Metern auf einer monolithischen Datenplattform. Der

zentrale Teil der Architektur ist verantwortlich für:

(to ingest) , , . , , : ; ; ; , ; ( ..).
, , , . , , — .
(to serve) . machine learning BI . , . , Kafka.

Standardmäßig ist die allgemein akzeptierte Vereinbarung die Tatsache, dass die monolithische Datenplattform Daten speichert und besitzt, die zu verschiedenen Geschäftsdomänen gehören. Zum Beispiel "Ereignisse abspielen", "Verkaufs-KPIs", "Künstler", "Alben", "Labels", "Audio", "Podcasts", "Musikereignisse" usw. - Daten aus einer Vielzahl unterschiedlicher Domänen.

Trotz der Tatsache, dass wir in den letzten zehn Jahren das Konzept des domänengesteuerten Designs (und sein Schlüsselmuster für den begrenzten Kontext ) erfolgreich auf das Design unserer Informationssysteme angewendet haben , haben wir diese Konzepte beim Design von Datenplattformen weitgehend ignoriert. Wir sind unabhängig von den Geschäftsdomänen vom Dateneigentum auf Geschäftsdomänenebene zum Dateneigentum übergegangen. Wir sind stolzdas schuf den größten Monolithen - die Big Data Platform.

Bild

Abbildung 3: Eine zentralisierte Datenplattform ohne klare Grenzen zwischen Daten aus verschiedenen Geschäftsbereichen. Und ohne das Eigentum an den relevanten Daten durch die Geschäftsdomäne kann ein

solches zentrales Modell für kleine Organisationen funktionieren, die über einfache Geschäftsdomänen und begrenzte Datenverbrauchsoptionen verfügen. Es ist jedoch nicht für große Unternehmen mit großen und komplexen Geschäftsbereichen, einer großen Anzahl von Datenquellen und unterschiedlichen Anforderungen an die Arbeit mit Daten von Verbrauchern geeignet.

Es gibt zwei Schwachstellen in der Architektur und Struktur einer zentralisierten Datenplattform, die häufig zu Fehlern beim Aufbau führen:

Eine große Anzahl von Quellen und große Datenmengen. , , . , . . , , , . , data scientists . , ( ) , . , – - .
. . , . .

Hier muss ich klarstellen, dass ich mich nicht für die Verwendung fragmentierter, unterschiedlicher Daten ausspreche, die in den Tiefen älterer Systeme verborgen sind. Solche Daten, die schwer zu erkennen, zu verstehen und zu verwenden sind. Ich unterstütze auch nicht die zahlreichen unterschiedlichen Data Warehouses innerhalb derselben Organisation, die das Ergebnis langjähriger akkumulierter technischer Schulden sind. Ich behaupte jedoch, dass die Antwort auf solche unzugänglichen fragmentierten Daten nicht darin besteht, eine zentralisierte Datenplattform mit einem zentralisierten Team zu erstellen, das Daten aus allen Geschäftsbereichen speichert und besitzt.

Dieser Ansatz lässt sich in großen Organisationen nicht skalieren, wie oben gezeigt.

Stark verbundene Fördererzersetzung

Abbildung 4: Architektonische Zerlegung der Datenplattform

Das zweite Problem bei der traditionellen Architektur der Datenplattform besteht darin, wie wir die Architektur zerlegen. Wenn es auf 3.000 Meter über der Architektur der Datenplattform abfällt, finden wir eine architektonische Zerlegung um die Funktionen Laden, Bereinigen, Aggregieren, Bereitstellen von Daten usw. Wie im vorherigen Abschnitt beschrieben, erfordert die Notwendigkeit, neue Quellen und neue Verbraucher zu verbinden, ein Plattformwachstum. Architekten müssen einen Weg finden, das System zu skalieren, indem sie es in architektonische Quanten zerlegen. Architekturquantum, wie im Buch „ Building Evolutionary Architectures”, Ist eine unabhängig einsetzbare Komponente mit hoher funktionaler Konnektivität, die alle für den ordnungsgemäßen Betrieb des Systems erforderlichen Strukturelemente enthält. Die Motivation, das System in Architekturquanten zu unterteilen, besteht hauptsächlich darin, unabhängige Teams zu bilden, von denen jedes sein eigenes Architekturquantum (funktionales Subsystem) erstellt und aufrechterhält. Auf diese Weise können Sie die Arbeit parallelisieren und die Geschwindigkeit und Skalierbarkeit des Betriebs erhöhen.

Von früheren Generationen von Datenplattformen beeinflusst, unterteilen Architekten die Plattform in eine Reihe von Datenverarbeitungsschritten. Dies ist eine Pipeline, die die Datenverarbeitung implementiert: Laden, Vorbereiten, Aggregieren, Bereitstellen des Zugriffs / Entladens usw.

Obwohl diese Partitionierung ein gewisses Maß an Skalierung bietet, weist sie auch eine interne Einschränkung auf, die die Entwicklung neuer Funktionen auf der Plattform verlangsamt: Es besteht eine hohe Konnektivität zwischen den Schritten der Pipeline, die nicht die erforderliche Unabhängigkeit der Arbeit einzelner Teams ermöglicht.

Kehren wir zu unserem Beispiel für Streaming-Medien zurück. Die Streaming-Media-Plattformen im Internet haben ein starkes Domain-Design in Bezug auf die Art der von ihnen angebotenen Medien. Sie beginnen ihre Dienste häufig mit „Songs“ und „Alben“ und gelten dann für „Musikereignisse“, „Podcasts“, „Radiosendungen“, „Filme“ usw. Aktivieren einer neuen Funktion, z. B. Sichtbarkeit für „Podcasts“. Wiedergaberate “erfordert eine Änderung aller Komponenten der Pipeline. Die Teams müssen neue Dienste zum Laden, Bereinigen und Vorbereiten von Daten (einschließlich Aggregation) entwickeln, um die Sichtbarkeit der „Podcasts-Wiedergaberate“ zu verbessern. Dies erfordert eine Synchronisation zwischen den Releases verschiedener Funktionsteams. Viele Datenplattformen verwenden konfigurationsbasierte Download-Tools, mit denen solche Aufgaben problemlos erledigt werden können.wie einfach neue Quellen hinzuzufügen oder bestehende zu erweitern. Dies beseitigt jedoch nicht die Notwendigkeit eines End-to-End-Release-Managements in allen Phasen der Datenverarbeitungspipeline. Um Benutzern den Zugriff auf neue Daten zu ermöglichen, muss lediglich die gesamte Pipeline geändert werden. Dies schränkt unsere Fähigkeit, die Geschwindigkeit und den Umfang der Entwicklung der Datenplattform als Reaktion auf das Aufkommen neuer Datenquellen und Benutzer zu erhöhen, erheblich ein.Dies schränkt unsere Fähigkeit, die Geschwindigkeit und den Umfang der Entwicklung der Datenplattform als Reaktion auf das Aufkommen neuer Datenquellen und Benutzer zu erhöhen, erheblich ein.Dies schränkt unsere Fähigkeit, die Geschwindigkeit und den Umfang der Entwicklung der Datenplattform als Reaktion auf das Aufkommen neuer Datenquellen und Benutzer zu erhöhen, erheblich ein.

Unterschiedliche und hochspezialisierte Teams

Das dritte Problem bei modernen Datenplattformen besteht darin, wie wir die Teams strukturieren, die die Plattform erstellen und warten. Wenn wir uns mit der Architektur einer herkömmlichen Datenplattform befassen, werden wir eine Gruppe eng spezialisierter Dateningenieure sehen, die von den Organisationseinheiten getrennt sind, in denen Daten erstellt oder für die Entscheidungsfindung verwendet werden. Datenplattformingenieure werden nur aufgrund ihrer technischen Kompetenzen und ihrer Erfahrung mit Big-Data-Technologien in separaten Teams ausgewählt. In solchen Teams fehlen betriebswirtschaftliche Kenntnisse der entsprechenden Themenbereiche (Geschäftsbereiche).

Bild

Abbildung 5: Verstreute, eng spezialisierte Datenplattformteams

Persönlich beneide ich das Leben von Datenplattformingenieuren nicht. Sie sollten Daten von Teams erhalten, die keinen Anreiz haben, qualitativ hochwertige und korrekte Daten bereitzustellen. Ihnen fehlt ein Verständnis für die geschäftliche Bedeutung der Daten, die Sie herunterladen müssen. Sie müssen Daten vorbereiten, um die analytischen und betrieblichen Anforderungen zu erfüllen, ohne ein klares Verständnis der Endverwendung dieser Daten zu haben und ohne Zugang zu Experten auf dem Gebiet des Verbrauchs dieser Daten.

Es sollte beachtet werden, dass wir zuvor auf ein ähnliches Problem der Teamtrennung gestoßen sind. Und sie konnten eine erfolgreiche Lösung für dieses Problem finden.

Bild

In unserem Beispiel mit Multimedia-Streaming haben wir den Befehl „Media Player“, der Daten darüber enthält, wie Benutzer mit dem Player interagieren: Songs, die Benutzer hören, getätigte Käufe, Audioqualität der Songs, die sie hören usw. Auf der anderen Seite gibt es Verbraucherteams mit relevanten Daten: ein Team von Songempfehlungen; Verkaufsüberwachungsteam; Künstler-Zahlungsteam usw. Und zwischen ihnen ein trauriges Team von Entwicklern einer Datenplattform, die auf Kosten eines großen Aufwands Daten von einem Team empfängt und allen Verbrauchern (nach vorläufiger Verarbeitung) Zugriff darauf gewährt.

In Wirklichkeit haben wir unbeteiligte Teams von Datenquellen und frustrierte Teams von Datenkonsumenten, die um einen Platz an der Spitze des Rückstands des Datenplattform-Entwicklungsteams kämpfen müssen.

Wir haben eine Architektur und Organisationsstruktur geschaffen, die nicht die erforderliche Skalierbarkeit bietet und die Ziele des Aufbaus einer datengesteuerten Organisation nicht erreichen kann.

Datenplattformarchitektur der nächsten Generation

Und was ist die Lösung für die oben diskutierten Probleme? Meiner Meinung nach ist ein Paradigmenwechsel erforderlich. Ein Paradigmenwechsel an der Schnittstelle von Methoden, die eine wichtige Rolle beim Aufbau einer modernen skalierbaren verteilten Architektur gespielt haben und die die gesamte Technologiebranche beschleunigt implementiert hat. Methoden, die zu erfolgreichen Ergebnissen geführt haben.

Ich glaube, dass die nächste Architektur für Unternehmensdatenplattformen darin besteht, die Distributed Domain Driven Architecture zu integrieren, Self-Service-Plattformen zu entwerfen und Produkte für Daten zu denken.

Bild

Abbildung 6: Wechsel des Paradigmenwechsels der Datenplattform der nächsten Generation.

Ich verstehe, dass dies wie viele Schlagworte in einem Satz klingt, aber jede dieser Komponenten hat sich unglaublich positiv auf die Änderung der technischen Grundlagen unserer Informationssysteme ausgewirkt. Lassen Sie uns sehen, wie wir jede dieser Disziplinen auf die Datenwelt anwenden können, um uns von dem aktuellen Paradigma zu entfernen, das aus vielen Jahren des Aufbaus von Data Warehouses früherer Generationen übernommen wurde.

Daten- und verteilte domänengesteuerte Architektur

Zerlegung und Besitz von Daten basierend auf der Ausrichtung der Geschäftsdomäne

Das Buch von Eric Evans, Domain-Driven Design , hat das zeitgenössische architektonische Denken und damit die Organisationsmodellierung tiefgreifend beeinflusst. Die neue Microservice-Architektur zerlegte Informationssysteme in verteilte Services, die innerhalb der Grenzen bestimmter Geschäftsbereiche erstellt wurden. Dies hat die Art und Weise, wie Teams gebildet werden, grundlegend verändert: Von nun an kann ein Team seine Microservices unabhängig und autonom besitzen.

Interessanterweise haben wir das Konzept der Geschäftsdomänen im Datenbereich ignoriert. Kommende Anwendung von domänengesteuertem Design in der Datenplattformarchitektur: Dies ist die Entstehung von Geschäftsdomänenereignissenin Informationssystemen und deren Laden in monolithische Datenplattformen. Nach dem Hochladen der Daten in den zentralen Speicher geht jedoch das Konzept des Eigentums an Daten aus verschiedenen Geschäftsbereichen durch verschiedene Teams verloren.

Um eine monolithische Datenplattform zu dezentralisieren, müssen Sie Ihre Meinung zu Daten, ihrem Standort und ihrem Besitz ändern. Anstatt Daten an einen Data Lake oder eine Plattform zu übertragen, sollten Domänen ihre Datensätze benutzerfreundlich speichern und verwalten.

In unserem Beispiel können Sie diese Datensätze nicht in der Domäne speichern und verarbeiten, anstatt Daten vom Media Player in ein zentrales Repository zur weiteren Verarbeitung durch das Repository-Supportteam zu laden und keinem anderen Team Zugriff darauf zu gewähren. Der Ort, an dem diese Datensätze physisch gespeichert werden, kann nach Ihren Wünschen technisch innerhalb der Domäne implementiert werden. Natürlich können Sie eine zentralisierte Architektur verwenden, aber die Daten der Mediaplayer selbst bleiben im Besitz und unter der Unterstützung des Teams der entsprechenden Domäne, in der diese Daten generiert werden. In unserem Beispiel kann die Entwicklungsdomäne für Songempfehlungen Datensätze in dem Format erstellen, das für die Verwendung am besten geeignet ist (z. B. in Form von Diagrammstrukturen), basierend auf Daten vom Media Player. Wenn es andere Teams gibt,Wer dieses Format für bequem und nützlich hält, kann auch darauf zugreifen.

Dies bedeutet natürlich, dass wir Daten in verschiedenen Domänen duplizieren können, wenn wir ihr Format in ein Format ändern, das für einen bestimmten Verbraucher geeignet ist.

All dies erfordert eine Verschiebung unseres Denkens vom Herunterladen von Daten (über ETL oder Streaming) zur Skalierung dieses Prozesses auf alle Domänen. Das Architekturquantum in einer domänenorientierten Datenplattform ist eine Geschäftsdomäne, nicht die Phase des Ladens und Transformierens von Daten.

Bild

Abbildung 7: Zerlegung einer Architektur basierend auf Geschäftsdomänen und datenbesitzenden Teams.

Quelldomänen-Datasets

Einige Geschäftsbereiche sind gut auf Datenquellen (Informationssysteme) abgestimmt. Im Idealfall sind das Informationssystem und das dazugehörige Team nicht nur für das Hinzufügen und Unterstützen von Geschäftsfunktionen verantwortlich, sondern stellen auch Datensätze bereit, die die Fakten und die Realität des entsprechenden Geschäftsbereichs beschreiben. Auf der Ebene einer großen Organisation besteht jedoch in der Regel keine eindeutige Entsprechung zwischen der Geschäftsdomäne und dem Informationssystem. In der Regel gibt es für jede Domäne mehrere Informationssysteme, die unterschiedliche Geschäftsprozesse einer bestimmten Domäne automatisieren und dementsprechend zugehörige Daten speichern. Für solche Domänen müssen unterschiedliche Daten integriert und aggregiert werden, um Datensätze zu erhalten, die über die gesamte Geschäftsdomäne hinweg konsistent und ausgerichtet sind.

Das beste Format zum Speichern von Fakten, die eine Geschäftsdomäne beschreiben, ist Domain Events . Sie können als verteiltes Ereignisprotokoll mit Zeitstempeln gespeichert werden. Dieses Protokoll kann autorisierten Verbrauchern Zugriff gewähren.

Zusätzlich zu diesen Protokollen müssen Datenquellen auch Zugriff auf regelmäßige Snapshots von Schlüsseldatensätzen in ihrer Domäne bieten. Das Zusammenfassen solcher Bilder bezieht sich auf das Zeitintervall, das das Änderungsintervall für Ihre Domain besser widerspiegelt (normalerweise ein Tag / eine Woche / ein Monat / ein Quartal usw.).

Bitte beachten Sie, dass für Verbraucher vorbereitete Geschäftsdomänendatensätze von internen Quellendatensätzen (die Informationssysteme für ihre Arbeit verwenden) getrennt werden sollten. Sie sollten an einem physisch anderen Ort gespeichert werden, der für die Arbeit mit Big Data geeignet ist. Als nächstes wird beschrieben, wie eine solche Data Warehouse- und Service-Infrastruktur dafür erstellt wird.

Für Verbraucher erstellte domänenspezifische Datensätze sind die grundlegendsten Elemente der gesamten Architektur. Sie transformieren sich nicht und sind nicht auf einen bestimmten Verbraucher zugeschnitten, sondern sind Rohdaten und unverarbeitete Daten.

Consumer-Domain-Datasets

Andere Domänen sind eng mit Datenkonsumenten verbunden. Die Datensätze einer solchen Domäne werden so erstellt, dass sie bei Verwendung zu den zugehörigen Benutzerszenarien passen. Diese Datasets unterscheiden sich von Quelldomänendatensätzen. Dies sind keine Rohdaten, sondern Daten, die mehrere Transformationsstufen durchlaufen haben. Die Struktur dieser Datensätze und ihre Darstellung sind auf die spezifischen Fälle ihrer Verwendung zugeschnitten. Jene. Dies ist ein Analogon zu spezialisierten Data Marts in einem zentralen Repository. Für solche Datensätze der Consumer Domain (Consumer Domain Datasets) sollte die Möglichkeit einer schnellen Wiederherstellung aus Rohdaten bereitgestellt werden.

Verteilte Datenpipelines, die in ihren Domänen implementiert sind

Das Eigentum an Daten in unserer neuen Architektur wird von der zentralen Plattform an Teams innerhalb von Geschäftsdomänen delegiert, aber die Notwendigkeit der Datenbereinigung, -vorbereitung und -aggregation (unter Verwendung der Datenpipeline) verschwindet nicht. Daher wird die Implementierung einer eigenen Datenpipeline zu einer internen Aufgabe des Business Domain-Teams. Als Ergebnis erhalten wir unsere eigenen Domain-Daten-Pipelines, die auf alle Domains verteilt sind.

Beispielsweise sollten Quelldomänen Datenbereinigung, Entfernung von Duplikaten, Datenanreicherung usw. umfassen, damit andere Domänen diese Daten ohne vorherige Verarbeitung verwenden können. Jeder dieser Datensätze muss hinsichtlich der Datenqualität seinem Service Level-Ziel entsprechen.

In ähnlicher Weise werden die Phasen des Aufbaus spezialisierter Vitrinen einer zentralisierten Pipeline zur Datenverarbeitung in die eigenen Datenpipelines von Verbraucherdomänen geleitet, die Verbraucherdomänen-Datasets erstellen.

Bild

Abbildung 8: Verteilte Datenverarbeitungspipelines, die in ihren Domänen implementiert sind

Es scheint, dass ein solches Modell zu einer großen Doppelarbeit in jeder Domäne führt, um eine eigene Implementierung einer Datenverarbeitungspipeline zu erstellen. Wir werden über dieses Problem im Abschnitt „Zentralisierte Dateninfrastruktur als Plattform“ sprechen.

Daten- und Produktdenken

Die Übertragung des Eigentums an Daten und die Verantwortung für die Entwicklung und Wartung von Datenverarbeitungspipelines auf die Seite von Geschäftsbereichen können ernsthafte Bedenken hinsichtlich der fortgesetzten Verfügbarkeit und Benutzerfreundlichkeit solcher verteilter Datensätze hervorrufen. Daher kommen wir hier zum praktischen Produktdenken in Bezug auf Daten.

Domänendaten als Produkt

In den letzten zehn Jahren hat das Produktdenken die Entwicklung von Informationssystemen von Organisationen tiefgreifend durchdrungen und den Ansatz für diese Entwicklung ernsthaft verändert. Domänenteams für die Entwicklung von Informationssystemen bieten neue Funktionen in Form von APIs, die Entwickler in Organisationen als Bausteine verwenden, um Funktionen höherer Ordnung und einen höheren Wert zu schaffen. Die Teams bemühen sich, den Benutzern ihrer APIs durch eine klare und detaillierte Dokumentation, auf die Benutzer leicht zugreifen können, die bestmögliche Erfahrung zu bieten. Testumgebungen sorgfältig nachverfolgte Qualitätsindikatoren.

Damit eine verteilte Datenplattform erfolgreich ist, müssen Datenteams von Geschäftsbereichen Produktdenken in Bezug auf die Bereitstellung von Datensätzen anwenden: Wahrnehmen der Daten, die sie als Produkt aufbereiten, und Verbraucher (Analysten, Datenwissenschaftler, Dateningenieure, ML-Spezialisten) etc.) als Ihre Kunden.

Bild

Abbildung 9: Merkmale von Domain-Datasets als Produkte

Betrachten Sie unser Beispiel - Streaming von Medieninhalten über das Internet. Der wichtigste Geschäftsbereich ist die Geschichte der Reproduktion: von wem, wo, wann und welche Songs wurden gehört. Diese Domain hat verschiedene Schlüsseldatenkonsumenten innerhalb der Organisation. Man benötigt Daten im Echtzeitmodus, um die Benutzererfahrung zu untersuchen und Probleme und Wiedergabefehler rechtzeitig zu erkennen. Andere interessieren sich für historische Schnappschüsse, die nach Tag oder Monat zusammengefasst sind. Daher bietet unsere Domain Daten in zwei Formaten an: Wiedergabeereignisse in Streaming-Form (Streaming, Thema in Kafka oder ähnlichem) und aggregierte Wiedergabeereignisse im Batch-Format (Datei, Tabelle in Hive usw.).

Um den Verbrauchern die bestmögliche Benutzererfahrung zu bieten, müssen Business Domain-Datenprodukte die folgenden Hauptmerkmale aufweisen.

Bequemlichkeit und einfache Erkennung (auffindbar)

Es muss sichergestellt werden, unter welchen Bedingungen ein Datenprodukt leicht gefunden werden kann. Die häufigste Implementierung dieser Anforderung ist das Vorhandensein einer Registrierung - eines Katalogs aller verfügbaren Datenprodukte mit den erforderlichen Metainformationen (wie Eigentümer, Herkunftsquellen, Datensatzbeispiele, Aktualisierungshäufigkeit, Struktur von Datensätzen usw.). Ein solcher zentraler Dienst ermöglicht es Datenkonsumenten, den Datensatz, an dem sie interessiert sind, leicht zu finden. Jedes Datenprodukt aus einer beliebigen Geschäftsdomäne muss in einem zentralen Datenverzeichnis registriert sein.

Bitte beachten Sie, dass es eine Verschiebung von einer einzigen zentralisierten Plattform, die alle Daten besitzt, zu verteilten Datenprodukten verschiedener Geschäftsdomänen gibt, die in einem einzigen Datenverzeichnis registriert sind.

Eindeutige Adresse (adressierbar)

Jedes Datenprodukt muss eine eindeutige Adresse haben (gemäß der globalen Vereinbarung), die es seinen Verbrauchern ermöglicht, programmgesteuert darauf zuzugreifen. Unternehmen können abhängig von den verfügbaren Methoden zur physischen Speicherung von Daten und den Formaten der Daten selbst verschiedene Vereinbarungen über den Namen der Datenprodukte und deren Standort treffen. Für eine verteilte dezentrale Architektur sind solche allgemeinen Konventionen erforderlich. Dataset-Adressstandards beseitigen Reibungsverluste beim Suchen und Zugreifen auf Datenprodukte.

Datenqualität

Niemand wird ein Produkt verwenden, das nicht glaubwürdig ist. In den Datenplattformen der aktuellen Generation ist das Herunterladen und Veröffentlichen von Daten, die Fehler enthalten und nicht die gesamte Geschäftswahrheit widerspiegeln, weit verbreitet, d. H. Daten, denen nicht vertraut werden kann. In diesem Teil konzentriert sich eine erhebliche Anzahl von ETL-Jobs, die Daten nach dem Laden löschen.

Die neue Architektur erfordert, dass die Eigentümer von Datenprodukten SLO (Service Level Objective) in Bezug auf Genauigkeit, Zuverlässigkeit und Relevanz der Daten anwenden. Um eine akzeptable Qualität sicherzustellen, müssen bei der Erstellung eines Datenprodukts Methoden wie Datenbereinigung und automatische Datenintegritätstests verwendet werden. Informationen zur Datenherkunft in den Metadaten jedes Datenprodukts geben den Verbrauchern zusätzliches Vertrauen in das Produkt selbst und dessen Eignung für bestimmte Anforderungen.

Der Zielwert des Datenqualitätsindikators (oder des akzeptablen Bereichs) hängt vom Datenprodukt einer bestimmten Geschäftsdomäne ab. Beispielsweise kann eine Domäne "Wiederholungsereignis" zwei verschiedene Produkte bereitstellen: eines im Echtzeitmodus mit einer geringeren Genauigkeit (einschließlich verpasster oder sich wiederholender Ereignisse); und die zweite mit einer längeren Verzögerung und einer höheren Datenqualität. Jedes Datenprodukt definiert und verwaltet ein Zielniveau für die Integrität und Zuverlässigkeit seiner Daten in Form eines SLO-Satzes (Service Level Objective).

Klare Beschreibung der Semantik und Datensyntax

Qualitätsprodukte sollten einfach zu bedienen sein. Um Datenprodukte zu erstellen, die für Analysten, Ingenieure und Datenwissenschaftler so einfach wie möglich sind, müssen gut beschriebene Semantik und Datensyntax vorhanden sein. Im Idealfall werden Beispieldatensätze als Beispiele bereitgestellt.

Datenintegrierbarkeit und organisationsweite Standards

Eines der Hauptprobleme in einer verteilten domänengesteuerten Datenarchitektur ist die Notwendigkeit, Daten aus verschiedenen Domänen zu integrieren. Der Schlüssel zur einfachen und effizienten Datenintegration zwischen Domänen liegt in der Definition und Befolgung von Regeln und Standards. Solche Standards sollten auf Organisationsebene definiert werden. Standardisierung ist erforderlich im Bereich der Bestimmung akzeptabler Datentypen und Regeln für deren Anwendung, Konventionen für Namen und Adressen von Datenprodukten, Metadatenformaten usw.

Für Entitäten, die in einer anderen Form und mit unterschiedlichen Attributen in verschiedenen Domänen gespeichert werden können, muss die Praxis des Stammdatenmanagements implementiert werden. Weisen Sie ihnen globale Bezeichner zu und richten Sie die Mengen- und vor allem Attributwerte auf alle Domänen aus.

Die Gewährleistung der Interoperabilität von Daten für ihre effektive Integration sowie die Festlegung von Standards für die Speicherung und Präsentation von Datenprodukten auf Organisationsebene sind eines der Grundprinzipien für den Aufbau solcher verteilter Systeme.

Datensicherheit und Zugriffskontrolle

Der sichere Zugriff auf Daten ist ein Muss, unabhängig davon, ob die Architektur zentralisiert ist oder nicht. In der Welt der dezentralen, auf Geschäftsdomänen ausgerichteten Datenprodukte ist eine Zugriffskontrolle mit einem höheren Grad an Granularität für jeden Datensatz möglich (und sollte angewendet werden). Richtlinien für die Datenzugriffskontrolle können zentral definiert, jedoch für jedes Datenprodukt separat implementiert werden. Als bequeme Möglichkeit, die Zugriffssteuerung auf Datensätze zu implementieren, können Sie das Enterprise Identity Management-System und die rollenbasierte Zugriffssteuerung verwenden .

Als Nächstes wird eine einzelne Infrastruktur beschrieben, mit der Sie die oben genannten Funktionen für jedes Datenprodukt einfach und automatisch implementieren können.

Funktionsübergreifender Befehl für Geschäftsdomänendaten

Die folgenden Rollen sollten in Teams vertreten sein, die Daten in Form von Datenprodukten bereitstellen: Eigentümer des Datenprodukts und Dateningenieur.

Der Eigentümer des Datenprodukts ist für das Konzept und die Roadmap, den Lebenszyklus seiner Produkte, verantwortlich. Misst die Zufriedenheit seiner Kunden und misst und verbessert ständig die Qualität der Daten seiner Geschäftsdomäne. Es füllt und gleicht den Rückstand seiner Datenprodukte mit den Anforderungen der Datenkonsumenten aus.

Außerdem müssen Eigentümer von Datenprodukten wichtige Metriken und Leistungsindikatoren (KPIs) für ihre Produkte definieren. Beispielsweise kann die Zeit, die der Benutzer benötigt, um sich mit dem Datenprodukt vertraut zu machen und es zu verwenden, eine dieser Metriken sein.

Um eigene Datenpipelines innerhalb einer Geschäftsdomäne zu erstellen und zu verwalten, muss das Team Dateningenieure umfassen. Ein guter Nebeneffekt davon wird die Verbreitung relevanter Fähigkeiten innerhalb des Geschäftsbereichs sein. Nach meinen Beobachtungen fehlen derzeit einigen Dateningenieuren, obwohl sie in der Verwendung ihrer Tools und Technologien kompetent sind, Kenntnisse über Standardpraktiken der Softwareentwicklung bei der Erstellung von Datenprodukten. Zuallererst praktizieren DevOps die kontinuierliche Lieferung und das automatische Testen. Andererseits verfügen Softwareentwickler, die Informationssysteme entwickeln, häufig nicht über genügend Erfahrung und Wissen auf dem Gebiet der Technologien und Tools für die Arbeit mit Daten als Produkt.Durch die Kombination zu multifunktionalen Teams innerhalb des Geschäftsbereichs entstehen Spezialisten mit einem breiteren Profil. Ähnliches haben wir bei der Entwicklung von DevOps beobachtet, als neue Ingenieurtypen auftauchten, wie zSRE .

Bild

Abbildung 10: Befehl für funktionsübergreifende Domänendaten

Zentralisierte Dateninfrastruktur als Plattform

Einer der sensiblen Aspekte der verteilten domänengesteuerten Architektur der Datenplattform ist die Notwendigkeit, die für den Betrieb des in Datenpipelines verwendeten Infrastruktur- und Technologie-Stacks erforderlichen Anstrengungen und Fähigkeiten in jeder Domäne zu duplizieren. Glücklicherweise ist die Schaffung einer gemeinsamen Infrastruktur als Plattform eine Aufgabe, deren Lösung in der IT gut gelernt ist (jedoch nicht im Bereich der Arbeit mit Daten).

Das Dateninfrastruktur-Team muss die Tools besitzen und als Service bereitstellen, die für Geschäftsdomänen erforderlich sind, um ihre Datenprodukte zu sammeln, zu verarbeiten und zu speichern.

Bild

Abbildung 11: Dateninfrastruktur als Plattform

Die Dateninfrastruktur als Plattform sollte frei von domänenspezifischen Konzepten oder Geschäftslogiken sein. Außerdem sollte die Plattform die Komplexität ihrer Implementierung vor den Benutzern verbergen und die maximale Funktionalität für die Verwendung im Self-Service-Modus bereitstellen. Hier ist eine Liste einiger Funktionen, die eine zentralisierte Dateninfrastruktur wie eine Plattform bieten sollte:

Skalierbare Datenspeicherung in verschiedenen Formaten
Datenverschlüsselung (hier Hashing, Depersonalisierung usw.)
Versionierung von Datenprodukten
Speichern von Daten Produktdatenschema
Datenzugriffskontrolle
Protokollierung
Orchestrierung von Threads / Datenverarbeitungsprozessen
In-Memory-Caching
Speichern von Metadaten und Datenherkunft
Überwachung, Warnungen, Protokollierung
Berechnung von Qualitätsmetriken für Datenprodukte
Pflege des Datenkatalogs
Standardisierung und Richtlinien, die Fähigkeit, die Einhaltung zu kontrollieren
Adressierung von Datenprodukten
CI / CD-Pipelines für Datenprodukte

Bei der Erstellung einer zentralisierten Dateninfrastruktur muss sichergestellt werden, dass die Erstellung eines Datenprodukts auf einer solchen Infrastruktur so wenig Zeit wie möglich in Anspruch nimmt. Daher ist die maximale Automatisierung der Schlüsselfunktionalität sehr wichtig, z. B.: Das Herunterladen von Daten mithilfe einfacher Konfigurationen, die automatische Registrierung eines Datenprodukts im Datenverzeichnis usw. Durch die Verwendung der Cloud-Infrastruktur können die Betriebskosten gesenkt und der Zugriff auf die Dateninfrastruktur bei Bedarf beschleunigt werden.

Paradigmenwechsel in Richtung Data Mesh

Es war eine lange Lektüre! Lassen Sie uns kurz alles zusammenfassen, was oben geschrieben steht. Wir haben einige der Hauptmerkmale moderner Datenplattformen untersucht: zentralisierte, monolithische, komplexe Datenpipelines (mit Hunderten und Tausenden von Jobs, die eng miteinander verbunden sind), unterschiedliche, eng spezialisierte Teams. Nachdem wir über einen neuen Data-Mesh-Ansatz gesprochen hatten, der verteilte Datenprodukte umfasst, die sich auf Geschäftsbereiche konzentrieren, die von funktionsübergreifenden Teams (mit Eigentümern von Datenprodukten und Dateningenieuren) verwaltet werden und eine gemeinsame Dateninfrastruktur als Plattform für das Hosting verwenden.

Das Data Mesh ist eine verteilte Architektur mit zentraler Verwaltung und entwickelten Standards, die die Datenintegrierbarkeit gewährleisten, sowie einer zentralisierten Infrastruktur, die die Verwendung von Self-Service ermöglicht. Ich hoffe, der Leser ist sich ziemlich sicher, dass eine solche Architektur weit entfernt von einer lose gekoppelten Speicherung unzugänglicher Daten ist, die unabhängig voneinander in verschiedenen Abteilungen entwickelt wurden.

Bild

Abbildung 12: Datennetzarchitektur ab 10.000 Metern

Sie fragen sich vielleicht: Wie passt Data Lake oder das Data Warehouse in diese Architektur? Sie sind einfach separate Knoten (Domänen) in dieser verteilten Architektur. Es besteht eine hohe Wahrscheinlichkeit, dass wir in einer solchen Architektur Data Lake nicht mehr benötigen. Schließlich haben wir Zugriff auf die Recherche der Originaldaten verschiedener Geschäftsbereiche, die in Form von Datenprodukten erstellt wurden.

Dementsprechend ist Data Lake nicht mehr das zentrale Element der gesamten Architektur. Wir werden jedoch weiterhin die Technologien und Tools verwenden, die zum Aufbau von Data Lake verwendet werden, entweder um eine gemeinsame Dateninfrastruktur zu erstellen oder um unsere Datenprodukte intern zu implementieren.

Dies bringt uns tatsächlich dorthin zurück, wo alles begann. James Dickson2010 beabsichtigte er, Data Lake für eine Geschäftsdomäne zu verwenden, und mehrere Datendomänen würden Water Garden bilden.

Der Hauptparadigmenwechsel besteht darin, das Geschäftsdomänen-Datenprodukt als Aufgabe erster Priorität und Tools und Technologien als Aufgabe zweiter Priorität (als Implementierungsdetail) zu betrachten. Dies dient dazu, das mentale Modell von einem zentralisierten Data Lake in ein Ökosystem von Datenprodukten umzuleiten, die sich nahtlos und effizient miteinander integrieren.

Einige Worte zur Berichterstellung und Visualisierung (mithilfe von BI-Tools usw.). Für sie gilt das gleiche Prinzip: In dieser Architektur sind sie separate Knoten. Jene. Sie sind unabhängige Datenprodukte innerhalb einer Geschäftsdomäne, die sich hauptsächlich auf den Verbraucher und nicht auf die Datenquelle konzentrieren.

Ich gebe zu, dass die Skalierung dieser Prinzipien in großen Organisationen noch einen langen Weg vor sich hat, obwohl ich die erfolgreiche Anwendung der Data Mesh-Prinzipien durch meine Kunden sehe. Aber Technologie ist hier offensichtlich keine Einschränkung. Alle Tools, die wir heute verwenden, können gleichermaßen für die Verteilung und den Besitz von Datenprodukten durch verschiedene Teams verwendet werden. Insbesondere der Übergang zur Standardisierung von Paket- und Stream-Datenverarbeitungsaufträgen sowie die Verwendung von Tools wie Apache Beam oder Google Cloud DataFlow erleichtern die Verarbeitung einer Vielzahl von Datensätzen mit eindeutigen Adressen.

Datenkatalogplattformen wie Google Cloud Data Catalog, bieten einfache Erkennung, Zugriffskontrolle und zentralisierte Verwaltung von Datensätzen verteilter Geschäftsdomänen. Eine große Anzahl von Cloud-Plattformen ermöglicht es Geschäftsdomänen, sich für die gezielte Speicherung ihrer Datenprodukte zu entscheiden.

Die Notwendigkeit eines Paradigmenwechsels liegt auf der Hand. Hierfür stehen alle notwendigen Technologien und Werkzeuge zur Verfügung. Führungskräfte und Datenverarbeitungsfachleute müssen anerkennen, dass das aktuelle Big-Data-Paradigma und der Ansatz mit einer einzigen Big-Data-Lake-Plattform nur die Fehler der Vergangenheit mit neuen Cloud-Technologien und -Tools wiederholen werden.

Wechseln wir von einer zentralisierten monolithischen Datenplattform zu einem Ökosystem von Datenprodukten.

Bild

Migration von einem nahtlosen Data Lake zu einem verteilten Data Mesh

Die aktuelle Architektur der Datenplattform in einem großen Unternehmen

Problematische architektonische Ansätze

Zentralisiert und monolithisch

Stark verbundene Fördererzersetzung

Unterschiedliche und hochspezialisierte Teams

Datenplattformarchitektur der nächsten Generation

Daten- und verteilte domänengesteuerte Architektur

Zerlegung und Besitz von Daten basierend auf der Ausrichtung der Geschäftsdomäne

Quelldomänen-Datasets

Consumer-Domain-Datasets

Verteilte Datenpipelines, die in ihren Domänen implementiert sind

Daten- und Produktdenken

Domänendaten als Produkt

Bequemlichkeit und einfache Erkennung (auffindbar)

Eindeutige Adresse (adressierbar)

Datenqualität

Klare Beschreibung der Semantik und Datensyntax

Datenintegrierbarkeit und organisationsweite Standards

Datensicherheit und Zugriffskontrolle

Funktionsübergreifender Befehl für Geschäftsdomänendaten

Zentralisierte Dateninfrastruktur als Plattform

Paradigmenwechsel in Richtung Data Mesh

Links zu Primärquellen und zusätzlichen Materialien zum Thema

More articles: