Masterarbeit von Raphael Fakhir zur Analyse und Design einer Architektur zur Aufbereitung und Visualisierung von Fast-Echtzeitdaten

1. Elasticsearch &
Wiener LinienAnalyse und Design einer Architektur basierend auf Elasticsearch und
Kibana zur Aufbereitung und Visualisierung von Fast-Echtzeit Daten
Raphael Fakhir, MSc

2. Masterarbeit Ziele
– Ein „Big Data“ Thema:
“The simplest definition of Big Data is it doesn’t fit in Excel”
- Stephane Hamel
The Big Data challenge  The 3 Vs: Volume, Velocity & Variety
– Design einer gesamten Architektur zur Auswertung und Visualisierung von Daten.
– Eine praktische Umsetzung (Nicht nur Theorie).
2

3. Die Open Data Suche
– Open Data der Stadt Wien (data.gv.at).
– Unter Kategorie Traffic findet man Information zu den öffentlichen Daten der
Wiener Linien und ein Formular zur Beantragung eines API Keys.
– Der API Key gibt Zugriff zu den Echtzeit Daten der Wiener Linien.
– Diese können mittels HTTP GET Request abgefragt werden:
3

4. ELK-Stack: Elasticsearch, Logstash & Kibana
Der ELK-Stack oder Elastic Stack besteht aus drei Hauptkomponenten:
 Elasticsearch: ist eine Suchmaschine auf Basis von Lucene, welches die Suchergebnisse in einem
NoSQL-Format (JSON) speichert und sie über ein RESTful-Webinterface aus gibt. Er ermöglicht auf
einfache Weise den Betrieb im Rechnerverbund zur Umsetzung von Hochverfügbarkeit und
Lastverteilung.
 Logstash: ist ein Tool zum Sammeln, Verarbeiten und Weiterleiten von Events und Logs an externe
Programme, wie Elasticsearch.
 Kibana: ist ein Browser basiertes Analytics and Search Interface für Elasticsearch, welches
hauptsächlich zur Visualisierung der Eventdaten aus Logstash verwendet wird.
4

5. Praktische Umsetzung
5
– Daten minütlich für ca. 2 Monate Daten sammeln
und speichern
– JSON Daten vereinfachen und linearisieren
– Elasticsearch aufsetzten und Mapping
konfigurieren
– Daten in Elasticsearch importieren
– Daten mittels Kibana auswerten und visualisieren

6. 6

7. Ergebnisse
7
0
5000000
10000000
15000000
20000000
25000000
30000000
35000000
40000000
45000000
-180 -160 -140 -120 -100 -80 -60 -40 -20 0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300 320 340 360 380 400 420 440 460
Count / Delay (s)

8. Ergebnisse
8
0
100 000
200 000
300 000
400 000
500 000
600 000
700 000
800 000
900 000
1 000 000
-180 -160 -140 -120 -100 -80 -60 -40 -20 0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300 320 340 360 380 400 420 440 460
Actual Count / Delay (s) Expected Normal Count / Delay (s)

9. Ergebnisse
9
0
20
40
60
80
100
120
140
160
180
Avg. Delay without 0 and 30 (in Seconds)
Austrian Holiday Period
Weekend

10. Ergebnisse
10
0
20
40
60
80
100
120
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Avg. Delay by Hour of the Day without 0 and 30 (in Seconds)
0
10
20
30
40
50
60
70
80
90
100
Monday Tuesday Wednesday Thursday Friday Saturday Sunday
Avg. Delay by Day of the Week without 0 and 30 (in Seconds)

11. Ergebnisse
11
0
20
40
60
80
100
120
ptTramWLB ptTramVRT ptTram ptBusCity ptBusNight ptMetro
Avg. Delay by categorized by Transportation Type without 0 and 30 (in Seconds)
barrierFree true false
Tram delay in seconds 57.83 109.21

12. 12

13. Fazit
13
Wichtige Erkenntnisse
• Die Analyse, Planung und Implementierung der Applikation konnten sehr gut die Herausforderungen der „3Vs“
wiederspiegeln:
Volume: Speicherplatz in jedem Prozessschritt
Velocity: Effizienter Code sammeln von fast Echtzeitdaten
Variety: Dynamischer Code für unterschiedliche Daten Typen
• Eine durchschnittliche Verspätung von ca. einer Minute deutet auf eine ziemlich gute Zuverlässigkeit, wenn man
bedenkt, dass ein Großteil der Wiener Linien die Gleise mit Autos im Straßenverkehr teilt.
• Ohne Vorkenntnisse zu den Daten und wenig Know-How zu den Tools  Aussagekräftige Auswertung
Vorteile für die Wiener Linien.
• Anpassung der Linien Fahrpläne mittels Machine Learning, in Abhängigkeit der Saison
• Erkennung von Verkehrsbottelnecks  Präventive Maßnahmen  Effiziente Zuteilung der Ressourcen

14. Thanks for listening
Raphael Fakhir, MSc