Spark Summit Europe 2015

Nach drei erfolgreichen Summits in San Francisco schwappt die Begeisterungswelle für Apache Spark nach Europa. Grund genug, sich selbst ein Bild vom “aktivsten Open-Source-Big-Data-Projekt” zu machen.

Für alle, die nur schnell wissen möchten, was sie verpasst haben: Am Ende des Artikels habe ich die wesentlichen Punkte zusammengefasst. Slides und Videos zu allen Talks gibt es übrigens auf der Homepage des Spark Summit .

Zum Einstieg ein Training

Vor der eigentlichen Konferenz gab es die Möglichkeit, an einem eintägigen Spark-Training teilzunehmen. Ich entschied mich für „Data Science with Apache Spark”. Das Training war insgesamt gut, das Material hervorragend. Nur der Hands-on-Teil litt unter der doch sehr großen Teilnehmerzahl. Die Schwerpunkte des Trainings lagen auf DataFrames und einer Einführung in Spark-ML.

Spark DataFrames sind von den gleichnamigen Strukturen aus R und Python inspiriert. Ein DataFrame ist grob gesagt ein RDD mit zusätzlichen Schemainformationen. Zur Manipulation der DataFrames gibt es eine an SQL angelehnte DSL. Durch die zusätzliche Struktur und die Einschränkung möglicher Manipulationen können Queries von Catalyst optimiert werden. Dadurch sind DataFrames im Allgemeinen performanter als RDDs.

Spark-ML ist ein sehr junges Mitglied der Spark-Familie. Es bietet selbst keine neue Funktionalität, sondern ist eine einheitliche API für die verschiedenen Machine-Learning-Algorithmen von MLlib. Wer das R-Paket caret kennt, fühlt sich schnell zu Hause. Während des Trainings wurde auch immer wieder die „alte“ Variante mit MLlib der „neuen“ Spark-ML Variante gegenübergestellt.

Jeder Teilnehmer bekam für die Dauer des Trainings Zugang zur Databricks-Plattform . Ich hatte vorher noch nicht damit gearbeitet und war beeindruckt von den Möglichkeiten und der Qualität dieses Angebots. Die Notebook-Funktionalität wirkte sehr ausgereift. Die direkte Einbindung der Spark-UI fand ich sehr gelungen.

Spark Training Continued – Der “Developer Track”

Quasi als Fortführung des Trainings konnten die Vorträge des Developer Track betrachtet werden. Hier gab es tiefere Informationen zur Verwendung von Spark und zu typischen Fehlern und Problemen – oft garniert mit Beispielen aus der Praxis.

Spark-UI – Wie erkenne ich, warum ein Job langsam ist?
Die erwähnte Integration der Spark-UI in die Databricks-Notebooks hilft natürlich nur, wenn man die Informationen der Spark-UI auch versteht und die nötigen Schlüsse daraus ziehen kann. Anhand einiger gelungener Beispiele wurde die Verwendung der Spark-UI erklärt und dabei auch auf die Performance-Vorteile der DataFrames im Vergleich zu RDDs eingegangen.

Backpressure für Spark Streaming
Bei Spark Streaming Jobs sollte immer darauf geachtet werden, dass die Verarbeitungszeit eines einzelnen (Mini-)Batches kleiner ist als das Intervall zwischen zwei (Mini-)Batches. Ist dies nicht der Fall, stauen sich unverarbeitete Batches an (was im schlimmsten Fall zu OutOfMemory-Fehlern führen kann). Um dem entgegenzuwirken, kann seit Spark 1.5 mit der (experimentellen) Konfigurationsoption spark.streaming.backpressure.enabled Backpressure aktiviert werden. Was in diesem Fall passiert, warum das nützlich ist und warum es einem trotzdem nicht die Arbeit abnimmt, seine Streaming-Jobs zu überwachen und die Konfiguration für Batch Size und Interval sinnvoll zu wählen, wurde von Gerard Maas und François Garillot mit vielen Beispielen erklärt.

Das Spark-Ökosystem

Bei Software spricht man ja gerne vom Ökosystem um die Kernkomponenten herum. Spark ist hierbei keine Ausnahme. Auf der Konferenz wurden einige sehr interessante Projekte vorgestellt, die man im Hinterkopf haben sollte. Meine persönlichen Highlights:

Notebooks
Das Databrick-Notebook konnte ich schon während des Trainings kennen lernen. Die Konferenz nutzte ich, um auch einen Eindruck der Open-Source-Alternativen zu bekommen.

Einen sehr guten Eindruck machte Apache Zeppelin . Allerdings merkt man dem Projekt an, dass es noch sehr jung ist. Es fehlt die Unterstützung von SparkR, es gibt keine Möglichkeit, Notebooks zu versionieren oder zu exportieren/importieren, und der verwendete Spark-Cluster muss hart vorkonfiguriert werden.

Das Spark-Notebook baut auf dem populären IPython (bzw. Jupyter) Notebook auf. Es enthält auch eine rudimentäre Clusterverwaltung. Zur Laufzeit kann ausgewählt werden, auf welchem Cluster ein Notebook ausgeführt werden soll. Standardmäßig an Bord ist auch ein Tachyon-Widget, mit dem der Inhalt des Tachyon-Clusters untersucht werden kann.

Auf die Notebook-Alternative Hue (bekannt aus der Hadoop-Welt) konnte ich während der Präsentation zum interaktiven Spark-REST-Server Livy einen Blick werfen. Leider ist es mir während der Konferenz nicht gelungen, Hue zu kompilieren und selbst auszuprobieren.

