Tag Archive for: Apache Spark

Dr. Mirco Müller

Die Abschätzung von Pi mit Apache Spark

/in , , , , , , , /by

Auf den Berliner Data Science/Big Data/Data Analytics/…-Meetups auf denen ich in letzter Zeit des Öfteren zugegen war, tauchte immer wieder der Begriff Spark auf. Ich wollte wissen was es hiermit auf sich hat. Nachdem ich Spark 1.5.1 lokal auf meinem Mac installiert hatte, fing ich an Wörter in frei verfügbaren Texten zu zählen. Da es mir aber zu aufwändig schien, extrem lange Texte im Internet zu suchen und ich ein Gefühl für die Leistungsfähigkeit von Spark bekommen wollte, widmete ich mich einem skalierbaren Problem: der Abschätzung von Pi mit der Monte Carlo-Methode.

 1000 Zufallspunkte lokal auf Mac

spark-scala-interface-pi-example

Dies war wie zu erwarten keine Herausforderung für meine Hardware. Was passiert bei 10^6/ 10^7/ 10^8/ 10^9… Zufallspunkten?

dataset-spark-pi-example-1

An dieser Stelle stieß ich auf ein “Integer-Problem“. Weil 3*10^9 > 2^31 – 1, kann in diesem Fall nicht mehr der Datentyp Integer verwendet werden, sondern man müsste „long Integer“ (64 bit) nehmen. Was mich nun jedoch viel mehr interessierte als mit Zufallspunkten > 2^31 – 1  zu experimentieren, war eine Spark-Installation auf AWS und die entsprechenden Berechnungszeiten. Ich installierte Spark 1.5.0 (auf Hadoop 2.6.0 YARN) auf einem AWS-Cluster (2 Core/1 Master x m3.xlarge). Zu meiner Überraschung ergab sich Folgendes:

dataset-spark-pi-example-2

Warum war mein Mac schneller als ein AWS-Cluster? Eine m3.xlarge-Instanz hat 4 Kerne und 15 GB Arbeitsspeicher, mein Mac ziemlich genau die Hälfte… Gut, dann probieren wir das Ganze mal mit einem 4 Core/1 Master x m3.xlarge-Cluster.

dataset-spark-pi-example-3

Es ergibt sich kein signifikanter Unterschied. Erst die Verwendung von einem 3 Core/1 Master x r3.2xlarge-Cluster brachte eine Beschleunigung. Wo ist der Flaschenhals? Um Netzwerkeffekte zu prüfen, habe ich schließlich eine 0 Core/1 Master-AWS-Installation getestet.

dataset-spark-pi-example-4

Dieser letzte Test skalierte zu meinen vorherigen Tests auf dem AWS-System, und er wies darauf hin, dass der Flaschenhals kein Netzwerkeffekt war.

Bei heise Developer fand ich einen sehr interessanten Artikel, welcher sich dem Thema „optimale Konfiguration der virtualisierten Cloud-Hardware für den jeweiligen Anwendungsfall finden“ widmet: Benchmarking Spark: Wie sich unterschiedliche Hardware-Parameter auf Big-Data-Anwendungen auswirken

Für heute belasse ich es bei dem vorgestellten Experiment.

To be continued…,

Dr. Dietrich Wettschereck

Kontrolle und Steuerung von Spark Applikationen über REST

/in , , /by

Apache Spark erfreut sich zunehmender Beliebtheit in der Data Science Szene da es in Geschwindigkeit und Funktionalität eine immense Verbesserung bzw. Erweiterung des reinen Hadoop MapReduce Programmiermodells ist. Jedoch bleibt Spark ebenso wie Hadoop eine Technologie für Experten. Es erfordert zumindest Kenntnisse von Unix-Skripten und muss über die Command-Line gesteuert werden. Die vorhandenen Weboberflächen bieten nur sehr rudimentäre Einblicke in den Status von Spark Applikationen:

spark basic ui

Der Spark JobServer ist ein Open-Source Projekt, das eine REST-Schnittstelle (Representational State Transfer) für Spark anbietet. (In diesem YouTube Video wird anschaulich erläutert, was ein REST API ist und wozu es verwendet werden kann.) Vereinfacht gesagt, ermöglicht es der JobServer, Spark über diese REST-Schnittstelle als Webservice zu nutzen. Es ist möglich, über den JobServer Spark Kontexte und Applikationen (Jobs) zu managen und Kontexte über verschiedene Aufrufe der REST-Schnittstelle hinweg wiederzuverwenden. Jar Files mit Job Implementierungen können vorab über die gleiche Schnittstelle installiert werden, so dass es z.B. möglich ist, auch sehr feingranulare Jobs über die Schnittstelle zu steuern (vollständige Liste der Features).

Der Spark JobServer ist bereits bei verschiedenen Organisationen (u.a. Netflix, Zed Worldwide, KNIME, Azavea und Maana) im Einsatz. Diese Nutzer des JobServers verwenden ihn meist versteckt „unter der Haube“, um so ihre jeweiligen Werkzeuge Big-Data tauglich zu machen. So nutzt KNIME ab dem nächsten Release (Oktober 2015) den JobServer. Anwendern können dann Spark Jobs über eine grafische Oberfläche bequem von ihrem lokalen Rechner aus starten, monitoren und stoppen. In der folgenden Abbildung sehen Sie, wie Trainingsdaten auf den Server hochgeladen werden, um daraus verschiedene Machine Learning Modelle zu erstellen. Diese Modelle können dann auf Testdaten angewandt werden, die z.B. aus einer HIVE-Tabelle nach Spark importiert werden:

spark knime hive jobs

Jeder der dargestellten Knoten mit der Überschrift „Spark ***“, wie z.B. „Spark Decision Tree“, ist ein Spark Job im Sinne des JobServers. Weitere Beispiele für Spark Jobs sind verschiedene Vorverarbeitungsaufgaben wie das Sampling einer Tabelle oder ein Join über mehrere Tabellen.

Spark kann über den JobServer im Standalone-, Mesos- oder im Yarn-Client-Modus angesteuert werden. Eine sehr hilfreiche Erweiterung der eigentlichen Spark-Funktionalität bietet der JobServer über die sogenannten „Named RDDs“ an. Ein Resilient Distributed Dataset (RDD) ist im Prinzip ein Datensatz bzw. eine Tabelle in Spark. „Named RDDs“ erlauben die Weiterverwendung von RDDs über einzelne Jobs hinweg. So kann man Jobs modularer aufbauen und leichter Zwischenergebnisse inspizieren.

Ich kann aus eigener Erfahrung sagen, dass der JobServer die geeignete Middleware zwischen einer benutzerfreundlichen Oberfläche und Spark ist. Die Open-Source Community ist hier sehr aktiv und der JobServer lässt sich bei Bedarf gut erweitern.