TwitterGeoStream

Twitter Geo Stream

Aktuell werden pro Tag weltweit ca. 500 Millionen Tweets mit dem offenen, sozialen Kurznachrichtendienst Twitter versendet [vgl. InternetLiveStats2016]; das entspricht ca. 6000 Tweets pro Sekunde. Obgleich jeder Tweet nur aus bis zu 140 Zeichen besteht sind diese mit zahlreichen zusätzlichen Meta-Informationen angereichert. Insbesondere der Zeitstempel sowie die geografischen Informationen über den Nutzer zum Zeitpunkt des Versandes sind wertvolle Informationen und bieten Ansätze für zahlreiche Analysen.

Motivation

Im Rahmen des Forschungsschwerpunktes nextPlace der Hochschule Ostwestfalen-Lippe haben die Autoren eine Web-Applikation zur Analyse und Visualisierung von georeferenzierten Tweets prototypisch implementiert um insbesondere technische Gegebenheiten bei der Analyse von Twitter-Tweets herauszuarbeiten: Die zu verarbeitenden Daten sind zahlreich (engl. volume) und werden kontinuierlich als Strom (engl. stream) in Echtzeit zur Verfügung gestellt. Twitter-Daten erfüllen somit teilweise Anforderungen an gängige Definitionen von Big-Data [vgl. z.B. Samuel2015].

Der Fokus bei der Entwicklung des Prototyps liegt entsprechend bei der Verarbeitung von Echtzeitdaten im Datenstrom mit entsprechender hoher Verarbeitungsgeschwindigkeit und geeigneter Kommunikationsmuster in einem verteilten System.

Verwandte Arbeiten

Es gibt diverse Web-Seiten welche sich mit der Analyse und Visualisierung von Twitter-Daten beschäftigen. Beispielsweise wird in [OneMilliontweetMap2016] eine Karte über georeferenzierten Tweets in Echtzeit angezeigt.  In [NCStateUniversity2016] werden Tweets mit einem gegebenen Schlüsselwort analysiert und die vermutete Gefühlsstimmung der Nutzer klassifiziert und entsprechend visualisiert.

Wissenschaftliche Diskussionen um technische Herausforderungen bei der Verarbeitung von Twitter-Tweets sind u.a. in [Kulkarni2015; Feng2015] beschrieben.

In [Amazon2016] wird eine ähnliche prototypische Implementierung wie die folgende vorgestellt.

Demo

Ein Prototyp der dynamischen Twitter-Karte kann hier ausprobiert werden.

Software-Architektur

Die prototypische Anwendung Twitter Geo Stream ist eine Web-Applikation, bestehend aus einem Java-Script-Client und einem Java-Server, welche mit diversen Open-Source-Komponenten angereichert ist. Die konzeptionelle Architektur ist in Abbildung 1 skizziert.

Die Server-Applikation liest Daten aus der Twitter Stream-API [Twitter2016] aus und führt verschiedene Arbeitsschritte mit den Tweet-Daten durch. Die Client-Applikation stellt das Ergebnis auf einer 3D-Karte mit der Web-Bibliothek Cesium [Cesium2016] dar.

Abbildung 1: konzeptionelle Architektur

Abbildung 1: konzeptionelle Architektur

Als wesentliche nicht-funktionale Anforderung für die Web-Applikation ist definiert, dass jeder Twitter-Tweet nur genau 140 Sekunden für die Verarbeitung sowie Visualisierung verfügbar ist. Damit soll zum einen der theoretisch stetig wachsenden Datenmenge begegnet werden und zum anderen soll der Fokus nur auf dem jeweiligen aktuellen Ausschnitt der Daten liegen. Weiterhin werden ausschließlich georeferenzierte Tweets in deutscher oder englischer Sprache berücksichtigt.

Der Prototyp bietet dem Nutzer dazu vier verschiedene Funktionalitäten: Tweet-Bubbles, Tweet-Connections, Tag-Cloud und Tag-Cluster. Wesentlich für die Bereitstellung dieser Funktionalitäten ist eine adäquate Kommunikation der einzelnen Komponenten innerhalb des verteilten Systems.

Kommunikation im verteilten System