Magellan – Geodaten für Spark
Natürlich nur interessant, wenn man mit Geodaten zu tun hat. Dann allerdings unverzichtbar: Magellan bietet die Möglichkeit, Shapefiles und GeoJSON zu lesen und typische Operationen auf Geodaten durchzuführen (Distance, Intersects, Within, …).

Spark ist die Lösung – aber für welches Problem?

Ich hatte viele Hoffnungen in den applications track gesteckt. Spark ist ein sehr interessantes Produkt – aber wo und vor allem warum wird es eingesetzt? Welche echten Probleme werden damit gelöst? Welche Fragen beantwortet? In dieser Hinsicht wurde ich leider etwas enttäuscht. Im Vordergrund stand meist das „Wie“ und weniger das „Warum“. Statt groß zu meckern, hier eine kurze Zusammenfassung meiner Notizen:

• Bei Goldman Sachs ist Spark nicht mehr wegzudenken und hat Hadoop als Processing Layer abgelöst. Die Einführung von Spark war vor allem einem internen Blogpost des CIO geschuldet (indem er sich für die Verwendung von Spark aussprach).
• Natalino Busa von der ING DiBa zeigte, wie man mit Spark GoWalla Daten analysieren kann. Zum Schluss gab es noch einen Hinweis auf die Eigenentwicklung CORAL – ein auf Akka basierendes Framework, das es erlaubt, mittels Event Processing Pipelines per REST zu definieren und zur Laufzeit zu verändern.
• Bei Yahoo wird Spark verwendet, um App-Empfehlungen mittels Collaborative Filtering zu verbessern. Ayman Farahat betonte insbesondere, dass eine Validierung des Modells nicht ausreicht. Auch eine Evaluation des Ergebnisses in der echten Welt ist nötig (z. B. indem verglichen wird, ob die „berechnete“ App-Empfehlung tatsächlich öfter geklickt wird als eine „Placebo“-Empfehlung).
• Bei der koreanischen SK Telecom ist ein 1400-Node-Cluster im Einsatz. Es wurde eine DSL entwickelt, die für die Erstellung von Spark-Jobs verwendet wird.
• Auch bei Barclays gibt es eine solche DSL . Gianmario Spacagna erklärte außerdem, wie diese DSL aussieht und welches Problem damit gelöst wird. Ich habe leider den Talk nicht live gesehen, aber ein Blick in die Folien hat mein Interesse geweckt.
• Eine interessante Anwendung eines NLP-Algorithmus in der Medizin stellte Casey Stella von Hormonworks vor: Indem Word2Vec auf medizinische Diagnosen angewandt wird, können Verbindungen zwischen Krankheiten erkannt werden.

Ein Blick in die Zukunft

Last but not least eignet sich eine Konferenz sehr gut, um auf den aktuellsten Stand zu kommen und einen Blick in die Zukunft zu werfen. Welche Themen sind aktuell relevant? Wohin geht die Entwicklung? Was ist für kommende Releases geplant?

Die Konferenz begann mit ein paar Statistiken über die aktuelle Verbreitung und Verwendung von Spark. Interessant: Vor allem die Python-Anbindung erfährt immer größere Beliebtheit, und die R-Integration – obwohl noch sehr jung – wird rege genutzt.

Für einen Blick in die Zukunft war vor allem Martin Oderskys Vortrag sehr interessant (s. Bild). Seine Hinweise auf Spores (für stabilere Serialisierung von Closures) und den Dotty Linker (für performantere map-Pipelines) zeigen, wo Spark von neuen Scala-Features profitieren könnte. Auch einen Ausblick auf „the next big thing“ nach DataFrames gab es: Die neue Dataset API soll die Flexibilität (und Typsicherheit) von RDDs mit dem Geschwindigkeitsvorteil von DataFrames verbinden.

Noch weiter in die Zukunft blicken ließ der Vortrag Data-centric Metaprogramming . Geschützt durch mehrere „Attention: Research Ahead“ Folien gab es einen tiefen Einblick in das Scala-Projekt iLDL . Mit diesem Compiler-Plugin kann die interne Repräsentierung von von Datenstrukturen geändert werden um Algorithmen performanter zu machen. Dies könnte z. B. dabei helfen, RDDs schneller zu machen (ohne dabei auf Flexibilität zu verzichten).

Fazit

Die Konferenz hat sich gelohnt. Das Wesentliche in Kurzform:

• Spark ist kein Newcomer mehr, sondern hat sich in der Big-Data-Welt etabliert.
• RDDs und MLlib sind out. DataFrames bieten mehr Geschwindigkeit als RDDs (auf Kosten der Flexibilität) und Spark-ML vereint verschiedene Machine-Learning Algorithmen (von MLlib) unter einer einheitlichen API.
• Notebook-Technologien sind das Tool der Wahl für Data Scientists, die mit Spark arbeiten. Neben den Notebooks der Databricks-Plattform gibt es einige interessante Open-Source-Konkurrenten wie Apache Zeppelin , Spark-Notebook und Hue.
• Das Ökoysystem um Spark wächst und gedeiht: Egal ob Geodaten (Magellan ), kollaboratives Arbeiten (Notebooks) oder Integration in die Unternehmens-IT mit dem Spark-Job-Server .
• DataFrames und Spark-SQL waren nur der erste Schritt. Die Zukunft wird mit der Datasets API in eine ähnliche Richtung gehen. Auch von der Weiterentwicklung von Scala wird Spark profitieren.