Nachdem wir nun das große Ganze unserer Big Data Twitter Demo erläutert haben und die auch aufgebaut haben, können wir endlich mit der Demo prahlen! 

01 Big Picture

Dabei unterscheiden wir zwei Stadien: die letzten Vorbereitungen (Stadium zwischen Aufbau und Demo) und Show Time.

  1. Letzte Vorbereitungen...
    1. Daten sammeln
    2. Hive-Analyse starten
    3. Refresh Data in PowerPivot
  2. Show Time
    1. Echtzeit-Dashboard
    2. SQL Datenbank
    3. Windows Azure Blob Storage
    4. Big Data: Analyse mit Hive auf HDInsight
    5. Zusammenführen der Daten in PowerPivot
    6. Visualisierung in PowerView
                 

1. Letzte Vorbereitungen...

Bevor wir die einzelnen Demo-Komponenten zeigen, müssen einige Dinge vorbereitet werden: Zum einen muss ein Basissatz an Daten stehen, d.h. viele viele Tweets über mehrere Tage sammeln; zum anderen dauern einige Komponenten der Demo zu lange, um diese live zu zeigen, wie zum Beispiel das Analysieren der Daten mit Hilfe von Hive und das Aktualisieren der Daten in PowerPivot.

1.1. Daten sammeln

Wir loggen uns per Remote in die VM (<virtual_machine>.cloudapp.net:51599) ein und öffnen die Visual Studio Solution TwitterCepSolution.sln.

08 twitter

Wie zuvor beim Aufbau ignorieren wir die Dialogfenster bezüglich TFS Version Control und Source Control.

08 twitter 02

In der Visual Studio Solution können wir das Projekt dann starten:

08 twitter 03

Beim Starten wird der Browser in der VM automatisch geöffnet, woraufhin wir unser Echtzeit-Dashboard über Default.html öffnen:

08 twitter 04

08 twitter 05

Die Rohdaten von Twitter, die im Windows Azure Blob Storage gespeichert werden, kann man dann im CloudXplorer einsehen:

08 twitter 06

1.2. Hive-Analyse starten

In dem Demo-Aufbau haben wir nur Text-Dateien in dem zuvor erstellten Ordner C:\hivescripts rüberkopiert. Diese Textdateien werden in der Hadoop-Command-Prompt ausgeführt und sind in der Sprache HiveQL geschrieben – welche SQL sehr ähnelt.

Dafür loggen wir uns zunächst auch per Remote in den HDInsight-Cluster ein und rufen die Hadoop Command Line auf:

04 hdinsight 09

In der Hadoop Command Line wollen wir in den Hive-Modus gehen. Dafür geben wir folgenden Befehl ein:

cd %hive_home%/bin
Zum Test geben wir noch ein:
hive
show tables;

Hier ist zu bemerken, dass zum jetzigen Zeitpunkt eine Remote Verbindung für maximal 7 Tage eingerichtet werden kann. Wird eine Remote Verbindung für mehr als eine Woche benötigt, wird einfach eine neue Remote Verbindung für weitere 7 Tage eingerichtet. Beim Neu-Einrichten kann es passieren, dass jegliche Hadoop-Services ausgeschaltet wurden, sodass zum Beispiele triviale Befehle wie show tables nur Fehlermeldungen produzieren. Diese Hadoop-Services müssen dann manuell wieder gestartet werden. Dafür geht man auf das Startmenü in der VM und tippt mmc.exe.

Nun gehen wir aus dem Hive-Modus mit dem exit-Befehl raus.

Daraufhin lassen wir die vorgefertigten Skripte laufen:

   1:  hive -f "C:\hivescripts\1_create-tweet-input.txt"
   2:  hive -f "C:\hivescripts\2_create-tweet-details.txt"
   3:  hive -f "C:\hivescripts\3_insert-tweet-details.txt"
   4:  hive -f "C:\hivescripts\4_create-others.txt"

