FLOATING CAR DATA ANALYTICS MIT BIG DATA
FWIE
Dr. David Zastrau – Data Scientist, Sulzer GmbH
Seite 2 │14
Inhaltsverzeichnis
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Big Data oder Smart Data? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Business Intelligence vs. Data Science . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Cloud Computing ermöglicht Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Von RDBMS zu NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Spark und MapReduce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Visualisierung von Big Data Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Showcase: Interaktives Echtzeitstreaming mit Apache Spark und R Shiny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Fazit und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Quellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Seite 3 │14
EinleitungDieses Whitepaper stellt eine Big-Data-Anwendung
vor, die von der Sulzer GmbH entwickelt wurde. Ziel
der Entwicklung war es, in Daten aus einer Echtzeit-
simulation des Straßenverkehrs von Luxemburg mit
verschiedenen Analyseverfahren automatisch
Verkehrsstaus zu erkennen. Für die Anwendung
wurden eine Hadoop-Distribution, sowie weitere Biblio-
theken aus dem Hadoop-Ökosystem auf dem firmen-
eigenen Computer-Cluster installiert.
Nachfolgend werden zunächst einige der Komponen-
ten der Hadoop-Installation näher vorgestellt, sowie
eine generelle Einführung zu Big-Data-Themen wie
NoSQL, Spark und Cloud Computing gegeben.
Big Data oder Smart Data?Der Begriff „Big Data“ hat in den Bereichen Business
Intelligence (BI) und Data Mining in den letzten Jahren
zunehmend an Bedeutung gewonnen. Häufig werden
die „4 Vs“ verwendet, um die Eigenschaften von Big
Data zu beschreiben:
▪ Es werden kontinuierlich große Datenmengen er-
fasst (Volume),
▪ die in Echtzeit verarbeitet werden (Velocity),
▪ teilweise semi- oder unstrukturiert (Variety),
▪ oder verunreinigt/unvollständig (Veracity) sind.
Der Erfolg von Unternehmen wie Google zeigt das Poten-
tial von Big Data, wenn Daten nicht bloß in einem Data
Lake (siehe Abb. 1) akkumuliert, sondern außerdem in-
telligent gefiltert, sortiert und analysiert werden.
Abbildung 1: Der Data Lake sammelt Informationen aus dem Data Warehouse, aber auch aus externen Quellen, wie
zum Beispiel aus Social Media.
Seite 4 │14
Intelligente Datenverarbeitung in Verbindung mit Big
Data ermöglicht neue Anwendungsfälle, die mit her-
kömmlichen Werkzeugen und Methoden nicht um-
setzbar sind. Denn die intelligente Kombination von
Cloud Computing, In-Memory-Technologien und
paralleler Datenverarbeitung ermöglicht die Ska-
lierbarkeit von Anwendungen mit nahezu beliebig
großen Datenvolumen: „Smart Data“ heißt das neue
Schlagwort! Zudem ermöglichen Cloud-Angebote
(z. B. Amazon EC2/S3, Microsoft Azure etc.) und Open-
Source-Frameworks wie Hadoop und Spark flexible
Kostenmodelle bei minimalem Ressourceneinsatz.
Kaum eine Branche bietet so viel Potential für Big
Data wie die Automobilbranche. Fahrt-, Werkstatt-
sowie Händlerdaten, aber auch Daten aus sozialen
Netzwerken und Autoblogs ermöglichen Verbesserun-
gen in den Bereichen Fahrzeugentwicklung, Produk-
tionsplanung, Aftersales, Vertrieb und Marketing [3].
Beispielhaft sind hier unter anderem die vernetzte Mo-
bilität, optimierte Wartungszyklen, die Versorgung
des Fahrers mit situationsrelevanten Informationen
und eine proaktive Kundenbetreuung als Anwen-
dungen zu nennen.
Business Intelligence vs. Data ScienceKlassische Business Intelligence (BI) verfolgt das
Ziel, durch ETL-Prozesse und Datamining nützliche
Zusammenhänge in den Daten eines Unternehmens
zu identifizieren. Data Science wird häufig als Erwei-
terung von BI auf Big Data definiert, welche durch die
immense Menge an verfügbaren Daten (siehe Abb. 2)
notwendig geworden ist. Tatsächlich handelt es sich
um einen Paradigmenwechsel vom Schema-on-Wri-
te hin zum Schema-on-Read. Ein Schema wird also
erst beim Lesen der Daten, sprich bei der Auswertung
festgelegt, so dass zunächst beliebige, auch unstruk-
turierte Daten in der Datenbank abgelegt werden kön-
nen. Der neue Begriff trägt außerdem dem Umstand
Rechnung, dass der Data Scientist komplexe verteil-
te Datenmodelle, parallele Verarbeitungsprozesse
und Machine Learning verwendet, um die Skalierbar-
keit der Big-Data-Anwendung zu optimieren.
Abbildung 2: Globales Volumen von Big Data [4].
Managern fehlenrelevante Daten fürihre Entscheidungen [2]
der Unternehmen setzenauf Analytics, um wettbe-werbsfähig zu bleiben [1]
der globalen Daten wurden in den letzten beiden Jahren erzeugt [1]
90 %
Warum Big Data?
von
110110100101000111
21 der CIOs nanntenBI & Analytics als Teilihrer Zukunftsstrategie [1]
83 % 54 %
der heutigen Daten sind unstrukturiert [1]
80 %
Seite 5 │14
Je nach Spezialisierung wird in der Regel zwischen
dem Data Scientist, Data Engineer, Data Architect
und Data Administrator unterschieden. Da Big Data
häufig in Form von semi- oder unstrukturierten Da-
ten (Weblogs, Bilder, E-Mails usw.) vorliegt, haben
NoSQL-Datenbanken in den letzten Jahren stark
an Bedeutung gewonnen. Diese Datenbanken spei-
chern sämtliche Daten als Schlüssel-Wert-Paare – wo-
bei als Werte beliebige Objekte, zum Beispiel Doku-
mente möglich sind, – und legen die Daten dezentral
auf verschiedenen Knoten eines Computer-Clusters
ab. NoSQL-Datenbanken skalieren deshalb hori-
zontal mit der Größe des Computer-Clusters und
können zudem beliebig strukturierte Daten speichern.
Die Aufgabe des Data Scientist liegt darin, durch ef-
fizientes Data Streaming, Data Caching und Data
Processing – falls möglich in-memory – klassische
Datamining-Algorithmen an die dezentrale Big-Data-
Infrastruktur anzupassen.
Durch die Verwendung der neuesten Generation von
Open-Source-Software aus dem Big-Data-Umfeld –
insbesondere Spark und Hadoop – können Aufwand
und Kosten für die Transformation von BI hin zu Big
Data Analytics inzwischen drastisch reduziert werden,
da Lizenzkosten für proprietäre Software größten-
teils entfallen und sowohl die Installation eines Com-
puter-Clusters von einem Anbieter wie Hortonworks
oder Cloudera als auch der Betrieb (z. B. mit Ambari)
einen Reifeprozess durchlaufen haben. Weitere
Kostenoptimierungen können durch die Verwendung
einer Cloud-basierten Lösung erzielt werden.
Cloud Computing ermöglicht Big Data Cloud Computing (Amazon EC2, Microsoft Azure,
usw.) bietet für Kunden gleich mehrere Vorteile:
▪ Skalierbarkeit der Ressourcen nach Bedarf
▪ niedriger Aufwand für Soft- und Hardware-Admi-
nistration
▪ flexibles Kostenmodell (Abrechnung nach Bedarf)
Diese Auflistung zeigt, dass vor allem große Projekte –
wie zum Beispiel Big Data Projekte – von Cloud Com-
puting profitieren. Durch eine Anonymisierung oder
Verschlüsselung der Daten, bevor sie in die Cloud
übertragen werden, kann die Vertraulichkeit der Da-
ten gewährleistet werden. Es ist hierbei auch wichtig
zu unterscheiden, welche Teile der Anwendung in die
Cloud ausgelagert werden. Die Ebenen einer service-
orientierten Architektur (SOA) sind im Cloud-Bereich
eine gängige Abstraktion, um zu entscheiden, welche
Komponenten in die Cloud ausgelagert werden sollten.
Konkret gibt es folgende Ebenen:
▪ Infrastructure as a service (IaaS)
▪ Platform as a service (PaaS)
▪ Software as a service (SaaS)
Während mit der IaaS-Ebene vor allem das Datei-
system gemeint ist, findet das Scheduling von Pro-
zessen (z. B. Spark) auf der PaaS-Ebene statt. Das
Datenbankmanagementsystem (DBMS) liegt üblicher-
weise zwischen der IaaS- und der PaaS-Ebene. Die
Analyse von Daten findet zwischen der PaaS- und der
SaaS-Ebene statt, und die Abfrage und Visualisie-
rung schließlich auf der SaaS-Ebene – zum Beispiel
webbasiert in einem Jupyter Notebook. Je nach An-
wendung entscheiden kurz- und langfristige Kosten-,
Performanz- und Sicherheitsüberlegungen darüber,
für welche Ebenen eine Cloud-Lösung sinnvoll ist.
Seite 6 │14
Von RDBMS zu NoSQLApache Hadoop ist ein frei verfügbares, in Java ge-
schriebenes Framework für verteilte Datenverar-
beitung (YARN) und verteilte Datenspeicherung
(HDFS). Die Zuverlässigkeit, Performanz und Verfüg-
barkeit von Daten wird durch Datenredundanz inner-
halb eines Computerclusters erreicht. Insbesondere
bei Ausfall einzelner Knoten und Fehlern während der
Netzwerkübertragung bleiben Dienste auf dem Clus-
ter verfügbar. Die Ausführung paralleler Prozesse und
Datenbankabfragen wird durch den YARN-Scheduler
weitgehend automatisiert. Dies stellt eine erhebliche
Vereinfachung der Implementierung gegenüber tra-
ditionellen Ansätzen wie zum Beispiel dem Message
Protocol Interface (MPI) dar. Im Unterschied zu HDFS
gibt es auch Dateisysteme wie den Amazon Simple
Storage Service (S3), Cosmos und Sector, deren Prin-
zip es ist, Daten lokal zu speichern, um Engpässe im
Netzwerk bei der Verarbeitung von Big Data zu vermei-
den. Dies ist insbesondere sinnvoll, wenn die Band-
breite zwischen den Knoten eines Clusters gering ist.
Alternativ können die zu übertragenden Daten zum Bei-
spiel mit Snappy, zlib oder BZip2 komprimiert werden.
Relationale DBMS (RDBMS) sind in der Regel nicht
für diese dezentralen und parallel arbeitenden Cluster-
Strukturen entwickelt worden und können dort deshalb
nicht die für BI benötigte Performanz bieten. Aus die-
sem Grund sind so genannte NoSQL-Datenbanken
inzwischen immer populärer geworden, obwohl
NoSQL-Datenbanken in der Regel nicht (den komplet-
ten) SQL-Standard unterstützen und einige Garantien
klassischer DBMS nicht gewährleistet werden, insbe-
sondere A.C.I.D.:
▪ Atomicity: Änderungen in der Datenbank werden
ganz oder gar nicht ausgeführt (erfordert Rollback-
Operationen)
▪ Consistency: Daten bleiben auch nach einer Ope-
ration korrekt (konsistent)
▪ Isolation: Parallel ausgeführte Datenbankoperatio-
nen beeinflussen sich nicht gegenseitig
▪ Durability: Daten werden dauerhaft gespeichert
(auch bei Ausfall des Hauptspeichers)
Auch NoSQL-Datenbanken definieren einige (weiche)
Standards. Abgesehen von der hohen vertikalen Ska-
lierbarkeit und der Performanz mit unstrukturierten Da-
ten werden die so genannten B.A.S.E.-Eigenschaften
garantiert, welche für einige Anwendungen durchaus
ausreichend sind:
▪ Basically Available: Die Datenbank steht gleich-
zeitig für Abfragen aller Benutzer zur Verfügung
(Gegenteil von Isolation)
▪ Soft State: Es gibt Systemzustände, diese gehen
allerdings fließend ineinander über (wegen der
„Eventual Consistency“)
▪ Eventual Consistency: Daten werden redundant
gespeichert, deshalb ist der Zustand der Datenbank
zwischen dem Ablegen der ersten und letzten Kopie
eventuell inkonsistent
Diese Nachteile lassen sich allerdings durch ein über-
geordnetes In-Memory-Datenmodell wie Apache Ignite
ausgleichen, so dass eine intelligent modellierte Daten-
bankarchitektur gleichzeitig A.C.I.D.-konforme Operati-
onen auf den aktuell relevanten Daten zulässt, ohne die
horizontale Skalierbarkeit in Bezug auf die gesamte Da-
tenmenge im Cluster einzubüßen. Je nachdem, welche
Daten vorliegen und welche Operationen ausgeführt
werden sollen, bieten verschiedene NoSQL-Daten-
banken unterschiedliche Vor- und Nachteile:
▪ HBase ist eine spaltenbasierte (Name, Wert, Zeit-
stempel) Datenbank, die auf Googles BigTable
Seite 7 │14
basiert und eng in das Hadoop-Ökosystem integriert
ist. Es unterstützt A.C.I.D. auf Zeilenebene. Spal-
tenorientierte Datenbanken wie HBase oder Cas-
sandra ermöglichen das dynamische Hinzufügen
(einer großen Anzahl) von Spalten zu einer individu-
ellen Zeile. Sie legen deshalb kein bestimmtes Da-
tenbank-Schema fest, sondern erlauben es, dyna-
misch große Mengen unterschiedlich strukturierter
Daten zu speichern. Laut der offiziellen HBase-Do-
kumentation sollten spaltenbasierte NoSQL-DBMS
erst für Datensätze ab einer Größe von mehreren
hundert Millionen Zeilen verwendet werden – da-
runter bieten RDBMS eine bessere Performanz.
Der große Vorteil gegenüber RDBMS ist die linea-
re Skalierbarkeit, was bedeutet, dass wachsende
Datenmengen nicht die Performanz belasten, so-
lange proportional Server hinzugefügt werden (ho-
rizontale Skalierung). Als Server-Hardware kann
Standard-Hardware (engl.: commodity hardware)
verwendet werden, während zentrale Systeme, auf
denen RDBMS installiert sind, nur sehr begrenzt und
mit teurer High-End-Hardware nachgerüstet werden
können (vertikale Skalierung).
▪ Cassandra ist ebenfalls eine spaltenorientierte
NoSQL-Datenbank, in der die Daten hierarchisch
über einen mehrdimensionalen Hash gespeichert
werden. Die erste Dimension des Hashs ist der so
genannte Keyspace, der ähnlich einem Schema
in einem RDBMS ist. Typischerweise existiert ein
Keyspace pro Applikation. Zudem existieren “Super-
Columns”, welche wiederum selbst Spalten haben
können. Wie auch HBase unterstützt Cassandra
Kompression, In-Memory-Operationen und Fil-
ter. Es besteht allerdings keine externe Abhängigkeit
von Apache Zookeeper und die Datenabfragespra-
che CQL ist umfangreicher als die Abfragesprache
von HBase. Zusammenfassend lässt sich sagen,
dass der engen Integration von HBase in das Ha-
doop-Ökosystem (zum Beispiel Hive) die etwas um-
fangreichere Dokumentation von Cassandra und die
Unabhängigkeit von Zookeeper gegenüberstehen.
▪ Apache Hive ist ein Open-Source-Data-
Warehouse-System für Abfragen und Analysen
großer, in Hadoop gespeicherter Datenmengen [5].
Hive bringt die Abfragesprache HiveQL mit, welche
SQL-artige Abfragen automatisch in MapReduce-
Jobs übersetzt. Es können darüber hinaus auch indi-
viduelle MapReduce-Jobs in die Abfragen eingebun-
den werden. Auf diese Weise unterstützt Hive Data
Warehouse-Operationen wie ETL, Reporting und
Datenanalyse. Mit dem Hive-Metastore wird die
Definition von Schemata für verschiedene Datenfor-
mate unterstützt (CSV, Parquet, ORC etc.). Es kann
auch direkt auf Dateien zugegriffen werden, die zum
Beispiel in HDFS oder HBase gespeichert sind.
Der Zugriff auf Hive wiederum ist interaktiv über die
Shell, aber unter anderem auch aus Apache Tez,
Apache Spark und über MapReduce möglich [6].
Für multidimensionale Daten, Caching oder Textdoku-
mente sind der Vollständigkeit halber noch Hypertab-
le, MongoDB, CouchDB und Redis zu nennen, wenn-
gleich diese weniger eng mit dem Hadoop-Ökosystem
verbunden sind und gegebenenfalls etwas mehr Auf-
wand bei der Integration in Hadoop erfordern können.
Spark und MapReduceDas Programmiermodell für nebenläufige Berechnun-
gen in Hadoop ist MapReduce, welches vor allem
noch für Batch-Processing wie zum Beispiel ETL,
Datenintegration oder Datentransformation ver-
wendet wird. Genau wie bei früheren Ansätzen zur
Parallelisierung (GPGPU, MPI, OpenMP, phtreads
usw.) gilt auch für das MapReduce-Modell Amdahls
Gesetz. Es besagt im Kern, dass nur inhärent parallele
Seite 8 │14
Aufgaben wie zum Beispiel Matrix-Operationen durch
eine horizontale Architektur signifikant schneller bear-
beitet werden können. Deshalb ist es häufig zunächst
erforderlich, eine sequentielle BI/RDBMS-Lösung
durch einen parallel arbeitenden Algorithmus zu
ersetzen, bevor auf eine Cluster-Infrastruktur migriert
werden kann. Die Programmierung von MapReduce-
Jobs in Java gilt generell als anspruchsvoll, auch wenn
es seit der Einführung der Open-Source-Variante 2004
durch Google eine wachsende Anzahl von Entwicklern
und Dienstleistern gibt und Bibliotheken wie Apache
Pig die Implementierung vereinfachen. MapReduce
kann (bzgl. der Fehlertoleranz) als robuster im Ver-
gleich zu Spark angesehen werden, da Ergebnisse
stets persistiert werden und ein abgebrochener Job
deshalb nicht von vorne gestartet werden muss wie bei
Spark In-Memory-Jobs. Andere Projekte wie Hive oder
Impala fügen zudem SQL-Kompatibilität zu MapRe-
duce hinzu. Und schließlich ist MapReduce gut in die
Hadoop-Sicherheitsarchitektur integriert, zum Bei-
spiel in Apache Knox Gateway und Apache Ranger.
In Spark wird die Sicherheit bislang lediglich über ein
Shared Secret hergestellt, die Weboberfläche ist über
Javax-Servlet-Filter gesichert. Da Spark über YARN
auf HDFS ausgeführt wird, werden außerdem HDFS-
Zugriffsrechte und die Verschlüsselung zwischen Kno-
ten und Kerberos Authentifizierung unterstützt. Spark
ist ein allgemeines Programmiermodell und unter-
stützt Batch-Operationen, Streaming, Machine
Learning Library (MLlib), Dataframes, interaktive
und iterative Aufgaben. Bei letzteren bietet Spark in
der Regel eine bessere Performanz als MapReduce,
da Spark Transformationen mittels Lazy Evaluation
optimiert (d. h. die Datentransformation erfolgt erst,
wenn eine konkrete Aktion darauf erforderlich ist) und
diese dann in-memory durchgeführt werden soll. So-
lange die zu verarbeitenden Daten im Arbeitsspeicher
Platz finden, können so Beschleunigungen bis zu ei-
nem Faktor von über 100 gegenüber der Verarbeitung
mit MapReduce erzielt werden. Zudem bietet Spark
für Entwickler eine flachere Lernkurve, da es zahlrei-
che miteinander konsistente Schnittstellen in Java,
Scala und Python gibt. Native SQL-Unterstützung
ist in Spark ebenfalls mit Spark SQL (früher Apache
Shark) enthalten. Mit Spark Streaming stellt Spark
ebenfalls eine native Streaming-Lösung bereit, die
sich nahtlos in andere Hadoop-Streaming-Komponen-
ten wie NiFi und Kafka integriert.
▪ Bei NiFi handelt es sich um ein ursprünglich von der
NSA entwickeltes System zur Automatisierung,
Steuerung und Überwachung von Datenflüssen. Es
konvertiert zwischen den Formaten einzelner Systeme,
puffert Daten – bis sie gesendet werden können – und
erlaubt die Definition und Überwachung von Datenflüs-
sen über ein Web-Interface. Zusammenfassend lässt
sich festhalten: Die Ziele von NiFi liegen in der Verbes-
serung der Skalierbarkeit und Nachvollziehbarkeit
der Datenflüsse, Interaktivität bei der Bedienung
und Sicherheit des Datenaustausches [7].
▪ Kafka ist ein verteiltes Nachrichtensystem aus
Message-Brokern, welches auf dem „Publish &
Subscribe“-Prinzip beruht, wodurch es gute Ska-
lierbarkeit und einen hohen Nachrichtendurch-
satz im Vergleich zu anderen Nachrichtensystemen
bietet [8]. Publisher senden Daten an Kafka und
Subscriber empfangen diese, ggf. von mehreren Pu-
blishern. Kafka benutzt Zookeeper, damit Subscri-
ber und Publisher darüber informiert werden, sobald
ein Broker offline ist. Nachrichten sind nur durch
Topics organisiert, einzelne Nachrichten haben kei-
ne IDs, da die Verteilung nicht zentral organisiert
wird, sondern jeder Subscriber selbständig dafür
zuständig ist, seine Nachrichten innerhalb eines be-
stimmten Zeitfensters abzurufen. Dieses dezentrale
Seite 9 │14
Design bietet allerdings eine hohe Skalierbarkeit,
da die Übertragungslogik größtenteils dezentral
über die Clients und Zookeeper stattfindet.
▪ Zookeeper koordiniert die Kommunikation zwi-
schen Knoten in einem Cluster, so dass alle Ser-
vices zu jedem Zeitpunkt eine konsistente Cluster-
Konfiguration verwenden. Das bedeutet, dass die
einzelnen Knoten ihre Umwelt zwar nicht immer in
exakt synchronem Zustand sehen, Änderungen
aber in derselben Reihenfolge beobachten [9].
Zookeeper bearbeitet Anfragen einzelner Clients
nur, wenn eine Mehrheit der Knoten responsiv ist,
somit wird die Kommunikation pausiert, wenn zu vie-
le Knoten ausfallen sollten und es wird ein inkonsis-
tenter Cluster-Zustand vermieden. Gründe für eine
fehlende Netzwerkverbindung können Netzwerk-
fehler, Bandbreiten-Beschränkungen, Verbindungen
mit variablen Latenzzeiten oder Sicherheitsproble-
me sein. Ohne eine Koordination zwischen einzel-
nen Knoten kann es zu einem so genannten „Split
Brain“ kommen, d. h., dass in einem verteilten Sys-
tem ein Netzwerksegment nicht mehr „weiß“, was
in einem anderen Netzwerksegment vor sich geht.
Zookeeper stellt immer sicher, dass während einer
Systemanfrage eine Mehrheit der Knoten erreichbar
ist und beantwortet nur Anfragen von Knoten, wel-
che zu dieser Mehrheit gehören.
▪ In zeitkritischen Anwendungen im Millisekunden-
Bereich, wenn das Streaming nicht in diskreten
Zeitfenstern, sondern mit wenig Latenz erfolgen
soll, kann Spark auch mit Storm verwendet werden,
einer ereignisbasierten Streaming-Bibliothek in
Hadoop.
Visualisierung von Big Data AnalyticsWelches Tool für die Visualisierung der Analyse-Ergeb-
nisse am besten geeignet ist, hängt von den Anforde-
rungen des Nutzers ab. Apache Zeppelin und Jupyter
bieten browser-basierte Notebooks, in denen sogar
interaktive Hive-Abfragen möglich sind. R wiederum
bietet in einem einzigen Framework unzählige Pake-
te zur Datenanalyse, -transformation und -visuali-
sierung (z. B. mit R Shiny & Leaflet). Dies macht es
besonders in Verbindung mit Apache Spark zu einem
universell einsetzbaren Framework, da auch hier Da-
taframes als Datenstruktur verwendet werden. Spark
bietet bereits nativ eine interaktive Schnittstelle zu R an,
was die Einbindung von R in Spark stark vereinfacht.
Neben R Shiny wurde in dieser Studie für die Visua-
lisierung außerdem Tableau [10] verwendet, da beide
Programme Live-Verbindungen zu Datenbanken
unterstützen und die Visualisierung von Geo-Infor-
mationen auf interaktiven Straßenkarten anbieten.
Im Gegensatz zu Tableau können in R Shiny allerdings
auch über das Framework Buttons und Eingabefelder
hinzugefügt werden, was das Senden von Nutzereinga-
ben an Spark erleichtert. Auch die zahllosen frei verfüg-
baren R Pakete sind ein großer Vorteil von R Shiny. Fil-
ter auf den Daten können sowohl mit R Shiny als auch
mit Tableau ohne großen Aufwand hinzugefügt werden.
Showcase: Interaktives Echtzeitstrea-ming mit Apache Spark und R ShinyDie Hadoop-Infrastruktur für das Streaming und die
Datenanalyse der Verkehrssimulation SUMO ist sche-
matisch in Abb. 3 dargestellt:
Seite 10 │14
Die Verkehrsdaten wurden mit SUMO [11] erzeugt und
über einen Flume Agent nach Hadoop gestreamt und
in HDFS abgelegt. Bevor die Daten in HBase persistent
gespeichert werden, reinigt der Spark-Preparation-
Prozess die Daten, indem unvollständige Datensätze
entfernt werden (Data Cleansing). Die Entkopplung
der Datenaufnahme (Ingestion) von der Datenanaly-
se reduziert die Komplexität in den einzelnen Modulen
und erleichtert den Austausch einzelner Komponenten.
So wäre es z. B. denkbar, für das Streaming in Zukunft
Apache Kafka zu verwenden, um so die horizontale
Skalierbarkeit auch für extrem große Fahrzeugdaten-
mengen sicherzustellen.
Die Einbindung von Spark-MLlib- und Scikit-Learn-
Algorithmen sowie Datenbanken (HBase und Hive)
erfolgte modular und ist als UML-Klassendiagramm in
Abb. 4 dargestellt. Für einen neuen Algorithmus, bzw.
eine neue Datenbank werden die abstrakten Funktionen
der Klasse AlgoRunner, bzw. der Klasse DBI (Database
Interface) implementiert. Auf diese Weise können zu-
künftig weitere Algorithmen (Support Vector Machine,
Artificial Neural Network, Logistische Regression
usw.) und weitere Datenbanken (Cassandra, Apache
Ignite, Redis usw.) hinzugefügt und getestet werden.
Eine In-Memory-Datenbank wie Apache Ignite
könnte das Datenmodell noch erweitern, damit der
Flume Agent die empfangenen Daten nicht nur über
den Spark-Preparation-Prozess in HBase persistent
ablegt, sondern die Daten über den Ignite-Cache di-
rekt für den Spark-Analyse-Prozess zur Weiterverar-
beitung bereitstellt. Eine solche Architektur ermöglicht
es zum Beispiel je nach Datenmenge die für Big Data
ausgelegte HBase-Datenbank oder den effizienten
Ignite-Cache für kleinere Datenmengen zu verwen-
den. Nachdem die Daten von SUMO an den Spark-
Analyse-Prozess übertragen worden sind, werden sie
mit den Algorithmen aus Abb. 4 analysiert, um Staus
zu erkennen.
Abbildung 3: Software-Architektur für das Hadoop-Cluster
Seite 11 │14
Einer der Algorithmen in Abb. 4 ist der k-Means-
Algorithmus aus der Spark MLlib. Abb. 5 zeigt das
Ergebnis eines k-Means-Clusterings der simulierten
Auto-Geokoordinaten in Luxemburg. Die Visualisie-
rung wurde in Tableau umgesetzt. Über das im oberen
Teil integrierte Webinterface lassen sich unterschied-
liche Algorithmen auswählen, zu denen dann die ent-
sprechenden Parameter angezeigt und über einen
HTTP-Request an Spark gesendet werden.
Abbildung 4: Software-Architektur für die Spark-Anwendung (Analyseprozess)
Abbildung 5: Das Ergebnis eines k-Means-Clusterings mit der Spark MLlib und Verkehrsdaten für Luxemburg. Die
Durchschnittsgeschwindigkeit in dem mittleren Cluster (Innenstadt) liegt sichtbar unter der Durchschnittsgeschwindig-
keit in den Randbereichen der Stadt.
Seite 12 │14
Die Parameter werden nach einem Klick auf den
„übernehmen“-Knopf zusammen mit dem ausgewählten
Algorithmus an das Hadoop-Cluster gesendet. Die ge-
sendeten Daten werden dabei von einem Hintergrund-
prozess laufend in einer Parameterdatei gespeichert,
welche wiederum kontinuierlich durch Spark ausge-
lesen wird. Spark führt schließlich den ausgewählten
Algorithmus mit den Parametern auf den durch SUMO
gestreamten Daten aus und schickt die Ergebnisse
(Cluster) an Tableau, wo diese visualisiert werden.
Auf diese Weise ist eine Analyse und Visualisierung
mit Spark auf Big Data umgesetzt worden, die komplett
über eine grafische Benutzeroberfläche umgesetzt wur-
de, über die Tableau-Live-Datenbankverbindung kon-
tinuierlich neue Daten erhält und mit wenig Aufwand die
Integration neuer Algorithmen und Datenbanken ermög-
licht. Das k-Means-Clustering aus der Spark MLlib in
Abb. 5 in Kombination mit einem Tableau-Farbfilter für die
Fahrzeuggeschwindigkeit zeigt zum Beispiel eine deutlich
niedrigere Durchschnittsgeschwindigkeit der Fahrzeuge
im Zentrum von Luxemburg. Das Ziel der Studie war hin-
gegen eine Stauerkennung, wofür ein dichtebasiertes
Clustering-Verfahren im Vergleich zu dem varianzba-
sierten K-means-Clustering offenbar besser geeignet ist.
Dichtebasierte Clustering-Verfahren existieren bisher
allerdings nicht in der nativen Spark MLlib. Deshalb wur-
den für diese Studie noch weitere Algorithmen von Drit-
tanbietern implementiert, zum Beispiel das Density-
based spatial clustering of applications with noise
(DBSCAN). Es wurde sowohl die pypardis-Implemen-
tierung [12] als auch die sehr effiziente DBSCAN-Im-
plementierung aus der Python-Bibliothek Scikit-Learn
integriert. Die Scikit-Implementierung zeigte für die vor-
liegenden Daten (etwa 5.000 Fahrzeuge senden pro
Sekunde jeweils einen Datensatz mit 10 Werten) auf
dem Cluster eine Performanz-Verbesserung um den
Faktor 3. Dies sollte ungefähr konstant bleiben, solange
die pro Iteration zu verarbeitenden Daten in das RAM
auf dem Cluster passen. Der Snapshot eines Echtzeit-
streams in Tableau ist in Abb. 6 dargestellt.
Abbildung 6: DBSCAN-Clustering mit Spark, Scikit-Learn und simulierten Verkehrsdaten in Luxemburg. Nach der Kom-
bination des DBSCAN (links) mit Datenfiltern in Tableau (Mitte) sind zwei Staus auf den Zufahrtsstraßen gut zu erkennen
(rechts).
Seite 13 │14
Wie man sieht, können durch den DBSCAN zunächst
zahlreiche Punkte aussortiert werden (schwarze Punkte
im 2. Bild), die in einem Bereich mit geringer Fahrzeug-
dichte liegen. Die verbleibenden Cluster sind im dritten
Schritt (mittleres Bild) markiert. Anschließend werden
mit Tableau-Filtern in den nächsten beiden Schritten
Fahrzeuge mit einer Geschwindigkeit von mehr als
10 m/s (ca. 36 km/h) herausgefiltert (viertes Bild). Im
fünften Bild (rechts) wurden kleinere Cluster entfernt, so
dass fast nur noch Fahrzeuge verbleiben, die in einem
Bereich mit hoher Fahrzeugdichte und gleichzei-
tig niedriger Durchschnittsgeschwindigkeit liegen,
weshalb diese Fahrzeuge als Stau bewertet werden.
Fazit und AusblickFür die Stauerkennung ist das dichtebasierte
DBSCAN-Clustering sehr gut geeignet. Das Cluste-
ring der Daten nimmt je nach Datenmenge in der Regel
weniger als 1 Sekunde in Anspruch und sämtliche Kom-
ponenten, außer Tableau und dem Simba-Treiber, wur-
den ausschließlich mit Software umgesetzt, die lediglich
der Apache 2.0 Lizenz unterliegt. Die generische und
modulare Architektur des Hadoop-Clusters und der
Spark-Anwendung waren für die Entwicklung essenti-
ell, da die Integration neuer Hadoop-Komponenten, Al-
gorithmen und Datenbanken ansonsten sehr aufwendig
und somit kostspielig sein kann.
Die ODBC-Schnittstelle von Tableau ermöglicht
im Zusammenspiel mit dem Simba-Treiber eine prob-
lemlose Anbindung an das Hadoop-Cluster. Die in-
teraktive Steuerung des Spark-Prozesses wurde über
ein eigens geschriebenes Webinterface realisiert.
Da Tableau bezüglich der Performanz eher für Dash-
boards als für Echtzeitstreaming konzipiert wurde, sol-
len zukünftig weitere Alternativen wie bspw. Apache
Zeppelin oder Apache Jupiter getestet werden. Die
Variante mit R Shiny und Leaflet wird bereits in dem
Video zu diesem Showcase gezeigt. Das Speichermo-
dell mit HBase und Hive soll außerdem um einen In-
Memory-Cache mit Apache Ignite ergänzt werden,
um eine lückenlose Skalierbarkeit für beliebig große
Datenmengen zu gewährleisten.
Seite 14 │14
Quellen[1] https://www-01.ibm.com/events/wwe/grp/grp004.nsf/vLookupPDFs/Arnie‘s%20Presentation/$file/Arnie‘s%20
Presentation.pdf (07.03.2017)
[2] The Economist, 2007, In search of clarity: Unravelling the complexities of executive decision-making, S. 12
(07.03.2017)
[3] Stricker, S.; Wegener, R.; Anding, M. (2014), Bain & Company, Whitepaper: Big Data revolutioniert die Automo-
bilindustrie
[4] http://www.slideshare.net/ZulkiffleeSofee/big-data-big-rewards-47671198 (14.10.2016)
[5] http://www.searchenterprisesoftware.de/definition/Apache-Hive (14.10.2016)
[6] https://cwiki.apache.org/confluence/display/Hive (14.10.2016)
[7] http://www.pro-linux.de/news/1/22547/ (14.10.2016)
[8] https://www.infoq.com/articles/apache-kafka (14.10.2016)
[9] http://www.linux-magazin.de/Ausgaben/2014/09/Zookeeper (14.10.2016)
[10] http://tableau.com/ (14.10.2016)
[11] http://sumo.dlr.de/wiki/Simulation/Output (14.10.2016)
[12] https://github.com/bwoneill/pypardis (14.10.2016)
Sulzer GmbH | Frankfurter Ring 162 | 80807 München | [email protected] | www.sulzer.de