Kommentar von Kai Wähner, Confluent Legacy-Modernisierung mit Daten-Streaming

Anbieter zum Thema

Confluent Germany GmbH

QUNIS GmbH

Fivetran Germany GmbH

Immer mehr Unternehmen entwickeln digitale Geschäftsmodelle. Doch oft entpuppen sich ihre derzeitigen, in die Jahre gekommenen Data-Warehouse- und Messaging-Architekturen als hinderlich. Ein Streaming-getriebener neuer Ansatz hilft, die Flexibilität, Agilität und Skalierbarkeit der Infrastruktur zu erhöhen.

Klassisches Messaging und herkömmliche Data Warehouses (DWHs) gehören seit vielen Jahren zu den etablierten Technologien der Unternehmens-IT. Mit der Verbreitung der (Hybrid) Cloud als leitendem Infrastrukturmodell, auf Microservices basierenden Anwendungsarchitekturen und verbesserten Möglichkeiten zur Analyse sehr großer – zum Teil echtzeitnah zu verarbeitenden Datenmengen – reichen diese Ansätze aber nicht mehr.

Klassische Data-Warehouse-Systeme brauchen wegen des hohen ETL-Aufwands (Extract, Transform, Load) zu lange, um Datenströme aus unterschiedlichen Quellen ins Data Warehouse zu integrieren, dessen Datenformat vorgegeben ist. So stehen Erkenntnisse aus den Daten des laufenden Tages beispielsweise frühestens am Folgetag zur Verfügung. Herkömmliche Messaging-Plattformen wie Tibco, IBM MQ und andere werden meist mit ESBs (Enterprise-Service-Bussen), Backend-Verarbeitung oder Offline-APIs kombiniert. Die entstehenden Systeme sind häufig monolithisch und führen zu engen, unflexiblen Systemkopplungen. Umstellungen oder Erweiterungen der Messaging-Infrastruktur dauern deshalb viel zu lange, was hohe Kosten verursacht.

Nötig sind also Infrastrukturen, die besser skalieren, flexibler, kostengünstiger und schneller sind und die einst stationären Daten in Bewegung bringen oder halten (Data in Motion). Messaging-Plattformen müssen unterschiedliche echtzeitnahe Datenströme wie Sensordaten, Bilddaten, Nutzungsdaten von Plattformen, aber auch klassische Applikationsdaten unterschiedslos verarbeiten können. Dabei dürfen keine Daten verloren gehen, die Reihenfolge sollte ersichtlich und jede Manipulation der Ursprungsdaten aus Compliance-Gründen nachverfolgbar sein.

Die Lösung: Cloud DWH plus Daten-Streaming

Als Lösung bieten sich Cloud DWHs in Verbindung mit modernen Streaming-Plattformen an. Cloud DWH können klassische Datenformate aus Applikationen und vielfältige Formen unstrukturierter Daten verarbeiten. Auf die Cloud zugeschnittene Daten-Streaming-Plattformen sorgen dafür, dass Daten aus anderen Quellen, Clouds oder dem On-premises-Rechenzentrum schnell und nahtlos ins Cloud DWH überspielt und dort analysiert werden. So kommen Unternehmen zu zeitnahen Erkenntnissen, die sich wiederum in aktuelle Entscheidungen zur Geschäftsoptimierung umsetzen lassen.

Das ermöglicht Anwendungen wie proaktive Wartung, echtzeitnahe Kapazitätsbereitstellung, schnellere Empfehlungen für Kunden, das Erkennen von Account-Mehrfachnutzungen oder die exakte Wiederaufnahme von Streaming-Daten am Unterbrechungspunkt, etwa beim Ansehen von Filmen.

Das kann Apache Kafka

Das wichtigste Werkzeug zum Aufbau von Daten-Streaming-getriebenen Infrastrukturen ist derzeit Apache Kafka. Auf dieser Lösung baut auch Confluent auf. Deshalb hier ein kurzer Blick auf die Grundkonzepte.

Kafka setzt verteilte und geclusterte Ressourcen im Rechenzentrum voraus, während herkömmliche Message Broker meist von einer zentralen Einheit und sternförmig angebundenen Clients ausgehen (Hub-and-spoke-Architektur). In Kafka gibt es keine zentrale Warteschlange, sondern event-getriebene flexible Producer/Consumer-Strukturen und Topics. Letztere werden in kleinere Einheiten zerteilt („Topic Partitions“) und diese dann auf unterschiedliche Clusterknoten verteilt. Jeder Client-Knoten hat Zugriff auf alle Metadaten, über die dann der Weg zu den interessierenden Daten geöffnet wird, egal, wo sie liegen. Das steigert die Lese- und Schreibleistung. Außerdem lässt sich der Cluster dynamisch durch neue Knoten erweitern.

Durch die flexiblen Producer/Consumer-Strukturen lassen sich Daten von mehreren Clients parallel und in der richtigen Reihenfolge konsumieren. Mehrere Consumer-Instanzen, zusammengeschlossen in einer Consumer-Gruppe, können also gleichzeitig auf dieselben Topics zugreifen. Sie bekommen ihre Messages trotzdem unabhängig voneinander und wechselseitig exklusiv, wenn gewünscht, auch mit einem ID-basierten Zugriffsschutz.

Single Source of Truth