Abbildung 2 zeigt das UML-Sequenzdiagramm der Kommunikation in dem verteilten System mit den Akteuren Client-Browser (Präsentation), Server-Applikation (Anwendung) und Twitter-API (Daten).

Der Browser führt eine Vermittlungsanfrage (engl. handshake) via HTTP mit der Serveranwendung durch (1) um dann auf das TC-Protokoll für Web-Sockets zu wechseln. Sofern dies der erste Client ist, welcher sich mit der Server-Anwendung verbindet, wird eine HTTP-Verbindung zwischen dem Server und der Twitter-API etabliert (2). Diese Verbindung bleibt so lange bestehen bis der Server diese aktiv abbaut (9). Bei bestehender Verbindung wird in der Server-Anwendung ein separater Thread geöffnet welcher von diesem Zeitpunkt die ankommenden Daten auf dem Datenstrom kontinuierlich verarbeitet.

Abbildung 2: Sequenzdiagramm der Kommunikation im verteilten System

Abbildung 2: Sequenzdiagramm der Kommunikation im verteilten System

Entsprechend dem Strategie-Entwurfsmuster [Gamma1995] sind für die Server-seitige Verarbeitung (4a, 4b) jeweils dedizierte Algorithmen und Datenstrukturen für die einzelnen Funktionalitäten (Tweet-Bubbles, Tag-Cloud, Tag-Cluster) implementiert. Nach einer jeden Verarbeitung (engl. process) wird ein Tweet über die jeweils bestehende Web-Socket-Verbindung an alle angemeldeten Clients (5a, 5b)  übertragen, dort ebenfalls verarbeitet (6a, 6b) und auf der Karte dargestellt. Beim Beenden der Client-Anwendung wird die Web-Socket-Verbindung zu dem Server mit einer dedizierten Nachricht beendet (7). Ist keine Verbindung zu mindestens einem Client aktiv, wird die Verbindung zur Twitter-API abgebaut (9).

Funktionalitäten

Die genannte Verarbeitung sowohl im Client als auch im Server wird im Folgenden für die einzelnen Funktionalitäten beschrieben.

Tweet-Bubbles

Jeder in der Applikation verarbeitete Tweet wird an alle angemeldeten Browser-Clients übertragen. Dazu werden die relevanten Tweet-Daten Id, Text, Nutzername und Position (als Längen und Breitengrad) aus dem JSON-Format der Twitter-API extrahiert und in das Cesium-Spezifische CZML-Format transformiert.

In CZML kann zu den Twitter-Daten auch zeitliches Verhalten modelliert werden. Dazu definieren die Autoren zum einen Tweets ohne Relevanz (keine Schlagworte, kein Referenzieren anderer Nutzer) und zum anderen mit Relevanz (Schlagworte und/oder Referenzen auf Nutzer sind gegeben). Bei letzteren wird die Relevanz durch die Anzahl der Vorkommen in den aktuell vorhandenen Daten entsprechend gewichtet. Die Information dazu wird durch die Funktionalität Tag-Cloud bereitgestellt (s.u.). Nach der Metapher von Seifenblasen (engl. bubbles) steigen die Tweets als Punkte an der georeferenzierten Position auf der Karte auf. Mit zunehmender Dauer bzw. Höhe verfärben sich die Punkte von grün nach rot. Je relevanter der Tweet, desto langsamer die Steiggeschwindigkeit und desto größer der Punktdurchmesser.

Abbildung 3: Bildschirmfoto Tweet-Bubbles

Abbildung 3: Bildschirmfoto Tweet-Bubbles

Die Visualisierung findet hier nahe Echtzeit statt. Wird ein Tweet von einem Nutzer bereitgestellt, z.B. über die Twitter-Web-Seite, dann erscheint dieser innerhalb kürzester Zeit t (mehrere Messungen mit verschiedenen Nutzern: t < 2 Sek.) auf der Karte der Anwendung.

Tweet-Connections

Jeder relevante Tweet auf der Karte prüft ob es einen anderen Tweet gibt, welcher gleiche Relevanz-Informationen enthält. Gibt es einen passenden, wird genau eine farbige Verbindungslinie zwischen diesen beiden Tweets dargestellt um die inhaltliche Zusammengehörigkeit hervorzuheben. Verbindungen bezogen auf Schlagworte zeigen eine grüne, bezogen auf den Nutzer eine blaue Linie.

