Begriffe, Architekturen, Produkte: Große Datenmengen in Echtzeit analysieren

Wer sich auch nur oberflächlich mit Big-Data und Echtzeit-Analyse beschäftigt, stößt schnell auf Begriffe und Lösungen, die sich nicht sofort erschließen. Warum brauche ich eine Nachrichten-Queue und was unterscheidet Apache Hadoop von Kafka? Welche Rolle spielt das in einer Kappa-Architektur?

Artikel von George Anadiotis, übersetzt von Alexander Merz veröffentlicht am 4. Februar 2019 (aktualisiert am 15. Oktober 2021)

Echtzeitverarbeitung erfordert ein anderes Paradigma im Umgang mit Daten. (Bild: Pixabay)

Schieben wir im realen Leben Entscheidungen auf, droht uns der aufgetürmte Stapel an Problemen schnell zu erschlagen. In IT-unterstützten Abläufen sind Stapelverarbeitung und Batch-Betrieb hingegen immer noch an der Tagesordnung. Wären dabei nicht auch Entscheidungen in Echtzeit praxisnäher?

Für diese scheinbar naive Frage gibt es eine ganze Reihe komplexer, alles andere als naiver Antworten. Zum Teil ist das die Folge bestehender Programmierparadigmen und -praktiken, zum anderen Folge der verwendeten Infrastruktur zur Datenverwaltung. Doch hauptsächlich liegt es daran, dass Echtzeit einfach schwierig ist. Doch wer bereit ist, sich damit auseinanderzusetzen, und das ist mittlerweile deutlich einfacher geworden, kann davon profitieren.

Betrachten wir ein Beispiel aus dem Alltag des Einzelhandels. Der Online-Einkauf ist heute eine Selbstverständlichkeit. Doch wer würde als Kunde aktiv versuchen, eine Lösung zu finden, wenn der Bezahlvorgang scheitert? Viel eher bricht er den Bestellvorgang ab. Die meisten Einzelhändler würden dem Kunden dann gerne Hilfe anbieten, um ihn nicht zu verlieren.

Manche Händler betreiben ein Callcenter oder bieten Hilfe per E-Mail. Doch auch hier muss der Kunde aktiv werden. Viel besser wäre es doch, wenn der Händler die Bestellvorgänge, die Transaktionen, analysieren und solche Probleme in Echtzeit erkennen und den Kunden dann proaktiv kontaktieren könnte.

Nun gibt es bereits Analysewerkzeuge und datengetriebene Entscheidungsprozesse, die sich dafür anbieten und zunehmend Verbreitung finden. Die Vorstellung, durch die Analyse von Daten neue Erkenntnisse zu gewinnen, ist nicht neu. Jede Anwendung erzeugt Daten und es gibt eine Vielzahl von Werkzeugen für Datenanalysen. Wir könnten annehmen, dass etablierte Analyseprozesse zur Überwachung von Transaktionen unser Problem lösen könnten. Leider ist das nicht der Fall. Wir benötigen tatsächlich echtzeitfähige Analyseprozesse.

Datenanalyse und die Lambda-Architektur

Traditionell werden Datenanalysen auf einer Kopie der operativen Daten durchgeführt. Dafür gibt es gute Gründe, da sich die Anforderungen an eine Datenbank für den Alltagsbetrieb und die Analyse unterscheiden. Im Alltag sollen die ACID-Eigenschaften einen störungsfreien und sicheren Betrieb gewährleisten. Sie sorgen aber auch für mehr Aufwand in der Datenverarbeitung.

Deshalb wurden Datenbanksysteme entwickelt, die praktischer für die Datenanalyse sind. Sie werden häufig als Data Warehouses bezeichnet und verzichten zum Beispiel auf ACID-Eigenschaften. Außerdem folgen sie anderen Speicherkonzepten als klassische Datenbanken.

Eines dieser Systeme ist Hadoop. Im Gegensatz zu typischen Data Warehouses unterstützt es nicht nur relationale Datenstrukturen, sondern auch unstrukturierte und semi-strukturierte Daten wie XML, JSON, Dokument- und Bildformate. Doch wie andere Data-Warehouse-Systeme wurde auch Hadoop nicht für Echtzeit-Aufgaben konzipiert, sondern setzt auf die Stapelverarbeitung von Daten.

Ganz gleich ob klassisches Data Warehouse oder Hadoop: Um Anwendungsdaten zu analysieren, müssen sie zuerst aus der eigentlichen operativen Datenbank übertragen werden. Dieser Prozess erfordert einiges an Verarbeitung, die als ETL (Extract, Transform, Load) bezeichnet wird. In sogenannten ETL-Pipelines durchlaufen die Daten eine Reihe von Verarbeitungsschritten, einen zumeist zeitintensiven Vorgang.

Das führte zur Einführung der Lambda-Architektur. Diese hybride Architektur kombiniert drei Bestandteile: Das Batch Layer führt eine umfassende Analyse der gesamten Datenmenge per Stapelverarbeitung durch. Das Speed Layer zielt auf die sofortige, schnelle Verarbeitung neu eingetroffener Daten, wobei die Analyseergebnisse häufig nur angenähert sind. Dem einheitlichen Zugriff auf die Analyseergebnisse dient das Serving Layer.

Das Problem mit der Lambda-Architektur besteht laut dem Big-Data-Entwickler Dean Wampler darin, dass "ohne ein Werkzeug [..], das zur Implementierung von Batch- und Streaming-Jobs verwendet werden kann, die Logik zweimal implementiert werden muss: einmal mit den Tools für den Batch-Layer und dann noch einmal für den Speed-Layer. Auch der Serving-Layer erfordert in der Regel benutzerdefinierte Tools für die Integration der beiden Datenquellen."

Das bedeutet viel Komplexität, schlechte Reaktionszeiten und hohe Betreuungskosten. Deshalb wird die Lambda-Architektur von vielen als ein reines Übergangsmodell betrachtet. Um auf unser Ausgangsproblem zurückzukommen: Nicht durch die Lambda-Architektur ist es großen Händlern gelungen, die Zahl der abgebrochenen Onlinebestellungen um 80 Prozent zu reduzieren, das gelang nur durch Echtzeit-Analysen.