Datenmanagement im Maßstab, 2. Auflage

Kapitel 4. Datenproduktmanagement

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Vielleicht fragst du dich, was der Begriff " Datenprodukt" bedeutet - ister nur ein weiteres Modewort? In diesem Kapitel werden wir die Verwirrung durchbrechen und besprechen, was Datenprodukte wirklich sind. Ich erkläre dir alle wichtigen Informationen, die du brauchst, um große Datenmengen für andere Bereiche bereitzustellen. Wir beginnen mit einer Klärung des Begriffs, denn in der Praxis gibt es viele verschiedene Interpretationen und Definitionen. Als Nächstes untersuchen wir das Muster der Command Query Responsibility Segregation (CQRS) und warum es die Gestaltung deiner Datenproduktarchitekturen beeinflussen sollte. Wir besprechen verschiedene Designprinzipien für Datenprodukte und du erfährst, warum ein gut durchdachtes, integrierbares und leseoptimiertes Datenmodell für deine Kunden wichtig ist. Dann werden wir uns mit Datenproduktarchitekturen beschäftigen: was sie sind, wie sie entwickelt werden können, welche Fähigkeiten typischerweise benötigt werden und welche Rolle Metadaten spielen. Ich werde versuchen, das Ganze anhand eines praktischen Beispiels so konkret wie möglich zu machen. Am Ende dieses Kapitels wirst du ein gutes Verständnis dafür haben, wie Datenproduktarchitekturen dazu beitragen können, große Datenmengen für Datenkonsumenten verfügbar zu machen.

Was sind Datenprodukte?

Die Datenproduzenten zur Verantwortung zu ziehen und die Art und Weise, wie die Daten bereitgestellt werden, zu dezentralisieren, ist ein guter Weg, um Skalierbarkeit zu erreichen. Dehghani verwendet den Ausdruck "Daten als Produkt" und führt das Konzept der "Datenprodukte" ein, aber es gibt einen großen Unterschied zwischen den beiden. Daten als Produkt beschreibt die Denkweise: Dateneigentümer und Anwendungsteams müssen Daten als ein vollständig enthaltenes Produkt behandeln, für das sie verantwortlich sind, und nicht als Nebenprodukt eines Prozesses, den andere verwalten. Es geht darum, wie Datenanbieter die Datenkonsumenten als Kunden behandeln und ihnen ein Erlebnis bieten, das sie begeistert; wie Daten definiert und gestaltet werden sollten, um das bestmögliche Kundenerlebnis zu bieten.

Ein Datenprodukt unterscheidet sich vom Denken über Daten als Produkt, weil es sich mit der Architektur befasst. In der Daten-Community gibt es unterschiedliche Erwartungen undInterpretationen, wie sich Datenprodukte auf die Architektur von beziehen. Einige Praktiker sagen, dass ein Datenprodukt nicht nur ein Datensatz ist, der relevante Daten aus einem bestimmten begrenzten Kontext enthält, sondern auch alle notwendigen Komponenten, um Daten zu sammeln und bereitzustellen, sowie Metadaten und Code, der die Daten umwandelt. Diese Interpretation stimmt mit Dehghanis Beschreibung eines Datenprodukts als architektonisches Quantum überein, einem "Knotenpunkt im Netz, der drei strukturelle Komponenten enthält, die für seine Funktion erforderlich sind und den Zugang zu den analytischen Daten des Bereichs als Produkt ermöglichen." Diese drei Komponenten sind laut Dehghani der Code, die Daten und Metadaten sowie die Infrastruktur. Ihr Fokus liegt also eindeutig auf der Lösungsarchitektur, die alle Komponenten für die Beschaffung, Umwandlung, Speicherung, Verwaltung und gemeinsame Nutzung von Daten umfassen kann.

Einige Praktiker haben unterschiedliche Ansichten über Datenprodukte. Accenture zum Beispiel bezeichnet Datensätze, analytische Modelle und Dashboard-Berichte als Datenprodukte. Diese Sichtweise unterscheidet sich deutlich von der von Dehghani, denn sie konzentriert sich auf die physische Darstellung von Daten und schließt nicht unbedingt Metadaten, Code oder Infrastruktur ein. Bevor wir also eine Architektur entwerfen können, müssen wir uns zunächst auf eine gemeinsame Terminologie für Datenprodukte einigen und festlegen, was enthalten sein muss oder nicht.

Probleme bei der Kombination von Code, Daten, Metadaten und Infrastruktur

In einer idealen Welt werden Daten und Metadaten zusammen als Datenprodukte verpackt und ausgeliefert. Ferd Scheepers, Chief Information Architect bei ING Tech Group Services, hielt auf der Domain-Driven Design Europe 2022 einen Vortrag zum Thema Metadatenmanagement. Dabei erklärte er, dass Metadaten für das Datenmanagement entscheidend sind, denn "Metadaten sind Daten, die Informationen über andere Daten liefern." Um die Bedeutung zu unterstreichen, zieht er eine Analogie dazu, wie Blumen in den Niederlanden verteilt werden.

Die Aalsmeer Blumenauktion ist die größte Blumenauktion der Welt. Von Montag bis Freitag werden jeden Tag rund 43 Millionen Blumen und 5 Millionen Pflanzen verkauft. An jedem Werktag nehmen Händler aus der ganzen Welt an der Auktion teil. Bei der Ankunft werden die Blumen etikettiert und an die entsprechenden Einrichtungen geschickt. Für die Käufer/innen ist der gesamte Prozess nahtlos: Du gibst digital Bestellungen auf, übermittelst Mengen und gibst einen Preis und einen Bestimmungsort an. Das Tolle an der Geschichte ist, dass die Auktion vollständig metadatengesteuert ist. Alle Blumenkisten sind mit Barcodes versehen, die wichtige Informationen über ihren Inhalt enthalten, wie Herkunftsland und -stadt, Mengen, Startgebotspreis, Gewicht, Produktions- und Verfallsdatum, Name des Erzeugers und so weiter. Wenn Blumen verkauft werden, wird ein weiterer Barcode mit Informationen für den Versand hinzugefügt: Eigentumsangaben des Käufers, Bestimmungsort, Versandanweisungen und so weiter. Ohne Metadaten würde die Blumenauktion nicht funktionieren.

Bei der Blumenauktion werden Blumen und Metadaten immer gemeinsam verwaltet und verteilt, weil die physischen Objekte miteinander verbunden sind. In der digitalen Welt funktioniert das jedoch nicht so! Um das zu verdeutlichen, möchte ich einige Beispiele anführen. Wenn du einen zentralen Datenkatalog für die Verwaltung und Beschreibung all deiner Daten verwendest, dann werden Daten und Metadaten getrennt voneinander verwaltet. In diesem Beispiel befinden sich alle Metadaten in deinem Datenkatalog und alle physischen Daten sind an einem anderen Ort gespeichert, wahrscheinlich an vielen anderen Orten. Die gleiche Trennung gilt zum Beispiel für ein metadatengesteuertes Ingestion Framework, das den Extraktions- und Ladeprozess von Daten verwaltet. Ein solches Framework holt sich keine Metadaten aus Hunderten von Datenproduktcontainern, bevor es mit der Verarbeitung der Daten beginnt. Ein metadatengesteuertes Ingestion Framework verwaltet als architektonische Komponente in der Regel Metadaten in einer eigenständigen Datenbank, die von den Daten selbst getrennt ist. Es nutzt diese Metadaten, um den Prozess und die Abhängigkeiten zu steuern, durch die Daten extrahiert, kombiniert, umgewandelt und geladen werden.

Das Gleiche gilt für Informationen zur Herkunft und Datenqualität. Würden die zugehörigen Metadaten in den Datenprodukt-Container selbst gepackt, müsstest du komplexe föderierte Abfragen über alle Datenprodukte hinweg durchführen, um die Herkunft oder die Datenqualität von Ende zu Ende zu überwachen. Alternativ könntest du auch alle Metadaten an einem anderen zentralen Ort replizieren, aber das würde deine Gesamtarchitektur dramatisch verkomplizieren. Und wie würdest du mit Sicherheit, Datenschutzklassifizierungen, Sensitivitätskennzeichnungen oder Eigentumsinformationen für dieselben semantischen Daten umgehen, die mehrere physische Repräsentationen haben? Wenn du Metadaten und Daten fest miteinander verbinden würdest, würden die Metadaten beim Kopieren von Datenprodukten dupliziert werden, da beide in derselben Architektur liegen. Alle Metadaten-Aktualisierungen müssten dann gleichzeitig in mehreren Datenprodukt-Containern durchgeführt werden. Das wäre ein komplexes Unterfangen, da alle diese Container immer verfügbar und zugänglich sein müssten. Du könntest eine Overlay-Architektur implementieren, um diese Aktualisierungen asynchron durchzuführen, aber das würde deine Gesamtarchitektur wieder dramatisch verkomplizieren.

Abschließend lässt sich sagen, dass es viel zu naiv ist, ein Datenprodukt als einen Container zu betrachten, der Code, Daten und Metadaten sowie die Infrastruktur zusammenhält. Die Definition eines Datenprodukts muss überarbeitet werden, damit sie der Realität, wie Datenplattformen heutzutage funktionieren, besser entspricht .

Datenprodukte als logische Entitäten

Wenn die bisherige Definition von nicht gut ist, wie sollten wir dann ein Datenprodukt definieren? Ich bin der festen Überzeugung, dass die Verwaltung von Daten und Technologien aus verschiedenen architektonischen Blickwinkeln erfolgen sollte: einer, der sich mit der Verwaltung von Daten befasst, und ein anderer, der sich mit der Verwaltung der zugrunde liegenden Technologiearchitektur befasst. Abbildung 4-1 zeigt, wie das aussehen könnte.

Abbildung 4-1. Getrennte Sichtweisen für die Verwaltung der Daten und der Technologie

Warum solltest du die Verwaltung von Daten und Technologie trennen? Erstens, weil du die Architektur kosteneffizienter gestalten und den Aufwand für die Verwaltung der komplexen Infrastruktur reduzieren kannst. Du ermöglichst Szenarien mit "Datenproduktarchitekturen", in denen mehrere "Datenprodukte" verwaltet werden.

Zweitens erleichtert eine Trennung von Daten und Architektur die Szenarien, in denen dieselben (semantischen) Daten verteilt werden müssen. Die Verteilung von Daten kann z. B. bei der bereichsübergreifenden Datenvalidierung oder -anreicherung erforderlich sein. Die Duplizierung und Vorverarbeitung von Daten ist manchmal auch erforderlich, um mehrere Anwendungsfälle gleichzeitig zu ermöglichen, z. B. wenn genau dieselben Daten in den Dateiformaten Parquet und Delta Lake gespeichert werden. Dabei duplizierst du Daten, ohne die zugrunde liegende Semantik zu verändern. Dieses Szenario ist in Abbildung 4-1 dargestellt: Die physischen Datensätze 01 und 02 haben dieselbe Semantik, und die einzelnen Attribute der physischen Daten sind mit denselben Elementen verknüpft.

Drittens vermeidest du eine enge Kopplung zwischen Daten und Metadaten. Stell dir eine Situation vor, in der Daten und Metadaten immer zusammen im selben Container gespeichert sind. Wenn sich z. B. Eigentümer, Geschäftseinheiten oder Klassifizierungen ändern, müssen sich auch die entsprechenden Metadaten in allen Datenproduktarchitekturen ändern. Wie stellst du darüber hinaus sicher, dass die Daten konsistent sind? Wenn du Metadaten duplizierst, besteht das Risiko, dass sich auch die Eigentumsverhältnisse an den Daten ändern. Das sollte bei ein und denselben semantischen Daten, die an verschiedenen Orten unterschiedlich repräsentiert werden, nicht möglich sein.

Durch die Trennung von Daten und Metadaten ändert sich die Definition eines Datenprodukts: Ein Datenprodukt ist eine eigenständige logische Einheit, die Daten beschreibt, die für den Konsum bestimmt sind. Von dieser logischen Einheit aus ziehst du Beziehungen zur zugrunde liegenden Technologiearchitektur, d.h. zu den physischen Orten, an denen lesbare und verbraucherfreundliche physische Datenbestände gespeichert sind. Das Datenprodukt selbst enthält einen logischen Datensatznamen, eine Beschreibung der Beziehungen zur Ursprungsdomäne, die eindeutigen Datenelemente und Geschäftsbegriffe, den Eigentümer des Datensatzes und Verweise auf physische Datenbestände (die eigentlichen Daten). Die Daten sind für das Unternehmen semantisch konsistent, können aber auf der physischen Ebene mehrere verschiedene Formen und Darstellungen haben. Diese Änderungen erfordern, dass ein Datenprodukt als technologieunabhängig definiert wird. Diese Metadaten werden im Interesse der Flexibilität abstrakt gehalten.

Tipp

In Kapitel 9 werde ich die logische Sichtweise eines Datenprodukts konkretisieren, indem ich Screenshots eines Metamodells für das Datenproduktmanagement zeige. Wenn du nicht warten willst, um zu erfahren, wie das funktioniert, empfehle ich dir, "Das Unternehmens-Metadatenmodell" zu lesen und dann hier weiterzulesen.

Wenn du Datenprodukte als logische Einheiten definierst, kannst du Daten beschreiben, klassifizieren, kennzeichnen oder verknüpfen (z. B. mit Domänen, Dateneigentümern, organisatorischen Metadaten, Prozessinformationen und anderen Metadaten), ohne die Implementierungsdetails zu kennen. Eine Ebene unterhalb eines Datenprodukts gibt es Datenelemente: atomare Informationseinheiten, die als Verknüpfungspunkte zu physischen Daten, Schnittstellen-Metadaten, Anwendungs-Metadaten und Datenmodellierungs-Metadaten dienen. Um die physischen Daten zu beschreiben, brauchst du technische Metadaten, die Schemainformationen, Datentypen und so weiter enthalten.

Nachdem wir nun eine klare Vorstellung davon haben, was Datenprodukte sind, wollen wir uns nun damit beschäftigen, was ihr Design und ihre Architektur beeinflusst. Wir beginnen mit CQRS und sehen uns dann die leseoptimierte Modellierung und andere Gestaltungsprinzipien an. Danach werden wir die Architektur des Datenprodukts genauer unter die Lupe nehmen.

Entwurfsmuster für Datenprodukte

Die Änderung der Definition eines Datenprodukts bedeutet nicht, dass wir das Konzept der Datenverwaltung als Produkt aufgeben sollten. Anwendungseigner und Anwendungsteams müssen Daten als eigenständige Produkte behandeln, für die sie verantwortlich sind, und nicht als Nebenprodukt eines Prozesses, den andere verwalten. Datenprodukte werden speziell für Datenkonsumenten erstellt. Sie haben definierte Formen, Schnittstellen und Wartungs- und Aktualisierungszyklen, die alle dokumentiert sind. Datenprodukte enthalten verarbeitete Fachdaten, die über Schnittstellen mit nachgelagerten Prozessen in einem Service Level objective (SLO) geteilt werden. Sofern nicht anders vorgeschrieben, sollten deine (technischen) Anwendungsdaten verarbeitet, geformt, bereinigt, aggregiert und (de)normalisiert werden, damit sie den vereinbarten Qualitätsstandards entsprechen, bevor du sie für die Nutzung bereitstellst.

In Kapitel 1 hast du die technischen Probleme bei der Begrenzung von Datentransfers, der Entwicklung von transaktionalen Systemen und dem Umgang mit stark erhöhtem Datenverbrauch kennengelernt. Die Entnahme großer Datenmengen aus einem stark ausgelasteten System kann riskant sein, denn Systeme, die zu stark belastet werden, können abstürzen oder unberechenbar, nicht mehr verfügbar oder - noch schlimmer - beschädigt werden. Deshalb ist es klug, eine schreibgeschützte und leseoptimierte Version der Daten zu erstellen, die dann für den Verbrauch zur Verfügung gestellt werden kann. Werfen wir einen Blick auf ein gängiges Design Pattern für diesen Zweck: CQRS.

Was ist CQRS?

CQRS ist ein Entwurfsmuster, das auf der Erstellung einer Kopie der Daten für intensive Lesevorgänge basiert.

Operative Befehle und analytische Abfragen (oft als Schreib- und Lesevorgänge bezeichnet) sind sehr unterschiedliche Vorgänge und werden im CQRS-Muster getrennt behandelt (wie in Abbildung 4-2 dargestellt). Wenn du die Auslastung eines ausgelasteten Systems untersuchst, wirst du wahrscheinlich feststellen, dass die Befehlsseite den größten Teil der Rechenressourcen beansprucht. Das ist logisch, denn für einen erfolgreichen (d.h. dauerhaften) Schreib-, Aktualisierungs- oder Löschvorgang muss die Datenbank in der Regel eine Reihe von Schritten durchführen:

1. Überprüfe den Umfang der verfügbaren Speicherung.

2. Weisen Sie zusätzliche Speicherung für das Schreiben zu.

3. Rufe die Metadaten der Tabelle/Spalte ab (Typen, Beschränkungen, Standardwerte usw.).

4. Finde die Datensätze (im Falle einer Aktualisierung oder Löschung).

5. Sperre die Tabelle oder die Datensätze.

6. Schreibe die neuen Datensätze.

