Im ersten Beitrag dieser Serie habe ich den Fall einer hybriden Batch- und Streaming-Architektur für die Datenintegration vorgestellt und mich auf das Verständnis der Batch-Verarbeitung konzentriert. In diesem Beitrag konzentriere ich mich auf das Verständnis von Streaming-Berechnungen. Im letzten Beitrag gehe ich auf die Vorteile der Vereinheitlichung von Batch und Streaming für die Datenintegration ein.
Verständnis der Streaming-Berechnungen
Streaming-Datenverarbeitungssysteme haben unterschiedliche Funktionen und Implementierungsstrategien. Einerseits kann eine Streaming-Engine Daten verarbeiten, sobald sie ankommen, im Gegensatz zu einem Stapelsystem, bei dem zunächst alle Daten vorhanden sein müssen, bevor eine Berechnung gestartet werden kann. Das Ziel der Streaming-Berechnung kann darin bestehen, nicht benötigte Daten herauszufiltern oder eingehende Daten umzuwandeln, bevor die resultierenden Daten an ihr endgültiges Ziel gesendet werden. Wenn die einzelnen Streaming-Daten unabhängig voneinander verarbeitet werden können, lässt sich der Speicherbedarf der Stream-Processing-Knoten begrenzen, solange die Streaming-Berechnung mit den eingehenden Daten Schritt halten kann. Außerdem ist es oft nicht notwendig oder wünschenswert, eingehende Stream-Daten auf der Festplatte zu speichern.
Eine andere, anspruchsvollere Sichtweise der Stream-Verarbeitung beinhaltet die Durchführung von Berechnungen an Gruppen eingehender Daten, wie z. B. die Aggregation zur Ermittlung einer Summe oder eines Durchschnitts. Dies ist in vielen Kontexten nützlich, in denen Sie auf eingehende Daten in Echtzeit reagieren wollen, um Verhalten zu erkennen oder Probleme zu entdecken. Ein Datensatz kann durch eine feste Anzahl von Datenelementen definiert sein, z. B. alle 10 Nachrichten. Alternativ kann ein Datensatz als die Datenelemente definiert werden, die innerhalb eines bestimmten Zeitraums eintreffen, z. B. alle 30 Sekunden. Schließlich kann ein Streaming-Datensatz auch durch ein gleitendes Fenster definiert werden, in dem etwa alle 10 Sekunden eine Streaming-Berechnung für die letzten 30 Sekunden der Daten durchgeführt wird. Auf diese Weise entstehen sich überschneidende Datensätze.
Wie bei der stapelorientierten Datenverarbeitung ist auch bei der Streaming-Verarbeitung ein Mittel zur Behandlung von Fehlern während der Ausführung erforderlich. Aktuelle Stream-Verarbeitungs-Engines wie Apache Storm, Apache Flink und Spark Streaming haben alle unterschiedliche Ansätze, um Fehlertoleranz zu erreichen. Ein Ansatz besteht darin, regelmäßig Prüfpunkte von den Stream-Knoten im persistenten Speicher zu speichern und im Falle eines Fehlers vom Prüfpunkt aus wiederherzustellen. Apache Flink verwendet eine Form von Checkpointing, um Fehler zu tolerieren. Ein anderer Ansatz ist die Wiederherstellung nach einem Ausfall durch die erneute Wiedergabe des eingehenden Datenstroms aus einem zuverlässigen Speicher, wie z. B. Apache Kafka. Apache Storm verwendet einen Replay-Ansatz. Ein weiterer Ansatz, der von Spark Streaming verfolgt wird, besteht darin, eingehende Daten in Mikrobatches zu lesen, die im Speicher des Streaming-Clusters repliziert werden. Auf diese Weise können eingehende Stream-Daten aus einer Replikation wiederhergestellt werden.
Die verschiedenen Stream-Processing-Engines haben auch unterschiedliche Verarbeitungssemantiken, die durch ihre Ansätze zur Fehlertoleranz beeinflusst werden. Sowohl Storm als auch Flink können Daten verarbeiten, sobald sie ankommen, während Spark eingehende Daten in Mikrostapeln zusammenfassen muss, bevor die Daten verarbeitet werden. Der Micro-Batch-Ansatz kann jedoch zu einem höheren Gesamtdurchsatz auf Kosten der Latenzzeit führen. Ein weiterer semantischer Unterschied ist die mindestens einmalige gegenüber der genau einmaligen Nachrichtenverarbeitung. Spark Streaming und Flink haben eine "Exact Once"-Semantik, die für einen Programmierer einfacher zu verstehen ist. Storm unterstützt standardmäßig die Mindesteinmal-Semantik, aber die Exakt-Einmal-Semantik kann mithilfe der Trident-API-Schicht für Storm erreicht werden.
Diese Streaming-Engines überschneiden sich zwar bis zu einem gewissen Grad in ihrer Funktionalität, aber einige Engines sind für verschiedene Arten von Problemen besser geeignet. Zum jetzigen Zeitpunkt gibt es keinen universellen Rahmen, der alle Streaming-Probleme löst. In zunehmendem Maße müssen Datenintegrationsaufgaben sowohl im Streaming- als auch im Batch-Kontext ausgeführt werden.
Im letzten Beitrag dieser Serie werde ich die Vorteile der Vereinheitlichung von Batch und Streaming für die Integration von Unternehmensdaten erläutern.
