Moderne Realtime-Architektur

Streams – oder das Ende von Batch

Uhr
von Ursula Deriu, Dozentin, Fernfachhochschule Schweiz (FFHS), Fachbereich Data Science; Autorin und Trainerin für Big-Data-Technologien, Tirsus

Seien es Staumeldungen, Unwetterwarnungen, die Verbreitung von Breaking News oder der Versand eines bestellten ­Produkts: Klassische Batch-Verarbeitung ist diesen Fluten von Meldungen und Messungen nicht mehr ­gewachsen. Dieser Artikel zeigt, wie dieser Herausforderung in einer modernen Realtime-Architektur begegnet wird.

Ursula Deriu, Dozentin, Fernfachhochschule Schweiz (FFHS), Fachbereich Data Science; Autorin und Trainerin für Big-Data-Technologien, Tirsus (Source: zVg)
Ursula Deriu, Dozentin, Fernfachhochschule Schweiz (FFHS), Fachbereich Data Science; Autorin und Trainerin für Big-Data-Technologien, Tirsus (Source: zVg)

Die klassische Batch-Verarbeitung zur Auswertung gros­ser Datenmengen hat sich vielerorts bewährt. Auch kleinere Webanwendungen passen sich nahtlos ein. Folgende Grafik veranschaulicht die Architektur einer solchen Webanwendung:

Die App in einem Smartphone etwa schickt kontinuierlich Meldungen via Internet an einen Server, wo ein Programm sie empfängt, verarbeitet, in einer Datenbank speichert und letztlich eine Antwort an die App zurückschickt. Die Gesamtauswertung aller Daten erfolgt nachgelagert, sei es mit einem Data Warehouse (DWH), sei es mit Batch-Programmen. Die Dashboards zeigen die Ergebnisse der Analysen mit relativ grosser Verzögerung.

Für viele Anwendungsfälle ist diese Architektur zu träge – gerade die eingangs genannten Beispiele lassen keine langen Wartezeiten zu. Was wir brauchen, ist eine Realtime-Auswertung der Daten, die mit wachsender Datenmenge schrankenlos skaliert.

 

Speicherung und Auswertung der Daten auf Server verteilt

Die folgende Grafik zeigt, wie es geht:

Die eintreffenden Nachrichten – man spricht von Events – werden zu einem Event Log zusammengefasst und sofort ausgewertet. Statt dass ein Batch-Programm nachgelagert eine grosse Menge von Daten liest und analysiert, horcht ein Stream-Processing-Programm (SP) auf dieses Log, filtert on-the-fly die Events, die es verarbeiten soll, wertet Realtime aus, generiert neue Events, führt laufend Dashboards nach, versorgt die Daten erst dann sicher in einer Datenbank.

Soll die Architektur schrankenlos skalieren, dann kommen Big-Data-Technologien zum Zuge. Diese speichern Daten verteilt und ausfallsicher auf vielen parallel laufenden relativ kostengünstigen Servern in einem Cluster. Wächst die Datenmenge, dann wird der Cluster erweitert. Die Systeme skalieren von ein paar wenigen Servern bis mehrere hundert Server. Nicht nur die Speicherung der Daten, sondern auch deren Auswertung erfolgt verteilt auf diesen Servern. Solche Analysen haben naturgemäss eine hohe Latenzzeit, und so ist für Realtime-Verarbeitung spezielles Distributed Stream Processing (DSP) notwendig.

 

Daten werden in Echtzeit bereinigt und ausgewertet

Die Grafik zeigt eine typische Architektur:

Die Events werden in einem verteilten Event Log gesammelt. Distributed-Stream-Processing-Programme lesen die Events kontinuierlich aus dem Log, verteilen sie auf den DSP-Cluster, werten sie dort aus, aggregieren die Teilergebnisse zu einem Gesamten, reagieren darauf, zeigen sie in Echtzeit auf dem Dashboard. Sie schreiben neue Events ins verteilte Log oder bewahren sie ausfallsicher im verteilten Filesystem auf. Diese gesammelten Daten können erneut analysiert werden – wobei die Ergebnisse dieser langlaufenden Analysen mit denjenigen der Realtime-Analysen aggregiert werden.

Mit einer konsequenten event-getriebenen Stream-Processing-Architektur werden viele klassische Batch-Verarbeitungen obsolet, weil die Daten in Echtzeit bereinigt, ausgewertet und erst danach auf dem Filesystem gespeichert werden.

Webcode
DPF8_144191