7. Überprüfe die eingefügten Werte (z. B. Eindeutigkeit, korrekte Typen usw.).

8. Führe die Übergabe durch.

9. Löse die Sperre.

10. Aktualisiere die Indizes.

Das Lesen der Datenbank nimmt im Vergleich zum Schreiben weniger Rechenressourcen in Anspruch, da weniger dieser Aufgaben ausgeführt werden müssen. Zur Optimierung trennt CQRS die Schreibvorgänge (Befehle) von den Lesevorgängen (Abfragen), indem es zwei Modelle verwendet, wie in dieser Abbildung dargestellt. Sobald sie getrennt sind, müssen sie synchronisiert werden, was normalerweise durch die Veröffentlichung von Ereignissen mit Änderungen geschieht. Dies wird durch den "Ereignispfeil" (das Blitzsymbol) in Abbildung 4-2 veranschaulicht.

Abbildung 4-2. Eine Anwendung, die CQRS verwendet, trennt Abfragen und Befehle, indem sie zwei verschiedene Datenmodelle verwendet: ein Befehlsmodell für die Transaktionen und ein Abfragemodell für die Lesungen

Ein Vorteil von CQRS ist, dass du nicht an denselben Datenbanktyp für Schreib- und Lesevorgänge gebunden bist.¹ Du kannst die Schreibdatenbank objektiv komplex lassen, aber die Lesedatenbank für die Leseleistung optimieren. Wenn du unterschiedliche Anforderungen für verschiedene Anwendungsfälle hast, kannst du sogar mehr als eine Lesedatenbank erstellen, jede mit einem optimierten Lesemodell für den spezifischen Anwendungsfall, der implementiert wird. Unterschiedliche Anforderungen ermöglichen auch unterschiedliche Konsistenzmodelle zwischen den Lesedatenbanken, auch wenn die Schreibdatenbank dieselbe bleibt.

Ein weiterer Vorteil von CQRS ist, dass du die Lese- und Schreibvorgänge nicht gleichzeitig skalieren musst. Wenn dir die Ressourcen ausgehen, kannst du entweder das eine oder das andere skalieren. Der letzte große Vorteil, der sich daraus ergibt, dass nicht nur ein einziges Modell für Schreib- und Lesevorgänge verwendet wird, ist die Flexibilität der Technologie. Wenn die Lesevorgänge sehr schnell ausgeführt werden müssen oder du andere Datenstrukturen brauchst, kannst du eine andere Technologie für den Lesespeicher wählen, ohne die ACID-Datenbankeigenschaften (Atomarität, Konsistenz, Isolation und Dauerhaftigkeit) zu vernachlässigen, die auch für den Befehlsspeicher benötigt werden.

Obwohl CQRS ein Entwurfsmuster der Softwareentwicklung ist, das dazu beitragen kann, den Entwurfsprozess für bestimmte (und möglicherweise größere) Systeme zu verbessern, sollte es den Entwurf und die Vision deiner Datenproduktarchitektur stark inspirieren. Das zukünftige Modell einer Architektur muss so aussehen, dass mindestens ein Lesedatenspeicher pro Anwendung erstellt oder verwendet wird, wenn andere Anwendungen die Daten intensiv lesen wollen. Dieser Ansatz vereinfacht das zukünftige Design und die Implementierung der Architektur. Außerdem verbessert er die Skalierbarkeit bei intensivem Datenkonsum.

Hinweis

CQRS hat eine enge Beziehung zu materialisierten Ansichten.² Eine materialisierte Ansicht in einer Datenbank ist eine physische Kopie der Daten, die ständig von den zugrunde liegenden Tabellen aktualisiert wird. Materialisierte Ansichten werden oft für Leistungsoptimierungen verwendet. Statt die Daten aus den zugrundeliegenden Tabellen abzufragen, wird die Abfrage gegen die vorberechnete und optimierte Teilmenge ausgeführt, die sich in der materialisierten Ansicht befindet. Diese Trennung von zugrundeliegenden Tabellen (für Schreibvorgänge) und materialisierter Teilmenge (für Lesevorgänge) ist dieselbe Trennung wie bei CQRS, mit dem feinen Unterschied, dass beide Datensammlungen in derselben Datenbank und nicht in zwei verschiedenen Datenbanken gespeichert sind.

Replikate als Datenprodukte lesen

Replikate als Quelle für das Lesen von Daten zu nutzen, ist nicht neu. In der Tat kann jeder Lesevorgang aus einem Replikat, einer Kopie, einem Data Warehouse oder einem Data Lake als eine Form von CQRS angesehen werden. Ähnlich verhält es sich mit der Aufteilung von Befehlen und Abfragen zwischen Online-Transaktionsverarbeitungssystemen (OLTP), die in der Regel transaktionsorientierte Anwendungen ermöglichen und verwalten, und einem operativen Datenspeicher (ODS, der für das operative Reporting verwendet wird). Der ODS ist in diesem Beispiel eine replizierte Version der Daten aus dem OLTP-System. Alle diese Muster folgen der Philosophie von CQRS: Aufbau von Lesedatenbanken aus operativen Datenbanken.

Hinweis

Martin Kleppmann verwendet das "Turning the database inside-out"-Pattern, eine weitere Variante von CQRS, bei der das Sammeln von Fakten über Event-Streaming im Vordergrund steht. Wir werden uns dieses Muster in Kapitel 6 ansehen.

Datenproduktarchitekturen sollten ebenfalls der CQRS-Philosophie folgen. Sie nehmen die Position einer replizierten Kopie der Daten ein und werden verwendet, um Datenkonsumenten ein intensives Lesen zu ermöglichen. Sie sind stark reglementiert und erben ihren Kontext von den Domänen und den zugrunde liegenden Anwendungen. Auf einer hohen Ebene bedeutet dies, dass immer dann, wenn Datenanbieter und Datenkonsumenten Daten austauschen wollen, wie in Abbildung 4-3 dargestellt, eine Datenproduktarchitektur verwendet werden muss.

Abbildung 4-3. Dezentralisierte Zusammenarbeit von Datenanbietern und Datenkonsumenten

Beachte, dass die Datenprodukte auf der linken Seite in der Nähe der Datenanbieter und die Transformationsschritte in der Nähe der Datenkonsumenten angeordnet sind. Diese Positionierung ergibt sich aus dem vereinheitlichten Ansatz, Daten für die Verbraucher bereitzustellen. Anstatt ein einziges, einheitliches Datenmodell zu verwenden, wird das Design geändert, um allen konsumierenden Anwendungen bereinigte und leicht konsumierbare Versionen der Domänendaten zur Verfügung zu stellen. Diese Daten sind nicht dazu gedacht, Verhalten oder Funktionalität zu liefern. Die Beschaffenheit der Daten ist daher anders als die der Betriebsdaten: Sie sind für eine intensive Lesbarkeit optimiert und ermöglichen jedem, Daten schnell in Wert zu verwandeln!

Gestaltungsprinzipien für Datenprodukte

Die Erstellung von leseoptimierten und benutzerfreundlichen Daten ist der Weg in die Zukunft. Das klingt einfach, aber in der Praxis ist es oft schwieriger als erwartet. Du musst dir vor allem überlegen, wie die Daten erfasst, strukturiert und modelliert werden sollen. Die Schwierigkeiten entstehen, wenn du wiederholt und parallel mit vielen Teams Datenprodukte erstellen musst. Du willst dies effizient tun und vermeiden, dass jeder neue Datenkonsument zu einem neu entwickelten Datenprodukt führt oder dass du dich lange mit komplexen Datenstrukturen beschäftigen und Probleme mit der Datenqualität lösen musst. Du willst maximale Wiederverwendbarkeit und einfach zu bearbeitende Daten! In diesem Abschnitt werden eine Reihe von Designprinzipien vorgestellt, die bei der Entwicklung von Datenprodukten hilfreich sind. Sei gewarnt, die Liste ist lang.

Ressourcenorientiertes, leseoptimiertes Design

Analytische Modelle, die ständig neu trainiert werden, lesen ständig große Mengen an Daten. Dies wirkt sich auf die Gestaltung von Datenprodukten aus, da wir die Lesbarkeit der Daten auf optimieren müssen. Eine bewährte Methode ist die Ressourcenorientierung bei der Entwicklung von APIs. Eine ressourcenorientierte API wird in der Regel als eine Ressourcenhierarchie modelliert, bei der jeder Knoten entweder eine einfache Ressource oder eine Sammelressource ist. Der Einfachheit halber werden sie oft als Ressourcen bzw. Sammlungen bezeichnet.

Bei Datenprodukten kannst du denselben ressourcenorientierten Ansatz verfolgen, indem du die Daten logisch gruppierst und sie nach Themenbereichen gruppierst, wobei jeder Datensatz eine Sammlung homogener Daten darstellt. Ein solches Design führt dazu, dass die Daten in Datenprodukten vorberechnet, denormalisiert und materialisiert werden. Auf der Verbraucherseite führt dies zu einer einfacheren und schnelleren nachgelagerten Nutzung, da keine rechenintensiven Joins durchgeführt werden müssen. Außerdem verringert sich der Zeitaufwand für die Suche nach den richtigen Daten, da zusammengehörige Daten logisch gruppiert werden.

Wenn du ein ressourcenorientiertes Design auf deine Datenprodukte anwendest, dann müssen folglich stark normalisierte oder zu technische physische Datenmodelle in wiederverwendbare und logisch geordnete Datensätze übersetzt werden. Das Ergebnis sind stärker denormalisierte und leseoptimierte Datenmodelle, ähnlich wie ein Kimball-Sternschema oder ein Inmon Data Mart. Das bedeutet auch, dass die komplexe Anwendungslogik abstrahiert werden muss. Die Daten müssen anderen Bereichen mit einer angemessenen Granularität zur Verfügung gestellt werden, um so viele Verbraucher wie möglich zufrieden zu stellen. Für alle verknüpften Datenprodukte bedeutet dies, dass Querverweise und Fremdschlüsselbeziehungen im gesamten Datenbestand konsistent sein müssen. Die konsumierenden Domänen sollten zum Beispiel keine Schlüssel manipulieren müssen, um verschiedene Datensätze zu verbinden! Die Erstellung von Datenprodukten mit diesem Ansatz bedeutet folglich, dass die Domänen die semantische Logik besitzen und dafür verantwortlich sind, wie die Daten zur besseren Lesbarkeit umgewandelt werden. Doch genug davon - werfen wir einen Blick auf einige andere bewährte Methoden und Gestaltungsprinzipien.

Datenprodukte und Datentresore

Du fragst dich vielleicht, ob du deine Datenprodukte mit einem Data Vault-Modell entwerfen kannst. Das Data Vault ist ein Entwurfsmuster für die Datenmodellierung, das für den Aufbau eines Data Warehouse verwendet wird.³ Es soll Flexibilität, Wartbarkeit und Skalierbarkeit bieten, indem es Entitäten mit zusätzlichen Beziehungen entkoppelt. Aufgrund seiner hohen Komplexität sind die Daten für Außenstehende, die nicht in dieser Technik geschult sind, schwer zu verstehen. Außerdem wird deine Architektur dadurch langsamer und teurer, weil die Methodik der feingranularen Datenmodellierung oft im Widerspruch zu den zugrunde liegenden verteilten Speicherarchitekturen der großen Cloud-Anbieter steht. Es erfordert viele Verbraucher, um die Iterationen beim Zusammenführen und Integrieren von Daten zu durchlaufen.

Abbildung 4-4 vergleicht ein Data Vault-Schema mit einem einfachen Sternschema. Kurz gesagt, die Data Vault-Methode ersetzt Entitäten durch Hubs, Links und Satelliten, um die sich ständig weiterentwickelnden Geschäftsanforderungen zu unterstützen.

Abbildung 4-4. Data Vault-Methodik im Vergleich zum einfachen Sternschema (Quelle: PhData)

Daten Produktdaten sind unveränderlich

Datenprodukt Daten sind unveränderlich und daher schreibgeschützt. Warum müssen deine Read(-only)-Datenspeicher unveränderlich sein? Diese Eigenschaft garantiert, dass wir die gleichen Daten immer wieder neu generieren können. Wenn wir ein Nur-Lese-Design verwenden, gibt es keine verschiedenen Versionen der Wahrheit für dieselben Domänendaten. Datenproduktarchitekturen, die diesem Prinzip folgen, erstellen keine neuen semantischen Daten. Die Wahrheit kann nur in der goldenen Quellanwendung geändert werden.

Die allgegenwärtige Sprache verwenden

Es ist wichtig, den Kontext zu verstehen, in dem die Daten erstellt wurden. Hier kommt die allgegenwärtige Sprache ins Spiel: eine konstruierte, formalisierte Sprache, auf die sich Stakeholder und Designer geeinigt haben, um die Anforderungen des Designs zu erfüllen. Die allgegenwärtige Sprache sollte auf die Domäne abgestimmt sein, d. h. auf die Unternehmensfunktionen und -ziele. Der Kontext der Domäne bestimmt das Design der Datenprodukte. Eine gängige Umsetzung ist ein Datenkatalog, in dem all diese Informationen zusammen mit den Informationen aus den Domänen gespeichert werden. Durch die Veröffentlichung des Kontexts und dietransparente Darstellung der Definitionen für die Domänen kann jeder den Ursprung und die Bedeutung der Daten erkennen und sich darüber einigen.

Einige Organisationen verlangen, dass die Domänen menschenfreundliche Spaltennamen in ihren physischen Datensätzen verwenden. Das ist nicht unbedingt notwendig, solange die Zuordnung zwischen dem physischen Datenmodell und dem konzeptionellen Datenmodell gewährleistet ist. Diese Verknüpfung ermöglicht es deinen Bereichen, Geschäftskonzepte aus der allgegenwärtigen Sprache in physische Daten zu übersetzen.

Erfassen direkt von der Quelle

In meiner früheren Funktion habe ich gelernt, dass Unternehmen oft lange Datenketten haben, in denen Daten von System zu System weitergegeben werden. Für das Datenmanagement kann das ein Problem sein, weil der Ursprung nicht so eindeutig ist. Deshalb solltest du die Daten immer von dem System erfassen, von dem sie stammen. Die Verwendung eindeutiger Daten aus den goldenen Quellen garantiert, dass es sowohl für den Datenzugriff als auch für die Datenverwaltung eine einzige Quelle der Wahrheit gibt. Das bedeutet, dass die Datenprodukte eindeutig und eindeutig sind: Sie gehören zu einer einzigen Domäne, das heißt, sie sind isoliert und können keine direkten Abhängigkeiten zu Anwendungen aus anderen Domänen haben. Dieses Gestaltungsprinzip bedeutet auch, dass Domänen keine Daten aus anderen Domänen mit unterschiedlichen Dateneigentümern einkapseln dürfen, da dies die Dateneigentümerschaft verwirren würde.

Klare Interoperabilitätsstandards

Es ist wichtig zu definieren, wie Datenprodukte für andere Domänen bereitgestellt werden. Ein Datenprodukt kann als Datenbank, als standardisiertes Dateiformat, als Grafik, als API-Endpunkt, als Ereignisstrom oder auf andere Weise bereitgestellt werden. In jedem Fall solltest du die Schnittstellenspezifikationen standardisieren. Wenn alle deine Bereiche ihre eigenen Standards definieren, wird die Datennutzung sehr schwierig. Deshalb ist die Standardisierung entscheidend. Dazu musst du die verschiedenen Verteilungsarten (z. B. Batch-, API- und ereignisorientiert), Metadatenstandards usw. klar definieren. Lege genau fest, wie eine Datenproduktarchitektur aussieht. Batch-Datenprodukte werden zum Beispiel im Delta-Format veröffentlicht und müssen in einem Datenkatalog registriert werden.

Keine Rohdaten

Ein Datenprodukt ist das Gegenteil von Rohdaten, denn die Offenlegung von Rohdaten erfordert eine Nachbearbeitung durch alle konsumierenden Domänen. Daher solltest du in jedem Fall alte oder komplexe Systeme kapseln und technische Anwendungsdaten verstecken. Wenn du darauf bestehst, Rohdaten zur Verfügung zu stellen, z. B. für Forschungsanalysen, solltest du sicherstellen, dass sie standardmäßig als temporär gekennzeichnet sind. Für Rohdaten oder unveränderte Daten gibt es keine Garantien.

Können Systeme Schnittstellen herstellen, die Rohdaten offenlegen?

Ziehe in Erwägung, Anwendungen zu erlauben, Rohdaten und verbrauchsoptimierte Daten gleichzeitig bereitzustellen. Dieser Ansatz kommt Datenwissenschaftlern und Verbrauchern zugute, die sofortigen Zugriff wünschen. Schnittstellen, die Rohdaten enthalten, sollten als privat gekennzeichnet sein und keine Garantien enthalten. Sie sollten niemals als Produktionsdaten-Pipelines verwendet werden.

Der in Kapitel 2 erläuterte Grundsatz, dass es keine Rohdaten geben darf, gilt auch für externe Datenanbieter: externe Parteien, die außerhalb der logischen Grenzen des Ökosystems deines Unternehmens operieren. Sie operieren in der Regel an separaten, unkontrollierten Netzwerkstandorten. Fordere deine Ökosystempartner auf, sich an deinen Standard zu halten, oder wende eine Mediation über eine Zwischendomäne an: eine konsumierende Domäne, die als Vermittler fungiert, indem sie die Komplexität abstrahiert und einen stabilen und sicheren Konsum garantiert.