Mit dem ersten Skript wird eine externe Hive-Tabelle namens tweet_Input erstellt; mit einer externen Hive-Tabelle ist quasi ein Pointer zu all den Tweets, die im Azure Blob Storage unter /twitter gespeichert sind. tweet_input wird per alter table verändert, sodass Partitionen für jeden einzelnen Tag bestehen. Ab Zeile 4 müssen die Locations (hier: /twitter/2013-11-04) entsprechend angepasst werden, wo die Twitter-Rohdaten im Azure Blob Storage gespeichert sind.

1_create-tweet-input.txt
   1:  -- DROP TABLE tweet_input;
   2:  CREATE EXTERNAL TABLE tweet_input (tweet string) PARTITIONED BY (date string);
   3:   
   4:  ALTER TABLE tweet_input ADD PARTITION (date = '2013-11-04') LOCATION '/twitter/2013-11-04';
   5:  ALTER TABLE tweet_input ADD PARTITION (date = '2013-11-05') LOCATION '/twitter/2013-11-05';
 

Im zweiten Skript wird eine Hive-Tabelle namens tweet_details erstellt, um alle Informationen zu jedem Tweet in einer einheitlichen Tabelle zu erfassen. Hierbei wird lediglich eine leere Tabelle mit vordefinierten Attributen erstellt und als Sequencefile gespeichert.

2_create-tweet-details.txt

   1:  set hive.exec.dynamic.partition=true;
   2:  set hive.exec.dynamic.partition.mode=nonstrict;
   3:   
   4:  drop table tweet_details;
   5:  create table tweet_details
   6:  (
   7:      id bigint,
   8:      […]
  37:  )
  38:  partitioned by (partition_key string)
  39:  STORED AS SEQUENCEFILE;

Im dritten Skript wird daraufhin tweet_details mit Inhalt von den Twitter-Rohdaten (spezifiziert durch die externe Tabelle tweet_input) gefüllt.

3_insert-tweet-details.txt

   1:  set hive.exec.dynamic.partition=true;
   2:  set hive.exec.dynamic.partition.mode=nonstrict;
   3:   
   4:  insert overwrite table tweet_details
   5:  partition (partition_key)
   6:  select […]
  62:  from tweet_input
  63:  where (length(tweet) > 500);

Im letzten Skript (4_create-others.txt) werden noch weitere Hive-Tabellen in der gleichen Methodik wie tweet_details leer erstellt und daraufhin mit Inhalten diesmal aus tweet_details gefüllt. Wir erhalten die folgenden Hive-Tabellen:

tweet_coordinates Geo-Koordinaten
tweet_hashtags Twitter-Hashtags
tweet_user_mentions Twitter-Konversationen entstanden durch den Tweet
tweeter Informationen zu dem, der tweetet

All diese Hive-Tabellen kann man ebenfalls im CloudXplorer einsehen:

08 hive 08

1.3. Refresh Data in PowerPivot

Vor der eigentlichen Demo aktualisieren wir die Daten, die in Excel PowerPivot von der SQL Azure Datenbank und dem Windows Azure Blob Storage zusammengeführt werden. Dies tuen wir vor der Demo, da das Aktualiseren von vielen Hunderttausenden von Daten eine Weile dauern könnte.

Dafür klicken wir auf Refresh All in PowerPivot unserer vorbereiteten Excel-Tabelle:

09 excel 02

09 excel 05

2. Show Time

Now, it’s show time! Die Demo kann gezeigt werden!

Und was ist die ganze Story dahinter? Nehmen wir an, wir sind Marketeers und starten eine Marketing-Kampagne zu einem bestimmten Thema. Natürlich möchten wir gern erfahren, wie unsere Kampagne in der Außenwelt ankommt – und nein, nicht die üblichen zig Monate auf einen Report warten, sondern jetzt – in Echtzeit, um vor Begeisterung nur Luftsprünge zu machen oder notfalls noch Damage Control zu leisten. Echtzeit ist DAS Stichwort schlechthin für Twitter: In der Kürze von 140 Zeichen lässt es sich schnell herauslesen, wie die Stimmung zu gegebenen Themen ist.

