Data Mesh für Unternehmen

Data Mesh ist ein aktuelles Thema im Bereich Unternehmenssoftware und ein neuer Ansatz für die Datenverwaltung auf der Grundlage einer verteilten Architektur. Die Grundidee besteht darin, den Zugang zu Daten und deren Verfügbarkeit für Geschäftskunden zu verbessern, indem Dateneigentümer, Datenproduzenten und Datenkonsumenten direkt miteinander verbunden werden. Data Mesh zielt auf die Verbesserung der Geschäftsergebnisse datenzentrierter Lösungen sowie auf die Einführung moderner Datenarchitekturen ab.

Aus geschäftlicher Sicht führt Data Mesh neue Ideen rund um das „Datenproduktdenken“ ein. Mit anderen Worten, Daten werden als Produkt betrachtet, das eine „Aufgabe“ erfüllt, z. B. die Verbesserung der Entscheidungsfindung, die Aufdeckung von Betrug oder die Warnung des Unternehmens vor Veränderungen in der Lieferkette. Um hochwertige Datenprodukte zu erstellen, müssen Unternehmen einen Kultur- und Mentalitätswandel herbeiführen und sich zu einem funktionsübergreifenden Ansatz bei der Modellierung von Geschäftsbereichen verpflichten.

Von der technologischen Seite her betrachtet, umfasst die Sicht von Oracle auf das Data Mesh drei wichtige neue Schwerpunktbereiche für datengesteuerte Architektur:

1. Tools, die Datenprodukte wie Datensammlung, Datenereignisse und Datenanalysen bereitstellen
2. Verteilte, dezentrale Datenarchitekturen, die Organisationen helfen, die sich von monolithischen Architekturen wegbewegen wollen, hin zu Multicloud- und Hybrid-Cloud-Computing, oder die global dezentralisiert arbeiten müssen
3. Daten in Bewegung für Unternehmen, die sich nicht ausschließlich auf zentralisierte, statische, batchorientierte Daten verlassen können und stattdessen zu ereignisgesteuerten Daten-Ledgern und Streaming-zentrierten Pipelines für Echtzeit-Datenereignisse übergehen, die schnellere Analysen ermöglichen

Andere wichtige Anliegen wie Selfservice-Tools für Laien und starke föderierte Daten-Governance-Modelle sind für die Data-Mesh-Architektur genauso wichtig wie für andere, stärker zentralisierte und klassische Datenmanagementmethoden.

Ein Data-Mesh-Ansatz ist ein Paradigmenwechsel hin zur Betrachtung von Daten als Produkt. Data Mesh führt organisatorische und verfahrenstechnische Änderungen ein, die Unternehmen benötigen, um Daten als materielles Kapital des Unternehmens zu verwalten. Die Perspektive von Oracle für die Data-Mesh-Architektur erfordert eine Anpassung über organisatorische und analytische Datenbereiche hinweg.

Ein Data Mesh zielt darauf ab, Datenproduzenten direkt mit Geschäftsnutzern zu verbinden und den IT-Vermittler aus den Projekten und Prozessen herauszunehmen, die Datenressourcen aufnehmen, aufbereiten und umwandeln.

Der Fokus von Oracle auf Data Mesh liegt in der Bereitstellung einer Plattform für unsere Kunden, die diese neuen technologischen Anforderungen erfüllen kann. Dazu gehören Tools für Datenprodukte, dezentrale, ereignisgesteuerte Architekturen und Streaming-Muster für Daten in Bewegung. Bei der Modellierung von Datenproduktdomänen und anderen soziotechnischen Belangen deckt sich Oracle mit der Arbeit des Vordenkers im Bereich Data Mesh, Zhamak Dehghani.

Die traurige Wahrheit ist, dass die monolithischen Datenarchitekturen der Vergangenheit mühsam, kostspielig und unflexibel waren. Im Laufe der Jahre hat sich gezeigt, dass die meiste Zeit und das meiste Geld für digitale Geschäftsplattformen, von Anwendungen bis hin zu Analysen, in Integrationsbemühungen fließen. Folglich scheitern die meisten Plattforminitiativen.

