Batch Processing vs. Event Stream Processing in Big Data Infrastruktur

Wer sich um die Planung einer Big Data Infrastruktur kümmert, wird sehr schnell an die Frage kommen, ob er Batch Processing oder Event Stream Processing einsetzt. Die Unterschiede sind oberflächlich klar: Batch Processing arbeitet diskret größere Mengen an angefallenen Daten ab, während Stream Processing einen kontinuierlichen Strom von Daten verarbeitet. Dennoch gibt es einige Details in der direkten Gegenüberstellung, auf die es sich lohnt einen Blick zu werfen. 

Direkt zur Gegenüberstellung von Batch Processing und Event Stream Processing springen.

Inhaltsverzeichnis

Was ist Batch Processing?

Batch Processing, auf Deutsch Stapelverarbeitung, bezeichnet den Prozess, dass Daten angesammelt und dann gemeinsam verarbeitet werden. Ein ganz klassisches Beispiel sind über Nacht generierte Reports, bei denen der Batch Processing Prozess auf die tagesaktuellen Daten wartet. Batch Processing ist der historische Weg, um Daten zu verarbeiten und wird daher oft mit Legacy-Systemen und Monolithen-Infrastrukturen in Verbindung gebracht. 

Vorteile und Anwendungsfälle von Batch Processing

Batch Processing hat im Vergleich zum Stream Processing nach wie vor einige Vorteile und daher auch viele Anwendungsfälle. Einer der signifikantesten Vorteile ist, dass mittels Batch Processing sehr große Datensätze verarbeitet werden können. Eine herkömmliche Assoziation im Bereich Big Data Infrastruktur ist hierbei das Hadoop Ökosystem. Stapelverarbeitung erlaubt also Inferenzen von Millionen von Datenpunkten zu ziehen, was im Event Streaming nicht der Fall ist.

Auch Data Engineers freuen sich oft über Batch Processing. Aufgrund der fix festgelegten Reihenfolge des Verarbeitungsdurchgangs ist es möglich, meist sehr komplexe ETL (Extract Transform Load) Operationen durchzuführen. Das Zusammenfügen von mehreren Datensätzen aus verschiedenen Systemen und die Aufbereitung für Dashboards ist hierbei nur eines von vielen Beispielen für den Einsatz.

Ein weiterer Vorteil ist die geringere Anforderung an die Infrastruktur. Da Batches meist nachts laufen, wenn auf den Kernsystemen wenig Last liegt, gibt es weder Gefahr beim Ausfall noch Gefahr der Überlastung der Architektur. Da die Laufzeit somit meist auch begrenzt ist, kann besser und genauer für Ausfälle kontrolliert werden. Im Falle einer Cloudarchitektur schlägt sich dies zusätzlich in niedrigeren Kosten nieder, da zum Beispiel verbilligte Computing Ressourcen genutzt werden können.

Nachteile und Herausforderungen im Batch Processing

Nebst dieser Vorteile gibt es aber natürlich auch eine Reihe an Herausforderungen im Bereich Batch Processing. Am signifikantesten ist der Pflegeaufwand zum Erhalt der Pipelines. Kleinste Änderungen, zum Beispiel ein falsches Datumsformat oder Encoding, können direkt zum Zusammenbruch des gesamten Vorgangs führen, falls sie nicht sauber abgefangen werden. 

Auch fehlende Datensätze sind ein großes Thema in der Stapelverarbeitung. Einerseits muss ein umfassender Prozess entwickelt werden, was mit Daten geschehen soll, die nicht zum eigentlichen Zeitpunkt verarbeitet werden können. Andererseits können fehlende Datensätze ebenso dazu führen, dass nachfolgende Schritte in der Processing Pipeline nicht ausgeführt werden können, was den gesamten Prozess blockiert.

Als den größten Unterschied zwischen Batch Processing und Event Data Streaming wird meist jedoch das Thema Real-Time gesehen. Batch Processing ist, wie bereits gesagt, meist auf tägliche oder stündliche Zyklen ausgelegt. Daher gibt es immer einen gewissen Verzug in der Aktualität der Daten mit denen gearbeitet werden kann. Dies ist beim Event Streaming nicht der Fall. Batch Processing Tools versuchen dieses Problem durch sogenannte Micro Batches, also sehr kleine Batch-Prozesse zu lösen und sind damit auch teilweise erfolgreich.

Tools im Bereich Batch Processing

