Echtzeitanalysen & Streamingarchitekturen

2012 veröffentlichte die Firma Nucleus Research eine Studie zur Messung der Halbwertszeit von Daten. Folgende Grafik entspricht den Ergebnissen der Studie:

Nukleus Research spricht hierbei von taktischen, operativen und strategischen Daten. 
Taktische Daten sind besonders schnelllebig Daten.

Die Relevanz von taktischen Daten ist besonders hoch bei Unternehmen, die eine Vielzahl an Optionen (z.B. mehrere Zulieferermöglichkeiten, Versandverteilung) in ihrer Wertschöpfungskette aufweisen und schnell auf Ereignisse in ihrer Welt reagieren müssen.

Die operativen Daten weisen eine etwas höhere Halbwertszeit auf. Hierbei geht es um Daten, wie die Analyse der Verkaufszahlen der letzten Woche eines Marktes oder einer Region, um auf diese reagieren zu können und die richtigen Waren zu bestellen.

Strategische Daten sind die langlebigsten Daten. Sie werden genutzt, um Vorhersagen zu erstellen und um langfristig strategische Entscheidungen zu unterstützen.

Um auf die Schnelllebigkeit der Daten reagieren zu können, muss ein System konzeptioniert und implementiert werden, das den Wert der Daten berücksichtigt. Ein Report, dessen Informationen in seiner Erstellungszeit nicht mehr relevant sind, ist überflüssig und kann keinen Mehrwert fürs Unternehmen schaffen.

Nathan Marz stellte 2011 das Konzept der Lambda-Architektur vor, das Daten sowohl schnell als auch über einen längeren Zeitraum hinweg auswerten kann.

Die Daten werden sowohl an ein Speed Layer als auch an ein Batch Layer übergeben. Das Speed Layer hält die Daten nur flüchtig und verarbeitet diese sofort. Das aus der Verarbeitung resultierende Ergebnis wird auf ein altes Ergebnis inkrementiert und erzeugt somit eine schnell erstellte und einzusehende Sicht.

Das Batch Layer speichert die eintreffenden Rohdaten zunächst in einer Datenbank oder einem Filesystem. Diese Daten werden in regelmäßigen Abständen über einen Batchjob verarbeitet und als Sichten (Views) bereitgestellt. Der Anwender hat nun die Möglichkeit, sowohl auf die Informationen der Echtzeitsichten als auch auf die Langzeitprognosen zuzugreifen, welche auf den gleichen Ursprungsinformationen basieren. Fehler, die bei der Echtzeitprognose durch die schnelle Verarbeitung entstehen können, werden durch die Analysen des Batchvorgangs bereinigt. 

Dieses Konzept kann auch erweitert oder angepasst werden, es ist nicht unbedingt notwendig flüchtige Sichten zu erzeugen. So kann auch das Speed Layer an das Serving Layer angeknüpft und die Analysemöglichkeiten der Echtzeitdaten somit erweitert werden.

Die Kappa-Architektur wurde einige Zeit später als Ableitung der Lambda-Architektur durch Jay Kreps vorgestellt. Sie soll das Konzept der Lambda-Architektur vereinfachen.

Kreps stellt in diesem Konzept die Notwendigkeit des Batch Layers in Frage. Die Schwäche der Lambda-Architektur ist die Wartung von zwei Verarbeitungsprozessen. Dies wird in der Kappa-Architektur bereinigt. Hier muss lediglich das Speedlayer geschrieben und gewartet werden. Die eintreffenden Daten werden nach wie vor als Rohdaten gespeichert, jedoch an dieser Stelle mit dem Speed Layer verknüpft. Die Verfügbarkeit der Rohdaten macht es möglich, durch einen Rollback oder nächtliche Nachberechnung Fehler in den Echtzeitberechnungen zu überspielen.

Als Datenquelle wird für dieses Beispielprojekt Twitter genutzt. Die Daten können von dort aus über die Twitterapi abgerufen werden. Eine Streaming-API ermöglicht es uns, die Daten als Stream zu erhalten. Sobald also ein neuer Tweet generiert wird, ist dieser über die Streaming-API verfügbar. Ein einfacher Kafka Producer geschrieben in Python kann diesen Stream lesen und an den Kafka Server übergeben. Dabei kann der Datensatz bereits gefiltert werden. Über die Streaming-API können Filter auf Hashtags, Sprachen und Geozonen gesetzt werden, außerdem extrahieren wir nur relevante Informationen wie den Text. Die Tweets liegen nach der Übertragung zum Kafka Server in einer Queue vor.  Diese kann von einem Consumer abgerufen werden. In unserem Fall verwenden wir Spark Streaming, welche durch eingebaute Kafka-Tools den Kafka Server lesen und in In-Memory Datensätze umwandeln kann. 

Um die Sentimentanalyse durchzuführen, nutzen wir NLTK Vader. Vader bietet ein Wörterbuch in welchem jedem Wort eine Stimmungswertung zugewiesen wurde. Diese sagt aus, ob das Wort eher eine neutrale, positive oder negative Stimmung ausdrückt. Füllwörter werden von der Python Bibliothek herausgefiltert. Übergibt man der Bibliothek einen Text, erhält man ein berechnetes Durchschnittsergebnis.