Published Date: December 1, 2020
Beim Stream-Processing werden Daten erfasst, bearbeitet, analysiert und bereitgestellt, während sie noch in Bewegung sind.
Daten sind selten statisch und bewegen sich konstant von einer Quelle zur nächsten. Das kann von großem Vorteil für das Unternehmen sein, das auf diese Weise in Echtzeit Einblick in den Zustand eines Systems erhält. Anstatt Protokolldaten zu sichten, repräsentieren Streaming-Daten den unmittelbaren Status Quo.
Stream-Processing wurde entwickelt, um Daten sofort verarbeiten und in Echtzeit analysieren zu können. Das Ziel ist es, aktuelle, millisekundengenaue Erkenntnisse zu den Abläufen innerhalb eines Systems zu gewinnen und Sie bei der Reaktion auf kritische Vorfälle zu unterstützen, sobald sie passieren.
In den nachfolgenden Abschnitten werden wir genau auf Stream-Processing eingehen, die Funktionsweise skizzieren und die Anwendungsfälle untersuchen, in denen die verschiedenen Arten des Stream-Processing am hilfreichsten sind.
Beim Stream-Processing können Informationen zu Ereignissen mit geringer Latenz erfasst werden, während sie gerade passieren, indem die Daten "on the fly" verarbeitet werden. Ein Daten-Stream, oder Event-Stream, kann nahezu jede Art von Information darstellen – Social-Media- oder Web-Clickstream-Daten, werkseigene Produktionsdaten und sonstige Prozessdaten, Aktienmarkt- oder Finanztransaktionsdetails, Patientendaten im Krankenhaus, Machine Learning-Systemdaten, Internet-of-Things-Gerätezustands- und sonstige IoT-Daten sind allesamt Beispiele für Informationen, die fortwährend zurück zum Unternehmen gestreamt werden.
Was die Architektur anbelangt, beinhaltet Stream-Processing ein Framework aus Datenverarbeitungssoftware, die zwischen der Datenquelle (den Produzenten) und den Benutzern dieser Daten (den Verbrauchern) eingesetzt wird. Mithilfe dieses Stream-Processing-Frameworks kann die IT entscheiden, welche speziellen Event-Streams und Data-Feeds wichtig sind, und wie diese Daten in der Entwicklung neuer zweckgebundener Streaming-Anwendungen eingesetzt werden.
Stream-Processing ist besonders hilfreich in Fällen, in denen Datenanalysen erforderlich sind, d. h. wenn Daten kontinuierlich erzeugt werden und sich im Laufe der Zeit verändern. Eines der wichtigsten Stream-Processing-Ziele besteht darin, den Data-Stream auf Anomalien und Ausreißer zu überwachen und das IT-Management zu benachrichtigen, wenn etwas schiefläuft. In einem Internet-of-Things-Beispiel speisen Hunderte von Industrieventilator-Sensoren ihre Temperatur und ihre Rotationsgeschwindigkeit konstant in eine Logging-Datenbank ein. Das Stream-Processing-System kann diese Streaming-Daten noch während der Übertragung erfassen, bevor sie in der Datenbank gespeichert werden, sodass das Management sofort die entsprechenden Informationen enthält, wenn einer dieser Ventilatoren erste Anzeichen eines Ausfalls zeigt.
Beim Stream-Processing geht es um die Echtzeitanalyse neuer, sich in Bewegung befindlicher Daten, während beim Batch-Processing regelmäßig statische Informationen analysiert werden.
Beim Batch-Processing werden Daten, die in der Vergangenheit erzeugt und in einer Datei (z. B. einer SQL-Datenbank) gespeichert wurden, durchsucht, bearbeitet und ausgewertet, wenn ein Analyst die Aktion initiiert. Die verarbeiteten Daten werden in der Regel als Data-at-Rest, also ruhende Daten, bezeichnet, da sie während der Analyse nicht aktiv verändert oder bewegt werden.
Im Gegensatz dazu werden beim Stream-Processing Daten in Bewegung in Echtzeit analysiert. Statt in einer statischen Datei gespeichert zu sein, werden Data-Streams, während sie generiert werden, sofort verarbeitet. Durch diese direkte Verarbeitung wird beim Stream-Processing ein schnelleres und aktuelleres Zustandsbild eines Geräts oder eines Services generiert.
Stellen Sie sich beispielsweise eine Datenbank vor, die regelmäßig anhand von Protokolldateien aktualisiert wird, welche durch eine Matrix von Sensoren produziert werden, die die Produktionslinie und andere Systeme in einer Werkshalle überwachen. In einem Batch-Processing-System würde die Datenbank häufig abgefragt werden, und es würden regelmäßig Berichte über den Gesamtzustand der Sensoren und etwaige Anomalien erstellt, die auf ein Problem hindeuten könnten. Für Operations-Analysten und -Administratoren sind diese Informationen nur so aktuell wie der Zeitstempel auf dem Bericht, der wiederum nur so aktuell ist wie die letzte Aktualisierung der Datenbank. Wenn der Bericht stündlich erstellt wird, bedeutet das, dass die Daten schon veraltet sein könnten, wenn sie eingehen.
In einem Stream-Processing-System werden Daten fortwährend erfasst und verarbeitet, sodass Operations-Fachleute in Echtzeit Einblick in die Zustände in der Werkhalle erhalten. Statt erst nach einer Stunde festzustellen, dass eine Maschine bereits ausgefallen ist, wird diese Information sofort bereitgestellt, sodass sie proaktiv reagieren können.
Da es beim Stream-Processing nicht auf die in einer Datenbank gespeicherten Daten ankommt, kann sie auch ohne Speicheranforderungen implementiert werden. Und da es sich um eine Lösung mit geringer Latenz handelt, werden nur die relevantesten Informationen in dem Data-Stream ausgewählt und permanent gespeichert, während die Daten, die nicht unmittelbar relevant sind, für zukünftige Suchprozesse, Security-Events oder Audits gespeichert werden.
Zustandsorientiertes Stream-Processing beinhaltet einen Informationstyp, bei dem Daten aus der Vergangenheit – die den "Zustand" der Daten wiedergeben – neue Daten und zukünftige Daten beeinflussen. Wenn sich ein Webbenutzer zu einer Sitzung anmeldet, ist jeder geöffnete Link von dem vorherigen Link abhängig, der den Benutzer auf die aktuelle Seite geleitet hat. Zur Durchführung einer Streaming-Analyse am gesamten Datenfluss eines Benutzers muss der Zustand der kompletten Sitzung des Benutzers von Anfang bis Ende berücksichtigt werden. Eine Kreditkartentransaktion beinhaltet z. B. generell zustandsorientierte Data-Streams, da detaillierte Informationen über den Kauf so lange gespeichert werden müssen, bis die Transaktion abgeschlossen ist und das Betrugserkennungssystem die Transaktion für legitim befunden hat.
Stateful Stream-Processing erhöht die Komplexität erheblich, da die Zustandsinformationen für mehrere oder verteilte Streams gleichzeitig verwaltet werden müssen. Wenn ein Stream-Prozessor die Aufgabe hat, die Benutzer einer stark frequentierten Website zu überwachen, muss das Data-Processing-System gegebenenfalls den Zustand Tausender Benutzersitzungen gleichzeitig überwachen. Dadurch erhöhen sich die Ressourcenanforderungen für das Netzwerkmonitoringsystem beträchtlich und die Situation stellt neue und komplexe Anforderungen an die zu seiner Erstellung verwendeten Algorithmen. Wenn eine zustandsorientierte Stream-Processing-Anwendung beispielsweise ausfällt, muss es einen Mechanismus geben, der sicherstellt, dass keine Zustandsinformationen verloren gehen.
Was ist der Unterschied zwischen zustandsorientiertem und zustandslosem Stream-Processing (Stateless Stream Processing)?
Während es beim zustandsorientierten Stream-Processing (wie bereits im vorherigen Abschnitt beschrieben) um den Gesamtzustand der Daten geht, ist das beim zustandslosen Stream-Processing nicht so.
In einer Umgebung mit zustandsorientiertem Stream-Processing werden Informationen über Ereignisse aus der Vergangenheit im Rahmen der Analyse aktueller Ereignisse eingesetzt. So sind z.B. Temperaturmessungen einer Industriemaschine aussagekräftiger, wenn sie im Gesamtzusammenhang über einen längeren Zeitraum hinweg berücksichtigt werden, sodass bestimmte Tendenzen auffallen, während sie sich entwickeln.
Beim zustandslosen Stream-Processing werden Daten nur bei ihrem Eintreffen analysiert, ohne Berücksichtigung des Zustands oder früherer Informationen. Wenn Sie einfach nur einen Echtzeit-Feed der Umgebungstemperatur benötigen, ohne dass Sie sich für Temperaturänderungen interessieren, ist ein zustandsloses Stream-Processing-System ausreichend. Wenn Sie aber zukünftige Temperaturen auf der Grundlage vergangener Temperaturänderungen vorhersagen möchten, benötigen Sie ein zustandsorientiertes Stream-Processing-System.
Stateful Stream-Processing ist im Hinblick auf Codierung, Betrieb und Skalierung wesentlich komplexer. Je mehr Streams verwaltet werden und je größer das Datenvolumen ist, das die einzelnen Streams produzieren, umso komplexer und ressourcenintensiver wird das zustandsorientierte Stream-Processing-System. Da beim Stateful Stream-Processing jedoch weitaus nützlichere Erkenntnisse generiert werden als beim Stateless Stream-Processing, ist es im Unternehmensalltag der heutigen Zeit die dominante Stream-Processing-Form.
Ein Stream-Processing-Framework ist ein End-to-End-Verarbeitungssystem, das eine Datenfluss-Pipeline bereitstellt, die Streaming-Inputs zur Verarbeitung annimmt und gleichzeitig hilfreiche Echtzeitanalysen generiert. Diese Frameworks sollen die Entwicklung von Stream-Processing- und Event-Stream-Processing-Software für das Datenstreaming (siehe unten) vereinfachen. Mit einem Stream-Processing-Framework kann ein Entwickler schnell Funktionen aus einer bestehenden Bibliothek von Tools einbinden und muss nicht ein komplettes Stream-Processing-System von Grund auf neu entwickeln.
Je nach der spezifischen Unternehmensumgebung und dem Anwendungsfall können verschiedene Frameworks verwendet werden. Heutzutage werden in Unternehmen mehrere dieser Frameworks verwendet, und zwar sowohl kommerzielle als auch Open-Source-Systeme. Obwohl verschiedene spezielle Stream-Processing-Frameworks entwickelt wurden, sind universelle Stream-Processing-Frameworks am weitesten verbreitet.
Unabhängig von den verwendeten Stream-Processing-Engines besteht die Aufgabe des Stream-Processing-Frameworks darin, eine Pipeline von Daten als Eingabe zu akzeptieren, diese Daten zu verarbeiten und die Ergebnisse an eine Ausgabewarteschlange zu senden, die in der Regel als Sink bezeichnet wird. Das Stream-Processing-Framework beinhaltet darüber hinaus sein eigenes Programmiermodell, bei dem es sich um ein Processing-System handelt, das definiert, wie mit Daten interagiert wird, wie Daten partitioniert werden und wie Datenzustände, Fehlermanagementkontrollen und andere Dinge verwaltet werden.
Während ein Stream-Processing-Framework das Rückgrat Ihrer Analysen bildet, ist die darauf aufbauende Stream-Processing-Software (oder eine Stream-Processing-Anwendung) für die eigentliche Analyse zuständig. Die Verwendung eines Stream-Processing-Frameworks spart Zeit und Aufwand bei der Codierung verschiedener Streaming-Anwendungen.
Stream-Processing-Software kommt häufig in den folgenden Anwendungsfällen zum Einsatz:
- Datenerfassung einschließlich Multi-Cloud-Integrationen sowie Streamen und Senden von Geschäftsdaten
- Unternehmensweite Bereitstellung, einschließlich Datenverteilung und Überwachung und Erkennung von Datendrifts
- Nachweis von Anomalien während des Streaming-Vorgangs
- Aggregation während des Streaming-Vorgangs
- Anreicherung und regelbasierte Erkennung während des Streaming-Vorgangs
- Daten-Compliance
- Erkennung von Finanzbetrug; Aufdeckung krimineller Aktivitäten in Echtzeit
- System-Monitoring; Ermöglichung von Echtzeitanalysen und vorausschauender Instandhaltung von Serverhardware, Netzwerken, Anwendungen oder Industrieanlagen
- Algorithmischer High-Speed-Wertpapierhandel
- Lieferketten-Monitoring und -Management
- Erkennung von unbefugtem Zugriff
- Analyse von Marketing- und Werbekampagnen; Verfolgung der Kundenaktivität in Echtzeit
- Verkehrsüberwachung und -reduzierung
Obwohl Stream-Processing in einem Big Data-Ökosystem im Grunde genommen genauso funktioniert wie in jeder anderen Umgebung, bietet es einige besondere Vorteile. Dazu gehört, dass mithilfe von Stream-Processing Datenanalysen durchgeführt werden können, ohne Zugriff auf den gesamten Datenspeicher haben zu müssen. Da es sich bei Big Data definitionsgemäß um riesige Datenbanken mit unstrukturierten Daten handelt, geht das Batch-Processing bei enormen Big Data-Speichern oftmals sehr langsam vonstatten. Stream-Processing bietet einen bequemen Workaround, der aus Big Data in Echtzeit in nur wenigen Millisekunden Erkenntnisse generiert. Außerdem ist ein Big Data-Speicher in einem Batch-Prozess niemals ganz vollständig, da sich diese Daten fortwährend ändern. Sobald das Batch-Processing begonnen hat, ändern sich die zugrunde liegenden Daten weiter, sodass alle Batch-Berichte veraltet sind, sobald sie vorliegen. Stream-Processing bietet eine intelligente Lösung für diese Situation und die Verarbeitung anderer komplexer Ereignisse.
Dennoch ist Batch-Processing in einem Big Data-Szenario sinnvoll, insbesondere wenn langfristige detaillierte Einblicke benötigt werden, die nur durch eine vollständige Analyse des gesamten Datenspeichers erlangt werden können. Wenn schnellere und aktuellere Analysen erforderlich sind, ist Stream-Processing die bessere Lösung.
Pulsar ist ein verteiltes Publish-and-Subscribe-Messaging-System, das sehr niedrige Veröffentlichungs- und End-to-End-Latenzzeiten, garantierte Nachrichtenzustellung, keinen Datenverlust und unendliche Datenaufbewahrung mit abgestufter Speicherung bietet.
Es wurde zuerst 2013 von Yahoo als Messaging-Plattform für kritische Anwendungen wie Yahoo Finance, Yahoo Mail und Flickr entwickelt. 2016 wurde es als Teil der Apache Foundation schnell zu einem Top-Level-Projekt mit einer dynamischen und wachsenden Community.
Herkömmliche Messaging-Systeme wie z. B. Kafka verfolgen den Ansatz, ihre Datenverarbeitung und Datenspeicherung auf demselben Knoten unterzubringen. Auch wenn dieses monolithische Design einige Performance-Vorteile im Hinblick auf die Bereitstellung von Daten von einer lokalen Festplatte bietet, wirkt es sich negativ auf die Skalierbarkeit und die Resilienz aus.
Das Programmiermodell hinter Pulsar Functions ist sehr übersichtlich. Pulsar Functions empfangen Nachrichten zu einem oder mehreren Input-Topics. Jedes Mal, wenn eine Nachricht zu dem Thema veröffentlicht wird, wird der Funktionscode ausgeführt. Wenn dieser ausgelöst wird, führt der Funktionscode seine Verarbeitungslogik an der eingehenden Nachricht aus und schreibt seinen Output zu einem Output-Topic. Das Output-Topic einer Pulsar Function kann das Input-Topic einer anderen Function sein, sodass auf effektive Art und Weise ein DAG (Directly Acyclic Graph) der Pulsar Functions erstellt werden kann.
Pulsar Functions sind leichte Rechenprozesse, die Nachrichten von einem oder mehreren Pulsar-Themen abrufen, eine vom Benutzer bereitgestellte Funktion (Verarbeitungslogik) auf jede eingehende Nachricht anwenden und die Ergebnisse in einem oder mehreren Pulsar-Themen veröffentlichen.
Das Programmiermodell, auf dem Pulsar Functions basieren, ist sehr übersichtlich. Pulsar Functions empfangen Nachrichten zu einem oder mehrerenInput-Topics. Jedes Mal, wenn eine Nachricht zu dem Thema veröffentlicht wird, wird der Funktionscode ausgeführt. Wenn der ausgelöst wird, führt der Funktionscode seine Verarbeitungslogik an der eingehenden Nachricht aus und schreibt seinen Output zu einem Output-Topic. Das Output-Topic einer Pulsar Function kann das Input-Topic einer anderen Function sein, sodass auf effektive Art und Weise ein DAG (Directly Acyclic Graph) der Pulsar Functions erstellt werden kann.
Die Verarbeitung von Datenströmen beginnt in der Regel damit, dass das Unternehmen die verfügbaren Stream-Processing-Frameworks in Betracht zieht - mit besonderem Augenmerk darauf, wie gut sie in eine bestimmte Umgebung passen und wie gut sie verschiedene Anwendungsfälle abdecken können. Es sind sowohl Open-Source- als auch kommerzielle Frameworks verfügbar, die Sie je nach dem Grad der Unterstützung, die Ihr Unternehmen benötigt, in Betracht ziehen sollten.
Folgende Fragen könnten Sie sich während der Evaluierung möglicherweise stellen:
- Wünschen Sie sich ein Data-Processing-Framework, das sowohl Batch- als auch Stream-Processing-Funktionen bietet?
- Unterstützt das Framework Programmiersprachen, mit denen sich Ihre Mitarbeiter bereits auskennen?
- Wie skalierbar ist das Framework insgesamt, und kann es mit zunehmender Unternehmensgröße geclustert werden?
- Wird zustandsorientiertes Stream-Processing unterstützt und wie skalierbar ist die Implementierung der Zustandsverwaltung?
- Welche Ansätze verfolgt das Framework in Bezug auf Fehlertoleranz, und wie gut erholt es sich von Fehlern oder Abstürzen?
- Wie komplex ist die Plattform, auf der die Entwicklung erfolgt? Wie schwer wird es den Entwicklern fallen, sich einzuarbeiten und aktiv Code für das Framework zu schreiben?
- Ist das System unabhängig in Bezug auf die Datenquellen? Wird jeder beliebige Cloud-Dienstanbieter unterstützt?
- Welche System- und Netzwerk-Monitoringtools stehen zur Verfügung?
- Wird die Plattform aktiv verwaltet und entwickelt? Wie schnell werden Fehler behoben?
Fazit: Stream-Processing kann Probleme in Big Data-Umgebungen lösen (ebenso wie in Small Data-Umgebungen)
Stream-Processing bietet IT-Managern eine neue und spannende Methode zum Analysieren von Informationen, ohne direkt eine Datenbank oder einen anderen Datenspeicher abfragen zu müssen. Durch dieses Konzept ergeben sich umfangreiche Möglichkeiten der Datenanalyse, wie z. B. Echtzeit-Analysen für Streaming-Anwendungen statt eines veralteten Blicks in die Vergangenheit. Stream-Processing wird naturgemäß nahezu sofort ausgeführt, sodass Sie langwierige Verzögerungen vermeiden, wenn Sie Berichte vor dem Hintergrund großer Datenbanken ausführen.
Je größer und komplexer Ihre Datenströme sind, umso wahrscheinlicher ist es, dass Stream-Processing Ihrer Organisation Vorteile bringt. Jedes Unternehmen, dass Informationsströme in Echtzeit analysieren muss – ganz gleich, ob es sich bei den Daten um einen Sensor-Feed aus einer Fabrik, einen Kreditkarten-Transaktionsfluss oder etwas anderes handelt – wird aller Wahrscheinlichkeit nach von einem Stream-Processing-System profitieren.
Wie funktioniert Stream-Processing?
Was ist der Unterschied zwischen Stream-Processing und Batch-Processing?
Was ist zustandsorientiertes Stream-Processing (Stateful Stream Processing)?
Was ist ein Stream-Processing-Framework?
Was ist Stream-Processing-Software?
Was ist Streaming in Big Data?
Der Turbo für Ihr IT-Monitoring
Verbessern Sie das Monitoring Ihres gesamten Netzwerks mit den drei Säulen der Observability.