Basis von Kafka ist ein sogenanntes Commit Log, eine garantiert integre Datenquelle für das gesamte System („Single Source of Truth“), wo alle Messages unveränderlich in der Form und der Reihenfolge ihrer Versendung dauerhaft aufbewahrt werden. Die Speicherung des sequentiell abgerufenen Message-Trails auf Festplatten ist dabei weitaus günstiger als oft angenommen wird. Langsame Daten-Consumer können das System nicht mehr verlangsamen, da sie nicht direkt mit den Datenproduzenten gekoppelt sind.

Topic Partitions können für Fehlertoleranz auf mehreren Knoten gelagert werden. Die Zahl der Kopien lässt sich pro Topic individuell bestimmen. Das ermöglicht Erweiterungen, Reparaturen und das Wiederhochfahren einzelner Maschinen bei laufendem Betrieb.

Cloud-native Architekturen ermöglichen

Auf Kafka basierende Daten-Streaming-Infrastrukturen wie die von Confluent sind die ideale Basis zum Umstieg auf Cloud DWHs. Confluent ermöglicht Cloud-native Cluster mit per Knopfdruck erweiterbaren Bandbreiten von null bis in den Gigabyte-Bereich und Abrechnung On-Demand entsprechend des Datendurchsatzes bei einem SLA von 99,95 Prozent. Datenintegration und Messaging sind auf einer Ebene integriert.

ksqlDB verarbeitet Echtzeit-Datenströme mit Millionen Nachrichten pro Sekunde. 120 Konnektoren auch für klassische Message Broker erlauben die Einbindung von Daten vieler Applikationen. Auch vorhandene Messaging-Muster werden unterstützt. Unterschiedlich lokalisierte Datenressourcen können über Multi-Cluster-Linking eingebunden werden.

Schrittweise Modernisierung

Die Modernisierung einer in die Jahre gekommenen Infrastruktur sollte in mehreren Schritten erfolgen: Im ersten ersetzt Confluent die Datenintegrationsebene. Die bestehende Messaging-Lösung wird noch beibehalten, die Daten aber über Confluent-Konnektoren in die gewünschten Cloud-Anwendungen (z. B. Snowflake) eingespeist. So entsteht eine Hybrid-Cloud-Infrastruktur.

In der zweiten Stufe werden JMS (Java Messaging System)-basierte Consumer- und Producer-Anwendungen so umgeschrieben, dass sie auf Confluent verweisen und die bisherige Middleware schrittweise ersetzen. Daten werden in Kafka Topics gesammelt, die Anwendungskommunikation nutzt aber JMS.

In Phase 3 erfolgt die Umstellung auf Cloud-natives Messaging. ksqlDB erstellt Streaming-Anwendungen mit neuen und event-getriebenen Mustern, wie sie für Event-Benachrichtigung, den erneuten Abruf von Ereignissen, schreibgeschützte physische Ansichten und andere Zwecke nötig sind.

Erfolgreiche Migrationsprojekte

Zum Schluss einige Beispiele für erfolgreiche Migrationen zu Daten-Streaming-getriebenen Messaging- und Warehousing-Infrastrukturen:

• Täglich Tausende physische Pakete und rund ein Terabyte an Datenpaketen – die Deutsche Post muss sich auf die Leistungsfähigkeit und Skalierbarkeit ihrer IT-Systeme zu 100 Prozent verlassen können. Denn Paketversand und weitere Services hängen von der reibungslosen Kommunikation der Systeme und der Bereitstellung von Daten in Echtzeit ab. Aufgrund der rasant steigenden Anzahl der Datenpakete, musste die Deutsche Post ihre Systemlandschaft modernisieren. Dabei vertraut das Unternehmen auf Apache Kafka und Confluent. So können große Mengen an Daten schnell verarbeitet und korreliert werden – und das alles in Echtzeit.

• Beim Online-Reiseunternehmen Expedia wurde mit Confluent eine flexibel skalierbare und regional verteilte Conversations-Plattform gebaut. Sie wird über eine event-getriebene Confluent-Architektur mit Millionen von Nachrichten pro Sekunde aus entkoppelten Systemen gefüllt. Zwischen den Systemen reichert ksqlDB die Datenströme an. Datenspeicherung und Datenverarbeitung wurden getrennt. So konnte Expedia die Flut an Anfragen während der Corona-Pandemie bewältigen.

• Für den Anbieter eines großen Live-TV- und Video-Streaming-Portals modernisierte der Integrator Data Reply das Data Warehouse. Die neue Architektur kombiniert Data Ingestion über einen Kafka Producer auf AWS Fargate mit Datenintegration aus Datenbanken über Kafka Connect in Confluent Cloud, Stream Processing mit Kafka Streams, Kafka mit Confluent Cloud als Event Broker, Apache Druid für die Echtzeit-Analyse und einem Cloud DWH von Snowflake. Mit der Lösung lassen sich Umsätze Millisekunden genau auf Content-Provider verteilen, Schwarzsehen durch mehrfache Account-Nutzung verhindern, genaueste Fortsetzungspunkte generieren und Echtzeitdaten sofort auswerten.

Fazit

Klassische DW- und Messaging-Infrastrukturen erfüllen die Anforderungen digitaler Geschäftsmodelle nicht mehr. Es braucht Data in Motion. Die Beispiele zeigen, dass moderne, auf Data Streaming basierende Verarbeitung mit Kafka oder Produkten und Services, die darauf aufbauen, eine gute Basis fürs digitale Business bilden, indem sie die Daten in Bewegung bringen und halten. Sie liefern die nötige Flexibilität, Sicherheit und Skalierbarkeit.

(ID:48689917)