Anhand unserer Demo können wir live zusehen, wie vorbestimmte Themen in der Twitter-Welt ankommen (wie viele Tweets und was für eine Stimmung), und innerhalb kürzester Zeit die Tweets je nach Belieben analysieren und einen nachhaltigen Report mit allen möglichen Daten wie auch einleuchtenden Visualisierungen produzieren.

Wie das gemacht wird, kann man anhand des Big Pictures der Demo von oben zeigen. Dabei kann man durchaus hervorheben, dass die Demo ausschließlich auf Windows Azure (außer Excel) aufbaut. Dafür eignet sich das Management-Portal auf Windows Azure:

10 demo 00

2.1. Echtzeit-Dashboard

In dem ersten Schritt der Demo knöpfen wir uns die in Azure aufgestellte VM vor, die sich um das Verwalten der Daten (also dem ersten Block des Big Data Workflows) kümmert:

10 demo 01 b

Dabei wird eigentlich der allseits bekannte ETL-Prozess (Extract, Transform, Load) umgesetzt: Twitter-Daten werden in Echtzeit extrahiert, in eine bestimmte Datenstruktur transformiert und so in eine SQL Azure Datenbank geladen, während die Rohdaten in den Windows Azure Blob Storage geladen werden. Darüber hinaus erhalten wir Insights über die Tweets anhand eines Echtzeit-Dashboard in der VM. Hier konzentrieren wir uns auf die Extrahierung der Tweets und die Erkenntnisse, die wir aus dem Dashboard ziehen können.

Das Extrahieren der Echtzeit-Twitter-Daten läuft über ein Visual Studio Projekt in der VM, welches auf StreamInsight basiert. StreamInsight ist eine Applikation, die die Verarbeitung von komplexen Events ermöglicht; in anderen Worten, sehr viele Events können sehr schnell (quasi in Echtzeit) bearbeitet werden. Solche Event Streams, wo StreamInsight unglaublich nützlich ist, findet man typischerweise in der Produktion, im Aktienhandel, Web-Controlling oder in der Betriebsanalyse.

In einer Konfigurierungsdatei (app.config) im Visual Studio Projekt legen wir fest, welche Keywords für uns von Interesse sind und über die wir Tweets sammeln und deren Stimmung erfahren wollen, z.B. HDInsight oder TechNetConf. Anhand der Keywords wird eine spezifizierte Anfrage an die Twitter Streaming API gestellt. Der Twitter-Streaming Dienst gibt somit alle Tweets her, die jetzt just in diesem Moment weltweit zu den gegebenen Themen (also Keywords) getweetet werden. Hierbei müssen die Keywords nicht unbedingt als Hashtag in dem Tweet vorkommen, sondern können auch einfach erwähnt werden. Zum Beispiel umfasst das Keyword XBox viele weitere Hashtags, wie #xboxone, #xbox360, etc.

Sobald die “gefilterten” Tweets per StreamInsight von der Twitter API gelesen werden, werden diese im Echtzeit-Dashboard gezeigt. Im Dashboard gibt es drei Bereiche:

  1. Das blaue Fenster ist eine grafische Darstellung über den Grad der Aufmerksamkeit und der Popularität der vorgegebenen Themen. Im Detail besagt die orangene Linie (total tweets) die gesamte Anzahl der Tweets zu den vorgegebenen Themen zu dem vorgegeben Zeitpunkt, und die gelbe Linie (avg sentiment) die durchschnittliche Stimmung gegenüber den Keywords.
  2. Das grüne Fenster zeigt die eingehenden Tweets an.
  3. Die lilanen Kachel zeigen die Stimmungsrate und Tweet-Rate zu den vorgegeben Themen an.

10 demo 01

Die Stimmungsanalyse (Sentiment Analysis) läuft über einen Webservice ab, namens Sentiment140. Anhand dieses Services wird die Stimmung in jedem Tweet abgeschätzt und einkategorisiert: positiv (4), neutral (2) oder negativ (0). Der numerische Wert wird dann im blauen Diagrammfenster und den lila-farbenen Kacheln widerspiegelt.

Die extrahierten Tweets werden automatisch gespeichert, aber nicht lokal in der VM, sondern sogleich an Datenspeicher weitergeleitet, hier: Windows Azure Blob Storage und SQL Azure. Die beiden Speicher sind ebenfalls in der Konfigurationsdatei im Visual Studio Projekt definiert.

2.2. SQL Datenbank

Die eingegangenen Tweets werden per StreamInsight in einer vorkonfigurierten Datenstruktur in der SQL Azure Datenbank gespeichert.

10 demo 02 b

Hierbei wurde die SQL Azure Datenbank ganz im Stile von PaaS (Platform as a Service) schnell auf Windows Azure aufgebaut. In der Demo können wir auf das Verwaltungsportal der SQL-Datenbank zugreifen:

10 demo 02

10 demo 03

Die SQL-Datenbank kann man auch gleich über die folgende Internetadresse erreichen, die auch in der Setup-Textdatei vom Aufbau-Beitrag enthalten ist:

https://<sql_server>.database.windows.net/#$database=<sql_database_name>

Sobald wir uns in der SQL-Datenbank im Browser aufhalten, führen wir folgende Abfrage aus:

SELECT * FROM TweetInfo

Denn die extrahierten Tweets wurden als Tabelle namens TweetInfo in der Datenbank gespeichert. Anhand dieser Abfrage erhält man einen Einblick in das verwendete Schema:

TweetID, CreatedAt, Sentiment, Topic

Im nächsten Schritt werden wir sehen, wie viel von den Twitter-Rohdaten rausgefiltert wurde.

10 demo 04

2.3. Windows Azure Blob Storage

ALLES, was die Twitter API hergibt, also die Twitter-Rohdaten werden im Windows Azure Blob Storage gespeichert. Mit dem Blob Storage auf Azure können Daten redundant und preisgünstig gespeichert werden. Der Blob Storage dient auch als Basis für das herkömmliche HDFS (Hadoop Distributed File System) für typische Hadoop-Problematiken.

Der Blob Storage ist essentiell, wenn wir mit HDInsight arbeiten möchten. Die Idee hierbei ist, dass der Speicher separat von der Datenanalyse ist. Das birgt einige Vorteile, vor allem, dass man sich bei der Analyse so austoben kann, wie man will, ohne die Original-Daten zu verändern oder gar verderben, und dass man jederzeit den HDInsight-Cluster herunterfahren könnte ohne die Daten zu verlieren. Rechenleistung ist nämlich das, was am teuersten ist und leicht zu skalieren ist. So sind die Daten auf dem Blob Storage jederzeit vom HDInsight-Cluster lesbar.10 demo 05 b

Um den Azure Blob Storage und dessen Inhalte zu zeigen, eignet sich der CloudXplorer, der bereits auf der Demo-Maschine installiert sein sollte, extrem gut. So sieht man, dass jedes Tweet als Textdatei gespeichert ist, die auch schön in Unterordner entsprechend ihres Erstellungsdatum sortiert sind.

10 demo 05

Ein Tweet können wir uns natürlich genauer anschauen, um zu sehen, was eine Twitter-Rohdatei alles beinhaltet. So sieht man, dass es sich um eine JSON-Datei handelt. Zwar erkennt man eine gewisse Semi-Struktur, dennoch der Tweet-Text selber weist keinerlei Struktur vor, und viele Felder beinhalten ein NULL.

10 demo 06

2.4. Big Data: Analyse mit Hive auf HDInsight