Data Mesh ist zwar kein Wundermittel für zentralisierte, monolithische Datenarchitekturen, doch die Prinzipien, Praktiken und Technologien der Data Mesh-Strategie sind darauf ausgelegt, einige der dringendsten und bisher nicht angegangenen Modernisierungsziele für datengesteuerte Geschäftsinitiativen zu lösen.

Einige der Technologietrends, die zum Aufkommen von Data Mesh als Lösung geführt haben, sind:

Eine Änderung der Denkweise ist der wichtigste erste Schritt in Richtung eines Data Meshs. Die Bereitschaft, die erlernten Praktiken der Innovation anzunehmen, ist das Sprungbrett für eine erfolgreiche Modernisierung der Datenarchitektur.

Diese erlernten Tätigkeitsbereiche umfassen:

• Design Thinking – eine bewährte Methode zur Lösung „bösartiger Probleme“, die auf Unternehmensdatendomänen angewendet wird, um großartige Datenprodukte zu erstellen.
• „Jobs to be done“-Theorie – – Anwendung einer kundenorientierten Innovation und eines ergebnisorientierten Innovationsprozesses, um sicherzustellen, dass Unternehmensdatenprodukte echte Geschäftsprobleme lösen.

Design-Thinking-Methoden bieten bewährte Techniken, die dabei helfen, organisatorische Silos abzubauen, die häufig funktionsübergreifende Innovationen blockieren. Die „Jobs to be done“-Theorie ist die entscheidende Grundlage für die Entwicklung von Datenprodukten, die bestimmte Endverbraucherziele – oder zu erledigende Aufgaben – erfüllen. Außerdem definiert sie den Zweck des Produkts.

Obwohl der Datenproduktansatz ursprünglich aus der Data-Science-Community hervorgegangen ist, wird er mittlerweile auch auf alle Aspekte des Datenmanagements angewendet. Anstatt monolithische Technologiearchitekturen aufzubauen, konzentriert sich Data Mesh auf die Datenkonsumenten und die Geschäftsergebnisse.

Während das Datenproduktdenken auf andere Datenarchitekturen angewendet werden kann, ist es ein wesentlicher Bestandteil eines Data Meshs. Als pragmatische Beispiele für die Anwendung des Datenproduktdenkens hat das Team von Intuit eine detaillierte Analyse seiner Erfahrungen verfasst.

Produkte jeglicher Art – von Rohwaren bis hin zu Artikeln in Ihrem örtlichen Geschäft – werden als Wertgüter hergestellt, die zum Konsum bestimmt sind und eine bestimmte Aufgabe erfüllen müssen. Datenprodukte können je nach Geschäftsbereich oder zu lösendem Problem unterschiedliche Formen annehmen und Folgendes umfassen:

• Analysen – Verlaufs-/Echtzeitberichte und Dashboards
• Datasets – Datensammlungen in verschiedenen Formen/Formaten
• Modelle – Domänenobjekte, Datenmodelle, Funktionen für maschinelles Lernen (ML)
• Algorithmen – ML-Modelle, Bewertung, Geschäftsregeln
• Datenservices und APIs – Dokumente, Payloads, Themen, REST-APIs und mehr

Ein Datenprodukt wird für den Verbrauch erstellt, gehört normalerweise nicht der IT und erfordert die Verfolgung zusätzlicher Attribute, wie z. B.:

• Stakeholder-Karte – Wem gehört, wer erstellt und konsumiert dieses Produkt?
• Verpackung und Dokumentation – Wie wird es verbraucht? Wie ist es gekennzeichnet?
• Zweck und Wert – Was ist der implizite/explizite Wert des Produkts? Wird es im Laufe der Zeit eine Abschreibung geben?
• Qualität und Konsistenz – Was sind die KPIs und SLAs für die Nutzung? Kann es überprüft werden?
• Herkunft, Lebenszyklus und Governance – Gibt es Vertrauen und Erklärbarkeit der Daten?