Da jeder Client eine zustandslose Verbindung zu dem Server hält, muss die Prüfung auf beziehbare Tweets im Web-Browser des Clients durchgeführt werden. Die Prüfung ist in Java-Script implementiert und eine einfache Iteration über alle aktuell sichtbaren Tweets. Die Suche hat entsprechend eine obere Schranke von O(n) und ist bei mehreren Tausend sichtbaren Elementen suboptimal.

Abbildung 4: Bildschirmfoto Tweet-Connections

Abbildung 4: Bildschirmfoto Tweet-Connections

Tag-Cloud

Die empfangen Tweets der Twitter-Stream-API mit Relevanz werden zusätzlich in der Web-Anwendung verarbeitet. Die mit dem Doppelkreuz markierten Schlagworte (engl. hash tags) aus den Tweets werden extrahiert und in einen Suchindex für eine Volltextsuche  überführt. Der Index ist mittels der Open-Source-Komponente Apache Lucene [Lucene2016] umgesetzt. Für die drei Regionen Deutschland, UK und USA wird jeweils ein eigener Index etabliert und passende Schlagworte werden entsprechend ihrer Region gespeichert. Durch eine Abfrage an den Index kann die Anzahl sowie eine Reihenfolge über die Häufigkeit der Vorkommen gebildet werden. Durch eine zusätzliche Zeitsteuerung werden die Schlagworte periodisch mittels der Open-Source-Komponente Kumo [Kumo2016] in eine Grafik einer Schlagwortwolke (engl. tag cloud) überführt. Die Anzahl der Vorkommen pro Schlagwort bestimmt dabei die Gewichtung und Größe der verwendeten Schriftart und –stärke für die Abbildung des Schlagwortes. Die Anordnung der Worte in der Grafik ist zufällig. Abbildung 5 zeigt die Grafiken für die Schlagwortwolke aller Tweets der letzten 140 Sekunden welche in Großbritannien bzw. Deutschland von Twitter-Nutzern versendet wurden. Dieses Bild wird in CZML überführt und auf Anfrage an den Web-Browser ausgeliefert und als texturiertes Polygon in den entsprechenden Ländergrenzen dargestellt.

Abbildung 5: Bildschirmfoto Tag-Cloud

Abbildung 5: Bildschirmfoto Tag-Cloud

Im Gegensatz zur Client-seitigen Verarbeitung bei den oben skizzierten Tag-Connections ist die Verarbeitung bei der Tag-Cloud deutlich optimiert, u.a. da die Datenstruktur des Index einen wahlfreien Zugriff bietet. Insgesamt gib es hier allerdings weiterhin den Nachteil, dass der Index programmatisch periodisch angepasst werden muss, denn jedes Schlagwort muss entsprechend der nichtfunktionalen Anforderungen nach 140 Sekunden wieder aus dem Index entfernt werden.

Tag-Cluster

Ist die Kommunikation zwischen den beteiligten Anwendungen des verteilten Systems Stream-orientiert, so ist es die oben skizzierte Verarbeitung der Funktionen nur bedingt. Grundsätzlich unterscheidet sich die Verarbeitung von (Echtzeit-) Datenströmen in einigen Merkmalen von der Verarbeitung bei herkömmlichen Daten [Lui2014]; u.a. müssen permanent neue Daten berücksichtigt werden und veraltete Daten vernachlässigt werden. Typische skalierbare Stapelverarbeitung von Big-Data etwa mittels MapReduce [Dean2008] ist für diese Anforderungen nur bedingt geeignet. Vielmehr etablieren sich daher Software-Komponenten welche den Paradigmen-Wechsel von Stapel- zu Stream-Verarbeitung für Big-Data propagieren.