Passe dich nicht den Verbrauchern an

Es ist wahrscheinlich, dass dieselben Datenprodukte wiederholt von verschiedenen Fachteams für eine Vielzahl von Anwendungsfällen verwendet werden. Deshalb sollten deine Teams ihre Datenprodukte nicht an die spezifischen Bedürfnisse der (einzelnen) Datenkonsumenten anpassen. Das oberste Gestaltungsprinzip sollte sein, die Produktivität der Fachbereiche zu maximieren und die Nutzung und Wiederverwendung zu fördern.

Andererseits können sich Datenprodukte auf der Grundlage des Nutzerfeedbacks weiterentwickeln und tun dies auch. Hier solltest du vorsichtig sein! Es kann für Teams verlockend sein, spezifische Anforderungen von Verbrauchern zu übernehmen. Wenn die Verbraucher jedoch Geschäftslogik in die Datenprodukte einer produzierenden Domäne einbringen, entsteht eine strikte Abhängigkeit vom Anbieter, der Änderungen vornehmen muss. Dies kann eine intensive gegenseitige Abstimmung und Rückstandsverhandlungen zwischen den Domänenteams auslösen. Eine Empfehlung ist hier die Einführung eines Governance-Gremiums, das darüber wacht, dass Datenprodukte nicht für bestimmte Kunden erstellt werden. Dieses Gremium kann die Fachteams anleiten, Walk-in-Sitzungen und Wissensaustausch organisieren, praktisches Feedback geben und Probleme zwischen den Teams lösen.

Die Gefahren der Auslagerung von Geschäftslogik

Lass mich eine persönliche Geschichte erzählen. In meiner früheren Position schlug der Leiter des Rechnungswesens vor, die Rechnungslegungsvorschriften der International Financial Reporting Standards (IFRS) in alle Datenprodukte einzubauen. Er ging davon aus, dass es einfacher ist, die berechneten Ergebnisse zusammenzufassen als alles selbst zu berechnen. Es gibt eine Reihe von guten Gründen, warum du deine Geschäftslogik niemals in andere Bereiche auslagern solltest. Zum einen wird vorausgesetzt, dass andere Domänen über tiefgreifende Kenntnisse deiner Domäne verfügen. Außerdem müssen alle Domänen gleichzeitig Änderungen durchführen, wenn die Geschäftslogik aktualisiert werden muss. Wie würdest du das in einer Umgebung mit Dutzenden oder Hunderten von Domänen schaffen? Du bräuchtest wahrscheinlich ein Heer von Beratern, um all diese Aktivitäten zu organisieren und zu verwalten. Der richtige Ansatz ist, die Geschäftslogik dort zu belassen, wo sie hingehört. Für IFRS bedeutet das, dass du andere Domänen aufforderst, der Buchhaltung die Informationen zu liefern, die sie für ihre Berechnungen benötigt. Diese Informationen sollten den ursprünglichen Kontext der bereitstellenden Domäne beibehalten, damit andere Domänen die Daten ebenfalls nutzen können.

Fehlende Werte, Standardwerte und Datentypen

Ich habe hitzige Debatten darüber erlebt, wie fehlende, minderwertige oder voreingestellte Daten interpretiert werden sollten. Nehmen wir zum Beispiel an, das Webformular eines betrieblichen Systems verlangt einen Wert für das Geburtsdatum des Nutzers, aber der Nutzer gibt diese Daten nicht an. Wenn keine Anleitung gegeben wird, könnten die Mitarbeiter einen zufälligen Wert eingeben. Dieses Verhalten könnte es dem Verbraucher erschweren zu erkennen, ob die Daten korrekt sind oder Standardwerte enthalten. Wenn du klare Hinweise gibst, z. B. dass fehlende Geburtsdaten immer auf absurde oder zukünftige Werte wie 9999-12-31 gesetzt werden, können die Kunden erkennen, dass die Daten wirklich fehlen.

Vielleicht möchtest du auch Richtlinien für Datentypen oder Daten einführen, die im gesamten Datensatz einheitlich formatiert sein müssen. Die Angabe der korrekten Dezimalpräzision stellt zum Beispiel sicher, dass Datenkonsumenten keine komplexe Anwendungslogik anwenden müssen, um die Daten zu nutzen. Du könntest diese Grundsätze auf System- oder Domänenebene festlegen, aber ich sehe auch, dass große Unternehmen allgemeine Richtlinien für die Datenformate und -typen aufstellen, die in allen Datenprodukten verwendet werden müssen.

Semantische Konsistenz

Datenprodukte müssen über alle Bereitstellungsmethoden hinweg semantisch konsistent sein: Batch, ereignisgesteuert und API-basiert. Für mich klingt das selbstverständlich, aber ich sehe immer noch Organisationen, die getrennte Richtlinien für Batch-, ereignis- und API-orientierte Daten erstellen. Da der Ursprung der Daten bei allen Verbreitungsmethoden derselbe ist, empfehle ich dir, die Richtlinien für alle Methoden zu vereinheitlichen. Ich werde in Kapitel 7 auf diesen Punkt zurückkommen.

Atomarität

Datenproduktattribute müssen atomar sein. Sie stellen die unterste Ebene der Granularität dar und haben eine genaue Bedeutung oder Semantik. Das heißt, es sollte nicht möglich sein, sie in sinnvolle andere Komponenten zu zerlegen. Im Idealfall sind die Datenattribute eins-zu-eins mit den Geschäftselementen in deinem Datenkatalog verknüpft. Das hat den Vorteil, dass die Datenkonsumenten nicht gezwungen sind, Daten aufzuteilen oder zu verketten.⁴ Ein weiterer Vorteil der Verwendung von atomaren Daten ist, dass alle Richtlinienregeln von den Daten entkoppelt werden können. Wenn du zum Beispiel aufgrund von Vorschriften gezwungen bist, die Kennzeichnung sensibler Daten zu überdenken, musst du nicht alle physischen Daten neu kennzeichnen. Mit einem guten Metadatenmodell und atomaren Daten sollten alle Änderungen automatisch von deinen Geschäftsmetadaten übernommen werden.

Kompatibilität

Datenprodukte sollten stabil bleiben und von den operativen/transaktionalen Anwendungen entkoppelt werden. Dies erfordert einen Mechanismus zur Erkennung von Schemaabweichungen und zur Vermeidung von störenden Änderungen. Außerdem ist eine Versionskontrolle erforderlich, und in einigen Fällen müssen unabhängige Pipelines parallel laufen, damit deine Datenkonsumenten Zeit haben, von einer Version auf eine andere zu migrieren.

Die Kompatibilität von Datenprodukten zu gewährleisten, ist nicht so einfach, wie es vielleicht klingt. Es kann bedeuten, dass historische Daten zwischen alten und neuen Datenprodukten verschoben werden müssen. Das kann ein komplexes Unterfangen sein, da es ETL-Aufgaben wie das Mapping, die Bereinigung und die Bereitstellung einer Standardlogik beinhaltet.

Abstrakte flüchtige Referenzdaten

Du möchtest vielleicht, dass eine Anleitung dafür liefert, wie komplexe Referenzwerte auf abstraktere, datenproduktfreundliche Referenzwerte abgebildet werden. Dies erfordert eine Nuancierung der Agilitätsunterschiede: Wenn das Tempo der Änderungen auf der konsumierenden Seite hoch ist, muss dein Leitprinzip sein, dass komplexe Mapping-Tabellen auf der konsumierenden Seite gepflegt werden; wenn das Tempo der Änderungen auf der bereitstellenden Seite höher ist, lautet das Leitprinzip, dass die Datenprodukteigentümer aufgefordert werden sollten, detaillierte lokale Referenzwerte zu abstrahieren oder auf allgemeinere (weniger granulare), verbraucherunabhängige Referenzwerte aufzurollen. Dieser Leitfaden impliziert auch, dass der Verbraucher zusätzliche Arbeit leisten kann, z. B. die Zuordnung der allgemeineren Referenzwerte zu verbraucherspezifischen Referenzwerten.

Neue Daten bedeuten neue Besitzverhältnisse

Alle Daten, die aufgrund einer Geschäftsumwandlung (einer semantischen Änderung mit Hilfe von Geschäftslogik) erstellt und verteilt werden, gelten als neu und fallen in das Eigentum der erstellenden Domäne. Die in diesem Kapitel besprochenen Grundsätze der Datenverteilung sollten für alle neu erstellten Daten, die gemeinsam genutzt werden, eingehalten werden.

Warnung

Es ist grundlegend falsch, anwendungsfallbezogene, integrierte Daten als (verbraucherorientierte) Datenprodukte zu klassifizieren. Wenn du zulässt, dass anwendungsfallspezifische Daten direkt von anderen Domänen konsumiert werden, sind diese Domänen in hohem Maße von den Implementierungsdetails des zugrunde liegenden konsumierenden Anwendungsfalls abhängig. Schaffe daher immer eine zusätzliche Abstraktionsebene und entkopple deinen Anwendungsfall von anderen Konsumenten. Dieser Ansatz, verbraucherspezifische Daten in ein neues Datenprodukt umzuwandeln, ermöglicht es deinen Domänen, sich unabhängig von anderen Domänen zu entwickeln.

Ein Problem bei der Verbreitung neu erstellter Daten ist die Rückverfolgbarkeit: zu wissen, was mit den Daten passiert. Um die Risiken der Transparenz zu mindern, solltest du die Datenkonsumenten auffordern, ihre Erwerbe und die Abfolge der Aktionen und Transformationen, die sie auf die Daten anwenden, zu katalogisieren. Diese Metadaten zur Datenabfolge sollten zentral veröffentlicht werden. Ich werde in den Kapiteln 10 und 11 darauf zurückkommen.

Datensicherheitsmuster

Für die Datensicherheit, musst du Richtlinien für Datenanbieter festlegen. Diese sollten Folgendes beinhalten:

• Anleitung zur Kapselung von Metadaten für Filterung und Zugriff auf Zeilenebene. Indem du Metadaten zusammen mit den Daten bereitstellst, kannst du Richtlinien oder Ansichten erstellen, um bestimmte Datenzeilen auszublenden oder anzuzeigen, je nachdem, ob ein Verbraucher die Erlaubnis hat, diese Zeilen anzuzeigen.

• Anleitung zu Tags oder Klassifizierungen für den Zugriff auf Spaltenebene und dynamische Datenmaskierung. Diese Tags oder Klassifizierungen werden als Input für Richtlinien oder Ansichten verwendet.

• Anleitung zur effizienten Speicherung von Daten in separaten Tabellen, um grobkörnige Sicherheit zu gewährleisten, die Leistung zu verbessern und die Wartung zu erleichtern.

Wir werden in Kapitel 8 mehr über diese Themen sprechen.

Ein Metamodell aufstellen

Um Datenprodukte und die dazugehörigen Metadaten richtig zu verwalten, empfehle ich dir, ein konsistentes Metamodell zu erstellen, in dem du definierst, wie Entitäten (wie Datendomänen, Datenprodukte, Dateneigentümer, Geschäftsbegriffe, physische Daten und andere Metadaten) miteinander in Beziehung stehen.⁵ Wenn du an deinem Metamodell arbeitest, ist es am besten, einen Datenkatalog zu verwenden, um die Erfassung aller notwendigen Metadaten zu erzwingen. Jedes Mal, wenn du ein neues Datenprodukt in deinen Katalog aufnimmst, kann es einen Workflow auslösen, der damit beginnt, dass der Datenanbieter aufgefordert wird, eine Beschreibung zu liefern und das Datenprodukt mit einem Dateneigentümer, einer Ursprungsanwendung, einer Datendomäne usw. zu verbinden. Als Nächstes kann der Katalog den Anbieter auffordern, alle Elemente des Datenprodukts mit Geschäftsbegriffen und technischen (physischen) Datenattributen zu verknüpfen. Er könnte dann automatisierte Tests durchführen, um zu prüfen, ob diese physischen Orte adressierbar sind, und nach Klassifizierungen und Informationen zu Nutzungsbeschränkungen fragen.

Selbstbedienung zulassen

Datenprodukte sind über die Demokratisierung von Daten. Um die Erstellung von Datenprodukten zu verbessern, solltest du einen Datenmarktplatz einrichten und Selbstbedienungsfunktionen für die Auffindbarkeit, Verwaltung, gemeinsame Nutzung und Beobachtbarkeit anbieten. Erlaube den Ingenieuren zum Beispiel, die REST-Schnittstelle des Datenkatalogs zu nutzen, damit die Registrierung von Datenprodukten automatisiert werden kann. Wenn du es richtig anstellst, kannst du deine Datenprodukte als Teil deiner Continuous Integration/Continuous Delivery (CI/CD)-Pipelines registrieren. Weitere Anleitungen zu diesem Thema findest du in Kapitel 9.

Domänenübergreifende Beziehungen

In der betrieblichen Welt sind die Systeme oft miteinander verflochten oder stark verbunden. Stell dir ein Bestellsystem vor, über das Kunden Bestellungen aufgeben können. Es ist wahrscheinlich, dass ein solches System Daten aus der Kundendatenbank enthält. Andernfalls wäre es nicht in der Lage, Bestellungen mit Kunden zu verknüpfen.

Wenn Bereiche Datenprodukte unabhängig von anderen Bereichen entwickeln, wie erkennen die Verbraucher dann, dass bestimmte Daten zusammengehören oder miteinander verbunden sind? Um diese Abhängigkeiten zu verwalten, solltest du einen Katalog oder einen Wissensgraphen verwenden, der die Beziehungen zwischen den Datensätzen beschreibt und auf die Verknüpfungsschlüssel oder Fremdschlüssel der Datenprodukte verweist.

Bei der Verwaltung von domänenübergreifenden Beziehungen ist es wichtig, dass die Daten immer domänenorientiert bleiben. Der Abgleich zwischen Daten und Dateneigentum muss stark sein, daher sollte keine domänenübergreifende Integration durchgeführt werden, bevor Daten an andere Domänen geliefert werden.

Konsistenz im Unternehmen

Eine starke Dezentralisierung führt dazu, dass die Daten in den einzelnen Domänen isoliert werden. Dies führt zu Bedenken hinsichtlich der Zugänglichkeit und Nutzbarkeit der Daten, denn wenn alle Domänen beginnen, Daten einzeln bereitzustellen, wird es schwieriger, die Daten auf der Verbraucherseite zu integrieren und zu kombinieren. Um diese Bedenken aus dem Weg zu räumen, solltest du ein gewisses Maß an unternehmensweiter Konsistenz einführen, indem du Leitlinien für die Einbeziehung von Unternehmensreferenzwerten (Währungscodes, Ländercodes, Produktcodes, Kundensegmentierungscodes usw.) bereitstellst. Falls zutreffend, kannst du die Eigentümer deiner Datenprodukte bitten, ihre lokalen Referenzwerte den Werten aus den Unternehmenslisten zuzuordnen.

Einige Datenexperten werden argumentieren, dass die Verwendung von Unternehmensreferenzwerten nicht mit einer echten Datenverknüpfung übereinstimmt. Das stimmt bis zu einem gewissen Grad, aber ohne referentielle Integrität wird es zu doppelten Bemühungen um Harmonisierung und Integration in allen Bereichen kommen. Ich schlage nicht vor, ein kanonisches unternehmensweites Datenmodell zu erstellen, wie es in den meisten Data-Warehouse-Architekturen von Unternehmen zu finden ist, sondern lediglich einige Referenzdaten als Orientierung bereitzustellen. Die daraus resultierende Konsistenz kann in einem großen Unternehmen, in dem viele Bereiche auf dieselben Referenzwerte angewiesen sind, hilfreich sein.

Das Gleiche gilt für Stammkennzahlen, die Stammdaten und Daten aus den lokalen Systemen miteinander verbinden. Diese Datenelemente sind wichtig, um herauszufinden, welche Daten gemastert wurden und welche zusammengehören. Du könntest also deine lokalen Domänen bitten, diese Stammkennungen in ihre Datenprodukte aufzunehmen. Weitere bewährte Methoden in diesem Bereich findest du unter in Kapitel 10.

Historisierung, Neulieferungen und Überschreibungen

Um die Bedürfnisse der Verbraucher zu erfüllen, müssen die Datenanbieter oft historische Daten in ihrem ursprünglichen Kontext aufbewahren. Die Verbraucher brauchen diese Daten zum Beispiel, um rückblickende Trendanalysen durchzuführen und vorherzusagen, was als Nächstes passieren wird. Um dies gut zu machen, empfehle ich, Richtlinien zu formulieren, die auf dem Design des Systems, der Art der Daten und der Art, wie sie für spätere Analysen historisiert werden sollen, basieren. Datensätze mit Stammdaten sollten zum Beispiel immer in sich langsam verändernde Dimensionen umgewandelt werden. Auf die Verarbeitung historischer Daten gehen wir in "Datenhistorisierung" näher ein.

Geschäftsmöglichkeiten mit mehreren Eigentümern