Die Tools im Bereich Batch Processing sind so breit wie die Big Data Tool Welt selbst. Prinzipiell kann so ziemlich jedes Tool als Batch Processing eingesetzt werden, daher möchten wir uns hierbei auf ein paar Beispiele konzentrieren, die sehr oft im Zusammenhang mit Big Data Infrastruktur eingesetzt werden.

Die erste Plattform die meist im Zuge von Big Data Processing genannt wird ist Apache Spark. Spark umfasst eine Bandbreite an Optionen um große Datenmengen schnell und einfach zu verarbeiten. Dabei setzt es auf Apache Hadoop – ein weiteres Tool im Batch Processing – auf. Dazugehörige Tools wie Apache Hive als Data Warehouse und Apache Pig als Skriptsprache fallen in die gleiche Architektur.

Ein weiterer Teil sind die genutzten Storage Solutions. Klassischerweise gelten im Batch Processing alle Datenbankarten von SQL über NoSQL, aber auch unstrukturierte Container wie Azure Blob Storage oder AWS S3 als verarbeitbar.

Weitere Beiträge zum Thema Data Driven Company direkt per E-Mail bekommen:

Was ist Event Data Stream Processing?

Im Vergleich zu Batch Processing beschäftigt sich Event Data Stream Processing – oder kurz Stream Processing – nicht mit dem Ansammeln und Verarbeiten von Daten, sondern der kontinuierlichen Erfassung, Verteilung und Analyse der Daten. 

Dabei kann ein Event Stream ähnlich dem Batch Processing nur ein Ziel haben, üblicherweise verteilt der Stream die Daten jedoch von mehreren Systemen an mehrere Systeme. Oft schreibt ein Event Data Stream die Daten auch in eine Datenbank oder eine unstrukturierte Data Storage Lösung, was wiederum die Weiterverarbeitung durch Batch Processing ermöglicht. 

Data Streaming ist eine modernere Lösung in der Big Data Landschaft und die Antwort auf die Frage, wie man sehr aktuelle (“Real Time” oder “Near Real Time”, also Millisekunden oder Sekunden-genaue) Daten der Data Science Unit zur Verfügung stellt und Daten aus mehreren Systemen auch entsprechend breit weiterverteilen kann.

Vorteile und Anwendungsfälle für Event Stream Processing

Mit zunehmender Datenmenge und vor allem der zunehmenden Bandbreite an Einsatzzwecken für Daten hat sich auch das Bedürfnis nach sehr aktuellen Daten entwickelt. Die beim Batch Processing üblichen Batches auf Tages- oder Stundenbasis genügen für viele Anwendungsfälle nicht mehr. Event Stream Processing hat hierzu die Antwort.

Als einfachstes Beispiel kann man das Internet of Things nehmen. IoT-Devices, die nicht nur Daten senden sondern auch in irgendeiner Art und Weise eine Aktion folgen lassen sollen, können selbstverständlich nicht auf den nächsten Batch in mehreren Stunden warten, bevor sie reagieren. Auch die Bandbreite an Datensendern (Edge Devices) ist im Internet der Dinge sehr groß, was für eine sequentielle Datenspeicherung und -sammlung ungeeignet ist.

Weitere Beispiele die vor allem die (Near-)Realtime Komponente von Event Streaming einsetzen sind die Veränderung von Lagerbestand (“Haben wir X noch auf Lager?”), Fraud Detection im Banking oder auch einfach die Übermittlung von Aktienkursen. Alle haben zum Ziel, zu jeder Zeit an viele Kanäle zu übermitteln wie sich eine Metrik verändert – obwohl sehr viele Komponenten einen Einfluss auf die Metrik haben.

Nachteile und Herausforderungen im Event Streaming

Die Herausforderungen im Event Stream Processing entsprechen der Lösung die sie präsentiert. Durch die ständige neu ankommenden Daten gilt es, genügend Kapazität bereit zu stellen, dass die Verarbeitung nicht die Weiterleitung blockiert. Dies ist vor allem auch der Fall, so von einem Stream in eine statische Datenbank geschrieben wird. 

Bei der Menge an Daten im IoT-Umfeld kann es schnell zu Problemen kommen, wenn sehr hohe Volumina schnell aufgezeichnet werden müssen. Auch die Anzahl an (Edge) Devices, die Daten einspeisen, steigt in den letzten Jahren exponentiell, was zu weiteren Herausforderungen in Bezug auf die eingesetzte Infrastruktur führt.

