Aufbau eines ereignisgesteuerten Datennetzes

Kapitel 1. Ereignisgesteuerte Datenkommunikation

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

Die Art und Weise, wie Unternehmen mit ihren Daten umgehen, ändert sich schnell. Vorbei sind die Zeiten, in denen alle Daten eines Unternehmens in eine einzige relationale Datenbank passten. Die Big-Data-Revolution, die vor mehr als zwei Jahrzehnten begann, hat sich seitdem weiterentwickelt, und es reicht nicht mehr aus, riesige Datensätze in einem Big-Data-See zu speichern, um sie im Stapelverfahren zu analysieren. Geschwindigkeit und Konnektivität haben sich als die nächsten wettbewerbsrelevanten Anforderungen herauskristallisiert, die wiederum die Art und Weise verändern, wie Unternehmen ihre wichtigen Daten erstellen, speichern, abrufen und weitergeben.

Daten sind das Lebenselixier eines Unternehmens. Aber die Art und Weise, wie Unternehmen Daten erstellen, weitergeben und nutzen, ist oft planlos und unzusammenhängend. Data Mesh bietet einen umfassenden Rahmen, um diese oft dysfunktionalen Beziehungen zu überdenken und einen neuen Weg zu finden, um über Daten nachzudenken, sie zu erstellen und sie im gesamten Unternehmen zu teilen, damit wir hilfreiche und nützliche Dinge tun können: besserer Service für unsere Kunden, fehlerfreie Berichte, umsetzbare Erkenntnisse und wirklich datengesteuerte Prozesse.

Um zu verstehen, was wir beheben wollen, brauchen wir zunächst eine Vorstellung von den wichtigsten Datenproblemen, mit denen ein modernes Unternehmen konfrontiert ist.

Erstens sind die Big-Data-Systeme, die die Grundlage für die Geschäftsanalyse eines Unternehmens bilden, in ihrer Größe und Komplexität explodiert. Es hat viele Versuche gegeben, diese Komplexität zu reduzieren, aber sie haben alle ihr Ziel verfehlt.

Zweitens sind die Geschäftsabläufe großer Unternehmen schon lange nicht mehr durch eine einzige monolithische Bereitstellung zu bedienen. Multiservice-Implementierungen sind die Norm, einschließlich Microservice- und serviceorientierter Architekturen. Die Grenzen dieser modularen Systeme sind selten einfach zu definieren, vor allem, wenn viele getrennte operative und analytische Systeme auf einen Lesezugriff auf dieselben Datensätze angewiesen sind. Hier besteht ein Spannungsverhältnis: Einerseits ermöglicht die Zusammenlegung von Geschäftsfunktionen in einer einzigen Anwendung einen konsistenten Zugriff auf alle Daten, die in diesem System erzeugt und gespeichert werden. Andererseits haben diese Geschäftsfunktionen möglicherweise keinerlei Bezug zueinander, abgesehen davon, dass sie einen gemeinsamen Nur-Lese-Zugriff auf wichtige Geschäftsdaten benötigen.

Und drittens ein Problem, das sowohl im operativen als auch im analytischen Bereich auftritt: die Unfähigkeit, auf qualitativ hochwertige, gut dokumentierte, selbstaktualisierende und zuverlässige Daten zuzugreifen. Die schiere Menge an Daten, mit denen ein Unternehmen zu tun hat, nimmt von Jahr zu Jahr erheblich zu, was den Bedarf an besseren Möglichkeiten zum Sortieren, Speichern und Verwenden der Daten erhöht. Dieser Druck macht dem Ideal, alles in einer einzigen Datenbank zu speichern, einen Strich durch die Rechnung und zwingt die Entwickler dazu, monolithische Anwendungen in separate Implementierungen mit eigenen Datenbanken aufzuteilen. In der Zwischenzeit haben die Big-Data-Teams Mühe, mit der Fragmentierung und dem Refactoring dieser operativen Systeme Schritt zu halten, da sie allein für die Beschaffung ihrer eigenen Daten verantwortlich bleiben.

Daten wurden in der Vergangenheit als Bürger zweiter Klasse behandelt, als eine Art Abgas oder Nebenprodukt, das von Geschäftsanwendungen erzeugt wird. Diese anwendungsorientierte Denkweise ist nach wie vor die Hauptursache für Probleme in den heutigen Computerumgebungen und führt zu Ad-hoc-Datenpipelines, zusammengeschusterten Datenzugriffsmechanismen und inkonsistenten Quellen mit ähnlichen und doch unterschiedlichen Wahrheiten. Data Mesh geht diese Mängel direkt an, indem es die Beziehungen, die wir zu unseren Daten haben, grundlegend verändert. Statt eines sekundären Nebenprodukts werden Daten und der Zugang zu ihnen zu einem Bürger erster Klasse, gleichgestellt mit jedem anderen Geschäftsdienst.

Wichtige Geschäftsdaten müssen als Grundbausteine für deine Anwendungen leicht und zuverlässig verfügbar sein, unabhängig von der Laufzeit, der Umgebung oder der Codebasis deiner Anwendung. Wir behandeln unsere Daten wie Bürger erster Klasse, mit eigenen Eigentumsrechten, Mindestqualitätsgarantien, Service Level Agreements (SLAs) und skalierbaren Mechanismen für einen sauberen und zuverlässigen Zugriff. Ereignisströme sind der ideale Mechanismus, um diese Daten bereitzustellen. Sie bieten eine einfache, aber leistungsstarke Möglichkeit, wichtige Geschäftsdaten innerhalb eines Unternehmens zuverlässig zu übermitteln und jedem Verbraucher den Zugriff auf die benötigten Datenprimitive zu ermöglichen.

In diesem Kapitel werfen wir einen Blick auf die Kräfte, die die operativen und analytischen Werkzeuge und Systeme, die wir heute üblicherweise verwenden, geprägt haben, und auf die Probleme, die damit einhergehen. Die massiven Ineffizienzen der heutigen Datenarchitekturen liefern uns wertvolle Erkenntnisse, die wir auf unsere ereignisgesteuerten Lösungen anwenden werden. Damit ist der Grundstein für das nächste Kapitel gelegt, in dem wir über Datenverflechtung als Ganzes sprechen.

Was ist Data Mesh?

Das Datengeflecht wurde von Zhamak Dehghani erfunden. Es handelt sich um einen sozialen und technologischen Wandel in der Art und Weise, wie Daten erstellt, abgerufen und in Organisationen geteilt werden. Data Mesh ist eine Sprache, in der die Bedürfnisse und Verantwortlichkeiten verschiedener Teams, Bereiche und Dienste diskutiert werden und wie sie zusammenarbeiten können, um Daten zu einem Bürger erster Klasse zu machen. Dieses Kapitel befasst sich mit den Grundsätzen, die dem Data Mesh zugrunde liegen.

In meinem letzten Buch " Building Event-Driven Microservices " (O'Reilly) habe ich den Begriff "Data Communication Layer" (Datenkommunikationsschicht) eingeführt und auf viele der gleichen Prinzipien wie Data Mesh angesprochen: Daten als Bürger erster Klasse behandeln, die Struktur für die Kommunikation zwischen Domänen formalisieren, Daten in Ereignisströmen für die allgemeine Nutzung veröffentlichen und die Nutzung sowohl für die Datenproduzenten als auch für die Datenkonsumenten erleichtern. Auch wenn ich die Terminologie der Datenkommunikationsschicht mag, glaube ich doch, dass die Sprache und die formalisierten Prinzipien von Data Mesh alles bieten, was wir brauchen, um über dieses Problem zu sprechen , ohne ein weiteres "Daten-irgendwas"-Paradigma einzuführen.

Dehghanis Buch Data Mesh (O'Reilly) stellt die Theorie und die Vordenkerrolle von Data Mesh sehr ausführlich und detailliert dar, bleibt aber notwendigerweise unabhängig von konkreten Implementierungen.

In diesem Buch befassen wir uns mit einer praktischen Implementierung von Data Mesh, die den Event Stream als primären Datenproduktmodus für die Interdomain-Datenkommunikation nutzt. Wir können etwas pragmatischer sein und uns weniger intensiv mit der Theorie und konkreter und spezifischer mit der Umsetzung eines ereignisgesteuerten Designs beschäftigen. Ich bin zwar der Meinung, dass Ereignisströme grundsätzlich die beste Option für die Interdomain-Kommunikation sind, aber sie bringen auch Kompromisse mit sich, und ich werde natürlich auch auf diese eingehen und Nicht-Streaming-Möglichkeiten erwähnen, wo sie am besten geeignet sind.

Das Data Mesh basiert auf vier Grundprinzipien: Domain Ownership, Daten als Produkt, föderierte Governance und Self-Service-Plattform. Gemeinsam helfen uns diese Prinzipien dabei, die Kommunikation wichtiger Geschäftsdaten im gesamten Unternehmen zu strukturieren. Wir werden diese Grundsätze im nächsten Kapitel genauer untersuchen, aber vorher wollen wir uns ansehen, warum Datengeflecht heute so wichtig ist.

Ein ereignisgesteuertes Datengeflecht

Die modernen Wettbewerbsanforderungen von Big Data in Motion, kombiniert mit modernem Cloud Computing, erfordern ein Umdenken wie Unternehmen Daten erstellen, speichern, bewegen und nutzen. Die Grundlage dieser neuen Datenarchitektur ist das Ereignis, das Datenquantum, das reale Geschäftsaktivitäten repräsentiert und durch eine Vielzahl von zweckbestimmten Ereignisströmen bereitgestellt wird. Ereignisströme bilden ein zentrales Nervensystem, das es den Geschäftseinheiten ermöglicht, auf grundlegende, sich selbst aktualisierende Datenbausteine zuzugreifen und sie zu nutzen. Diese Daten Bausteine gesellen sich zu den Komponenten Containerisierung, Infrastructure as a Service (IaaS), Continuous Integration (CI) und Continuous Deployment (CD)Pipelines und Monitoring-Lösungen, auf denen moderne Cloud-Anwendungen aufgebaut sind.

Ereignisströme sind nicht neu. Aber viele der technologischen Einschränkungen, die früheren ereignisgesteuerten Architekturen zugrunde lagen, wie z. B. die begrenzte Skalierbarkeit, Speicherung und Leistung, wurden weitgehend beseitigt. Moderne mandantenfähige Event-Broker mit abgestufter Speicherung können unbegrenzte Datenmengen speichern, wodurch die strengen Kapazitätsbeschränkungen früherer Architekturen wegfallen. Produzenten schreiben ihre wichtigen Geschäftsdaten in einen Event Stream, so dass andere auf diesen Stream zugreifen und die Datenbausteine für ihre eigenen Anwendungen nutzen können. Die Verbraucheranwendungen wiederum können ihre eigenen Ereignisströme erstellen, um ihre eigenen Geschäftsdaten mit anderen zu teilen, so dass ein standardisiertes Kommunikationsnetz entsteht, das alle nutzen können.

Data Mesh bietet uns sehr nützliche Konzepte und eine Sprache, um dieses vernetzte zentrale Nervensystem aufzubauen. Abbildung 1-1 zeigt ein grundlegendes Beispiel dafür, wie ein Datennetz aussehen könnte.

Abbildung 1-1. Eine sehr einfache Hello Data Mesh-Implementierung

Das Team, dem das Betriebssystem Alpha gehört, wählt einige Daten aus seiner Servicegrenze aus, wandelt sie um und schreibt sie in ein quellenorientiertes Datenprodukt, das ihm ebenfalls gehört (auf die Ausrichtung von Datenprodukten gehen wir im Abschnitt "Die drei Arten der Datenproduktausrichtung" näher ein). Das Team , dem das operative System Beta gehört, liest die Daten aus diesem Datenprodukt in seine eigene Servicegrenze ein, bearbeitet sie erneut, wandelt sie um und speichert nur das, was es braucht.

In der Zwischenzeit verbindet sich ein drittes Team mit dem Datenprodukt von Alpha Team und nutzt es, um sein eigenes aggregiertes Datenprodukt zusammenzustellen. Dasselbe Team nutzt dann sein aggregiertes Datenprodukt, um einen Streaming-Analytics-Anwendungsfall zu unterstützen und einen Batch von Dateien in die Speicherung in der Cloud zu schreiben, wo Datenanalysten damit Berichte zusammenstellen und bestehende Batch-basierte Analyseaufträge ausführen.

Dieses Diagramm stellt nur die Spitze des Eisbergs der Datenverflechtung dar, und es gibt noch viele Bereiche, die abgedeckt werden müssen. Der Kern des ereignisgesteuerten Datennetzes besteht jedoch darin, Daten in Echtzeit für alle Verbraucher bereitzustellen, die sie benötigen.

Viele der Probleme, die das Datengeflecht löst, gibt es schon seit langer Zeit. Wir werden jetzt einen kurzen Ausflug in die Geschichte machen, um ein besseres Verständnis dafür zu bekommen, was wir lösen und warum data mesh eine sehr relevante und leistungsstarke Lösung ist.

Daten in der Operationsebene verwenden

Daten werden in der Regel von einem operativen System erzeugt , das geschäftliche Aufgaben erledigt. Schließlich werden diese Daten für Analyse- und Berichtszwecke in die analytische Ebene gezogen. In diesem Abschnitt konzentrieren wir uns auf die operative Ebene und die allgemeinen Herausforderungen bei der gemeinsamen Nutzung von Geschäftsdaten mit anderen operativen (und analytischen) Diensten.

Der Datenmonolith

OLTP-Datenbanken (Online Transaction Processing) bilden die Grundlage für einen Großteil der heutigen operativen Computerdienste (nennen wir sie der Einfachheit halber "Monolithen"). Monolithische Systeme spielen in der Regel eine große Rolle auf der operativen Ebene, da eine konsistente synchrone Kommunikation einfacher zu begründen und zu entwickeln ist als eine asynchrone Kommunikation. Relationale Datenbanken wie PostgreSQL und MySQL spielen in monolithischen Anwendungen eine große Rolle. Sie sorgen für atomare, konsistente, isolierte und dauerhafte (ACID) Transaktionen und einen konsistenten Zustand der Anwendung.

Zusammen demonstrieren die Anwendung und die Datenbank die folgenden monolithischenDatenprinzipien:

Die Datenbank ist die Quelle der Wahrheit

Der Monolith verlässt sich auf die zugrunde liegende Datenbank als dauerhaften Informationsspeicher für die Anwendung. Alle neuen oder aktualisierten Datensätze werden zuerst in der Datenbank gespeichert, so dass sie die endgültige Quelle der Wahrheit für diese Entitäten ist.

Die Daten sind sehr konsistent

Wenn die Daten des Monolithen in einer typischen relationalen Datenbank gespeichert werden, sind sie sehr konsistent. Dies bietet der Geschäftslogik eine starke Lese-nach-Schreib-Konsistenz, und dank der Transaktionen kann sie nicht versehentlich auf teilweise aktualisierte Datensätze zugreifen.

Nur-Lese-Daten sind leicht verfügbar

Auf die in der Datenbank des Monolithen gespeicherten Daten kann von jedem Teil des Monolithen aus zugegriffen werden. Schreibgeschützte Zugriffsrechte stellen sicher, dass die Daten nicht versehentlich geändert werden.

Beachte, dass nur der Dienst, dem sie gehört, direkt auf die Datenbank zugreifen und sie nicht als Integrationspunkt nutzen sollte.

Diese drei Prinzipien bilden eine verbindliche Kraft, die monolithische Architekturenleistungsstark macht. Dein Anwendungscode hat Lesezugriff auf alle Daten, die in der Datenbank des Monolithen gespeichert sind, und zwar in Form von verbindlichen, konsistenten und zugänglichenDatenprimitiven. Auf dieser Grundlage ist es einfach, neue Anwendungsfunktionen zu entwickeln, vorausgesetzt, es handelt sich bei um dieselbe Anwendung. Aber was ist, wenn du eine neue Anwendung erstellen musst?

Die Schwierigkeiten bei der Kommunikation von Daten für betriebliche Belange

Eine neue Anwendung kann sich nicht auf denselben einfachen Zugriff auf Datenprimitive verlassen, den sie hätte, wenn sie als Teil des Monolithen erstellt worden wäre. Das wäre kein Problem, wenn die neue Anwendung keinen Bedarf an den Geschäftsdaten des Monolithen hätte. Dies ist jedoch nur selten der Fall, da Unternehmen im Grunde eine Reihe von sich überschneidenden Domänen sind, insbesondere der gemeinsame Kern, wobei dieselben Daten mehrere Geschäftsanforderungen erfüllen. Ein E-Commerce-Händler kann sich z. B. auf seinen Monolithen verlassen, um seine Bestellungen, Verkäufe und Bestände zu verwalten, benötigt aber eine neue Anwendung, die auf einer dokumentenbasierten Datenbank (oder einem anderen Datenbanktyp) basiert, um eine Klartextsuche durchzuführen. Abbildung 1-2 zeigt den Kern des Problems: Wie bekommen wir die Daten von Ol' Reliable in die neue Dokumentendatenbank, um die Suche zu unterstützen?

Abbildung 1-2. Das neue Suchdienstteam muss herausfinden, wie es die benötigten Daten aus dem Monolithen herausbekommt und sie auf dem neuesten Stand hält

Das bringt das neue Suchdienst-Team in eine ziemliche Zwickmühle. Der Dienst muss auf die Artikel-, Lager- und Bestandsdaten im Monolithen zugreifen, aber er muss sie auch als eine Reihe von Dokumenten für die Suchmaschine modellieren. Es gibt zwei gängige Methoden, mit denen Teams versuchen, dieses Problem zu lösen. Die eine besteht darin, die Daten für die Suchmaschine zu replizieren und umzuwandeln, um die drei Monolith-Datenprinzipien zu wahren. Die zweite besteht darin, die Dienstgrenzen des Quellsystems mithilfe von APIs so umzustrukturieren, dass dieselben Daten nicht einfach kopiert, sondern vollständig von einem einzigen System bereitgestellt werden. Beides kann zu einem gewissen Erfolg führen, ist aber letztlich als allgemeine Lösung unzureichend. Schauen wir uns die beiden Möglichkeiten genauer an, um zu sehen, warum.

Strategie 1: Daten zwischen Diensten replizieren

Es gibt mehrere Mechanismen, die unter zu dieser Strategie gehören. Der erste und einfachste ist, einfach in die Datenbank zu greifen und die Daten zu holen, die du brauchst, wenn du sie brauchst. Ein etwas strukturierterer Ansatz besteht darin, die Quelldatenbank regelmäßig abzufragen und die Ergebnisse in deine neue Struktur zu übertragen. Dies hat zwar den Vorteil, dass du eine andere Datenspeichertechnologie für deinen neuen Dienst auswählen kannst, aber es gibt auch ein paar große Nachteile:

Enge Kopplung mit der Quelle

Du bleibst an das interne Modell der Quelldatenbank gekoppelt und verlässt dich ausschließlich darauf, um deine Abfragen zu bearbeiten.

Leistungsbelastung der Quelle

Große Datensätze und komplexe Abfragen können die Datenbank zum Erliegen bringen. Das gilt besonders für die Denormalisierung von Daten für analytische Anwendungsfälle, bei denen mehrere Tabellen und komplexe Joins üblich sind.

Der zweithäufigste Mechanismus für die Datenreplikationsstrategie ist ein Nur-Lese-Replikat der Quelldatenbank . Dies kann zwar die Abfrageleistung verbessern, aber die Verbraucher bleiben weiterhin an das interne Modell gekoppelt. Und leider macht jede zusätzliche externe Kopplung an das interne Datenmodell Änderungen teurer, riskanter und schwieriger für alle Beteiligten.

Warnung

Die Kopplung an das interne Datenmodell eines Quellsystems verursacht viele Probleme. Das Quellmodell wird sich im Laufe der normalen Geschäftsentwicklung ändern, was oft zu Unterbrechungen sowohl bei den regelmäßigen Abfragen als auch bei den internen Operationen aller externen Konsumenten führt. Jeder gekoppelte Dienst muss seine Kopie des Modells so umgestalten, dass sie mit den Daten des Quellsystems übereinstimmt, Daten aus dem alten Modell in das neue Modell migrieren und seinen Geschäftscode entsprechend aktualisieren. Jeder dieser Schritte birgt ein erhebliches Risiko, denn wenn er nicht korrekt ausgeführt wird, kann dies zu Missverständnissen über die Bedeutung der Modelle, zu abweichenden Datenkopien und letztlich zu falschen Geschäftsergebnissen führen.

Datenreplikationsstrategien werden mit jeder neuen unabhängigen Quelle und jedem neuen erforderlichen Replikat schwieriger zu pflegen. Das bringt einige neue Probleme mit sich:

Der ursprüngliche Datensatz kann schwer zu finden sein

Es kommt nicht selten vor, dass ein Team seinen Dienst versehentlich an eine Kopie der Originaldaten koppelt, anstatt an die Originaldaten von selbst. Es kann schwierig sein, die ursprüngliche Quelle der Daten herauszufinden, ohne auf informelleWissensnetzwerke zurückzugreifen.

Zunahme der Punkt-zu-Punkt-Verbindungen

Außerdem kann jeder neue unabhängige Dienst zu einer eigenen maßgeblichen Datenquelle werden, wodurch sich die Anzahl der Punkt-zu-Punkt-Verbindungen für die Datenreplikation zwischen den Diensten erhöht.

Die Punkt-zu-Punkt-Replikation von Daten zwischen Diensten führt zu zusätzlicher Komplexität und gleichzeitig zu einer engen Kopplung an das interne Datenmodell der Quelle. Sie ist unzureichend für den Aufbau der modernen Datenkommunikationsschicht.

Strategie 2: APIs nutzen, um Datenreplikationen zu vermeiden

Direkt gekoppelte Anfrage-Antwort Microservices, manchmal auch als synchrone Microservices bezeichnet, sind ein weiterer gängiger Ansatz für den Zugriff auf entfernte Daten. Microservices können direkt die API eines anderen Dienstes aufrufen, um kleine Mengen an Informationen auszutauschen und Arbeiten im Namen des anderen auszuführen.

Du kannst zum Beispiel einen Microservice haben, der die Vorgänge rund um das Inventar verwaltet, während du andere Microservices für den Versand und die Buchhaltung hast. Die Anfragen für jeden dieser Dienste kommen von den Microservices für das mobile Frontend und das Web-Frontend, die die Vorgänge zusammenfassen und den Nutzern eine nahtlose Ansicht bieten, wie in Abbildung 1-3 dargestellt.

Abbildung 1-3. Ein Beispiel für eine einfache E-Commerce-Microservice-Architektur

Synchrone Microservices haben viele Vorteile:

• Zweckgebundene Dienste dienen den Bedürfnissen des Geschäftsbereichs.

• Die Eigentümer haben ein hohes Maß an Unabhängigkeit, um die Werkzeuge, Technologien und Modelle zu nutzen, die für ihre Bedürfnisse am besten geeignet sind.

• Die Teams haben auch mehr Kontrolle über die Grenzen ihrer Bereiche, einschließlich der Kontrolle und Entscheidung darüber, wie sie diese erweitern, um die Bedürfnisse anderer Kunden zu erfüllen.

Es gibt zahlreiche Bücher, die über synchrone Microservices geschrieben wurden, wie z.B. Building Microservices von Sam Newman (O'Reilly) und Microservices Patterns von Chris Richardson (Manning), die weitaus mehr ins Detail gehen, als ich Platz habe, daher werde ich hier nicht näher darauf eingehen.

Die Hauptnachteile dieser Strategie sind dieselben wie bei einem einzelnen Dienst:

• Es gibt keinen einfachen und zuverlässigen Mechanismus für den Zugriff auf Daten, der über die in der API der Microservices bereitgestellten Mechanismen hinausgeht.

• Synchrone Microservices sind in der Regel so strukturiert, dass sie eine API für Geschäftsvorgänge anbieten und nicht für den zuverlässigen Zugriff auf Massendaten der zugrunde liegenden Domäne.

• Die meisten Teams greifen auf dieselben Ausweichmöglichkeiten zurück wie bei einem einzelnen Monolithen: Sie greifen auf die Datenbank zu und holen die Daten heraus, die sie brauchen, wenn sie sie brauchen (siehe Abbildung 1-4).
  

  
  

  

  Abbildung 1-4. Die Grenzen der Microservices stimmen möglicherweise nicht mit den Anforderungen des Geschäftsproblems überein

In dieser Abbildung ist der neue Dienst nur für den Zugriff auf die zugrundeliegenden Geschäftsdaten auf den Bestands-, Konten- undVersanddienst angewiesen, nicht aber für die Ausführungder Geschäftslogik. Diese Form des Datenzugriffs kann zwar über eine synchrone API bereitgestellt werden, ist aber nicht für alle Anwendungsfälle geeignet. So können zum Beispiel große Datensätze, zeitkritische Daten und komplexe Modelle verhindern, dass diese Art des Zugriffs Realität wird. Hinzu kommt, dass die Datenzugriffs-API und die Leistung der Datenbereitstellung zusätzlich zur Basisfunktionalität des Microservices bereitgestellt werden müssen.

Betrieblichen Systemen fehlt eine allgemeine Lösung für die Kommunikation wichtiger Geschäftsdaten zwischen Diensten. Das ist kein Problem, das nur auf den Betrieb beschränkt ist. Der Bereich Big Data, der Analysen, Berichte, maschinelles Lernen, künstliche Intelligenz und andere Unternehmensdienste unterstützt, ist ein gefräßiger Verbraucher von vollständigen Datensätzen aus dem gesamten Unternehmen.

Die Verletzung der Domänengrenzen in Form von Datenzugriffen istdie Grundlage, auf der Big Data Engineering aufgebaut wurde (ich habe in den zehn Jahren, die ich in diesem Bereich tätig bin, an solchen Überfällen teilgenommen) und hat uns zum Glück viele Erkenntnisse gebracht, die wir nutzen können, um eine bessere Lösung für alle Datennutzer zu finden. Doch bevor wir dazu kommen, werfen wir einen Blick auf die Anforderungen im Big-Data-Bereich für den Zugriff auf und die Nutzung von Daten und wie sich dieser Bereich zu dem entwickelt hat, was er heute ist.

Die analytische Ebene: Data Warehouses und Data Lakes

Während sich die operativen Belange in erster Linie auf OLTP und die Server-zu-Server-Kommunikation konzentrieren, geht es bei den analytischen Belangen traditionell um die Beantwortung von Fragen zur Gesamtleistung des Unternehmens. OLAP-Systeme (Online Analytical Processing) speichern Daten in einem Format, das sich besser für analytische Abfragen eignet und esDatenanalysten ermöglicht, Daten auf verschiedenen Dimensionen auszuwerten. Data Warehouses helfen bei der Beantwortung von Fragen wie "Wie viele Artikel haben wir letztes Jahr verkauft?" und "Was war unser beliebtester Artikel?". Um diese Fragen zu beantworten, müssen betriebliche Daten in ein Modell umgewandelt werden, das für Analysen geeignet ist, und es müssen auch die riesigen Datenmengen berücksichtigt werden, in denen die Antworten letztendlich zu finden sind.

Um Daten in ein Data Warehouse zu bekommen, wurde bisher ein Prozess verwendet, der als Extrahieren, Transformieren und Laden (ETL) bekannt ist, wie in Abbildung 1-5 dargestellt.

Ein periodisch geplanter Auftrag extrahiert Daten aus einer oder mehreren Quelldatenbanken und wandelt sie in das für das Data Warehouse erforderliche Datenmodell um. Die Daten werden dann in das Data Warehouse geladen, wo Datenanalysten weitere Abfragen und Analysen durchführen können. Data Warehouses setzen in der Regel beim Schreiben genau definierte Schemata durch, einschließlich Spaltentypen, Namen und Nullbarkeit.

Abbildung 1-5. Ein typischer Data Warehouse ETL-Workflow

In der Vergangenheit haben sich Data Warehouses als Mittel für analytische Ergebnisse bewährt. Aber die ständig wachsende Daten- und Rechenlast erforderte größere Festplatten und leistungsfähigere Computerchips und stieß schließlich an die physikalischen Grenzen der Computerhardware. Anstatt weiter aufzustocken, war es an der Zeit, sie zu verkleinern.

Die Notwendigkeit einer massiven Skalierung war für Google offensichtlich, als das Unternehmen im Oktober 2003 das Google File System veröffentlichte. Dies ist die Zeit, in der Big Data geboren wurde und die Art und Weise, wie wir Daten erstellen, speichern, verarbeiten und letztendlich nutzen, weltweit überdacht wurde.

Hinweis

Viele moderne Data Warehouses bieten auch eine hohe Skalierbarkeit, aber erst mit dem Aufkommen der Big-Data-Revolution wurde dies zur Realität. In der Vergangenheit waren Data Warehouses durch dieselben Faktoren eingeschränkt wie jedes andere System, das auf einem einzelnen Server läuft.

Apache Hadoop hat sich schnell als die endgültige Lösung für die Skalierungsprobleme herkömmlicher OLAP-Systeme durchgesetzt. Da es kostenlos und quelloffen ist, kann es von jedem Unternehmen überall eingesetzt werden, vorausgesetzt, man weiß, wie man die Infrastrukturanforderungen bewältigen kann. Außerdem bot es eine neue Art der Datenverarbeitung, bei der man nicht mehr an ein proprietäres System gebunden war, das durch die Ressourcen eines einzelnen Computers begrenzt war.

Mit Hadoop wurde das Hadoop Distributed File System (HDFS) eingeführt, ein robustes, fehlertolerantes Dateisystem, das es ermöglichte, wirklich riesige Datensätze auf mehreren Standard-Hardwareknoten zu erstellen, zu speichern und zu verarbeiten. Obwohl HDFS inzwischen weitgehend von Optionen wie Amazon S3 und Google Cloud Storage verdrängt wurde, ebnete es den Weg für eine kühne neue Idee: Kopiere alle Daten, die du brauchst, an einen einzigen logischen Ort, unabhängig von ihrer Größe, und wende eine Verarbeitung an, um die Daten zu bereinigen, zu sortieren und in das erforderliche Format für wichtige Geschäftsanalysen umzuwandeln.

Die Big-Data-Architektur hat die Mentalität in Bezug auf Daten erheblich verändert. Sie löste nicht nur die Kapazitätsprobleme bestehender OLAP-Systeme, sondern führte auch ein neues Konzept in die Datenwelt ein: Es war nicht nur akzeptabel, sondern sogar vorzuziehen, unstrukturierte oder halbstrukturierte Daten zu verwenden, anstatt sie wie in einem DataWarehouse in ein Schema zu zwingen. In dieser neuen Welt der Big Data war es möglich, Daten mit oder ohne Schema oder Struktur zu schreiben und sie später in Abfragezeit durch die Anwendung eines Schemas beim Lesen aufzulösen. Viele Dateningenieure waren froh, dass das Schema beim Schreiben nicht mehr erforderlich war, denn so war es einfacher, die Daten einfach in das Ökosystem zu übertragen.

In Tabelle 1-1 werden die Datenstrukturen und Anwendungsfälle von zwischen einer relationalen Datenbank und MapReduce verglichen. MapReduce ist ein frühes Hadoop-Verarbeitungsframework und wird verwendet, um Daten zu lesen, ein Schema anzuwenden (beim Lesen), Transformationen und Aggregationen durchzuführen und das Endergebnis zu erzeugen.

Tabelle 1-1. Ein Vergleich zwischen einem relationalen Datenbankmanagementsystem und Hadoop, ca. 2009

	Traditionelle RDBMS	MapReduce
Datengröße	Gigabytes	Petabytes
Zugang	Interaktiv und Batch	Batch
Updates	Viele Male lesen und schreiben	Einmal schreiben, viele Male lesen
Struktur	Statisches Schema	Dynamisches Schema
Integrität	Hoch	Niedrig
Skalierung	Nichtlinear	Linear

In diesem Leitfaden aus dem Jahr 2009 wird MapReduce als eine Lösung für den Umgang mit Daten mit geringer Integrität und einem dynamischen Schema angepriesen. Dabei wird betont, dass HDFS unstrukturierte Daten mit geringer Integrität speichern sollte, wobei unterschiedliche und möglicherweise widersprüchliche Schemata zur Laufzeit aufgelöst werden müssen. Er weist auch darauf hin, dass diese Daten einmal geschrieben und viele Male gelesen werden. Das ist genau das Szenario, in dem du ein starkes, konsistentes und durchgesetztes Schema brauchst - und bietet damit reichlich Gelegenheit für wohlmeinende, aber unbedarfte Nutzer der Daten, ein Schema zum Lesen anzuwenden, das die Daten falsch interpretiert oder ungültig macht.

Ein Schema beim Schreiben, das gut definierte Spalten mit Typen, Standardwerten, Nullbarkeit und Namen enthält, schränkt die nachgelagerten Transformationen nicht unbedingt in irgendeiner Weise ein. Es zwingt dich auch nicht dazu, Daten vor dem Schreiben zu denormalisieren oder zu verknüpfen.

Ein Schema bietet dir eine Sicherheitsprüfung, die gewährleistet, dass die Daten, die du einliest, zumindest den grundlegenden Erwartungen der nachgelagerten Prozessoren entsprechen. Wenn du auf diese Prüfung verzichtest, werden Fehler erst in den nachgelagerten Prozessen entdeckt, was für diejenigen, die die Daten nutzen wollen, zu erheblichen Problemen führt.

Ich glaube nicht, dass ich - oder viele andere - in den Anfängen von Hadoop erkannt haben, wie sehr das Konzept des Schemas beim Lesen die Art und Weise, wie Daten gesammelt, gespeichert und analysiert werden, verändern würde. Wir glaubten und unterstützten die Idee, dass es in Ordnung ist, Daten zu sammeln, wenn man sie braucht, und sie im Nachhinein zu bearbeiten, indem man sie umstrukturiert, bereinigt und Schemata zu einem späteren Zeitpunkt durchsetzt. Das machte es auch denjenigen schmackhaft, die eine Migration zu Hadoop in Erwägung zogen, um ihre analytischen Zwänge zu lindern, da dieser Schritt ihre Schreibprozesse nicht einschränkte oder sie mit strikten Regeln für die Datenaufnahme belästigte - schließlich können sie die Daten einfach korrigieren, sobald sie kopiert wurden!

Leider hat sich das Grundprinzip, unstrukturierte Daten zu speichern, um sie beim Lesen mit einem Schema zu verwenden, als einer der kostspieligsten und schädlichsten Grundsätze erwiesen, die durch die Big-Data-Revolution eingeführt wurden. Schauen wir uns an, wie sich dies negativ auf den verteilten Datenzugriff auswirkt und warum gut definierte, schematisierte Daten ein so wichtiger Grundsatz der Datenvernetzung sind.

Die organisatorischen Auswirkungen von Schemata auf das Lesen

Die Durchsetzung eines Schemas zum Zeitpunkt des Lesens statt zum Zeitpunkt des Schreibens führt zu einer Ausbreitung von "schlechten Daten", wie wir sie nennen. Das Fehlen von Prüfungen beim Schreiben bedeutet, dass Daten, die in das HDFS geschrieben werden, möglicherweise nicht mit den Schemata übereinstimmen, die die Leser bei ihrer Arbeit verwenden, wie in Abbildung 1-6 dargestellt. Einige fehlerhafte Daten führen dazu, dass die Verbraucher die Verarbeitung abbrechen, während andere fehlerhafte Daten unerkannt bleiben. Beides ist problematisch, aber stille Fehler können tödlich sein und sind schwer zu erkennen.

Abbildung 1-6. Beispiele für fehlerhafte Daten in einem Datensatz, die erst beim Lesen entdeckt werden

Um den schädlichen Einfluss von Schemata auf das Lesen besser zu verstehen, wollen wir uns drei Rollen und ihre Beziehung zueinander ansehen. Auch wenn ich mich auf meine eigenen Erfahrungen beschränke, hatte ich das Glück, in meiner Karriere mit vielen anderen Datenverantwortlichen aus verschiedenen Unternehmen und Branchen zu sprechen. Ich kann mit Gewissheit sagen, dass die Zuständigkeiten zwar von Unternehmen zu Unternehmen etwas variieren, diese Zusammenfassung der Rollen aber im Großen und Ganzen für die meisten modernen Unternehmen, die Big Data nutzen, gilt:

Der Datenanalyst

Sie sind damit beauftragt, Geschäftsfragen zu beantworten, Erkenntnisse zu gewinnen und datengesteuerte Berichte zu erstellen. Datenanalysten fragen die Datensätze ab, die ihnen von den Dateningenieuren zur Verfügung gestellt werden.

Der Dateningenieur

Die Aufgabe von besteht darin, die wichtigen Geschäftsdaten aus den Systemen des Unternehmens zu beschaffen und sie in ein für die Datenanalysten brauchbares Format zu bringen.

Der Anwendungsentwickler

Sie sind damit beauftragt, eine Anwendung zu entwickeln, um Geschäftsprobleme zu lösen. Die Datenbank dieser Anwendung ist auch die Quelle der Daten, die die Datenanalysten für ihre Arbeit benötigen.

In der Vergangenheit bestand die häufigste Art, Hadoop einzuführen, darin, ein spezielles Datenteam als Untergruppe des regulären Entwicklungsteams oder völlig getrennt davon einzurichten. Der Dateningenieur griff auf die Datenbank des Anwendungsentwicklers zu, holte die benötigten Daten heraus und legte sie im HDFS ab. Data Scientists würden die Daten bereinigen und umstrukturieren (und möglicherweise Machine-Learning-Modelle daraus erstellen), bevor sie sie für die Analyse weitergeben.

Schließlich würden die Datenanalysten die erfassten Datensätze abfragen und verarbeiten, um Antworten auf ihre analytischen Fragenzu erhalten. Dieses Modell führte jedoch zu vielen Problemen. Die Gespräche zwischen dem Datenteam und den Anwendungsentwicklern fanden nur selten statt und drehten sich in der Regel darum, sicherzustellen, dass die Abfragen des Datenteams die Leistungsfähigkeit der Produktion nicht beeinträchtigten.

Es gibt drei Hauptprobleme mit dieser Trennung von Anliegen und Verantwortlichkeiten. Schauen wir sie uns an.

Problem 1: Verletzte Datenmodellgrenzen

Daten, die in den Analysebereich aufgenommen werden, sind an das interne Datenmodell der Quelle gekoppelt und führen zu einer direkten Kopplung durch alle nachgelagerten Nutzer dieser Daten. Bei einfachen, sich selten ändernden Quellen mag das kein großes Problem darstellen. Viele Modelle erstrecken sich jedoch über mehrere Tabellen, sind für OLTP-Operationen konzipiert und werden möglicherweise stark überarbeitet, wenn sich die geschäftlichen Anwendungsfälle ändern. Durch die direkte Kopplung an dieses interne Modell sind alle nachgelagerten Benutzer diesen Änderungen ausgesetzt.

Warnung

Ein Beispiel für eine Tabellenänderung, die nachgelagerte Aufträge stillschweigend zerstört hat, ist die Änderung eines Feldes von boolesch zu long. Die ursprüngliche Version stellte eine Antwort auf die Frage "Hat der Kunde für die Werbung bezahlt?" dar. Die aktualisierte Version stellte die Budget-ID des neu erweiterten Bereichs dar und verknüpfte diesen Teil des Modells mit dem Budget und dem zugehörigen Typ (einschließlich des neuen Versuchstyps). Das Unternehmen hatte sich für ein "Teste, bevor du kaufst"-Modell entschieden, bei dem es z. B. mehrere hundert Dollar an Werbeguthaben reservierte, um die Wirksamkeit der Werbung zu demonstrieren, ohne sie bei den gesamten Bruttoeinnahmen zu berücksichtigen.

Die Aufträge, die diese Daten in das HDFS einspeisen, haben nichts verpasst (kein Schema beim Schreiben), aber einige der nachgelagerten Aufträge begannen, seltsame Werte zu melden. Bei den meisten dieser Aufträge handelte es sich um Python-Jobs, die die neuen Werte von long einfach als Boolesche Werte auswerteten, was zu einer Überbewertung verschiedener Benutzeranalysen führte. Da keine Aufträge wirklich kaputt waren, wurde dieses Problem leider erst entdeckt, als ein Kunde anfing, Fragen zu abnormalen Ergebnissen in seinen Berichten zu stellen. Dies ist nur eines von vielen Beispielen, die mir begegnet sind, bei denen gut gemeinte, sinnvolle Änderungen am Datenmodell eines Systems unbeabsichtigte Folgen für alle haben, die damit zu tun haben.

Problem 2: Fehlender Alleinbesitz

Anwendungsentwickler sind die Experten der Domäne und die Meister des Quelldatenmodells, aber ihre Verantwortung für die Kommunikation dieser Daten mit anderen Teams (wie dem Big-Data-Team) ist in der Regel nicht vorhanden. Stattdessen endet ihre Verantwortung meist an der Grenze zwischen ihrer Anwendung und der Datenbank.

In der Zwischenzeit ist es die Aufgabe des Dateningenieurs, einen Weg zu finden, diese Daten rechtzeitig aus der Datenbank des Anwendungsentwicklers herauszuholen, ohne das Produktionssystem zu beeinträchtigen. Der Datentechniker ist von den Datenquellen abhängig, hat aber oft wenig bis gar keinen Einfluss darauf, was mit den Datenquellen geschieht, was seine Rolle sehr reaktiv macht. Diese Kluft zwischen Produktion und Daten ist in vielen Unternehmen ein echtes Hindernis, und trotz aller Bemühungen, Vereinbarungen, Integrationschecks und vorbeugenden Tools kommt es immer wieder zu Störungen in den Dateneingabepipelines.

Und schließlich ist der Datenanalyst, der für die tatsächliche Nutzung der Daten zur Erzielung von Geschäftswert verantwortlich ist, zwei Stufen vom Fachexperten (Anwendungsentwickler) entfernt, und drei Stufen, wenn du eine Schicht von Datenwissenschaftlern hast, die die Daten weiter verarbeiten. Sowohl Analysten als auch Data Scientists müssen sich mit den Daten befassen, die die Dateningenieure extrahieren konnten, einschließlich der Lösung von inkonsistenten Daten, die nicht mit ihren bestehenden Leseschemata übereinstimmen.

Da Datenanalysten ihre Schemata oft mit anderen Datenanalysten teilen, müssen sie auch sicherstellen, dass ihre aufgelösten Schemata die Arbeit der anderen nicht beeinträchtigen. Das wird immer schwieriger, je mehr ein Unternehmen und seine Daten wachsen, und leider bleiben ihre Lösungsbemühungen darauf beschränkt, nur anderen Analysten zu helfen. Operative Anwendungsfälle müssen ihren eigenen Weg finden, um an Daten zu gelangen.

Problem 3: Do-it-yourself und benutzerdefinierte Punkt-zu-Punkt-Datenverbindungen

Während ein Datenteam in einer kleinen Organisation vielleicht nur aus einer Handvoll Mitgliedern besteht, haben größere Organisationen Datenteams mit Hunderten oder Tausenden von Mitgliedern. In großen Unternehmen ist es üblich, dieselben Datenquellen in mehrere verschiedene Subdomänen der Datenplattform einzubinden, je nach Anwendungsfall, Teamgrenzen und Technologiegrenzen.

So können z.B. Verkaufsdaten in die Analyseabteilung, die Abteilung für Verbraucherberichte und die Debitorenabteilung gezogen werden. Jede Untergruppe erstellt, plant und führt in der Regel unabhängig voneinander ETL-Aufträge aus, um die Daten in ihre eigene Subdomäne zu ziehen, was zu mehreren unabhängig verwalteten Kopien der Quelldaten führt, wie in Abbildung 1-7 dargestellt.

Abbildung 1-7. Drei analytische Bereiche, von denen jeder Daten abgreift, wo er kann, um seine Arbeit zu erledigen

Während zweckbestimmte Punkt-zu-Punkt-Datenverbindungen den Nutzern den Zugriff auf die Daten ermöglichen, die sie brauchen, wo sie sie brauchen, führt dies am Ende zu einem chaotischen Durcheinander. Es kann schwierig sein, festzustellen, wem der ETL-Auftrag gehört, vor allem, wenn Nutzer/innen und Teams sich die Zugangsdaten teilen. Die Nachverfolgung der Herkunft, der Aktualität und der Eigentumsverhältnisse eines Datensatzes kann ebenfalls schwierig sein, was oft zu einer weiteren Ausbreitung neuer ETL-Aufträge führt. Wenn du dir nicht sicher bist, ob die Daten genau das sind, was du brauchst, kannst du zur Sicherheit auch einfach deinen eigenen Auftrag und deine eigene Kopie erstellen.

Die Durchsetzung von Zugriffskontrollen an der Quelle kann helfen zu klären, wer auf welche Daten zugreifen kann, aber nur von der Hauptquelle aus. Die Einschränkung des Datenzugriffs kann aber auch nach hinten losgehen. Ein langwieriger oder mühsamer Prozess, um Zugang zu erhalten, kann dazu führen, dass Personen einfach Kopien aus anderen, weniger geschützten Quellen anfertigen. In Abbildung 1-7 siehst du, dass die Domäne Prognosen die Zugriffskontrollen der Quelle einfach umgeht, indem sie die Verkaufsdaten aus der Domäne Benutzereinblicke kopiert.

Aber sind diese Kopien wirklich dieselben Daten? Synchronisierungshäufigkeit, Transformationen, Zeitzonen, zeitweilige Ausfälle und eine falsche Umgebung (z. B. Staging, nicht Produktion) sind nur einige der Probleme, die die Integrität deiner kopierten Quelle beeinträchtigen können. Es ist möglich, dass du denkst, dass du die richtigen Daten bekommst, aber das stimmt nicht und du weißt es nicht. Du kopierst zum Beispiel einen Datensatz, von dem du denkst, dass er mit der UTC-0-Zeit synchronisiert ist, aber er ist tatsächlich mit der UTC-6-Zeit synchronisiert. Das Format, die Aufteilung und die Reihenfolge der Daten mögen identisch erscheinen, aber diese schwer zu erkennenden, undokumentierten Unterschiede bleiben bestehen.

Benutzerdefinierte Punkt-zu-Punkt-Verbindungen sind schwer zu pflegen, führen zu einem Übermaß an Daten und können zu vielen doppelten Synchronisierungsaufträgen führen, die ähnliche, aber unterschiedliche Daten produzieren.

Dieses unzusammenhängende Modell und die Zuständigkeiten für den Besitz und die Verteilung von Daten führen zu schlechten Daten, die Zeit, Geld und verpasste Chancen kosten. Werfen wir einen Blick auf die Kosten, bevor wir uns damit befassen, warum das Datengeflecht diese Probleme lösen soll.

Schlechte Daten: Die Kosten der Untätigkeit

Schlechte Daten bleiben normalerweise unentdeckt, bis sie in ein Schema eingefügt werden. Du kannst zum Beispiel keine TEXT in eine Int32 Spalte in einer Datenbank einfügen. Durch die Verwendung eines Schemas beim Lesen verschieben wir die Validierung unserer Daten jedoch bis zum Ende des Data-Piping-Prozesses. Auch wenn unsere Quellen ein Schema verwenden, gibt es keine Garantie, dass unsere unzähligen Punkt-zu-Punkt-Pipelines das Schema zusammen mit den Daten korrekt erfasst haben. Es gab schon viele Int32, die als String oder schlimmstenfalls als Object erfasst wurden.

Die Behebung von Datenpannen ist kostspielig, und zwar umso kostspieliger, je weiter sie verbreitet sind. Jeder, der auf die Daten zugegriffen, sie genutzt, kopiert oder verarbeitet hat, kann davon betroffen sein und muss unter Umständen Maßnahmen zur Schadensbegrenzung ergreifen. Die Komplexität wird noch dadurch erhöht, dass nicht jeder Verbraucher das Problem auf die gleiche Weise "beheben" wird. Das kann zu abweichenden Ergebnissen führen, die bei anderen abweichen, und es kann ein Albtraum sein, sie zu entdecken, aufzuspüren undzu beheben.

Schlechte Daten werden oft versehentlich von wohlmeinenden Personen erstellt, einfach weil viele Datentransfer-Tools von Punkt zu Punkt nach dem Prinzip "greif rein und hol sie dir" funktionieren. Dies wird noch verstärkt, wenn ein Team feststellt, dass nicht nur seine Kopie des Datensatzes falsch ist, sondern dass sie schon seit mehreren Monaten falsch ist und die Ergebnisse aller nachgelagerten Aufträge, die mit diesem Datensatz berechnet wurden, ebenfalls falsch sind. Diese Aufträge können Hunderte oder Tausende von Verarbeitungsknoten mit 32- bis 128-mal mehr GB Arbeitsspeicher nutzen und jede Nacht Hunderte von TB an Daten verarbeiten. Allein die Kosten für die Wiederholung aller betroffenen Aufträge können sich leicht auf Hunderttausende oder Millionen von Dollar belaufen.

Auch Geschäftsentscheidungen können davon betroffen sein. Ich war in die Details eines Szenarios eingeweiht, in dem ein Unternehmen seinen Kunden insgesamt mehrere Millionen Dollar falsch in Rechnung gestellt hatte, in einigen Fällen zu viel und in anderen zu wenig. Die Ursache dafür war eigentlich ganz harmlos: Eine Schemaänderung in Verbindung mit einer komplexen Kette von Daten-ETLs führte zu einigen Problemen bei der Dateninterpretation, als das Schema zum Zeitpunkt des Einlesens angewendet wurde. Erst als ein Kunde feststellte, dass seine Abrechnungskosten die Kosten für sein Engagement bei weitem überstiegen, wurde eine Untersuchung eingeleitet und das eigentliche Problem entdeckt.

Die zunehmende Bedeutung von Daten in der modernen Datenverarbeitung hat andere dazu veranlasst, die damit verbundenen Kosten zu erforschen, vor allem, wie viel schlechte Daten Unternehmen kosten. Die Ergebnisse sind erschütternd hoch.

Im Jahr 2016 schätzte ein Bericht von IBM, der von der Harvard Business Review (HBR) hervorgehoben wurde, die finanziellen Auswirkungen schlechter Daten auf 3,1 Billionen US-Dollar allein in den USA. Obwohl der Originalbericht (leider) nicht mehr verfügbar ist, hat die HBR einige der wichtigsten Zahlen aufbewahrt:

• 50 % - das ist die Zeit, die Wissensarbeiter/innen mit der Suche nach Daten, dem Finden und Korrigieren von Fehlern und der Suche nach Bestätigungsquellen für Daten, denen sie nicht vertrauen, verschwenden.

• 60 % - das ist der geschätzte Anteil der Zeit, den Datenwissenschaftler/innen mit dem Bereinigen und Organisieren von Daten verbringen.

Das Problem der schlechten Daten gibt es schon sehr lange. Datenkopien weichen voneinander ab, wenn sich ihre ursprüngliche Quelle ändert. Kopien werden veraltet. Fehler, die in einem Datensatz entdeckt wurden, werden in den doppelten Datensätzen nicht behoben. Das Fachwissen über die Interpretation und das Verständnis der Daten bleibt unvollständig, ebenso wie die Unterstützung durch die Eigentümer der Originaldaten.

Data Mesh schlägt vor, dieses Problem zu lösen, indem es Daten zu einem Bürger erster Klasse macht, zu einem Produkt wie jedes andere. Ein Datenprodukt mit einem klar definierten Schema, einer Domänendokumentation, standardisierten Zugriffsmechanismen und SLAs kann die Auswirkungen von fehlerhaften Daten direkt an der Quelle erheblich reduzieren. Sobald die Verbraucher/innen mit dem Datenprodukt verbunden sind, können sie immer noch ihre eigenen Fehler in der Geschäftslogik machen - das ist unvermeidlich. Sie werden jedoch selten unbeabsichtigte Fehler machen, wenn sie lediglich versuchen, die Daten zu beschaffen, zu verstehen und zu interpretieren die sie zur Lösung ihrer Geschäftsprobleme benötigen. Untätigkeit ist keine Lösung.

Können wir analytische und betriebliche Arbeitsabläufe vereinheitlichen?

Es gibt noch ein weiteres Problem, das im Herzen der Technik sitzt: Es ist nicht nur das Datenteam, das diese Datenzugriffs- und Qualitätsprobleme hat. Jede einzelne OLTP-Anwendung, die Daten in einer anderen Datenbank benötigt, hat die gleichen Probleme mit dem Datenzugriff wie das Datenteam. Wie kann man auf wichtige Geschäftsdaten zugreifen, die in einem anderen Dienst gespeichert sind, wenn es um betriebliche Belange geht?

Es gibt verschiedene Versuche, die operative Kommunikation zwischen Diensten zu verbessern, z. B. serviceorientierte Architekturen, Enterprise Service Busse und natürlich Punkt-zu-Punkt-Anfrage-Antwort-Microservices. Aber in jeder dieser Architekturen sind die Daten des Dienstes in seiner eigenen Datenbank gekapselt und für andere Dienste unerreichbar. In gewisser Weise ist das gut - das interne Modell ist geschützt, und du hast eine einzige Quelle der Wahrheit. Anwendungen stellen operative APIs zur Verfügung, die andere Anwendungen aufrufen können, um in ihrem Namen zu arbeiten. Diese Lösungen lösen jedoch nicht das grundsätzliche Problem des Nur-Lese-Zugriffs auf endgültige Datensätze, die sie für ihre eigenen betrieblichen Anwendungsfälle nutzen können.

Erschwerend kommt hinzu, dass viele betriebliche Anwendungsfälle heutzutage von analytischen Ergebnissen abhängen. Denk an maschinelles Lernen, Empfehlungsmaschinen, KI usw. Einige Anwendungsfälle, wie z. B. die Erstellung eines monatlichen Berichts über die meistverkauften Produkte, können eindeutig als "analytisch" bezeichnet werden, da sie von einem periodisch berechneten Auftrag abgeleitet werden.

Andere Anwendungsfälle sind nicht so eindeutig. Nehmen wir einen E-Commerce-Händler, der Schuhe auf der Grundlage des aktuellen Bestands (operativ), früherer Käufe (analytisch) und der in Echtzeit geschätzten Kaufabsichten des Nutzers (analytisch und operativ) bewerben möchte. In der Praxis ist die Grenze zwischen operativ und analytisch nur selten klar definiert, und ein und derselbe Datensatz kann für eine Vielzahl von Zwecken benötigt werden - analytisch, operativ oder irgendwo dazwischen.

Sowohl Datenanalyse- als auch herkömmliche operative Systeme haben erhebliche Schwierigkeiten, auf Daten zuzugreifen, die in anderen Datenbanken enthalten sind. Diese Schwierigkeiten werden durch das zunehmende Volumen, die Geschwindigkeit und den Umfang der Daten noch verschärft, während die Systeme gleichzeitig gezwungen sind, nach außen statt nach oben zu skalieren, da die Rechenleistung einzelner Dienste an ihre Grenzen stößt. Die Datenkommunikationsstrategien der meisten Unternehmen basieren auf der Technologie von gestern und schlagen die Angebote moderner Cloud-Speicherung, Computing und Software as a Service (SaaS) nicht in Betracht. Diese Tools und Technologien haben die Art und Weise verändert, wie Daten in einem Unternehmen modelliert, gespeichert und kommuniziert werden können, worauf wir im weiteren Verlauf dieses Buches näher eingehen werden.

Daten neu denken mit Data Mesh

Die Prämisse der Data Mesh-Lösung ist einfach. Veröffentliche wichtige Geschäftsdaten in speziellen, dauerhaften und leicht zugänglichen Datenstrukturen, den sogenannten Datenprodukten. Die ursprünglichen Ersteller der Daten sind für die Modellierung, Entwicklung, Qualität und Unterstützung der Daten verantwortlich und behandeln sie mit der gleichen erstklassigen Sorgfalt wie jedes andere Produkt im Unternehmen.

Potenzielle Kunden können die Datenprodukte, die sie für ihre geschäftlichen Anwendungsfälle benötigen, erkunden, entdecken und abonnieren. Die Datenprodukte sollten gut beschrieben und leicht zu interpretieren sein und die Grundlage für eine Reihe von sich selbst aktualisierenden Datenprimitiven bilden, die sowohl Geschäftsdienste als auch Analysen unterstützen.

Ereignisströme spielen die optimale Rolle für die Grundlage von Datenprodukten, da sie ein unveränderliches, anfügbares, dauerhaftes und wieder abspielbares Substrat für alle Verbraucher bieten. Diese Datenströme werden zu einer grundlegenden Quelle der Wahrheit für operative, analytische und alle anderen Formen von Arbeitslasten im gesamten Unternehmen.

Diese Architektur wird durch die Nutzung von modernem Cloud Computing und SaaS aufgebaut, wie in Kapitel 5 beschrieben. Ein guter Engineering Stack erleichtert die Erstellung und Verwaltung von Anwendungen während ihres gesamten Lebenszyklus, einschließlich der Beschaffung von Rechenressourcen, der Skalierbarkeit, der Protokollierung und der Überwachungsfunktionen. Ereignisströme bieten dem modernen Engineering Stack einen formalisierten und standardisierten Zugang zu den Daten, die er benötigt, um seine Aufgaben zu erfüllen.

Betrachten wir die Grundsätze für monolithische Daten von in diesem Kapitel noch einmal aus dem Blickwinkel dieses Vorschlags. Diese drei Prinzipien beschreiben die wichtigsten Einflüsse für die Ansiedlung neuer Geschäftsfunktionen in einem Monolithen. Wie würden sich selbstaktualisierende Ereignisströme zu diesen Prinzipien verhalten?

Die Datenbank ist die Quelle der Wahrheit → Der Ereignisstrom ist die Quelle der Wahrheit

Der Eigentümer der Datendomäne ist nun dafür verantwortlich, ein nach außen gerichtetes Modell zu erstellen und es als eine Reihe von Ereignissen in einen (oder mehrere) Ereignisströme zu schreiben. Im Gegenzug können andere Dienste nicht mehr direkt auf das interne Datenmodell zugreifen und koppeln, und der Produzent ist nicht mehr dafür verantwortlich, maßgeschneiderte Geschäftsaufgaben im Namen des abfragenden Dienstes zu erfüllen, wie es in einer Microservices-Architektur oft der Fall ist. Der Ereignisstrom wird zum Hauptpunkt der Kopplung zwischen den Systemen. Nachgelagerte Dienste nehmen Ereignisse aus dem Ereignisstrom auf, modellieren sie für ihre Zwecke und speichern sie in ihren eigenen Datenspeichern.

Daten sind stark konsistent → Daten sind schließlich konsistent

Der Event Stream Producer kann für seinen eigenen internen Zustand eine starke Lese-nach-Schreib-Konsistenz sowie andere Datenbankvorteile wie lokale ACID-Transaktionen beibehalten. Die Konsumenten des Ereignisstroms sind jedoch unabhängig in ihrer Verarbeitung von Ereignissen und der Modellierung des Zustands und verlassen sich daher auf ihre eigene, konsistente Sicht auf die verarbeiteten Daten. Ein Verbraucher hat keinen Schreibzugriff auf den Ereignisstrom und kann daher die Datenquelle nicht verändern. Bei der Entwicklung von Konsumentensystemen muss die letztendliche Konsistenz berücksichtigt werden, und wir werden dieses Thema im weiteren Verlauf des Buches noch genauer untersuchen.

Schreibgeschützte Daten sind leicht verfügbar (bleiben unverändert!)

Ereignisströme bieten einen formalisierten Mechanismus für die Übermittlung von Daten in einem schreibgeschützten, sich selbst aktualisierenden Format, und die Verbraucher müssen nicht mehr ihren eigenen Extraktionsmechanismus erstellen, verwalten und pflegen. Wenn eine Verbraucheranwendung ihren Status beibehalten muss, tut sie dies mit einem eigenen Datenspeicher, der völlig unabhängig von der Datenbank des Produzenten ist.

Data Mesh formalisiert die Eigentumsgrenzen von Daten innerhalb einer Organisationund standardisiert die Mechanismen der Speicherung und Kommunikation. Außerdem bietet es einen wiederverwendbaren Rahmen für die Produktion, den Verbrauch, die Modellierung und die Nutzung von Daten, und zwar nicht nur für aktuelle, sondern auch für noch zu entwickelnde Systeme.

Häufige Einwände gegen ein ereignisgesteuertes Datennetz

Es gibt einige häufige Einwände, die mir bei der Diskussion über ein ereignisgesteuertes Datennetz begegnet sind. Obwohl wir diese Situationen im Laufe des Buches detaillierter behandeln werden, möchte ich sie jetzt erwähnen, um anzuerkennen, dass es diese Einwände gibt, aber dass jeder einzelne von ihnen handhabbar ist.

Produzenten können keine Daten für alle Anwendungsfälle modellieren

Dieses Argument ist zwar richtig, geht aber an der Sache vorbei. Die Hauptaufgabe des Produzenten besteht darin, ein genaues und zuverlässiges externes öffentliches Modell seiner Domaindaten für die Nutzung durch die Verbraucher bereitzustellen. Diese Datenmodelle müssen nur die Teile der Domäne offenlegen, auf die andere Teams zugreifen können; der Rest des internen Modells bleibt tabu. Eine E-Commerce-Domäne verfügt beispielsweise über unabhängige Verkaufs-, Artikel- und Bestandsmodelle und Ereignisströme, die lediglich die aktuellen Eigenschaften und Werte der einzelnen Verkäufe, Artikel und Bestände beschreiben, während ein Versandunternehmen Ereignisströme für jede Sendung, jeden LKW und jeden Fahrer haben kann.

Diese Modelle sind bewusst einfach gehalten und konzentrieren sich auf eine einzige Bereichsdefinition. Daraus ergeben sich enge, modulare Datenbausteine, die andere Systeme nutzen können, um ihre eigenen Datenmodelle zu erstellen. Verbraucher, die diese Ereignisse aufnehmen, können sie nach Bedarf umstrukturieren, z. B. indem sie sie mit Ereignissen aus anderen Streams kombinieren oder mit bestehenden Zuständen zusammenführen, um ein Modell zu erstellen, das für die Lösung ihrer geschäftlichen Anwendungsfälle geeignet ist. Die Verbraucher können sich auch an die Produzententeams wenden, um zusätzliche Informationen zum öffentlichen Modell hinzuzufügen oder um bestimmte Felder und Werte zu klären.

Da das Produzententeam Eigentümer des ursprünglichen Datenmodells ist, ist es am besten geeignet, um zu entscheiden, welche Aspekte des Modells offengelegt werden sollen und wie andere darauf zugreifen können. Tatsächlich gibt es kein anderes Team, das besser qualifiziert ist als das Team, das die ursprüngliche Datenquelle erstellt, um zu definieren, was sie bedeutet und wie andere ihre Felder, Beziehungen und Werte interpretieren sollen. Mit diesem Ansatz können die Eigentümer der Datenquelle ihre internen Komplexitäten, wie z. B. ihr stark normalisiertes relationales Modell oder ihren Dokumentenspeicher, abstrahieren. Änderungen am internen Modell der Datenquelle können vor den Verbrauchern verborgen werden, die sich sonst direkt daran gekoppelt hätten, was zu weniger Unterbrechungen und Fehlern führt.

Mehrere Kopien von Daten zu erstellen ist schlecht

Dieser Einwand steht ironischerweise im Widerspruch zum ersten Argument. Doch genau wie das vorherige Argument hat es ein Körnchen Wahrheit in sich. Mehrere Kopien desselben Datensatzes können versehentlich aus dem Takt geraten, veralten oder auf andere Weise eine Datenquelle liefern, die nicht mit der Originalquelle übereinstimmt. Wir schlagen jedoch nicht vor, das Kopieren von Daten zu einem freien Spiel zu machen, sondern einen formalisierten und gut unterstützten Prozess einzuführen, der klare Regeln und Verantwortlichkeiten festlegt und sich dieser Realität stellt, anstatt sich vor ihr zu verstecken.

Es gibt drei Hauptunterarten dieses Arguments.

Es sollte nur eine einzige Stammkopie der Daten geben,auf die alle Systemedirekt verweisen sollten

Dieser Glaube schlägt fehl, wenn man bedenkt, dass Big-Data-Analytics-Teams auf der ganzen Welt schon seit den Anfängen der Big-Data-Bewegung gegen dieses Prinzip verstoßen (und eigentlich gegen OLAP im Allgemeinen), weil ihre Bedürfnisse nicht von einer einzigen Masterkopie erfüllt werden können, die irgendwo in einer einzigen Datenbank gespeichert ist. Auch die unterschiedlichen Bedürfnisse anderer betrieblicher Systeme, die die gleichen grenzüberschreitenden Datenerfassungsstrategien verfolgen, werden nicht berücksichtigt. Es ist einfach unhaltbar.

Wenn das Quellsystem nicht in der Lage ist, seine Daten für alle Anwendungsfälle zu modellieren, ist das ein Hauptgrund dafür, dass es irgendwann mehrere Kopien desselben Datensatzes geben wird. Ein System muss vielleicht ACID-Transaktionen in einem relationalen Modell unterstützen, während ein zweites System einen Dokumentenspeicher für Geolokalisierung und Klartextsuche unterstützen muss. Ein dritter Verbraucher muss diese Datensätze vielleicht in HDFS schreiben, um mit Hilfe von MapReduce-Verarbeitung Ergebnisse aus den vorherigen 364 Kopien dieser Daten mit Querverweisen zu anderen jährlichen Datensätzen zu erhalten. All dies kann nicht von einer einzigen zentralen Datenbank aus bedient werden, nicht nur wegen der Modellierung, sondern auch, weil eine zufriedenstellende Leistung für alle Anwendungsfälle nicht möglich ist.

Es ist zu rechenintensiv, mehrereKopien der gleichen Daten zu erstellen, zu speichern und zu aktualisieren

Dieses Argument konzentriert sich zu sehr auf die Tatsache, dass das Verschieben und Speichern von Daten Geld kostet und es daher Verschwendung ist, eine Kopie derselben Daten zu speichern (wobei Faktoren wie Umbau und Leistung natürlich außer Acht gelassen werden). Dieses Argument schlägt fehl, wenn man bedenkt, wie kostengünstig Cloud Computing ist, insbesondere die außergewöhnlich günstigen Speicher- und Netzwerkkosten der großen Cloud-Provider von heute. Auch die Entwicklerstunden, die für die Erstellung und den Support von benutzerdefinierten ETL-Pipelines erforderlich sind, werden nicht berücksichtigt - ein Teil der milliardenschweren Ineffizienz bei der Erstellung, Suche und Nutzung von Daten.

Optimierungen zur Minimierung der Datenübertragung, der Anwendungsgröße und der Festplattennutzung sind für die meisten Geschäftsanwendungen nicht mehr so wichtig wie früher. Stattdessen sollte die Priorität auf der Minimierung des Entwickleraufwands für den Zugriff auf Datenbausteine liegen, wobei der Schwerpunkt auf der betrieblichen Flexibilität liegt.

Die Verwaltung von Informationssicherheitsrichtlinien über Systeme und verteilte Datensätze hinweg ist zu schwierig

Die Formalisierung des Zugriffs auf Daten über Datenprodukte ermöglicht es dir, Zugriffskontrollen für Benutzer und Dienste durchzuführen. Durch Verschlüsselung kannst du alle deine sensiblen Daten vor unbefugten Nutzern schützen, so dass nur diejenigen, die dazu berechtigt sind, die sensiblen Daten lesen können.

Die Selbstbedienungsplattform spielt in einer Data-Mesh-Architektur eine große Rolle, da sie alle Sicherheitsrichtlinien, Zugriffskontrollen und Verschlüsselungsanforderungen durchsetzt. Die Einhaltung der Infosec-Richtlinien wird in die normalen Arbeitsabläufe von Datenproduzenten und -verbrauchern integriert, was die Durchsetzung und Prüfung der Einhaltung der Richtlinien erheblich erleichtert.

Beständigkeit ist zu schwierig zu managen

Daten, die über Ereignisströme übermittelt werden, erfordern die Berücksichtigung und Planung einer eventuellen Konsistenz. Die Klage, dass eventuelle Konsistenz zu schwierig zu handhaben sei, beruht jedoch in der Regel auf einem Missverständnis darüber, wie sehr sie sich auf die Geschäftsprozesse insgesamt auswirken kann. Wir können unsere Systemgrenzen richtig definieren, um eventuelle Konsistenz zwischen den Systemen zu berücksichtigen, und gleichzeitig Zugang zu starker Konsistenz innerhalb eines Systems haben. Es führt kein Weg daran vorbei: Wenn ein bestimmter Geschäftsprozess vollkommen konsistent sein muss, dann müssen die Erstellung und die Nutzung der Daten innerhalb der gleichen Servicegrenze erfolgen. Aber die meisten Geschäftsprozesse brauchen das nicht, und für die, die es brauchen, gibt es nichts, was wir in diesem Buch vorschlagen, um es nicht zu erreichen. In Kapitel 10 werden wir detaillierter darauf eingehen, wie die Konsistenz von gehandhabt werden kann.

Zusammenfassung

Bestehende Strategien für die Datenkommunikation scheitern an den tatsächlichen Geschäftsanforderungen. Es ist keinenachhaltige Praxis, die Grenzen eines Dienstes zu verletzen, indem man auf seine Daten zugreift, aber es ist sehr verbreitet und unterstützt oft mehrere kritische Systeme und Analyse-Workflows. Die Umstrukturierung deiner Systeme in saubere, modulare Microservices löst das Problem des Datenzugriffs nicht; andere Teile deines Unternehmens, wie die Big-Data-Analytik- und Machine-Learning-Teams, benötigen nach wie vor umfassenden Zugriff auf aktuelle und historische Daten aus allen Bereichen des Unternehmens. Auf die eine oder andere Weise werden Kopien von Daten entstehen, und wir können entweder dagegen ankämpfen oder diese Tatsache akzeptieren und daran arbeiten, sie zu verbessern. Wenn wir uns für Letzteres entscheiden, können wir Ereignisströme nutzen, um die Kommunikation von Daten im gesamten Unternehmen zu standardisieren und zu vereinfachen, indem wir sie als selbstaktualisierende Quellen der Wahrheit nutzen.

Ereignisse bilden die Grundlage der Kommunikation in ereignisgesteuerten Architekturen und prägen grundlegend den Raum, in dem wir unsere Probleme lösen. Ereignisse, die durch Ereignisströme übermittelt werden, bilden die Bausteine für den Aufbau asynchroner und reaktiver Systeme. Diese Bausteine sind Primitive, die synchronen APIs ähneln: Andere Anwendungen können sie entdecken, sich an sie koppeln und sie nutzen, um ihre eigenen Dienste aufzubauen. Eventuelle Konsistenz, verbraucherspezifische Modelle, schreibgeschützte Replikate und Stream-Materialisierungen sind nur einige der Konzepte, die wir in diesem Buch erkunden werden, ebenso wie die Rolle, die moderne Cloud-Rechen-, Speicher- und Netzwerkressourcen in dieser neuen Datenarchitektur spielen.

In den folgenden Kapiteln wird der Aufbau und die Verwendung eines ereignisgesteuerten Datennetzes näher erläutert. Wir erforschen, wie man Ereignisse entwirft, einschließlich Zustands-, Aktions- und Benachrichtigungsereignisse, sowie Muster für deren Erzeugung und Nutzung. Dieses Buch behandelt den Umgang mit Ereignissen im großen Maßstab, einschließlich Multicluster und Multiregion, bewährte Methoden für den Datenschutz und die Einhaltung gesetzlicher Vorschriften sowie Prinzipien für den Umgang mit eventueller Konsistenz und asynchroner Kommunikation. Wir untersuchen die sozialen und kulturellen Veränderungen, die notwendig sind, um ein ereignisgesteuertes Datennetz einzurichten, und sehen uns einige Fallstudien aus der Praxis an, die die Erfolge und Lehren anderer aufzeigen.

Abschließend werden wir uns auch die praktischen Schritte ansehen, die du unternehmen kannst, um in deinem eigenen Unternehmen darauf aufzubauen. Das Beste an dieser Architektur ist, dass sie modular und schrittweise aufgebaut ist und du die Vorteile in einem Bereich deines Unternehmens nach und nach nutzen kannst. Auch wenn es einige Anfangsinvestitionen gibt, haben moderne Cloud Computing- und SaaS-Lösungen die Einstiegshürden nahezu beseitigt, so dass es viel einfacher ist, damit anzufangen und zu testen, ob dies die richtige Lösung für dich ist.