Dezentralisierte IT-Systeme sind eine moderne Realität, und mit dem Aufkommen von SaaS-Anwendungen und Public-Cloud-Infrastrukturen (IaaS) wird die Dezentralisierung von Anwendungen und Daten Bestand haben. Architekturen von Anwendungssoftware verlagern sich weg von den zentralisierten Monolithen der Vergangenheit hin zu verteilten Microservices (ein Service-Mesh). Die Datenarchitektur wird dem gleichen Trend zur Dezentralisierung folgen, wobei Daten stärker über eine größere Vielfalt physischer Standorte und über viele Netzwerke verteilt werden. Wir bezeichnen dies als Data Mesh.

Ein Mesh ist eine Netzwerktopologie, mit der eine große Gruppe nicht hierarchischer Knoten zusammenarbeiten kann.

Einige gängige technische Beispiele sind:

• WiFiMesh – viele Knoten arbeiten zusammen, um eine bessere Abdeckung zu erzielen
• ZWave/Zigbee – energiesparende Smart-Home-Gerätenetzwerke
• 5G-Mesh – zuverlässigere und widerstandsfähigere Mobilfunkverbindungen
• Starlink – Satelliten-Breitband-Mesh auf globaler Ebene
• Service Mesh – eine Möglichkeit zur Bereitstellung einheitlicher Kontrollen über dezentrale Microservices (Anwendungssoftware)

Data Mesh ist auf diese Mesh-Konzepte ausgerichtet und bietet eine dezentrale Möglichkeit, Daten über virtuelle/physische Netzwerke und über große Entfernungen zu verteilen. Ältere monolithische Architekturen zur Datenintegration wie ETL und Datenföderationstools – und in jüngerer Zeit Public Cloud-Services wie AWS Glue – erfordern eine stark zentralisierte Infrastruktur.

Eine vollständige Data-Mesh-Lösung sollte in der Lage sein, in einem Multicloud-Framework zu arbeiten, das potenziell von On-Premises-Systemen, mehreren Public Clouds und sogar bis zu Edge-Netzwerken reichen kann.

In einer Welt, in der Daten stark verteilt und dezentralisiert sind, ist die Rolle der Informationssicherheit von größter Bedeutung. Im Gegensatz zu stark zentralisierten Monolithen müssen verteilte Systeme die Aktivitäten delegieren, die zur Authentifizierung und Autorisierung verschiedener Benutzer für unterschiedliche Zugriffsebenen erforderlich sind. Eine sichere netzwerkübergreifende Delegierung von Vertrauen ist schwierig.

Einige Überlegungen beinhalten:

• Verschlüsselung im Ruhezustand – als Daten/Ereignisse, die in den Speicher geschrieben werden
• Verteilte Authentifizierung – für Services und Datenspeicher wie mTLS, Zertifikate, SSO, Secret Stores und Data Vaults
• Verschlüsselung in Bewegung – als Daten/Ereignisse, die im Arbeitsspeicher fließen
• Identity Management – Services vom Typ LDAP/IAM, plattformübergreifend
• Verteilte Autorisierungen – für Serviceendpunkte zum Überarbeiten von Daten
  Zum Beispiel:Open Policy Agent (OPA) Sidecar to Place Policy Entscheidungspunkt (PDP) innerhalb des Container/K8S-Clusters, an dem der Microservice-Endpunkt verarbeitet wird. LDAP/IAM kann jeder JWT-fähige Service sein
• Deterministische Maskierung – um PII-Daten zuverlässig und konsistent zu verschleiern

Sicherheit innerhalb eines beliebigen IT-Systems kann schwierig sein, und es ist sogar noch schwieriger, eine hohe Sicherheit innerhalb verteilter Systeme bereitzustellen. Dies sind jedoch lösbare Probleme.