Jetzt kommt der eigentliche Spaß – das Analysieren der Daten. Im HDInsight-Cluster werden Pointers zu den Daten im Azure Blob Storage gebaut, aus denen Hive-Tabellen erstellt werden. HiveQL ist eine SQL-ähnliche Sprache, also eine einfachere Syntax, um Hadoop-Probleme zu lösen und deswegen auch mit unstrukturierten Daten zurechtkommen. Die Hive-Tabellen sind demnach ebenfalls strukturiert und aus den unstrukturierten Rohdaten geschöpft.

10 demo 07 b

Die Hive-Tabellen sind bereits in den Demo-Vorbereitungen erstellt, um Zeit während der Demo zu sparen. Als Erinnerung, wir haben 5 Hive-Tabellen im Voraus erstellt: tweet_details, tweet_coordinates, tweet_hashtags, tweet_user_mentions und tweeter. Diese kann man im CloudXplorer auch einsehen:

10 demo 09a

Eine Testdatei ist dennoch vorhanden, um ein Gefühl für das Arbeiten mit Hive zu vermitteln: Alles über die Command Line.

Mit dem Befehl hive –f werden Textdateien in SQL-Art verarbeitet:

hive -f "C:\hivescripts\5_test.txt"

10 demo 08

10 demo 09

Mit Hilfe der Hive-Tabelle tweet_details zeigen wir an, wie viele Tweets pro Tag gesammelt wurden. Von den restlichen Hive-Tabellen werden die ersten 10 Einträge angezeigt.

tweet_Details

tweet_details

tweet_hashtags 10 demo 09c

tweet_user_mentions 10 demo 09d

tweeter 10 demo 09e

2.5. Zusammenführen der Daten in PowerPivot

Das ist der eigentlich wichtigste Bestandteil des Big Data Workflows: Das ist der Part, wo wir unsere Erkenntnisse machen können, was gut gelaufen ist, und aus denen wir lernen und verbessern können; wir können weitere Entscheidungen treffen.

10 demo 10a

Hier werden zunächst die beiden Datenquellen (SQL Azure Datenbank und die Hive-Tabellen im HDInsight-Cluster) in PowerPivot (Excel) auf der Demo-Maschine zusammengeführt. PowerPivot dient als schnelle, In-Memory Kopie der Daten. Mit Hilfe eines Hive ODBC Treibers steht die Verbindung zwischen PowerPivot und den Hive-Tabellen, sodass die Hive-Tabellen in PowerPivot implementiert werden können. Ähnlich sieht es mit SQL Azure aus.

Was man in dem Mash-Up-Part der Demo zeigen kann, sind drei Komponenten: die Verbindungen von PowerPivot zu den Datenquellen, die Daten und die Beziehungen zwischen den einzelnen Datentabellen.

Bestehende Verbindungen

10 demo 10b

10 demo 11

10 demo 12

Datentabellen

10 demo 13

Datenrelationen

10 demo 14

2.6. Visualisierung in PowerView

Mit PowerView sind einige richtig tolle Visualisierungen möglich. Man erhält Einblicke darin, zu welcher Tageszeit die meisten Tweets zu bestimmten Themen ankommen, wer die Top-Tweeter sind. Toll sind auch die Interaktionen, wenn man zum Beispiel den bigdata Balken anklickt; man sieht daraufhin nur die relevanten Diagramme angepasst zum Thema Big Data.

10 demo 15

Dank des Twitter-Features Geolocation ist es möglich, die Standorte der Tweets in PowerView zu visualisieren.

10 demo 16

Extrem cool ist die Möglichkeit, die Stimmung über Zeit zu zeigen. So sieht man, wie XBox die anderen Themen im Grad der Aufmerksamkeit komplett abhängt, aber auch über die Tage immer mehr an Aufmerksamkeit gewonnen hat.

10 demo 17

Fertig! :)

Bitte Feedback geben – hat es geklappt? Welche Themen habt ihr ausgewählt? Was fehlte euch?