Der gleiche Nachteil von Batch Processing gilt in gewissen Zügen auch im Data Stream Processing: Die historische Reihenfolge der Daten. Während im Batch Processing große Chunks eingeordnet werden müssen, muss im Stream Processing natürlich jede Nachricht am richtigen Ort landen, um eine verlässliche Datengrundlage zu garantieren.

Tools im Bereich Event Stream Processing

Die einsetzbaren Tools im Bereich Stream Processing sind nicht nur anspruchsvoller, sondern auch weniger zahlreich als im Batch Processing. Dennoch gibt es einige spezialisierte Systeme, die sich auf das Event Streaming und Processing konzentrieren. 

An vorderster Front ist vermutlich immer Apache Kafka genannt, gerne auch als umfangreich erweiterte Version vom Anbieter Confluent. Andere Möglichkeiten sind beispielsweise Apache Storm oder Apache Flink, wobei jedes Produkt spezielle Vor- und Nachteile ausweisen kann.

Fokussiert man Datenbanksysteme, kommen high performance Datenbanken wie Cassandra, Azure Cosmos oder MongoDB zum Einsatz.

Die Unterschiede zwischen Batch Processing und Event Stream Processing einfach erklärt

Für eine einfache Übersicht, hier nochmal der Unterschied zwischen Batch Processing und Event Stream Processing als Big Data Infrastruktur erklärt:

Verarbeitungsvolumen

Das Verarbeitungsvolumen ist im Batch Processing üblicherweise sehr groß und besteht aus mehreren Datensätzen, während Streaming message-basiert arbeitet und daher jeder “Batch” sehr klein ist.

Verarbeitungseffizienz

Im Batch Processing ist die Verarbeitung sehr effizient angelegt, da nur einmal pro Zyklus alle Daten gemeinsam verarbeitet werden. Event Streaming hingegen führt die Aktionen bei jeder Nachricht aus, weshalb ein sehr hoher Overhead entstehen kann.

Komplexität der Datenverarbeitung

Batches bestehen meist aus Anwendungsfällen in denen mehrere Datenquellen konsolidiert, transformiert und weiterverarbeitet werden. Folglich entsteht eine hohe Komplexität, um diese Pipeline sauber zu gestalten, dokumentieren und am Laufen zu halten. Beim Event Processing ist die Processing-Pipeline generell sehr simpel, die nachfolgenden Schritte (also Abonnenten der Nachrichten) können hingegen ins unendliche komplex werden.

Responsetime auf neue Inhalte

Abhängig vom Verabeitungszyklus ist im Batch Processing die Antwortzeit auf neue Inhalte generell sehr hoch. Es dauert meist mindestens Stunden bis Tage, teils ganze Monate, bis neue Daten aggregiert, verarbeitet und zur Verarbeitung zur Verfügung gestellt werden. Auf der anderen Seite ist die Responsetime der ultimative Vorteil von Data Stream Processing und befindet sich üblicherweise im Rahmen von (Milli-)Sekunden.

Kosten für Infrastruktur und Personal

Das ist eine sehr offene Frage und selbstverständlich stark abhängig vom Einsatz, aber im generellen kann man sagen, dass Batch Processing geringere Kosten verursacht als Stream Processing. Ersteres hat weniger Anforderung an die Komplexität der Infrastruktur, geringere Laufzeitkosten und eine geringere Anforderung an die Architekturexpertise, weshalb meist unter dem Strich die Vorteile von Real-Time-Streaming teuer bezahlt sind.

Zusammenfassung: Batch Processing vs. Event Stream Processing

Gerne fassen wir nochmals die Unterschiede von Batch Processing und Event Data Stream Processing in einer Big Data Infrastruktur zusammen:

  • Batch Processing sammelt, konsolidiert und verarbeitet alle Daten auf einmal
  • Event Stream Processing nutzt ein Messaging-System und verarbeitet jedes Event einzeln
  • Batch Processing trumpft mit niedrigeren Kosten und geringeren Anforderungen an die Infrastruktur
  • Stream Processing gewinnt im Begriff auf Geschwindigkeit und Aktualität der Daten
  • Üblicherweise werden in heutigen Architekturen einer Data Driven Company beide Varianten ihren Platz finden, vor allem bei einer hohen Varianz an Use Cases

Weitere Informationen

Weitere Beiträge zum Thema Data Driven Company direkt per E-Mail bekommen: