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. Das

Speichermodell 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)

richard leitner

Kompetenzfeldleiter Big Data

089 31858 - 103

Sulzer gmbH | Frankfurter Ring 162 | 80804 münchen | bigdata@sulzer.de | www.sulzer.de

Dr. David Zastrau

Data Scientist

089 31858 - 3320

Kontakt