Für die Funktionalität Tag-Cluster wird eine derartige Verarbeitung mit einem iterativen Algorithmus prototypisch (auf einem Knoten) umgesetzt. Hierbei werden bezogen auf die Tweets geografische Häufungen (engl. cluster) gebildet und diese auf der Karte visualisiert. Dazu wird kontinuierlich ein k-means-Algorithmus [vgl. Kanungo2002] auf den aktuell im Zeitfenster vorhandenen Tweets von 140 Sekunden angewandt. Für die Umsetzung wird die Open-Source-Komponente Apache Spark [Meng2015] verwendet. Diese bietet eine dedizierte Implementierung für die Verarbeitung von Datenströmen. Der Nutzer kann in der Weboberfläche die Anzahl k der zu bestimmenden Cluster einstellen. Die Berechnung erfolgt dynamisch auf den Datenstrom, lediglich die Visualisierung erfolgt periodisch (engl. polling) und wird von dem Client an den Server angefragt. Ein Cluster enthält einen Mittelpunkt sowie die georeferenzierten Tweets die ihm zugrunde liegen. Diese Koordinaten werden zu einem geometrischen Polygon verbunden und wie in Abbildung 6 gezeigt auf der Karte dargestellt.

Abbildung 6: Tag-Cluster

Abbildung 6: Tag-Cluster

Diese Polygone zeigen geografische Flächen, welche sich teilweise deutlich von den realen Landgrenzen unterscheiden. Diese nun neu entstanden geografischen Flächen können beispielweise für weitere Analysen herangezogen werden.

Literatur

[Amazon2016]; https://blogs.aws.amazon.com/bigdata/post/Tx7CTJ1GEWSI57/Visualizing-Real-time-Geotagged-Data-with-Amazon-Kinesis; Amazon Big Data Blog; Visualizing Real-time, Geotagged Data with Amazon Kinesis; Zugriffsdatum 11.07.2016

[Cesium2016]; https://cesiumjs.org; An open-source JavaScript library for world-class 3D globes and maps; Zugriffsdatum: 12.07.2016

[Dean2008]; Dean et. al.; 2008; MapReduce: simplified data processing on large clusters; Communications of the ACM; Volume 51 Issue 1, January 2008

[Feng2015]; Feng et. al.; 2015; STREAMCUBE: Hierachical spatio-temporal hashtag clustering for event exploration over the Twitter stream; 2015 IEEE 31st International Conference on Data Engineering

[Gamma1995]; Gamma et. al.; 1995;  Design Patterns. Elements of Reusable Object-Oriented Software;  Addison-Wesley

[InternetLiveStats2016]; http://www.internetlivestats.com/twitter-statistics/; Twitter Usage Statistics; Zugriffsdatum 11.07.2016

[Lucene2016]; https://lucene.apache.org/core/; Ultra-Fast Search Library; Zugriffsdatum 06.07.2016

[Kanungo2002]; Kanungo et. al.; 2002; An efficient k-means clustering algorithm: analysis and implementation; IEEE Transactions on Pattern Analysis and Machine Intelligence

[Kulkarni2015]; Kulkarni et. al.; 2015; Twitter Heron: Stream Processing at Scale; Proceedings of the 2015 ACM SIGMOD International Conference on Management of Data

[Kumo2016]; https://github.com/kennycason/kumo; Kumo – Java Word Cloud; Zugriffsdatum 08.07.2016

[Lui2014]; Lui et. al.; 2016; Survey of Real-time Processing Systems for Big Data; IDEA’S 14; Proceedings of the 18th International Database Engineering & Applications Symposium; Pages 356 – 361

[Meng2016]; Meng et. al.; 2016; MLib: machine learning in apache spark; The Journal of Machine Learning Research, Volume 17, Issue 1, January 2016, Pages 1235 – 1241

[NCStateUniversity2016]; https://www.csc.ncsu.edu/faculty/healey/tweet_viz/tweet_app/; Sentiment Viz; Zugriffsdatum 12.07.2016

[OneMillionTweetMap2016]; http://onemilliontweetmap.com/; The one million tweet map; Zugriffsdatum 11.07.2016

[Samuel2015]; Samuel et. al.; 2015; A survey on Big Data and it’s research challenges; ARPN Journal of Engineering and Applied Sciences; Vol 10. No. 8 May 2015

[Twitter2016]; https://dev.twitter.com/streaming/overview; Twitter Streaming APIs; Zugriffsdatum 11.07.2016

Kommentar hinterlassen