Ein Kerngedanke von Data Mesh ist das Konzept der Verteilung von Eigentum und Verantwortung. Die bewährte Methode besteht darin, das Eigentum an Datenprodukten und Datendomänen den Personen in einer Organisation zu übertragen, die den Daten am nächsten stehen. In der Praxis kann dies auf Quelldaten (z. B. Rohdatenquellen wie die operativen Aufzeichnungssysteme/Anwendungen) oder auf die Analysedaten (z. B. typischerweise zusammengesetzte oder aggregierte Daten, die für eine einfache Nutzung durch die Datenkonsumenten formatiert sind) ausgerichtet sein. In beiden Fällen sind die Erzeuger und Verbraucher der Daten oft eher mit Geschäftseinheiten als mit IT-Organisationen verbunden.

Alte Formen der Organisation von Datendomänen geraten oft in die Falle, sich an Technologielösungen wie ETL-Tools, Data Warehouses, Data Lakes oder der strukturellen Organisation eines Unternehmens (Personalwesen, Marketing und andere Geschäftszweige) auszurichten. Für ein bestimmtes Geschäftsproblem sind die Datendomänen jedoch häufig am besten auf den Umfang des zu lösenden Problems, den Kontext eines bestimmten Geschäftsprozesses oder die Anwendungsfamilie in einem bestimmten Problembereich ausgerichtet. In großen Organisationen erstrecken sich diese Datendomänen normalerweise über die internen Organisationen und technologischen Footprints.

Die funktionale Zerlegung von Datendomänen nimmt im Data Mesh einen gehobenen erstklassigen Stellenwert ein. Verschiedene Datenzerlegungsmethoden für die Domänenmodellierung können in die Data Mesh-Architektur nachgerüstet werden, einschließlich der klassischen Data Warehouse-Modellierung (wie Kimball und Inmon) oder der Data Vault-Modellierung. Die gängigste Methode, die derzeit in der Data-Mesh-Architektur ausprobiert wird, ist jedoch das domänengesteuerte Design (DDD). Der DDD-Ansatz ist aus der funktionalen Zerlegung von Microservices hervorgegangen und wird nun in einem Data Mesh-Kontext angewendet.

Ein wichtiger Bereich, in dem Oracle die Data Mesh-Diskussion ergänzt hat, ist die Hervorhebung der Bedeutung von Daten in Bewegung als Hauptbestandteil eines modernen Data Meshs. Daten in Bewegung sind von grundlegender Bedeutung, um das Data Mesh aus der alten Welt der monolithischen, zentralisierten Batch-Verarbeitung herauszuholen. Die Fähigkeiten von Daten in Bewegung beantworten mehrere zentrale Fragen zum Datennetz, wie zum Beispiel:

• Wie können wir in Echtzeit auf quellenorientierte Datenprodukte zugreifen?
• Welche Tools können die Mittel für verteilte vertrauenswürdige Datentransaktionen über ein physisch dezentralisiertes Data Mesh bereitstellen?
• Was kann ich verwenden, wenn ich Datenereignisse als Datenprodukt-APIs verfügbar machen muss?
• Wie würde ich mich bei analytischen Datenprodukten, die ständig auf dem neuesten Stand sein müssen, an Datendomänen ausrichten und Vertrauen und Gültigkeit sicherstellen?

Bei diesen Fragen geht es nicht nur um die „Implementierungsdetails“, sondern auch um zentrale Aspekte der Datenarchitektur selbst. Ein domänengesteuertes Design für statische Daten verwendet andere Techniken und Tools als ein dynamischer Data-in-Motion-Prozess desselben Designs. Beispielsweise ist in dynamischen Datenarchitekturen das Daten-Ledger für Datenereignisse die zentrale Quelle der Wahrheit.

Ledger (Bücher) sind eine grundlegende Komponente für die Funktion einer verteilten Datenarchitektur. Genau wie bei einem Buchhaltungsbuch zeichnet ein Daten-Ledger die Transaktionen auf, während sie stattfinden.

