Echtzeitanalysen & Streamingarchitekturen

Am Beispiel von Twitterstream-Analysen mit Kafka, Spark & Elasticsearch

Im Wandel der Digitalisierung und der Erweiterung der digitalen Forschungsfelder durch erhöhte Rechenleistung, Vereinfachung von Machine Learning Prozessen und vielen weiteren technologischen Fortschritten, haben sich die letzten Jahre eine Vielzahl neuer Möglichkeiten und Herausforderungen für Unternehmen eröffnet, welche nicht selten mit Datenmanagement, Volumenskalierung und Geschwindigkeit zu tun haben. Wie man diese Herausforderungen lösen kann, zeigen wir im Folgenden anhand einiger Streaming-Konzepte und der Umsetzung einer Echtzeit-Sentiment-Analyse von Twitterstream-Daten mit Apache Kafka, Apache Spark und Elasticsearch.

Notwendigkeit von Echtzeitanalysen

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.

Bild: Lambda-Architektur

Nathan Marz stellte 2011 das Konzept derLambda-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.

Bild: Lambda-Architektur mit vereintem Serving Layer

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.

Bild: Kappa-Architektur

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.

Toolpalette

Die Anzahl der Tools, welche den Aspekt der schnellen Verarbeitung und Präsentation von Daten behandeln, ist in den letzten Jahren stark angestiegen. Besonders die Apache Software Foundation hat hier eine große Auswahl an Open Source Technologien bereitgestellt. 

Hier eine kleine Übersicht an möglichen Tools: 

Log Stores 

Batch Layer 

Speed Layer 

Serving Layer 

Apache Kafka 

Hadoop MapReduce 

Apache Storm 

ElephantDB 

Apache Pulsar 

Apache Spark 

Apache Spark Streaming 

Apache Hbase 

AWS Kinesis Firehouse 

Apache Hive 

Apache Samza 

Apache Druid 

Azure Eventhub 

Apache Pig 

Apache S4 

Elasticsearch 

Chronicle Queue 

Spork 

Spring XD 

Voldemort 

Welche Auswahl an Tools die Richtige ist, hängt stark vom Kontext ab. Auch sollte sich nicht auf die Lambda- oder Kappa-Architektur versteift werden, eine Mischung oder Erweiterung mit anderen Konzepten/Architekturen kann zu einem sinnvollen Ergebnis führen.

Beispielarchitektur zur Echtzeit-Sentimentanalyse von Twitterstream-Daten

Das Beispiel der Sentimentanalyse von Tweets aus einemTwitterstream ermöglicht es uns das Konzept und einige Tools zu veranschaulichen. 

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.

Für jeden Tweet, welcher im Spark Consumer verarbeitet wird, wird nun mit Hilfe von Vader der Durchschnittswert der Stimmung errechnet und an den Datensatz angehängt. Das Ergebnis kann nun weitergesendet werden und der nächste Datensatz wird vom Spark Consumer aufgerufen.

Um die Daten zu visualisieren, haben wir uns für Elasticsearch entschieden. Zusammen mit Kibana können Visualisierungen und Dashboards erzeugt werden, welche sich in regelmäßigen Abständen von selbst aktualisieren. Das nachträgliche Setzen von Textfiltern und Zeitspanne, sowie das spontane Erstellen neuer Visualisierungen auf den bestehenden Datensatz machen es zu einem flexiblen Tool für dynamische Datenvisualisierung.  

Nachdem der Datensatz also im Spark Consumer verarbeitet wurde, kann er an Elasticsearch weitergesendet werden. Dort wird er durch Kibana in einem aktualisierten Dashboard berücksichtigt.