Wenn die Business Capabilities gemeinsam genutzt werden, empfehle ich, eine Methode für den Umgang mit gemeinsamen Daten festzulegen. Dazu kann die Verwendung von reservierten Spaltennamen in deinen Datenprodukten gehören, um die Eigentumsverhältnisse zu definieren, die physische Erstellung mehrerer Datenprodukte oder die Einbettung von Metadaten in deine Datenprodukte.

Betriebsmodell

Erfolgreiche Daten Produktentwicklung erfordert ein Betriebsmodell, das ein effektives Datenmanagement, die Festlegung von Standards und bewährten Methoden, die Leistungsverfolgung und die Qualitätssicherung gewährleistet. Ein typisches Datenproduktteam besteht in der Regel aus einem unterstützenden Architekten, Dateningenieuren, Datenmodellierern und Datenwissenschaftlern. Dieses Team muss angemessen unterstützt und finanziert werden, damit es seine Datenprodukte entwickeln und kontinuierlich verbessern kann. Außerdem muss es ein Gremium geben, das die Standards und bewährten Methoden für die Erstellung von Datenprodukten im gesamten Unternehmen festlegt und überwacht. Meiner Meinung nach sind Unternehmen am erfolgreichsten, wenn sie Playbooks entwickeln: Dokumente, die alle Ziele, Prozesse, Arbeitsabläufe, Kompromisse, Checklisten, Rollen und Verantwortlichkeiten des Unternehmens beschreiben. Solche Playbooks werden oft in offenen Repositories gehostet, so dass jeder dazu beitragen kann.

Zur Festlegung guter Standards und bewährter Methoden gehört auch, dass die Teams festlegen, wie sie Leistung und Qualität messen können, und wie die erforderlichen Dienste für jedes Verbrauchsmuster zusammenpassen müssen, damit sie für alle Datenprodukte wiederverwendet werden können. Um sicherzustellen, dass die Datenprodukte den Bedürfnissen der Verbraucher entsprechen und kontinuierlich verbessert werden, sollten die Teams den Wert und den Erfolg ihrer Aktivitäten messen. Relevante Kennzahlen können die Anzahl der Nutzer/innen eines bestimmten Datenprodukts, offene Qualitätsprobleme, Zufriedenheitsbewertungen, die Kapitalrendite oder ermöglichte Anwendungsfälle sein.

Nachdem wir nun die Grundlagen für den notwendigen Bewusstseinswandel bei der Verwaltung von Daten als Produkte erforscht haben, wollen wir uns den Fragen zuwenden, die Architekten am häufigsten gestellt werden: Was ist eine gute Strategie für die Erstellung von Datenprodukten? Sollte dies durch eine zentral bereitgestellte Plattform erleichtert werden, oder müssen die Domänen für ihre eigenen Bedürfnisse sorgen?

Datenprodukt-Architektur

Um die Komplexität deiner Architektur deutlich zu reduzieren, musst du die richtige Balance zwischen Zentralisierung und Dezentralisierung finden. Am einen Ende des Spektrums steht ein vollständig föderierter und autonomer Ansatz, der es jedem Bereich erlaubt, seine eigene Architektur zu hosten und sein eigenes Technologiepaket zu wählen. Dies kann jedoch zu einem Wildwuchs an Datenprodukten, Schnittstellenprotokollen, Metadaten usw. führen. Es erschwert auch die Datenverwaltung und -kontrolle, denn jeder Bereich muss zentrale Disziplinen wie Archivierung, Abstammung, Datenqualität und Datensicherheit genau umsetzen. Die Ausarbeitung all dieser Kompetenzen in den Bereichen selbst wäre eine Herausforderung und würde zu fragmentierter, siloartiger Komplexität führen.

Am anderen Ende steht ein föderierter und zentral gesteuerter Ansatz, bei dem nicht ein einzelnes Silo, sondern mehrere Plattforminstanzen oder Landing Zone Blueprints dieselben Standardinfrastrukturdienste nutzen. Standardisierte Komponenten und eine gemeinsame Infrastruktur senken die Kosten, verringern die Anzahl der Schnittstellen und verbessern die Kontrolle. Im Idealfall werden mehrere Datenprodukt-Architekturen auf derselben Plattform-Infrastruktur gehostet, aber sie sind logisch voneinander isoliert.

High-Level Plattform Design

Packen wir die Architektur und die Komponenten aus, die für die Erstellung von Datenprodukten benötigt werden. Die Bereitstellung von Daten als Produkt ermöglicht es Datenkonsumenten, Daten in vielen Bereichen einfach zu entdecken, zu finden, zu verstehen und sicher darauf zuzugreifen. Das Hauptaugenmerk der gemeinsamen Plattformfunktionen für die Verteilung von Datenprodukten sollte jedoch auf der Erfassung von Daten, der Umwandlung von Daten in lesbare Versionen und der sicheren Bereitstellung von Daten für andere Bereiche liegen. Analyse- oder Berichtsfunktionen für die Entwicklung von Anwendungsfällen zur datengesteuerten Entscheidungsfindung werden zu einem späteren Zeitpunkt in die Architektur aufgenommen; sie werden in Kapitel 11 behandelt.

Etwas ausführlicher gesagt, sollte deine Datenproduktarchitektur mindestens die folgenden Fähigkeiten haben:

• Funktionen zur Erfassung, Aufnahme und Einbindung von Daten über deine Eingangsports

• Möglichkeiten zur Bereitstellung von Daten für verschiedene Domänen über deine Ausgangsports

• Metadatenfunktionen für die Dokumentation, Erkennung, Überwachung, Sicherung und Verwaltung von Daten

• Data-Engineering-Fähigkeiten für die Entwicklung, den Einsatz und die Ausführung des Codes des Datenprodukts

• Funktionen für Datenqualität und Stammdatenmanagement

• Datenmarktplatzfunktionen für ein einheitliches Dateneinkaufserlebnis

Abbildung 4-5 ist ein logischer Aufbau einer Datenproduktarchitektur, der zeigt, wie Daten erfasst, umgewandelt und an andere Bereiche weitergegeben werden. Wir werden auf die einzelnen Komponenten noch genauer eingehen, aber zunächst möchte ich einen Überblick geben. An der Spitze steht eine Metadatenschicht, die Einblicke in die verfügbaren Daten, ihre Eigenschaften und Beziehungen zu anderen Datenmanagementbereichen bietet. Innerhalb dieser Schicht gibt es Metadaten-Repositories für Orchestrierung, Beobachtbarkeit, Vertragsmanagement und so weiter. Sie sind die Bindeglieder zwischen deinem Datenmarktplatz und deiner Datenproduktarchitektur.

Abbildung 4-5. Beispiel für eine Datenproduktarchitektur

Wenn du eine gemeinsam genutzte Infrastruktur verwendest, werden verschiedene Datenproduktarchitekturen isoliert und nicht direkt zwischen Domänen ausgetauscht. Jede Datenproduktarchitektur und die Verantwortlichkeit verbleiben beim Datenanbieter. Ein Datenanbieter, und damit eine Domäne, hat seine eigene Datenproduktarchitektur und seine eigene Pipeline und ist für die Qualität und Integrität der Daten verantwortlich.

Der Schlüssel zur Entwicklung gemeinsamer Plattformen und Datenproduktarchitekturen liegt darin, eine Reihe zentraler grundlegender und domänenunabhängiger Komponenten bereitzustellen und verschiedene Designentscheidungen zu treffen, um sich wiederholende Probleme von den Domänen zu abstrahieren und das Datenmanagement weniger schwierig zu gestalten. In den nächsten Abschnitten werde ich die wichtigsten Überlegungen hervorheben, die auf Beobachtungen aus der Praxis beruhen.

Möglichkeiten der Datenerfassung und des Onboardings

Data Onboarding ist der entscheidende erste Schritt für den erfolgreichen Aufbau einer Datenarchitektur. Der Prozess der Extraktion von Daten aus dem Quellsystem ist jedoch auch eines der schwierigsten Probleme bei der Nutzung von Daten im Allgemeinen. Dabei müssen mehrere Aspekte berücksichtigt werden.

Verschlucken Methode

Zunächst solltest du die Geschwindigkeit festlegen, mit der Daten geliefert oder synchronisiert werden müssen. Grob gesagt gibt es zwei Szenarien, zwischen denen du wählen kannst:

Stapelverarbeitung

Verbraucher, die Daten nur in regelmäßigen Abständen benötigen, können sich mit der Stapelverarbeitung behelfen, bei der eine große Datenmenge auf einmal übertragen wird. Bei der Stapelverarbeitung handelt es sich in der Regel um einen Datensatz mit Millionen von Datensätzen, der in einer Datei gespeichert wird. Warum brauchen wir trotzdem eine Stapelverarbeitung? In vielen Fällen ist dies die einzige Möglichkeit, unsere Daten zu erfassen. Die meisten wichtigen relationalen Datenbankmanagementsysteme (RDBMS) verfügen über Stapelverarbeitungskomponenten, um die Bewegung von Daten in Stapeln zu unterstützen. Der Datenabgleich, also die Überprüfung der Daten während dieser Bewegung, ist oft ein Problem.⁶ Vor allem bei Finanzprozessen ist es wichtig, zu überprüfen, ob alle Daten vorhanden sind. Außerdem sind viele Systeme komplex und bestehen aus einer enormen Anzahl von Tabellen, und die Structured Query Language (SQL) ist die einzige Möglichkeit, die Daten auszuwählen und zu extrahieren.

Datenerfassung in Echtzeit

Verbraucher, die inkrementelle oder nahezu zeitnahe Datenaktualisierungen wünschen, können diese am besten mit ereignisgesteuerter oder API-basierter Dateneingabe erreichen. Auf diese Weise können wir Daten relativ schnell sammeln und verarbeiten und eignen sich gut für Anwendungsfälle, bei denen die Datenmengen relativ klein sind, die Berechnungen, die mit den Daten durchgeführt werden, relativ einfach sind und die Latenzzeiten nahezu in Echtzeit sein müssen. Viele Anwendungsfälle lassen sich mit ereignisgesteuertem Ingestion bewältigen, aber wenn Vollständigkeit und große Datenmengen ein wichtiges Anliegen sind, werden die meisten Teams auf die traditionellen Batches zurückgreifen. Darauf werden wir in Kapitel 6 näher eingehen.

Obwohl die Echtzeit-Datenerfassung immer beliebter wird, wird eine reine Streaming-Architektur (Kappa) die Batch-Verarbeitung nicht für alle Anwendungsfälle ersetzen können. Ich gehe davon aus, dass in den meisten Unternehmen beide Ingestion-Methoden Seite an Seite genutzt werden.

Komplexe Softwarepakete

Bei der Dateneingabe ist es wichtig, die Vielfalt der spezialisierten Softwarepakete zu berücksichtigen. Viele sind extrem schwer zu interpretieren oder zugänglich. Die Datenbankschemata sind oft furchtbar komplex, und die referentielle Integrität wird in der Regel programmatisch durch die Anwendung und nicht durch die Datenbank gewährleistet. Manche Anbieter schützen ihre Daten sogar, so dass sie nur mit Unterstützung einer Drittanbieterlösung extrahiert werden können.

In all diesen komplexen Situationen empfehle ich dir, für jedes Quellsystem zu prüfen, ob du deine Architektur mit zusätzlichen Diensten ergänzen musst, die eine Datenextraktion ermöglichen. Solche Dienste können die komplexen Strukturen des Quellsystems verbergen und dich vor langwierigen und teuren Mapping-Übungen schützen. Sie schützen dich auch vor einer engen Kopplung, da das Datenschema eines komplexen Herstellerprodukts in der Regel nicht direkt von dir kontrolliert wird. Wenn der Anbieter eine neue Produktversion herausbringt und sich die Datenstrukturen ändern, werden alle deine Datenpipelines unterbrochen. Unterm Strich ist eine Komponente eines Drittanbieters die Investition wert.

Externe APIs und SaaS-Anbieter

Externe API- oder SaaS-Anbieter erfordern in der Regel ebenfalls besondere Aufmerksamkeit. Ich habe Situationen untersucht, in denen ein vollständiger Datensatz benötigt wurde, der SaaS-Anbieter aber nur eine relativ kleine Datenmenge über eine API zur Verfügung stellte. Andere Anbieter wenden möglicherweise eine Drosselung an: eine Quote oder ein Limit für die Anzahl der Anfragen. Es gibt auch Anbieter mit teuren Zahlungsplänen für jeden Anruf, den du machst. In all diesen Fällen empfehle ich, sich entweder ein Tool zu besorgen, das die Extraktion aus APIs unterstützt, oder eine eigene Komponente zu entwickeln, die regelmäßig Daten abruft.

Eine richtig konzipierte benutzerdefinierte Implementierung kann alle API-Aufrufe zuerst an deine Datenproduktarchitektur weiterleiten. Wenn dieselbe Anfrage vor kurzem gestellt wurde, werden die Ergebnisse direkt von der Datenproduktarchitektur geliefert. Wenn nicht, wird die API des SaaS-Anbieters ausgelöst und die Ergebnisse werden zurückgegeben und in deiner Datenproduktarchitektur für spätere Aufrufe gespeichert. Mit diesem Muster kann schließlich eine vollständige Datensammlung für die Verbraucher bereitgestellt werden.

Abstammung und Metadaten

Bei all deinen Datenextraktions- und Onboarding-Komponenten ist es wichtig, dass du der Datenextraktion besondere Aufmerksamkeit schenkst. Für Unternehmen ist es wichtig zu wissen, welche Daten extrahiert wurden und welche Transformationen auf die Daten angewendet wurden. Die Standardisierung und die Festlegung, wie die Konnektoren mit deinem Datenstamm-Repository integriert werden sollen, ist eine wichtige Aufgabe. Du solltest diese Untersuchung im Vorfeld durchführen, damit du weißt, was sich integrieren lässt und was nicht. Lineage kann im Nachhinein nur schwer hinzugefügt werden, da es stark von Transformations-Frameworks und ETL-Tools abhängt; am besten wählst du aus, testest, validierst und standardisierst, bevor du mit der eigentlichen Implementierung beginnst.

Datenqualität

Die Datenqualität ist ein weiterer wichtiger Aspekt bei der Planung. Wenn die Datensätze in die Datenproduktarchitektur aufgenommen werden, sollte ihre Qualität überprüft werden. Hierfür gibt es zwei Aspekte.

Zunächst solltest du die Integrität deiner Daten überprüfen, indem du sie mit den veröffentlichten Schemata vergleichst. Damit willst du sicherstellen, dass neue Daten von hoher Qualität sind und deinen Standards und Erwartungen entsprechen. Diese erste Verteidigungslinie liegt in der Verantwortung der Dateneigentümer, Datenverwalter und Dateningenieure. Das sind die Teammitglieder, die die Daten erstellen und beschaffen. Sie müssen sicherstellen, dass die Daten die von den Behörden oder den Datenkonsumenten festgelegten Anforderungen an die Datenqualität erfüllen.

Zweitens gibt es Qualitätsprüfungen, die eher föderaler Natur sind. Diese Prüfungen sind weniger von den einzelnen Datenproduktteams abhängig, da andere Teams definieren, was eine gute Datenqualität ausmacht. Diese Arten von Datenqualitätsprüfungen werden in der Regel asynchron durchgeführt und zeigen die entsprechenden Parteien an oder benachrichtigen sie. Bei den föderierten Kontrollen handelt es sich in der Regel um Funktionsprüfungen: Vollständigkeit, Genauigkeit, Konsistenz, Plausibilität usw. Datenintegrität und föderierte Datenqualität sind zwei verschiedene Disziplinen, die manchmal ihr eigenes Metadaten-Repository haben, in dem Schema-Metadaten oder funktionale Validierungsregeln gespeichert werden. In diesem Fall hat jeder Bereich seine eigene Standardplattform.

Ein Vorteil bei der Verwendung der gemeinsamen Infrastruktur für Datenproduktarchitekturen ist, dass du die Leistung von Big Data für die Datenqualitätsverarbeitung nutzen kannst. Apache Spark zum Beispiel bietet die verteilte Verarbeitungsleistung, um Hunderte von Millionen von Datenzeilen zu verarbeiten. Um sie effizient zu nutzen, kannst du ein Framework verwenden, um Daten zu dokumentieren, zu testen und Profile für die Datenqualität zu erstellen. Great Expectations und Soda, zum Beispiel, sind offene Standards für Datenqualität, die von vielen großen Organisationen genutzt werden. Ein weiterer Vorteil des Datenqualitätsmanagements auf einer gemeinsamen Infrastruktur ist, dass du bereichsübergreifende Prüfungen der referentiellen Integrität durchführen kannst. Quellsysteme verweisen oft auf Daten aus anderen Anwendungen oder Systemen. Wenn du die Integrität der Referenzen überprüfst und verschiedene Datensätze vergleichst und gegenüberstellst, wirst du Fehler und Zusammenhänge finden, von denen du nichts wusstest.

Wenn die Überwachung der Datenqualität richtig implementiert ist, erkennt und beobachtet sie nicht nur Probleme mit der Datenqualität, sondern wird auch Teil der allgemeinen Datenqualitätskontrolle, die die bestehenden Daten von überprüft und um neue Daten ergänzt.⁷ Wenn die Qualität aus irgendeinem Grund unter einen bestimmten Schwellenwert fällt, kann der Rahmen die Daten parken und die Dateneigentümer auffordern, einen Blick darauf zu werfen und entweder für die Daten zu bürgen, sie zu entfernen oder sie erneut zu liefern. Ein Kontrollrahmen für die Datenqualität bedeutet, dass es eine geschlossene Feedbackschleife gibt, die Qualitätsprobleme kontinuierlich korrigiert und verhindert, dass sie erneut auftreten. Die Datenqualität wird fortlaufend überwacht; Abweichungen vom Qualitätsniveau werden sofort behoben. Denke daran, dass Probleme mit der Datenqualität in den Quellsystemen gelöst werden müssen, nicht in der Architektur deines Datenprodukts. Die Behebung von Datenqualitätsproblemen an der Quelle stellt sicher, dass sie nicht an anderen Stellen auftauchen.

Die Auswirkungen der Datenqualität sollten nicht unterschätzt werden. Wenn die Qualität der Daten schlecht ist, werden die Verbraucher mit der sich wiederholenden Arbeit konfrontiert, die Daten zu bereinigen und zu korrigieren. Ich möchte auch betonen, wie wichtig die Standardisierung ist. Wenn die einzelnen Teams über ihre eigenen Datenqualitätsrahmen entscheiden, ist es unmöglich, die Kennzahlen und Ergebnisse zwischen den Bereichen zu vergleichen.

Datenhistorisierung

Die korrekte Verwaltung historischer Daten ist für ein Unternehmen von entscheidender Bedeutung, denn ohne diese Daten ist es nicht möglich, Trends im Laufe der Zeit zu erkennen und Vorhersagen für die Zukunft zu treffen. Auch bei der Verwaltung historischer Daten sollten Standards berücksichtigt werden. In diesem Abschnitt werden einige Hintergründe erläutert und verschiedene Darstellungsformen und Ansätze für die Verwaltung dieser Daten untersucht.

Die Organisation historischer Daten ist ein wichtiger Aspekt des Data Warehousing. In diesem Zusammenhang hört man auf oft die Begriffe nichtflüchtig und zeitvariant. Nichtflüchtig bedeutet, dass die vorherigen Daten nicht gelöscht werden, wenn neue Daten hinzugefügt werden. Zeitvariant bedeutet, dass die Daten innerhalb eines bestimmten Zeitraums konsistent sind, z. B. werden die Daten täglich oder in anderen regelmäßigen Abständen geladen und ändern sich innerhalb dieses Zeitraums nicht.

Datenprodukte spielen eine wichtige Rolle bei der Speicherung und Verwaltung großer Mengen an historischen Daten. Aber wie würdest du dies in einer dezentralen Architektur angehen? Ein Unterschied zum Data Warehousing ist, dass Datenprodukte die Daten in ihrem ursprünglichen Kontext bewahren. Es wird keine Umwandlung in ein Unternehmensdatenmodell erwartet, weil die Datenprodukte auf Domänen ausgerichtet sind; der ursprüngliche (Domänen-)Kontext geht nicht verloren. Das ist ein großer Vorteil: So können Domänen ihre eigenen Datenprodukte für ihre eigenen betrieblichen Anwendungsfälle, wie z. B. maschinelles Lernen, "frisieren" und gleichzeitig Daten für andere Domänen bereitstellen. Das hat zur Folge, dass die Domänen das Bedürfnis haben, sich um die Daten zu kümmern, die ihnen gehören. Letztlich wird die Nutzung der eigenen Datenprodukte sowohl deren Qualität als auch die Kundenzufriedenheit verbessern.

Obwohl eine Datenproduktarchitektur ein technologieunabhängiges Konzept ist, ist es wahrscheinlich, dass viele dieser Architekturen mit kostengünstigeren verteilten Dateisystemen, wie z. B. Data Lake Services, entwickelt werden. Das bedeutet, dass für die Aktualisierung und das Überschreiben von Stamm-, Transaktions- und Referenzdaten unterschiedliche Arten der Datenverarbeitung erforderlich sind. Daher empfehle ich, einen oder eine Kombination der folgenden Ansätze in Betracht zu ziehen, die jeweils einen Kompromiss zwischen der Investition in und der Verwaltung von eingehenden Daten und der Einfachheit der Datennutzung darstellen. Jeder Ansatz hat Vor- und Nachteile.

Punkt-zu-Punkt

Der erste Ansatz für die Verwaltung historischer Daten ist die Speicherung der Originaldaten als historische Referenz, die normalerweise unveränderlich ist. Stell dir ein Reservoir vor, in das die Daten mit einer Kopieraktivität eingefügt werden. Bei diesem reinen Einfügeverfahren empfiehlt es sich, die Daten logisch zu partitionieren, z. B. durch eine logische Trennung von Datum und Uhrzeit (siehe Abbildung 4-6).⁸

Abbildung 4-6. Beispiele dafür, wie Daten aussehen, wenn sie mit volldimensionalen Snapshots oder sich langsam ändernden Dimensionen partitioniert sind (Typ 2)

Die Verwaltung nur vollständiger Snapshots ist einfach zu implementieren. Bei jedem ETL-Zyklus wird der gesamte Output als unveränderlicher Snapshot gespeichert. Danach können die Tabellenschemata durch den Ort ersetzt werden, an dem die neuen Daten gespeichert sind. Der Container ist eine Sammlung all dieser Snapshots zu einem bestimmten Zeitpunkt. Einige Praktiker/innen könnten argumentieren, dass dieser Ansatz zu einer Verdoppelung der Daten führt. Ich halte das nicht für ein Problem, denn die Speicherung in der Cloud ist heutzutage relativ günstig. Vollständige Snapshots erleichtern auch die erneute Bereitstellung oder den Wiederaufbau eines integrierten Datensatzes, der alle im Laufe der Zeit vorgenommenen Änderungen enthält. Wenn ein Quellsystem feststellt, dass falsche Daten geliefert wurden, können die Daten erneut übermittelt werden, und die Partition wird überschrieben.

Hinweis

Eine zeitpunktbezogene Darstellung kann nur dann sinnvoll sein, wenn die bereitgestellten Daten bereits alle benötigten historischen Daten enthalten - zum Beispiel, wenn die Daten so bereitgestellt werden, dass sie bereits Start- und Enddaten für alle Datensätze enthalten.

Ein Nachteil der Momentaufnahme vollständiger Datensätze ist, dass die (rückwirkende) Datenanalyse schwieriger ist. Vergleiche zwischen bestimmten Zeiträumen sind problematisch, wenn keine Anfangs- und Enddaten verfügbar sind, weil die Verbraucher alle historischen Daten verarbeiten und speichern müssen. Die Verarbeitung historischer Daten aus drei Jahren könnte zum Beispiel die Verarbeitung von über tausend Dateien nacheinander erfordern. Die Datenverarbeitung kann je nach Größe der Daten viel Zeit und Rechenkapazität in Anspruch nehmen. Deshalb wird empfohlen, auch einen Intervallansatz in Betracht zu ziehen.

Intervall

Ein anderer Ansatz für die Verwaltung und Präsentation historischer Daten ist der Aufbau historischer Datensätze, in denen alle Daten verglichen und verarbeitet werden. Du könntest zum Beispiel Datensätze mit sich langsam verändernden Dimensionen (SCDs) erstellen,⁹ die alle Veränderungen im Laufe der Zeit zeigen. Dieser Prozess erfordert ETL, denn du musst die vorhandenen Datenlieferungen nehmen und sie mit allen früheren Lieferungen vergleichen. Nach dem Vergleich werden die Datensätze geöffnet und/oder geschlossen. Bei diesem Prozess wird in der Regel den Werten, die aktualisiert werden, ein Enddatum und den neuen Werten ein Startdatum zugewiesen. Für den Vergleich ist es empfehlenswert, alle nicht funktionierenden Daten auszuschließen.¹⁰

Kann ich meine Datenprodukte mit Datenvirtualisierung gestalten?

Ich habe bis zur Diskussion über die Historisierung gewartet, um die Datenvirtualisierung anzusprechen. Die Datenvirtualisierung und die Erstellung von Datenprodukten sind aus mehreren Gründen keine gute Kombination:

• Die Datenvirtualisierung ist keine Ergänzung zum Datenlebenszyklusmanagement. Sie kann keine irrelevanten Daten aus den zugrundeliegenden Systemen verschieben. Alle historischen Daten müssen in den OLTP-Systemen verbleiben, was die Datenvirtualisierung auf lange Sicht zu einer teuren Lösung macht.

• Die Datenvirtualisierungsschicht führt zu einer engeren Kopplung.¹¹ Wenn sich die Quellsysteme ändern, sind sofort auch Änderungen an der Datenvirtualisierungsschicht erforderlich. Ansichten oder zusätzliche Schichten können helfen, aber jede Änderung erfordert immer noch eine Abstimmung zwischen den Eigentümern der Quellsysteme und den Ingenieuren, die die Datenvirtualisierungsschicht pflegen.

• Die Datenvirtualisierung ist auf das Netzwerk angewiesen. In einer verteilten Umgebung mit vielen Netzwerken und Hops (die über zusätzliche Netzwerkgeräte laufen) ist eine höhere Latenz zu erwarten. Außerdem gibt es eine Kopplung, d.h. wenn das Netzwerk ausfällt, ist auch die Virtualisierungsschicht unterbrochen.

• Die Datenvirtualisierung ist durch die zugrunde liegende Technologie begrenzt, bei der es sich in der Regel um ein RDBMS handelt. Obwohl die Datenvirtualisierung viele Datenbanksysteme lesen kann, ist es im Allgemeinen nicht möglich, Endpunkte für Dokumenten-, Schlüssel/Wert-, Spalten- und Graphdatenbanken zu erstellen.

• Bei intensiven und wiederholbaren Abfragen verbraucht die Datenvirtualisierung mehr Rechenleistung, da die Umwandlungen in Echtzeit durchgeführt werden, wenn die Daten abgefragt werden. Caching-Techniken können diesen Effekt verringern, aber die benötigte Rechenleistung ist immer größer, wenn Daten verwendet werden, nachdem sie für den Verbrauch vorverarbeitet wurden.

Fazit: Der Zugang zu Datenprodukten kann virtualisiert werden, aber du solltest deine Datenprodukte nicht nur mit einer Datenvirtualisierungs-Engine entwerfen und entwickeln.

Der Ansatz, Intervalle zu vergleichen und historische Daten aufzubauen, hat den Vorteil, dass die Daten effizienter gespeichert werden, weil sie verarbeitet, dedupliziert und kombiniert werden. Wie du in Abbildung 4-6 sehen kannst, nimmt die sich langsam verändernde Dimension auf der rechten Seite nur halb so viele Zeilen ein. Die Abfrage der Daten, z. B. mit einer relationalen Datenbank, ist folglich einfacher und schneller. Auch das Bereinigen der Daten oder das Entfernen einzelner Datensätze, wie es für die Einhaltung der GDPR erforderlich sein könnte, wird einfacher, da du nicht alle zuvor gelieferten Datensätze verarbeiten musst.

Der Nachteil ist jedoch, dass der Aufbau von sich langsam verändernden Dimensionen mehr Verwaltung erfordert. Alle Daten müssen verarbeitet werden. Änderungen in den zugrundeliegenden Quelldaten müssen erkannt werden, sobald sie auftreten, und dann verarbeitet werden. Diese Erkennung erfordert zusätzlichen Code und Rechenkapazitäten. Ein weiterer Aspekt ist, dass die Datenkonsumenten in der Regel unterschiedliche Anforderungen an die Historisierung haben. Wenn die Daten zum Beispiel täglich verarbeitet werden, der Kunde aber eine monatliche Darstellung benötigt, muss er einen zusätzlichen Verarbeitungsschritt durchführen.

Außerdem kann der Prozess der Neuauslieferung mühsam und schwierig zu verwalten sein, weil falsche Daten verarbeitet werden und Teil der Dimensionen werden könnten. Das kann mit einer Wiederverarbeitungslogik, zusätzlichen Versionen oder Gültigkeitsdaten behoben werden, aber es ist immer noch zusätzliches Management erforderlich. Der Fallstrick dabei ist, dass die korrekte Verwaltung der Daten zur Aufgabe eines zentralen Teams werden kann, so dass diese Skalierbarkeit ein hohes Maß an intelligenten Self-Service-Funktionen erfordert.

Ein weiterer Nachteil des Aufbaus von historischen Daten für den allgemeinen Gebrauch durch alle Verbraucher ist, dass die Verbraucher möglicherweise immer noch etwas verarbeiten müssen, wenn sie Spalten in ihrer Auswahl auslassen. Wenn ein Verbraucher zum Beispiel eine engere Auswahl trifft, kann es sein, dass er doppelte Datensätze erhält und die Daten erneut verarbeiten muss, um sie zu entduplizieren. Aus Gründen der Skalierbarkeit und um den Verbrauchern zu helfen, kannst du auch eine Mischung aus beiden Ansätzen in Betracht ziehen, indem du volldimensionale Snapshots aufbewahrst und "historische Daten als Service" anbietest. In diesem Szenario wird allen Verbraucherdomänen ein kleiner Berechnungsrahmen angeboten, mit dem sie die Erstellung historischer Daten je nach Umfang (täglich, wöchentlich oder monatlich), Zeitspanne, Attributen und Datensätzen, die sie benötigen, planen können. Mit kurzlebigen Verarbeitungsinstanzen in der öffentlichen Cloud kann dies sogar kosteneffizient gemacht werden. Der große Vorteil dieses Ansatzes ist, dass du flexibel bleibst, wenn es um neue Lieferungen geht, aber kein technisches Team für die Verwaltung und Aufbereitung der Datensätze brauchst. Ein weiterer Vorteil ist, dass du die Zeitspannen, den Umfang und die Attribute an die Bedürfnisse aller Beteiligten anpassen kannst.

Nur für Anhänge

Einige Arten der Datenübermittlung lassen sich am besten mit einer reinen Anfügemethode realisieren. Bei dieser Methode lädst du nur neue oder geänderte Datensätze aus der Anwendungsdatenbank und fügst sie an den bestehenden Satz von Datensätzen an. Das funktioniert sowohl für Transaktionsdaten als auch für ereignisbasierte Daten, die wir in Kapitel 6 besprechen werden. Die Methode des reinen Anhängens wird oft mit der Erfassung von Änderungsdaten kombiniert, bei der du einen Strom von Änderungen einrichtest, indem du Änderungen in Standardtabellen, Verzeichnistabellen und Ansichten identifizierst und erfaßt.

Historisierung und Streaming Ingestion

Die Dateneingabe in Echtzeit wird in der Regel auf zwei verschiedene Arten gehandhabt. Im ersten Szenario werden die Daten während des Eingangs transformiert und das Ergebnis wird direkt in eine NoSQL-Datenbank eingefügt. Der gesamte Prozess dauert in der Regel nur ein paar Sekunden oder Minuten. Das Hauptziel ist es, die Daten so schnell wie möglich bereitzustellen, sobald sie eintreffen. Im zweiten Szenario werden Echtzeitdaten in regelmäßigen Abständen verarbeitet, zum Beispiel in Form von Mikrobatches. Hier geht es vor allem darum, alle Daten zusammenzuführen und zu historisieren, damit die Daten in einem schnelleren Intervall nachgelagert werden können. Beim Zusammenführen von Daten ist die Latenzzeit der Verarbeitung zu beachten, denn die Verarbeitung braucht Zeit.

Definiere deine Historisierungsstrategie

Der richtige Historisierungsansatz für ein Datenprodukt hängt von den Datentypen, den Kundenanforderungen und den Vorschriften ab. Alle Ansätze für die Historisierung und den Aufbau von Datenprodukten können miteinander kombiniert werden, und du kannst verschiedene Ansätze für verschiedene Arten von Daten verwenden. Stammdaten können zum Beispiel aus einer Anwendung geliefert und nach dem Stil der sich langsam verändernden Dimensionen aufgebaut werden. Referenzdaten lassen sich leicht mit Hilfe von Snapshots verarbeiten, während du Transaktionsdaten für dasselbe System vielleicht per Append-Only-Lieferung verarbeiten möchtest. Du kannst vollständige Snapshots von allen Lieferungen aufbewahren und gleichzeitig langsam veränderte Dimensionen aufbauen.

Um bei der Entwicklung und Gestaltung von Datenprodukten erfolgreich zu sein, ist eine umfassende Strategie der Schlüssel. Bewährte Methoden sollten sich darauf konzentrieren, wie du Daten schichten und eine Historie in jedem deiner Bereiche aufbauen kannst. Diese Schichtstrategie kann die Entwicklung und Pflege von Skripten und Standarddiensten, wie z. B. Änderungsdatenerfassungsdiensten, beinhalten.¹²

Die hier vorgestellten bewährten Methoden sollen einen Einblick geben, aber auch zeigen, dass Datenproduktmanagement ein umfangreiches Unterfangen ist. Im nächsten Abschnitt werden wir uns eingehender mit einigen Aspekten des Lösungsdesigns bei der Entwicklung einer Architektur beschäftigen. Wir werden dies anhand eines realen Beispiels tun und dabei berücksichtigen, was wir bereits besprochen haben.

Lösungsdesign

Jetzt, da du mit einigen bewährten Methoden und Designprinzipien vertraut bist, wird es Zeit für etwas Praktisches: die Erstellung von leseoptimierten Abstraktionen über deine komplexen Anwendungsdaten mithilfe von Lösungen und Diensten. Die Technologien und Methoden, die Unternehmen für die Entwicklung von Datenprodukten einsetzen, unterscheiden sich in der Regel erheblich von Unternehmen zu Unternehmen. Dieses Thema ist auch deshalb so schwierig zu behandeln, weil es keine Plattformen oder Produkte gibt, die den gesamten Lebenszyklus von Datenprodukten verwalten. Es würde ein weiteres Buch erfordern, um all die verschiedenen Möglichkeiten zu beschreiben, wie eine durchgängige Datenproduktarchitektur umgesetzt werden kann:

• Die Cloud ist zur Standardinfrastruktur für die Verarbeitung von Daten geworden, weil sie erhebliche Vorteile gegenüber lokalen Umgebungen bietet. Alle gängigen Cloud-Plattformen bieten eine Reihe von Self-Service-Datendiensten, die für den Start jeder Implementierung ausreichen.

• Data Lake Services sind bei allen Arten von Unternehmen beliebt. Da das Datenvolumen täglich wächst, ist die Speicherung der Daten in einer HDFS-kompatiblen Cloud Object Storage eine gute Möglichkeit, die Architektur kosteneffizient zu gestalten. Zu den Vorteilen dieser Art von Diensten gehören die Trennung von Speicherung und Rechenleistung und die Reduzierung der Datenduplikation durch den Einsatz von leichtgewichtigen Abfragediensten.¹³

• Ein beliebter Stack ist die Datenverarbeitung mit Spark, Python und Notebooks. Gründe für dieses Muster sind die große und aktive Community, die Vorteile von Open Source und starker Interoperabilität sowie die breite Unterstützung für verschiedene Anwendungsfälle, von Data Engineering bis Data Science. Spark eignet sich zwar hervorragend für ETL und maschinelles Lernen, ist aber nicht für die Durchführung von interaktiven Abfragen mit niedriger Latenz optimiert. Eine weitere Überlegung bei der Verwendung von Notebooks ist die Beachtung von sich wiederholenden Aktivitäten, wie z. B. Datenhistorisierung, technische Datentransformationen und Schema-Validierung. Eine bewährte Methode für den Einsatz von Notebooks ist die Entwicklung gemeinsamer Verfahren und eines metadatengesteuerten Frameworks mit konfigurierbaren Verfahren für Ziele, Validierungen, Sicherheit und usw.¹⁴

• Für die Transformation und Modellierung von Daten ergänzen viele Unternehmen ihre Architektur mit zusätzlichen Diensten wie dbt. Obwohl Spark mit benutzerdefiniertem Code für die Datenumwandlung verwendet werden kann, sind Unternehmen oft der Meinung, dass sich größere Projekte durch Templating und das Schreiben von Konfigurationen besser rationalisieren lassen. Sowohl Templating-Tools als auch Notebooks sind praktikable Optionen, die sich gegenseitig ergänzen können. Ich sehe viele Unternehmen, die zunächst die Datenvalidierung, technische Transformation und Historisierung mit Notebooks erledigen und dann ihre Daten mit Tools wie dbt integrieren.

• Orchestrierung und Workflow-Automatisierung werden benötigt , um den Prozess von der Datenaufnahme bis zur Bereitstellung der Daten zu steuern. Obwohl Standardisierung der Schlüssel zur Beobachtbarkeit ist, ist es eine bewährte Methode, jedem Team die Freiheit zu geben, sein eigenes lokales Wissen zu entwickeln und lokale Prioritäten zu verfolgen. Eine weitere bewährte Methode besteht darin, die CI/CD- und Workflow-Prozesse zu integrieren, aber die Pipelines für jede Anwendung oder jedes Datenprodukt unabhängig zu halten.

• Wenn du dich für ein Tool entscheidest, empfehle ich dir, nach einem modernen Data Stack zu suchen. Es gibt viele beliebte Optionen, die von Open-Source- bis zu Closed-Source-Lösungen reichen.

• Metadatenmanagement Dienste, wie z.B. Datenkataloge und Data Lineage Tools, stehen oft außerhalb der Datenproduktarchitekturen. Diese Dienste werden als allgemeine Dienste von einer zentralen Behörde angeboten. Diese Überlegungen werden in Kapitel 9 eingehend erörtert.

Eine häufige Frage in Bezug auf die Gestaltung von Datenprodukten ist, wie die Konzepte von Data Lake und Data Mesh zusammenhängen. Auch wenn sie auf den ersten Blick widersprüchlich erscheinen, ergänzt die zugrunde liegende Technologie von Data Lakes die Vision des Datenproduktdesigns. Es spricht also nichts dagegen, Data-Lake-Technologien in einem Datennetz zu verwenden.

Eine weitere häufig gestellte Frage ist, ob jeder Bereich von die Autonomie hat, seinen eigenen modernen Datenstack auszuwählen. Enthusiasten ziehen schnell eine Parallele zwischen Microservices und Data-Mesh-Architekturen und argumentieren, dass die volle Autonomie es jeder Domäne ermöglicht, ihre eigene optimale Technologieauswahl zu treffen. Viele Unternehmen schlagen jedoch fehl, weil die Teams der einzelnen Bereiche gegensätzliche Entscheidungen treffen. Stell dir vor, du hast 25 "autonome" Teams, die alle ihre Datenproduktarchitekturen mit ihren eigenen Tools und Arbeitsweisen umsetzen. Wenn alle Tools unterschiedlich sind, wie willst du dann Lineage, Datenqualitätsmetriken, Überwachungsstatistiken und Ergebnisse der Stammdatenverwaltung sammeln? Wie kannst du Interoperabilität zwischen den Plattformen erreichen, wenn jedes Team seinen eigenen Standard verwendet? Auf diese Fragen gehe ich am Ende dieses Kapitels ein, aber es ist wichtig festzuhalten, dass Identität, Governance und Interoperabilität die Eckpfeiler eines jeden föderalen Musters sind. Wenn du eine dieser Säulen vernachlässigst, landest du schnell bei vielen Punkt-zu-Punkt-Lösungen, die architektonisch teuer und schwer zu verwalten sind. Autonomie beginnt mit der Unternehmensarchitektur auf einer zentralen Ebene und erfordert Standardisierung. Bei der Flexibilität geht es um eine lose Kopplung und die Beseitigung von Abhängigkeiten. Autonomie sollte nicht in organisatorischem Chaos, unkontrolliertem Technologie-Wildwuchs, einer Kostenexplosion oder einer Kombination aus all diesen Faktoren enden.

Beispiel aus der realen Welt

In diesem Abschnitt führe ich dich durch ein praktisches Beispiel für die Erstellung einer Datenproduktarchitektur. Dieses Beispiel ist nicht besonders komplex, enthält aber die wesentlichen Bestandteile für die spätere Diskussion und Bewertung. Nehmen wir an, die Datenproduktarchitektur wird für ein Unternehmen entworfen, in dem etwa die Hälfte der Bereiche operativ und transaktional ist. Diese Systeme sind als goldene Quellen gekennzeichnet und bilden den Ausgangspunkt für die Datenaufnahme. Die anderen Bereiche sind konsumentenorientiert; für sie müssen Daten bereitgestellt werden.

Tipp

Eine ausführliche Anleitung zu diesem Beispiel mit Screenshots und Schritt-für-Schritt-Anweisungen findest du in meinem Blogbeitrag "DBT für den Bau einer Medaillon-Seehaus-Architektur verwenden".

Wenn ich die Aufgabe hätte, eine Datenproduktarchitektur für diese Organisation auf Azure zu entwerfen, könnte ich die in Abbildung 4-7 dargestellte Lösung vorschlagen. Mein Ausgangspunkt wäre die Bereitstellung einer Datenlandezone und einiger Ressourcengruppen mit einem standardisierten Satz von Diensten für meine erste Domäne: Azure Data Factory (ADF), Azure Data Lake Storage (ALDS) und Azure Databricks. Anschließend würde ich mit einem Dienst wie ADF Daten sammeln und sammeln. Wenn möglich, würde ich vorgefertigte Konnektoren verwenden. Alternativ dazu würde ich die Eigentümer der Anwendungen bitten, ihre Daten zu exportieren und an zwischengeschalteten Orten bereitzustellen. Das können z. B. Blob-Storage-Konten sein, von denen die Daten zur späteren Verarbeitung abgeholt werden.

Abbildung 4-7. Eine einfache Datenproduktarchitektur mit einem Lakehouse-Design: Sie umfasst Dienste für die Datenaufnahme, die Erstellung von Datenprodukten und die Datenverwaltung

Ich würde ADLS verwenden, um Daten in meiner Datenproduktarchitektur zu speichern. Ein gängiges Entwurfsmuster für die Gruppierung von Daten ist die Verwendung von drei Containern:¹⁵

Bronze

Rohdaten, die in verschiedenen Formaten und Strukturen vorliegen können.

Silber

Gefilterte und bereinigte Daten, die in einem standardisierten spaltenorientierten Dateiformat gespeichert werden.

Gold

Leseoptimierte Daten, die für die Nutzung durch andere Bereiche bereit sind. Manche Organisationen bezeichnen diese leseoptimierten oder verbraucherfreundlichen Datensätze alsDatenprodukte.

Nachdem ich meinen Data Lake konfiguriert habe, fahre ich mit der Übung fort und erstelle meine erste Datenpipeline. Zunächst würde ich die Kopieraktivität verwenden, um Daten in die Bronze-Schicht zu kopieren. Die Daten in dieser Schicht werden im Parquet-Format gespeichert, da keine Versionierung erforderlich ist. Für die Historisierung der Daten wird ein JJJJMMTT-Partitionierungsschema verwendet. Ältere Datenversionen werden für Ad-hoc-Analysen oder Debugging-Zwecke aufbewahrt.

Als Nächstes würde ich eine weitere Pipeline-Aktivität hinzufügen, um Notebooks auszuführen und Parameter an Databricks zu übergeben.¹⁶ Databricks verwendet ein dynamisches Notebook, um die Daten zu validieren. Anschließend werden alle vorhandenen Schemata gelöscht und neue Schemata unter Verwendung der YYYYMMDD-Partitionspositionen erstellt.

Für die Silver-Ebene bevorzuge ich das Dateiformat Delta, das schnelle Leistung und Schutz vor Beschädigungen bietet. Für den Fall, dass du Änderungen rückgängig machen und Daten auf eine frühere Version wiederherstellen musst, ist die Aufbewahrung aktiviert - für jede Operation, die Daten verändert, erstellt Databricks eine neue Tabellenversion und speichert standardmäßig 30 Tage Historie. Für die Auswahl von Daten aus der Bronzeschicht und deren Umwandlung mit einem SCD-Tabellendesign vom Typ 2 bevorzuge ich dbt. Wenn ich Daten nach Silver verschiebe, wende ich nur begrenzte Transformationen an und wähle nur funktionale Daten aus. Bevor ich Daten auswähle, führe ich eine Reihe von Tests durch, um sicherzustellen, dass die Daten von hoher Qualität sind und den Integritätsstandards entsprechen. Ein letzter Hinweis für diese Ebene: Wenn ich verschiedene Quellen habe, behandle ich diese als separate Datenfeeds. Die Integration und Kombination aller Daten wird in den nächsten Ebenen vorgenommen.

Um die Daten in die Gold-Schicht zu übertragen, wo sie integriert und für den Verbraucher aufbereitet werden, muss ich Geschäftslogik schreiben, um alle Objekte in benutzerfreundliche und konsumierbare Datensätze umzuwandeln. Auch hier verwende ich dbt-Vorlagen, indem ich für jede logische Dateneinheit eine Vorlage und ein YML-Modell erstelle. Jede Vorlage definiert die Selects, Joins und Transformationen, die angewendet werden müssen, und schreibt in einen bestimmten Ordner (z. B. Kundendaten, Bestelldaten, Verkaufsdaten usw.). Jede Ausgabe gruppiert die Daten logisch um einen Themenbereich. Die Daten werden materialisiert, und das Dateiformat ist wieder Delta.

Schließlich würde ich meine Pipeline in ADF speichern und planen. Für alle einzelnen Schritte würde ich zusätzliche Schritte hinzufügen, um das Ladedatum/die Uhrzeit, die Prozess-ID, die Anzahl der verarbeiteten Datensätze, Fehler- oder Erfolgsmeldungen usw. zu erfassen.

Für jeden weiteren Bereich würde ich all diese Schritte wiederholen. Jede Domäne würde also ihre Datenprodukte in ihrer eigenen domänenspezifischen Datenproduktarchitektur speichern, ihre eigene Datenpipeline verwalten und die gleiche Schichtung für die Erstellung von Datenprodukten verwenden. Sobald ich in der Lage war, dies kontrolliert und in großem Maßstab zu tun, würde ich dieses Design variieren. Ich könnte zum Beispiel mehrere Ausgabeports haben, die dieselben semantischen Daten für unterschiedliche Darstellungen für verschiedene Verbraucher nutzen.

Für die Governance-, Self-Service- und Sicherheitselemente der Architektur würde ich eine Kombination aus einer Azure SQL-Datenbank, Azure Functions und Microsoft Purview, einem Unified Data Governance Service, vorschlagen. Diese Komponenten können in der Data Management Landing Zone eingesetzt werden, um alle Datenprodukte zu katalogisieren und zu überwachen.

Für die Veröffentlichung von Datenprodukten würde ich alle Domänen bitten, ihre Datenprodukte über eine deklarative Funktion als Teil ihrer CI/CD-Pipelines zu veröffentlichen. Diese Funktion könnte zum Beispiel die dbt YML-Spezifikationen aus der Gold-Schicht als Input nehmen und diese Spezifikationen in einer SQL-Datenbank speichern. Als Nächstes würde die Funktion überprüfen, ob die angegebenen Standort- und Schemainformationen dem Universal Resource Identifier (URI) und der Struktur des Datenprodukts entsprechen. Ist dies der Fall, wird ein weiterer Aufruf getätigt, um alle Informationen im Katalog zu veröffentlichen. Mit diesem letzten Aufruf werden die Daten für andere Verbraucher öffentlich zugänglich gemacht.

Für den Datenzugriff auf würde ich vorschlagen, die Datenermittlung und den Datenzugriff per Selbstbedienung zu nutzen. Im Hintergrund werden dabei Zugriffskontrolllisten (ACLs) für einzelne Datenprodukte erstellt. ACLs eignen sich nicht für eine feinkörnige Filterung auf Spalten- oder Zeilenebene, aber für die Zwecke dieses praktischen Beispiels sind sie ausreichend. Komplexere Szenarien werden in Kapitel 8 behandelt.

Hinweis

Dieses Beispiel aus der Praxis wurde zu Lehrzwecken vereinfacht. In der Realität ist das Datenproduktmanagement komplexer, da Faktoren wie Sicherheit, Profilerstellung, komplexe Lookups, Variationen bei der Datenaufnahme und -bereitstellung sowie verschiedene Anreicherungsszenarien berücksichtigt werden müssen. So kann es zum Beispiel bestimmte Einschränkungen für die Archivierung von Daten, die Tokenisierung oder den Zugriff auf Daten innerhalb eines bestimmten Zeitrahmens geben.

Fassen wir die wichtigsten Punkte aus diesem Beispiel kurz zusammen. Erstens haben wir schnell die Grundlage für die Erstellung von Datenprodukten geschaffen. Wir haben der Domäne die Verantwortung für den Lebenszyklus der von ihr kontrollierten Daten und für die Umwandlung der von den Anwendungen erfassten Rohdaten in eine Form übertragen, die für die Nutzung durch externe Parteien geeignet ist. Zweitens lässt sich die Architektur leicht skalieren, indem weitere Domänen mit zusätzlichen Datenproduktarchitekturen hinzugefügt werden. Drittens haben wir verschiedene Prinzipien des Datennetzes angewandt, wie z. B. domänenorientiertes Dateneigentum, Daten-als-Produkt-Denken, Self-Service-Datenplattformen und föderierte Computer-Governance. Im nächsten Abschnitt werden wir uns den zahlreichen Überlegungen zuwenden, die du bei der Erweiterung von anstellen musst.

Abgleich mit den Konten der Speicherung

Es ist wichtig, auf den Abgleich von Datenproduktdaten und Speicherungen zu achten. Im Beispielentwurf im vorherigen Abschnitt habe ich mich dafür entschieden, eine Datenproduktarchitektur mit mehreren Datenproduktdatensätzen aus einer einzigen Domäne zu teilen. Eine Alternative wäre gewesen, jedem Datensatz ein eigenes Speicherkonto und einen Spark-Pool für die Datenverarbeitung zuzuordnen. Ein solches Setup verbindet Daten, Code, Metadaten und die notwendige Infrastruktur miteinander und wäre näher am Datenproduktkonzept innerhalb eines Datengeflechts. Es vereinfacht die Zugriffsverwaltung und ermöglicht die Automatisierung, so dass du die Verarbeitungscluster und die Speicherung im Handumdrehen bereitstellen kannst. Wenn zum Beispiel deine Silberschicht zeitlich begrenzt ist, kannst du sie löschen, sobald sie nicht mehr benötigt wird. Andererseits erhöht die enge Verknüpfung von Datenprodukten und Infrastruktur den Aufwand für die Infrastruktur und die Anzahl der Pipelines, die du verwalten musst, drastisch. Das kann zum Beispiel zu einer großen Anzahl von Berechtigungen, Netzwerk- und Service-Endpunkten führen, die verwaltet, gesichert, gescannt und überwacht werden müssen, oder ein komplexes Netz von Speicherkonten erzeugen, da die Datenprodukte oft von denselben zugrunde liegenden Daten abgeleitet werden. Du musst also abwägen, wie eng du deine Datenprodukte mit deiner Infrastruktur abstimmen willst.

Wie wäre es, wenn mehrere Domains dasselbe Konto für die Speicherung nutzen würden? Auch das ist möglich, aber wenn mehrere Domänen die zugrunde liegende Speicherung gemeinsam nutzen, ist eine andere Container- und Ordnerstruktur erforderlich. Das ist ein Muster, das ich oft bei kleineren Organisationen sehe, weil eine zentral verwaltete Speicherung den Verwaltungsaufwand und andere Probleme, die beim Verschieben und Sichern von Daten auftreten können, erleichtert. Auf der anderen Seite müssen alle Domänen dieselben Grenzen und Konfigurationselemente wie ACLs und Regeln für IP-Adressen verwenden. Es ist wahrscheinlich auch nicht der beste Ansatz, wenn du Georedundanz und flexible Leistung brauchst.¹⁷ Auch hier musst du die Kompromisse abwägen.

Alternativ kannst du ein Gleichgewicht zwischen lokal und zentral ausgerichteten Daten herstellen, indem du einen hybriden Ansatz mit sowohl domänenlokalen als auch zentralen Speicherkonten verwendest. In diesem Fall verwendet jede Domäne ein internes, dediziertes Speicherkonto, in dem alle domänenspezifischen Verarbeitungen vorgenommen werden (z. B. in den Ebenen Bronze und Silber). Ein solches Konto ist nur für den internen Gebrauch bestimmt und wird nicht für andere Domänen zugänglich gemacht. Neben diesen domänenlokalen Speicherkonten gibt es ein zentral geteiltes Speicherkonto, das für die Verteilung der endgültigen Daten der (in der Gold-Schicht erstellten) Datenprodukte an andere Domänen bestimmt ist. Dieses Konto für die gemeinsame Speicherung wird häufig von einer zentralen Abteilung verwaltet. Der Grund für ein solches Konzept ist, den Domänen Flexibilität zu bieten und gleichzeitig den Überblick über den Datenaustausch aller Datenprodukte zu behalten.

Abgleich mit Datenpipelines

Ein weiterer wichtiger Aspekt ist die Abstimmung von Datenpipelines und Datenprodukten. Wie du bereits gesehen hast, ist eine Datenpipeline eine Reihe von Schritten zum Verschieben und Umwandeln von Daten. Sie verwendet in der Regel Metadaten und Code, genau wie in einem metadatengesteuerten Ingestion Framework, um zu bestimmen, welche Operationen mit welchen Daten ausgeführt werden sollen. Im vorherigen Beispiel haben wir dieselbe Pipeline für alle Datenprodukte verwendet, aber manche Praktiker empfehlen, für jedes Produkt eine eigene Pipeline zu verwenden. Die Frage ist also, welcher Ansatz für deine Situation besser ist.

Um diese Frage zu beantworten, betrachte die Granularität deiner Datenprodukte und die entsprechenden Datenpipelines. Angenommen, du verarbeitest die Daten einer Anwendung im Stapel und erstellst daraus mehrere grobkörnige Datenprodukte (Datensätze), die jeweils eine eigene Datenpipeline verwenden. Es ist wahrscheinlich, dass mehrere Pipelines dieselben zugrunde liegenden Quellsystemdaten verarbeiten, da sich die Eingabedaten für die Datenprodukte oft überschneiden. Das bedeutet, dass einige Verarbeitungsschritte wiederholt werden können, was die Wartung erschwert. Außerdem führt das Verschieben bestimmter Teile der Daten durch verschiedene Pipelines in unterschiedlichen Intervallen zu Integritätsproblemen, was es den Verbrauchern erschwert, die Daten später zu kombinieren.

Ein zu feines Setup für deine Datenprodukte und Datenpipelines ist ebenfalls eine Herausforderung. Wenn ein zugrundeliegendes Quellsystem Hunderte von kleinen Datenprodukten erzeugt, von denen jedes seine eigene Datenpipeline hat, ist es schwierig, Probleme zu beheben und Abhängigkeiten zu überwachen: Es kann ein komplexes Geflecht von sich wiederholenden Verarbeitungsschritten beobachtet werden. Außerdem ist es für die Verbraucher/innen schwierig, die Daten zu nutzen, da sie viele kleine Datensätze integrieren müssen. Auch die Referenzintegrität ist ein großes Problem, da viele Pipelines in leicht unterschiedlichen Intervallen ablaufen dürften.

Abschließend lässt sich sagen, dass eine eigene Pipeline für jedes Datenprodukt normalerweise nicht die ideale Lösung ist. Die bewährte Methode besteht darin, eine Pipeline mit einer geeigneten Reihe von Schritten zu erstellen, die den gesamten Anwendungsstatus erfasst, kopiert und dann die Daten in benutzerfreundliche Datensätze umwandelt.

Möglichkeiten der Datenübermittlung

Wechseln wir von zur Serving-Seite der Datenproduktarchitektur und sehen wir uns an, welche Komponenten und Dienste wir dort bereitstellen müssen. Für die Bereitstellung der Daten von den Ausgabeports,¹⁸ gibt es verschiedene Dimensionen der Datenverarbeitung, die sich darauf auswirken, wie die Datenproduktarchitekturen gestaltet werden können. Die Gestaltung der Datenproduktarchitektur hängt weitgehend von den Anwendungsfällen und Anforderungen der konsumierenden Bereiche ab. In vielen Fällen verarbeitest du Daten, die nicht zeitkritisch sind. Manchmal kann die Beantwortung einer Frage oder die Erfüllung eines Geschäftsbedarfs ein paar Stunden oder sogar ein paar Tage warten. Es gibt aber auch Anwendungsfälle, in denen die Daten innerhalb weniger Sekunden geliefert werden müssen.

Warnung

Das Datenproduktmanagement ist nicht zu verwechseln mit der Wertschöpfung aus Daten, z. B. durch Business Intelligence- und Machine Learning-Anwendungen. Trotz der Überschneidungen gibt es auf der Verbraucherseite in der Regel eine starke Diversifizierung bei der Nutzung von Daten. Daher muss die Erstellung von Datenprodukten getrennt von der Schaffung von Datenwerten verwaltet werden.

In den letzten Jahren hat die Vielfalt der verfügbaren Speicher- und Datenbankdienste stark zugenommen. Traditionell sind transaktionale und operative Systeme auf hohe Integrität ausgelegt und verwenden daher eine ACID-konforme und relationale Datenbank. Aber auch nicht-ACID-konforme, schemalose Datenbanken (wie Dokumenten- oder Key/Value-Stores) sind im Trend, weil sie die strengen Integritätskontrollen zugunsten einer schnelleren Leistung lockern und flexiblere Datentypen zulassen, z. B. Daten von Mobilgeräten, Spielen, Social-Media-Kanälen, Sensoren usw. Die Größe der Daten kann einen Unterschied machen: Einige Anwendungen speichern relativ kleine Datenmengen, während andere Anwendungen auf Terabytes von Daten angewiesen sein können.

Warum gibt es so viele verschiedene Datenbanken?

Bei der Wahl einer Datenbank gibt es viele Faktoren und Kompromisse zu berücksichtigen. Neben der Datenstruktur musst du auch deine Anforderungen in Bezug auf Konsistenz, Verfügbarkeit, Partitionstoleranz sowie Caching und Indexierung für eine bessere Leistung bewerten. Es gibt verschiedene Möglichkeiten, Daten zu speichern und abzurufen: kleine Chunks, große Chunks, sortierte Chunks, usw. Es gibt Kompromisse zwischen Verteilbarkeit und Konsistenz, die sich auf die Leistung auswirken können, sowie Funktionen wie kontinuierliche Überwachung und Analyse. Schließlich gibt es auch nicht-funktionale Anforderungen zu berücksichtigen, wie z. B. die Bindung an einen bestimmten Anbieter, Support, Kompatibilität und Abfragesprachen. Unterm Strich kann keine Datenbank in allen Dimensionen gleichzeitig brillieren. Wähle die Lösung, die am besten zu deinen Anforderungen passt.

Der Vorteil einer Datenproduktarchitektur ist, dass du mehrere Designs für die spezifischen Lesemuster der verschiedenen Anwendungsfälle hinzufügen kannst .¹⁹ Du kannst Daten duplizieren, um verschiedene Datenstrukturen, Geschwindigkeiten und Volumina zu unterstützen oder um verschiedene Darstellungen derselben Daten bereitzustellen. Du könntest einen dateibasierten Endpunkt für Ad-hoc-, explorative oder analytische Anwendungsfälle anbieten, einen relationalen Endpunkt, um komplexere und unvorhersehbare Abfragen zu erleichtern, einen spaltenbasierten Endpunkt für Datenkonsumenten, die umfangreiche Aggregationen benötigen, oder einen dokumentenbasierten Endpunkt für Datenkonsumenten, die eine höhere Geschwindigkeit und ein semistrukturiertes Datenformat (JSON) benötigen. Du könntest sogar deine Datenprodukte mit Knoten und Beziehungen in einer Graphdatenbank modellieren.

Wenn du verschiedene Endpunkte oder Ausgabeports bereitstellst, müssen alle unter demselben Data Governance Dach verwaltet werden. Die Rechenschaftspflicht liegt bei der gleichen bereitstellenden Domäne. Die Grundsätze für wiederverwendbare und leseoptimierte Daten gelten auch für alle Varianten von Datenprodukten. Darüber hinaus wird erwartet, dass der Kontext und die Semantik gleich sind; zum Beispiel sollte der Begriff "Kunde" oder "Kundenname" für alle Daten, die bereitgestellt werden, einheitlich sein. Für alle Datenprodukte, die zum gleichen Datenanbieter gehören, muss dieselbe allgegenwärtige Sprache verwendet werden. In Kapitel 7 werden wir uns ansehen, wie die semantische Konsistenz über alle Endpunkte und andere Integrationsmuster sichergestellt wird.

Datenbereitstellungsdienste

Wenn du auf die Interaktionen von Nutzern und Anwendungen mit den Datenproduktarchitekturen zoomst, wirst du in der Regel feststellen, dass es eine große Vielfalt an Datenzugriffsmustern gibt. Dazu gehören Ad-hoc-Abfragen, direkte Berichte, der Aufbau von semantischen Schichten oder Würfeln, die Bereitstellung von Open Database Connectivity (ODBC) für andere Anwendungen, die Verarbeitung mit ETL-Tools, Data Wrangling oder Data Science Processing. Um diese zu unterstützen, muss die Architektur deiner Datenprodukte über ausreichende Leistungs- und Sicherheitsfunktionen verfügen.

Hinweis

Bei allen datenverbrauchenden Diensten sollte den Datenzugriff und das Lebenszyklusmanagement einheitlich gestalten. Dafür gibt es Datenverträge, die wir in Kapitel 8 besprechen werden.

Verteilte Dateisysteme, wie z. B. die Cloud-basierte Speicherung von Objekten, sind kostengünstig, wenn es darum geht, große Datenmengen zu speichern, aber sie sind in der Regel nicht schnell genug für Ad-hoc- und interaktive Abfragen. Viele Anbieter haben dieses Problem erkannt und bieten SQL-Abfrage-Engines oder leichtgewichtige Virtualisierungsschichten an, um es zu lösen. Der Vorteil, dass Abfragen direkt auf Datenprodukten ausgeführt werden können, ist, dass die Daten nicht dupliziert werden müssen, was die Architektur günstiger macht. Diese Tools bieten außerdem einen feinkörnigen Zugriff auf die Daten und machen den operativen Datenspeicher überflüssig. Die Daten, die in einer Produktarchitektur gespeichert sind, werden zu einem Kandidaten für betriebliche Berichte und Ad-hoc-Analysen. Datenvirtualisierung ist eine gute Lösung, eignet sich aber nur für einfache Berichtsfälle. Wenn dies nicht ausreicht, solltest du Alternativen wie die Duplizierung von Daten in Betracht ziehen.

Dateimanipulationsdienst

Während wir über die Vervielfältigung von Daten und den Verbrauch von Daten sprechen, gibt es in einigen Bereichen Anwendungsfälle oder Anwendungen, die nur flache Dateien (z. B. CSV-Dateien) als Eingabe akzeptieren. Für diese Fälle solltest du einen Dienst zur Dateibearbeitung einrichten, der sensible Daten, die die Verbraucher nicht sehen dürfen, automatisch maskiert oder entfernt. Dieser Dienst muss, wie alle anderen Endpunkte, mit dem zentralen Sicherheitsmodell verbunden werden, das vorschreibt, dass alle Datenverwendungen die Datenverträge einhalten müssen (siehe "Datenverträge"). Es schreibt auch vor, dass Filter automatisch angewendet werden müssen und immer auf Metadatenklassifizierungen und -attributen beruhen. Wir werden dies in Kapitel 8 genauer besprechen.

De-Identification Service

Bei der direkten Nutzung von Daten Produkten für Datenexploration, Data Science, maschinelles Lernen und den Austausch von Daten mit Dritten ist es wichtig, sensible Daten vor Verbrauchern zu schützen. Dank Sicherheitsmethoden wie Tokenisierung, Hashing, Scrambling und Verschlüsselung kannst du Regeln und Klassifizierungen verwenden, um deine Daten zu schützen. Je nachdem, wie du die Architektur deines Datenprodukts gestaltest, kannst du die folgenden Methoden anwenden:

• Daten zur Laufzeit während des Verbrauchs zu schützen. Diese Technik schützt sensible Daten, ohne dass die gespeicherten Daten verändert werden, sondern nur, wenn sie abgefragt werden. Databricks zum Beispiel nutzt eine Funktion namens dynamische Ansichtsfunktionen, um Daten zu verbergen oder zu maskieren, wenn auf sie zugegriffen wird.

• Verschleiern oder maskieren Sie sensible Daten, bevor sie überhaupt in einer Datenproduktarchitektur landen (z. B. durch Tokenisierung). Der unkenntlich gemachte Abgleich erfolgt dann in der Phase der Nutzung.

• Dupliziere und verarbeite Daten für jedes Projekt. Du kannst deinen Schutz individuell anpassen, indem du festlegst, welche Klassifizierungen, Maskierungs- und Filterregeln du verwendest.

Die Datensicherheit hängt von der Data Governance ab. Diese beiden Disziplinen werden in Kapitel 8 eingehend behandelt.

Verteilte Orchestrierung

Der letzte Aspekt , der Designüberlegungen und Standardisierung erfordert, ist die Unterstützung der Teams bei der Implementierung, Prüfung und Orchestrierung ihrer Datenpipelines. Der Aufbau und die Automatisierung dieser Datenpipelines ist ein iterativer Prozess, der eine Reihe von Schritten wie Datenextraktion, -aufbereitung und -umwandlung umfasst. Du solltest es den Teams ermöglichen, die Qualität all ihrer Datenpipelines und Artefakte zu testen und zu überwachen, und sie mit Codeänderungen während des Bereitstellungsprozesses unterstützen. Dieser End-to-End-Bereitstellungsansatz ähnelt sehr dem DataOps-Ansatz, da er mit einer Menge Automatisierung, technischen Praktiken, Workflows, Architekturmustern und Tools einhergeht.

Bei der Standardisierung von Tools und bewährten Methoden empfehle ich Organisationen, ein zentrales Team oder ein Plattformteam einzurichten, das andere Teams unterstützt, indem es Funktionen für Aufgaben wie Zeitplannungsprogramme, die Kuratierung von Metadaten, die Protokollierung von Metriken usw. bereitstellt. Dieses Team sollte auch für die End-to-End-Überwachung zuständig sein und eingreifen, wenn die Pipelines zu lange unterbrochen sind. Um die Komplexität von Abhängigkeiten und Zeitintervallunterschieden zwischen verschiedenen Datenanbietern abstrahieren zu können, kann dieses Team auch ein zusätzliches Verarbeitungsframework einrichten, das z. B. die Verbraucher darüber informiert, wenn mehrere Quellen mit Abhängigkeitsbeziehungen kombiniert werden können.

Intelligente Verbrauchsdienste

Aufbauend auf allen dieser verschiedenen Fähigkeiten könntest du die Datenproduktarchitektur auch mit einer Schicht (Fabric) erweitern, um intelligente Datentransformationen bei der Datennutzung durchzuführen, wie z.B. automatisches Profiling, Filtern, Anpassen von Schemata, Kombinieren und so weiter. Auf diese Weise können die Datenkonsumenten die von ihnen benötigten Daten definieren und erhalten sie bereits in der gewünschten Form modelliert. Diese Art von intelligenten Diensten wird in der Regel auch verwendet, um eine semantische Schicht einzurichten, die komplexe Logik verbirgt und den Geschäftsanwendern benutzerfreundliche Darstellungen präsentiert. Dabei werden in hohem Maße Metadaten verwendet, einschließlich vieler anderer Dienste, die speziell für die Datenverwaltung bestimmt sind. Ein visionärer Ansatz wäre es, deine Fabric mit aufkommenden Technologien wie semantischen Wissensgraphen und maschinellem Lernen anzureichern. Obwohl dieser Trend noch relativ neu ist, gebe ich in Kapitel 9 einige Empfehlungen zur Vorbereitung auf die Umsetzung dieses Ansatzes.

Überlegungen zur direkten Nutzung

Eine wichtige Überlegung beim Design ist, ob Datenprodukte als direkte Quellen für konsumierende Bereiche dienen können oder ob diese Bereiche sie extrahieren und duplizieren müssen. Ich spreche hier von persistenten Datentransformationen, die sich auf den Prozess beziehen, bei dem Daten geschrieben und an einem neuen Ort (Data Lake oder Datenbank) gespeichert werden, außerhalb der Grenzen der Datenproduktarchitektur. Die Erstellung von unkontrollierten Datenkopien sollte vermieden werden, aber es kann Situationen geben, in denen es besser ist, eine Kopie in der Nähe oder innerhalb der konsumierenden Anwendung verfügbar zu haben. Zum Beispiel:

• Wenn das Datenprodukt zur Erstellung neuer Daten verwendet wird, müssen diese Daten logischerweise an einem neuen Ort gespeichert werden und benötigen einen anderen Eigentümer.

• Wenn du die Gesamtlatenzzeit verringern willst, ist es vielleicht besser, die Daten zu duplizieren, damit sie lokal verfügbar sind, also näher am Ziel der konsumierenden Anwendung. Wir werden uns das in Kapitel 6 genauer ansehen. Dort erfährst du, wie du vollständig kontrollierte, verteilte materialisierte Ansichten erstellen kannst.

• Direkte und Echtzeit-Datentransformationen können so schwerfällig sein, dass sie das Nutzererlebnis beeinträchtigen. Zum Beispiel können Abfragen von Datenprodukten so lange dauern, dass die Nutzer frustriert sind. Das Extrahieren, Umstrukturieren und Vorverarbeiten von Daten oder der Einsatz einer schnelleren Datenbank-Engine kann diese Frustration lindern.

• Wenn die konsumierende Anwendung so wichtig ist, dass eine Entkopplung erforderlich ist, um einen Ausfall der Datenproduktarchitektur zu vermeiden, kann es sinnvoll sein, die Daten zu duplizieren.

In all diesen Fällen empfehle ich, eine Form der Kontrolle der Unternehmensarchitektur zu implementieren, die vorgibt, welcher Ansatz für jedes Datenprodukt gewählt wird. Sei dir bewusst, dass doppelte Daten schwieriger zu bereinigen sind und es schwierig sein kann, Einblicke in die Nutzung der Daten zu erhalten. Wenn die Daten ohne Einschränkungen oder Verwaltung kopiert werden können, ist es möglich, dass sie weiter verteilt werden. Ein weiteres potenzielles Problem ist die Einhaltung von Vorschriften wie der Datenschutz-Grundverordnung (GDPR) oder der Datenschutz-Grundverordnung (CCPA); wir werden dies in Kapitel 11 genauer erörtern.

Erste Schritte

Der Übergang zu Dateneigentum und Datenproduktentwicklung kann für viele Teams eine kulturelle und technische Herausforderung sein. Zum Beispiel haben nicht alle Teams das nötige Wissen, sehen den Wert von Daten oder sind bereit, in Daten zu investieren. Wenn du eine natürliche Entwicklung zur Datenproduktentwicklung verfolgen willst, solltest du die folgenden bewährten Methoden in Betracht ziehen:

• Fang klein an. Schaffe Begeisterung und beginne mit einem oder wenigen Bereichen, deren Teams das Konzept der Datenproduktentwicklung angenommen haben. Zeig zuerst Erfolge, bevor du das Projekt ausweitest.

• Erstelle eine einheitliche Definition dessen, was ein Datenprodukt für dein Unternehmen bedeutet. Stimme dies mit dem Metamodell ab, das für das Metadatenmanagement verwendet wird.

• Governance ist wichtig, aber geh es langsam an. Achte auf ein ausgewogenes Verhältnis, um die Produktivität zu fördern. Konzentriere dich auf grundlegende Elemente wie Eigentumsrechte, Metadaten und Interoperabilitätsstandards. Orientiere dich, wo immer möglich, an Branchenstandards und bewährten Methoden.

• Deine ersten Datenprodukte sollten ein Beispiel für den Rest deiner Bereiche sein. Lege Qualitäts- und Designkriterien für die Akzeptanz fest und konzentriere dich auf das Design der Datensätze. Ein ressourcenorientiertes API-Design ist ein guter Ausgangspunkt für den Aufbau hochwertiger Datenprodukte.

• Versuche nicht, eine Plattform zu bauen, die alle Anwendungsfälle auf einmal unterstützt. Zu Beginn wird deine Plattform in der Regel nur eine Art von Dateneingabe und -verbrauch unterstützen: zum Beispiel Batch-Datenbewegungen und Parquet-Dateien als Verbrauchsformat.

• Erlaube eine Zentralisierung neben einer Dezentralisierung. Die anfängliche Einführung eines Datenprodukts muss nicht gleich deine Organisationsstruktur durcheinander bringen. Lasse die Dinge eine Zeit lang zentral laufen, bevor du die Ingenieure den Bereichen zuordnest, oder wende eine weiche Ausrichtung an, damit die Ingenieure mit Fachexperten zusammenarbeiten. Zu Beginn können domänenspezifische Datensätze mit Unterstützung des zentralen Teams erstellt werden.

Wenn du anfängst, geh es langsam an. Lerne und iteriere, bevor du zur nächsten Stufe übergehst. Zentralisierung oder Dezentralisierung ist kein Alles-oder-Nichts-Prinzip, sondern ein ständiger Abgleich, bei dem es um Nuancen und regelmäßige Bewertungen geht.

Einpacken

Datenprodukte stellen eine große Veränderung in der Art und Weise dar, wie Abhängigkeiten zwischen Domänen und Anwendungen verwaltet werden. Immer wenn die Grenzen eines funktionalen Anliegens oder eines begrenzten Kontexts überschritten werden, sollten sich die Teams an die einheitliche Art der Datenverteilung halten: Daten als Datenprodukte für andere Teams bereitstellen. Diese Arbeitsweise ist wichtig, weil weniger gemeinsame Abhängigkeiten bedeuten, dass weniger Koordination zwischen den Teams erforderlich ist.

Zu Beginn dieses Kapitels habe ich einen Unterschied zwischen den Konzepten "Daten als Produkt" und "Datenprodukte" gemacht. Um es noch einmal zu sagen: Daten als Produkt sind die Denkweise, die du bei der Verwaltung von Daten im Allgemeinen anwendest. Es geht darum, Vertrauen zu schaffen, Governance zu etablieren und das Produktdenken anzuwenden; es geht darum, sich um die Daten zu kümmern, die dir am wichtigsten sind, und Prinzipien in die Praxis umzusetzen. Diese Denkweise müssen auch deine Fachteams haben. Sie müssen die Verantwortung für ihre Daten übernehmen, Probleme mit der Datenqualität direkt an der Quelle beheben und die Daten so aufbereiten, dass sie für eine große Zielgruppe nützlich sind. Anstatt dass ein zentrales Team alle Änderungen aufnimmt und die Daten integriert, sollten deine Domain-Teams das physische Datenmodell innerhalb ihrer Domain-Grenzen kapseln. Das ist das Gegenteil davon, Rohdaten über den Zaun zu werfen und die Verbraucher/innen die Datenqualität und Modellierungsprobleme lösen zu lassen. Deine Domänen-Teams sollten die Daten so modellieren und bereitstellen, dass sie ein optimales Nutzererlebnis bieten.

Ein Datenprodukt ist ein Konzept, das du für dich selbst entmystifizieren musst. Ich empfehle dir, damit zu beginnen, die Art und Weise, wie du in deinem Unternehmen über Datenproduktmanagement sprichst, zu vereinheitlichen, da es Unterschiede in der Sprache und den verwendeten Definitionen geben kann. Ziehe in Erwägung, Datenprodukte als logische Konstrukte zu definieren, anstatt eine Sichtweise zu verwenden, die sich ausschließlich auf physische Darstellungen oder die zugrunde liegende Technologiearchitektur konzentriert. Irgendwann kannst du ein semantisches Modell für dein Unternehmen einführen, sodass deine Datenprodukte zu grafischen Darstellungen werden, aus denen du Beziehungen zu Domänen, Dateneigentümern, Ursprungsanwendungen und physischen Darstellungen ableitest. Das klingt vielleicht ein bisschen zu konzeptionell, aber die Vorteile einer solchen Verwaltung deiner Datenprodukte werden dir in Kapitel 9 klarer werden.

Es gibt eine Einschränkung bei Datenprodukten. Sie werden wahrscheinlich unter ähnlichen Problemen leiden wie Microservices-Architekturen, bei denen die Daten zu feinkörnig und unzusammenhängend sind und aus Hunderten von verschiedenen Orten abgerufen werden müssen. Die Lösung für diese Probleme ist die Einführung guter Standards und einer zentralen Behörde, die alle Aktivitäten zur Erstellung von Datenprodukten beaufsichtigt. Es müssen Interoperabilitätsstandards für den Datenaustausch festgelegt werden. Änderungen und die Art und Weise, wie Daten modelliert und bereitgestellt werden, müssen koordiniert werden. Leider sind diese Aktivitäten nicht einfach. Wie du gelernt hast, ist die Entwicklung von Datenprodukten eng mit dem Data Warehousing verbunden, das aus vielen Disziplinen besteht, z. B. der Datenmodellierung (Daten konsistent, lesbar, auffindbar, adressierbar, vertrauenswürdig und sicher machen). Einige dieser Aktivitäten können sehr komplex sein, wie die Historisierung, die wir in diesem Kapitel besprochen haben.

Bei Datenprodukten und der Denkweise "Daten als Produkt" geht es um die Bereitstellung von Daten. Daten zu verbrauchen ist die nächste Stufe. Obwohl sich bestimmte Aktivitäten und Disziplinen überschneiden können, wie du in Kapitel 11 erfährst, sind die Belange der Datenbereitstellung und des Datenkonsums nicht dieselben. Indem du Daten als Produkte verwaltest und die Datenprodukte als Domänenschnittstellen bereitstellst, eliminierst du Abhängigkeiten und trennst Anwendungen mit gegensätzlichen Anliegen besser voneinander. Das ist wichtig, denn weniger gemeinsame Abhängigkeiten bedeuten, dass weniger Koordination zwischen den Teams erforderlich ist.

Die Datenproduktarchitektur sollte gemeinsam und auf der Grundlage der Bedürfnisse des Unternehmens entwickelt werden. Stellen Sie den Fachteams allgemeine Entwürfe zur Verfügung. Erlaube anderen Teams, einen Beitrag zu leisten oder vorübergehend dem/den Plattformteam(s) beizutreten. Wenn z. B. ein neues Konsummuster benötigt wird, stelle es nachhaltig als wiederverwendbares Muster oder Komponente bereit. Das Gleiche gilt für die Datenerfassung und das Onboarding. Bei der Erweiterung und dem Aufbau einer modernen Datenplattform werden viele zusätzliche Self-Service-Anwendungskomponenten erforderlich sein: Dazu gehören wahrscheinlich zentral verwaltete ETL-Frameworks, Dienste zur Erfassung von Änderungsdaten und Echtzeit-Ingestion-Tools.

Ein letzter und wichtiger Hinweis: Datenprodukte, wie sie in diesem Kapitel besprochen wurden, sind dazu gedacht, Daten verfügbar zu machen. Wir haben noch nicht darüber gesprochen, wie man die Daten nutzbar macht und sie in einen echten Wert verwandelt. Dieser Aspekt hat eine andere Dynamik als die Erstellung von Datenprodukten und wird bis Kapitel 11 warten müssen.

Im nächsten Kapitel befassen wir uns mit der API-Architektur, die für die Kommunikation von Diensten und für die Verteilung kleinerer Datenmengen für Echtzeit- und Low-Latency-Anwendungen verwendet wird.

¹ Ein Nachteil von CQRS ist, dass es die Dinge komplexer macht - du musst die beiden Modelle mit einer zusätzlichen Schicht synchron halten. Das kann auch zu einer zusätzlichen Latenz führen.

² TechDifferences hat einen Überblick über die Unterschiede zwischen einer Datenbankansicht und einer materialisierten Ansicht.

³ Der Artikel von Morris über Data Vault 2.0 beschreibt "das Gute, das Schlechte und das geradezu Verwirrende" an diesem Entwurfsmuster.

⁴ Ob du es glaubst oder nicht, ich habe einmal eine Legacy-Anwendung gesehen, in der mehrere Kundenwerte mit Hilfe von Doppelpipe-Operatoren in ein einziges Feld verkettet wurden, z. B. Vorname||Mittelname||Nachname.

⁵ Ein Metamodell ist ein Rahmen für das Verständnis, welche Metadaten bei der Beschreibung von Daten erfasst werden müssen.

⁶ Der Abgleich kann auf viele verschiedene Arten durchgeführt werden. Du kannst zum Beispiel die Zeilenzahl vergleichen, Spaltenprüfsummen verwenden, große Tabellen aufteilen und neu verarbeiten oder Datenvergleichstools wie Redgate nutzen.

⁷ Wie Azure Synapse Analytics und Microsoft Purview zusammen integriert werden können, um Daten mit Great Expectations intelligent zu verarbeiten und zu validieren, erfährst du in meinem Blogbeitrag "Moderne Datenpipelines mit Azure Synapse Analytics und Azure Purview".

⁸ Die Partitionierung ist eine gängige Technik, um Dateien oder Tabellen in verschiedene Gruppen (Partitionen) aufzuteilen, um die Verwaltbarkeit, Leistung oder Verfügbarkeit zu verbessern. Sie wird normalerweise anhand von Datenattributen wie geografischen (Stadt, Land), wertbasierten (eindeutige Bezeichner, Segmentcodes) oder zeitbasierten Attributen (Lieferdatum, Uhrzeit) durchgeführt.

⁹ Eine sich langsam verändernde Dimension ist eine Dimension, die sowohl aktuelle als auch historische Daten im Laufe der Zeit in einem Data Warehouse speichert und verwaltet. Dimensionstabellen in der Datenverwaltung und im Data Warehousing können mit verschiedenen Methoden gepflegt werden, die als Typ 0 bis 6 bezeichnet werden. Die verschiedenen Methoden werden von der Kimball Group beschrieben.

¹⁰ Innerhalb deines Verarbeitungsrahmens kannst du zum Beispiel die exclude_from_delta_processing parameter auf einer Attributsebene verwenden, um Daten vom Vergleich auszuschließen.

¹¹ Einige Datenbankanbieter bieten eine (virtuelle) Datenbankabfrageschicht an, die auch als Datenvirtualisierungsschicht bezeichnet wird. Diese Schicht abstrahiert die Datenbank und optimiert die Daten für eine bessere Leseleistung. Ein weiterer Grund für die Abstraktion ist das Abfangen von Abfragen für mehr Sicherheit.

¹² In einem meiner Blogbeiträge findest du ein einfaches Beispielskript für die Verarbeitung von SCD-Tabellen im Delta-Format mit Spark-Pools.

¹³ Durch die Trennung von Speicherung und Rechenleistung kannst du die Infrastruktur automatisch skalieren, um sie an elastische Arbeitslasten anzupassen.

¹⁴ In meinem Blogbeitrag "Designing a Metadata-Driven Processing Framework for Azure Synapse and Azure Purview" findest du weitere Details zu diesem Konzept.

¹⁵ Wenn du planst, einen Data Lake einzurichten, ist der "Hitchhiker's Guide to the Data Lake" eine hervorragende Quelle mit Anleitungen und bewährten Methoden.

¹⁶ Microsoft hat zusammen mit dem OpenLineage-Projekt einen Lösungsbeschleuniger entwickelt. Dieser Open-Source-Konnektor überträgt Lineage-Metadaten von Spark-Operationen in Azure Databricks an Microsoft Purview und ermöglicht es dir, ein Lineage-Diagramm auf Tabellenebene zu sehen. Das Projekt wird auf GitHub gehostet.

¹⁷ Georedundanz wird erreicht, indem kritische Komponenten oder Infrastrukturen (z. B. Server) auf mehrere Rechenzentren an unterschiedlichen geografischen Standorten verteilt werden. Bei der Speicherung in der Cloud hast du zum Beispiel die Wahl zwischen herkömmlichen Festplatten und schnelleren Solid State Drives

¹⁸ Die Empfehlung für ein Datennetz besteht darin, Datenprodukte über stark standardisierte Schnittstellen auszutauschen, die einen schreibgeschützten und leseoptimierten Zugriff auf Daten ermöglichen. Diese Schnittstellen werden auch als Output Ports bezeichnet.

¹⁹ Wenn du ein Enterprise Data Warehouse für die Datenverteilung verwendest, ist es oft schwierig, verschiedene Formen und Dimensionen der Daten zu ermöglichen. Unternehmens-Data-Warehouses werden in der Regel mit einer einzigen Technologie entwickelt (der RDBMS-Datenbank-Engine) und lassen daher nicht viel Spielraum für Variationen.