Wenn wir das Ledger verteilen, können die Datenereignisse an jedem Ort „wiedergegeben werden“. Einige Ledger sind ein bisschen wie der Flugschreiber im Flugzeug, der für Hochverfügbarkeit und Disaster Recovery eingesetzt wird.

Im Gegensatz zu zentralisierten und monolithischen Datenspeichern sind Distributed Ledger speziell darauf ausgelegt, atomare Ereignisse und/oder Transaktionen zu verfolgen, die in anderen (externen) Systemen stattfinden.

Ein Data Mesh ist nicht nur eine Art Ledger. Abhängig von den Anwendungsfällen und Anforderungen kann ein Data Mesh verschiedene Arten von ereignisgesteuerten Daten-Ledgern verwenden, darunter die folgenden:

• Allgemeines Ereignis-Ledger – wie Kafka oder Pulsar
• Daten-Ereignis-Ledger – verteilte CDC/Replikationstools
• Messaging-Middleware – einschließlich ESB, MQ, JMS und AQ
• Blockchain-Ledger – für sichere, unveränderliche Transaktionen mit mehreren Parteien

Zusammen können diese Ledger als eine Art dauerhaftes Ereignisprotokoll für das gesamte Unternehmen fungieren und eine fortlaufende Liste von Datenereignissen bereitstellen, die in Aufzeichnungs- und Analysesystemen auftreten.

Mehrsprachige Datenstreams sind verbreiteter denn je. Sie variieren je nach Ereignistypen, Payload und unterschiedlicher Transaktionssemantik. Ein Data Mesh sollte die erforderlichen Stream-Typen für eine Vielzahl von Unternehmensdaten-Workloads unterstützen.

Natürlich gibt es mehr als nur drei Attribute eines Data Meshs. Wir haben uns auf die drei oben genannten konzentriert, um die Aufmerksamkeit auf Attribute zu lenken, von denen Oracle glaubt, dass sie einige der neuen und einzigartigen Aspekte des aufkommenden modernen Data Mesh-Ansatzes sind.

Weitere wichtige Data Mesh-Attribute sind:

• Selfservice-Tooling – Data Mesh nimmt den allgemeinen Datenverwaltungstrend in Richtung Selfservice auf, Citizen Developer müssen zunehmend aus den Reihen der Dateneigentümer kommen
• Daten-Governance – Data Mesh hat auch den langjährigen Trend zu einem stärker formalisierten föderierten Governance-Modell aufgegriffen, wie er seit vielen Jahren von Chief Data Officers, Data Stewards und Anbietern von Datenkatalogen verfochten wird.
• Datennutzbarkeit – Wenn wir uns mit den Prinzipien des Data Mesh befassen, gibt es eine Menge Grundlagenarbeit, um sicherzustellen, dass Datenprodukte in hohem Maße nutzbar sind. Prinzipien für Datenprodukte werden sich mit Daten befassen, die wertvoll und nutzbar sind und auch geteilt werden können.

Abgesehen von „Lift-and-Shift“-Migrationen von monolithischen Datenarchitekturen in die Cloud versuchen viele Unternehmen auch, ihre zentralisierten Anwendungen der Vergangenheit aufzugeben und auf eine modernere Microservices-Anwendungsarchitektur umzusteigen.

Monolithen von Legacy-Anwendungen sind jedoch in der Regel auf riesige Datenbanken angewiesen, was die Frage aufwirft, wie der Migrationsplan gestuft werden kann, um Störungen, Risiken und Kosten zu verringern. Ein Data Mesh kann eine wichtige operative IT-Funktionalität für Kunden bereitstellen, die einen schrittweisen Übergang von einer monolithischen zu einer Mesh-Architektur durchführen. Beispiel:

• Subdomain-Auslagerung von Datenbanktransaktionen, z. B. Filtern von Daten nach „gebundenen Kontext“
• Bidirektionale Transaktionsreplikation für schrittweise Migrationen
• Plattformübergreifende Synchronisierung, wie z. B. Mainframe zu DBaaS

Im Jargon der Microservices-Architekten verwendet dieser Ansatz einen bidirektionalen Transaktionsausgang, um das Würgefeigen-Migrationsmuster zu ermöglichen, einen gebundenen Kontext nach dem anderen.

Geschäftskritische Anwendungen erfordern sehr hohe KPIs und SLAs in Bezug auf Resilienz und Kontinuität. Unabhängig davon, ob diese Anwendungen monolithisch, Microservices oder etwas dazwischen sind, können sie nicht ausfallen!

Für geschäftskritische Systeme ist ein verteiltes Eventual-Consistency-Datenmodell normalerweise nicht akzeptabel. Diese Anwendungen müssen jedoch in vielen Data Centern betrieben werden. Dies wirft die Business-Continuity-Frage auf: „Wie kann ich meine Anwendungen in mehr als einem Data Center ausführen und gleichzeitig korrekte und konsistente Daten garantieren?“

Unabhängig davon, ob die monolithischen Architekturen „Sharded Datasets“ nutzen oder die Microservices auf standortübergreifende High Availability ausgelegt sind, das Data Mesh bietet korrekte und schnelle Daten auf jede Distanz.

Ein Data Mesh kann die Grundlage für dezentrale und dennoch standortübergreifend 100 % korrekte Daten bilden. Beispiel:

• Logische Transaktionen mit sehr geringer Latenz (plattformübergreifend)
• ACID-fähige Garantien für korrekte Daten
• Multiaktiv, bidirektional und Konfliktlösung

Eine moderne Plattform im Service-Mesh-Stil verwendet Ereignisse für den Datenaustausch. Anstatt von der Batch-Verarbeitung in der Datenebene abhängig zu sein, fließen Datennutzlasten kontinuierlich, wenn Ereignisse in der Anwendung oder im Datenspeicher eintreten.

Bei manchen Architekturen müssen Microservices Daten-Payloads untereinander austauschen. Und andere Schemata erfordern den Austausch zwischen monolithischen Anwendungen oder Datenspeichern. Dies wirft die Frage auf: „Wie kann ich Microservice-Daten-Payloads zuverlässig zwischen meinen Apps und Datenspeichern austauschen?“

Ein Data Mesh kann die grundlegende Technologie für den Microservices-zentrierten Datenaustausch liefern. Beispiel:

• Microservice zu Microservice im Kontext
• Kontextübergreifend von Microservice zu Microservice
• Monolith zu/von Microservice

Microservices-Schemata wie Event Sourcing, CQRS und Transaktionsausgang sind allgemein bekannte Lösungen – ein Data Mesh stellt die Tools und Frameworks bereit, um diese Schemata in großem Maßstab wiederholbar und zuverlässig zu machen.

Über Microservice-Designmuster hinaus erstreckt sich der Bedarf an Unternehmensintegration auf andere IT-Systeme wie Datenbanken, Geschäftsprozesse, Anwendungen und physische Geräte aller Art. Ein Data Mesh bildet die Grundlage für die Integration von Daten in Bewegung.

Daten in Bewegung sind typischerweise ereignisgesteuert. Eine Benutzeraktion, ein Geräteereignis, ein Prozessschritt oder ein Datenspeicher-Commit können alle ein Ereignis mit einer Daten-Payload auslösen. Diese Daten-Payloads sind entscheidend für die Integration von Internet of Things-(IoT-)Systemen, Geschäftsprozessen und Datenbanken, Data Warehouses und Data Lakes.

Ein Data Mesh liefert die grundlegende Technologie für die Echtzeit-Integration im gesamten Unternehmen. Beispiel:

• Verbinden realer Geräteereignisse mit IT-Systemen
• Integration von Geschäftsprozessen über ERP-Systeme hinweg
• Abgleich von Betriebsdatenbanken mit analytischen Datenspeichern

Große Organisationen werden natürlich eine Mischung aus alten und neuen Systemen, Monolithen und Microservices, operativen und analytischen Datenspeichern haben. Ein Data Mesh kann dazu beitragen, diese Ressourcen über verschiedene Geschäfts- und Datendomänen hinweg zu vereinheitlichen.

Analytische Datenspeicher können Data Marts, Data Warehouses, OLAP-Cubes, Data Lakes und Data Lakehouse-Technologien umfassen.

Im Allgemeinen gibt es nur zwei Möglichkeiten, Daten in diese analytischen Datenspeicher zu bringen:

• Batch-/Mikro-Batch-Laden – auf einem Zeitplaner
• Streaming-Aufnahme – Kontinuierliches Laden von Datenereignissen

Ein Data Mesh bildet die Grundlage für eine Streaming-Datenaufnahmefunktion. Beispiel:

• Datenereignisse aus Datenbanken oder Datenspeichern
• Geräteereignisse aus der Telemetrie des physischen Geräts
• Ereignisprotokollierung von Anwendungen oder Geschäftstransaktionen

Die Aufnahme von Ereignissen per Stream kann die Auswirkungen auf die Quellsysteme verringern, die Genauigkeit der Daten verbessern (wichtig für Data Science) und Echtzeitanalysen ermöglichen.

Nach der Aufnahme in die analytischen Datenspeicher sind in der Regel Datenpipelines erforderlich, um die Daten über verschiedene Datenphasen oder Datenzonen hinweg vorzubereiten und zu transformieren. Dieser Datenverfeinerungsprozess wird häufig für die nachgelagerten analytischen Datenprodukte benötigt.

Ein Data Mesh kann eine unabhängig verwaltete Datenpipeline-Schicht bereitstellen, die mit den analytischen Datenspeichern zusammenarbeitet und die folgenden Kernservices bereitstellt:

• Selfservice-Datenentdeckung und Datenvorbereitung
• Governance von Datenressourcen über Domänen hinweg
• Datenvorbereitung und Transformation in erforderliche Datenproduktformate
• Datenüberprüfung nach Policy, die Konsistenz gewährleistet

Diese Datenpipelines sollten in der Lage sein, über verschiedene physische Datenspeicher (z. B. Marts, Warehouses oder Lakes) oder als „Pushdown-Datenstream“ innerhalb von Analysedatenplattformen zu funktionieren, die Streaming-Daten unterstützen, wie z. B. Apache Spark und andere Data Lakehouse-Technologien.

Ereignisse finden ständig statt. Die Analyse von Ereignissen in einem Stream kann entscheidend sein, um zu verstehen, was von einem Moment zum anderen passiert.

Diese Art der zeitreihenbasierten Analyse von Echtzeit-Ereignisströmen kann wichtig sein für reale IoT-Gerätedaten und um zu verstehen, was in Ihren IT-Data-Centern oder bei Finanztransaktionen passiert, wie z. B. bei der Betrugsüberwachung.

Ein Data Mesh mit vollem Funktionsumfang umfasst die grundlegenden Funktionen zur Analyse von Ereignissen aller Art über viele verschiedene Arten von Ereigniszeitfenstern hinweg. Beispiel:

• Einfache Ereignisstreamanalyse (Web-Ereignisse)
• Überwachung der Geschäftsaktivitäten (SOAP/REST-Ereignisse)
• Komplexe Ereignisverarbeitung (Multistream-Korrelation)
• Datenereignisanalyse (bei DB/ACID-Transaktionen)

Wie Datenpipelines kann die Streaming-Analyse in der etablierten Data Lakehouse-Infrastruktur oder separat als Cloud-native Services ausgeführt werden.

Diejenigen, die an der Spitze der Datenintegration stehen, streben nach operativer und analytischer Datenintegration in Echtzeit aus einer vielfältigen Sammlung robuster Datenspeicher. Innovationen waren unerbittlich und schnell, als sich die Datenarchitektur zu Streaming-Analysen entwickelte. Die betriebliche High Availability hat zu Echtzeitanalysen geführt, und die Data-Engineering-Automatisierung vereinfacht die Datenvorbereitung, sodass Data Scientists und Analysten Selfservice-Tools nutzen können.