Spark Summit Europe 2016 Brüssel

Spark Summit EU 2016 Entrance

Zum zweiten Mal fand der europäische Ableger des Spark Summits statt, nach Amsterdam im letzten Jahr dieses mal nun in Brüssel. Ich gebe hier einen kurzen Eindruck und Zusammenfassung entsprechend der Talks, die ich besucht und der Gespräche, die ich in den Pausen mit Teilnehmern und Firmen geführt habe.

Developer Day

Spark’s Performance: The Past, Present, and Future (Developer)

Der Talk gibt eine kurzen Überblick über die Hardware-Entwicklungen der letzten Jahre. Während der Zugriff auf Festplatten und das Netzwerk immer schneller und schneller werden, hat sich bei Prozessoren die reine Rechenleistung nicht signifikant weiter entwickelt. Daher ist bei Databricks nun ein besonderer Fokus auf der besseren Ausnutzung von CPU-Architekturen, die im Sinne von Mechanical Sympathy Code prozessorgerecht optimieren (beispielweise, dass möglichst viel in den CPU-Registern landet). Ein Hauptfeature dafür ist die Code Generation in SparkSQL (Projekt Tungsten). Die Idee ist es, generisch geschriebenen Code (also in SQL, DataFrames, oder DataSets) so in spezifischen nativen Code zu überführen, als wäre jede Query handoptimiert. Diesen Code würde kein Entwickler selber schreiben, er ist jedoch für eine CPU einfacher zu optimieren, da die sonst üblichen Schichten an Abstraktionen wegfallen. In Spark 2.0 ist die sogenannte Whole-stage Codegenerierung bereits aktiv, bei der ganze Stages in eine handoptimierte Funktion überführt werden.

Zudem wird mehr auf ein Spaltenformat im Hauptspeicher gesetzt, da dieses einfacher Optimierungen (z.B. von sich wiederholenden Werten) erlaubt.

How to Connect Spark to Your Own Datasource (Developer)

Am Beispiel des MongoDB-Connector zeigt Ross Lawley von MongoDB, wie man eigene Datenquellen implementiert. Es gibt dazu keine Dokumentation, daher muss man sich stark an den bereits existierenden Connectoren orientieren. Ein Hauptaspekt ist dabei das richtige Partionieren der Daten. Im Falle von MongoDB ist es schwer, das automatisch zu tun, daher wählt man als Entwickler selber zwischen einigen Partitionierern.

Als nächstes sollen auch strukturierte Daten unterstützt werden, damit man die Datenquelle in SparkSQL (und damit Python und R) nutzen kann, sowie Predicate Pushdown.

Data-Aware Spark (Research)

Ein typisches Problem bei Spark-Jobs ist die ungleiche Verteilung von Keys auf Partitionen (data skew), die dann bei Key-Value-Operationen (z.B. reduceByKey()) zu einer nicht-ausgeglichenen Laufzeit der Executors führt. Dazu stellt Zoltan Zvara ein System vor, das die Verteilung von Daten in Partitionen überwacht und über dynamische Partitionierer automatisch neu verteilt. Das System ist auch in der Lage, die Datenverteilung aufzunehmen und zu visualisieren.

A Deep Dive into the Catalyst Optimizer (Developer)

Herman van Hovell geht in die Tiefen von Catalyst, dem Optimizer von SparkSQL. Zunächst wird erklärt, wie aus den SQL-Anweisungen ein AST generiert (logische Analyse) und dieser dann in verschiedene Executionpläne umgesetzt wird, von denen der beste über ein Kostenmodell ausgewählt wird (physische Planung). Einige Optimierungen werden noch vorgestellt: Constant Folding fasst mehrere konstante Ausdrücke zu einem Ausdruck zusammen; Predicate Pushdown führt Filter direkt an der Datenquelle statt im Programmcode aus; Column Pruning liest nur die Spalten aus, die im finalen Ergebnis benötigt werden.

Im zweiten gleichnamigen Talk im Anschluss gibt es noch eine Hands-on Demo der vorgestellten Konzepte.

SparkLint: a Tool for Monitoring, Identifying and Tuning Inefficient Spark Jobs Across Your Cluster (Ecosystem)

Groupon hat intern das Tool SparkLint entwickelt, das aus den Spark-Eventlogs die CPU-Auslastung eines Jobs ermittelt und visualisiert und so bei der Performance-Optimierung von Spark-Jobs unterstützt. Das Tool soll nun auch als Open-Source verfügbar sein.

From Single-Tenant Hadoop to 3000 Tenants in Apache Spark: Experiences from Watson Analytics (Experience and Use Cases)

Das Team von Watson Analytics für Social Media nutzt Spark Streaming als Pipeline für Textanalysen. Da durch einen einzelnen Social Media Kanal entgegen Vermutung nur relativ wenige relevante Daten strömen, nutzt Watson die Pipeline für 3000 Kunden parallel. Eine der Lektionen aus dieser Größenordnung ist, dass man Dinge wie HTTP-Fetches außerhalb von Spark machen sollte, da durch die schwer vorhersagbare Latenz die Batch-Intervalle gestört werden.

Mastering Spark Unit Testing (Developer)

Ted Malaska von Blizzard (die Firma hinter World of Warcraft, Starcraft, usw.) stellt vor, wie man Spark-Code Unittesten kann. Er zeigt dazu einige seiner Hilfsklassen, mit denen er Spark, SparkSQL, und Spark Streaming Jobs testet.

Für Integrationstests kann man Mini-Cluster nutzen (lokale gestartete Services), Beispiele findet man in den Integrationstests der jeweiligen Spark-Module (z.B. spark-streaming-kafka). Oder man nutzt direkt Docker.

Apache Spark 2.0 Performance Improvements Investigated With Flame Graphs (Developer)

Luca Canali vom CERN nutzt SparkSQL um 160 PB an Daten zu analysieren (50 PB/Jahr). Spark läuft hier auf drei YARN-Clustern mit ~1000 Cores und dient aktuell noch hauptsächlich für Analytics und Monitoring, soll in Zukunft aber auch für physikalische Modelle genutzt werden.

Zunächst wird darauf hingewiesen, dass man möglichst aktuelle Spark-Versionen nutzen soll. Eine Analyse, die auf SQL-Server 12 Stunden dauerte, lief in Spark 1.6 in 20 Minuten durch, in Spark 2.0 dann in zwei Minuten. Mit Hilfe von aktivem Benchmarking sollen noch existierende Bottlenecks aufgespürt und deren Ursachen identifiziert werden.

Als erstes kann man sich den SparkSQL Execution Plan anzeigen lassen. Bei mit Sternchen (*) gekennzeichneten Stages wird Codegenerierung ausgeführt (Whole-stage Codegen, s.o.). Als nächstes helfen Flame Graphs von Stackprofilen dabei, “heiße” Codestellen zu identifizieren. Zur Analyse der JVM sollte man dann Tools wie jstack und Java Flight Recorder (nur bei kommerziellen VM-Lizenzen verfügbar) einsetzen. Auf OS-Ebene kann noch HProfiler und Linux’ perf stat verwendet werden. Bei der Interpretation der Ergebnisse muss man allerdings schon genau verstehen, was vor sich geht.

Enterprise Day

TensorFrames: Deep Learning with TensorFlow on Apache Spark (Developer)

Wie auch schon in der Nvidia-Keynote angesprochen haben GPUs im Gegensatz zu CPUs weiter riesige Sprünge in der reinen Rechenleistung erfahren. Während Tungsten und Catalyst die Nutzung von CPUs stark optimieren, sind sie für allgemeine Workloads gedacht und nicht spezifisch für die numerischen Problemstellungen aus Machine Learning. Numerische Rechenleistung ist aber gerade eine der großen Vorteile von GPUs, die auf der anderen Seite nicht ganz so einfach zu programmieren sind (jede GPU hat eigene APIs, Metal gibt es nur für Mac, usw.). Für diesen Fall gibt es einige Bibliotheken, die Machine Learning auf Grafikkarten vereinfachen, u.a. Caffe und TensorFlow von Google. TensorFrames wiederum ist eine Adaption von TensorFlow auf Spark Dataframes und Datasets. Die Performance kann sich bereits mehr als sehen lassen, und es sind noch einige Optimierungen im Bereich des Datenaustausches zwischen Spark und TensorFlow offen.

Finding Outliers in Streaming Data: A Scalable Approach (Data Science)

Casey Stella, Committer des Cyber-Security-Projekts Apache Metron, präsentiert wie man Anomalien in Spark Streaming erkennen kann. Dazu wird die Pipeline in zwei Bereiche aufgeteilt. Zunächst werden nur Kandidaten durch Medianbestimmung erkannt, um Rechenzeit zu sparen. Erst im zweiten Schritt wird auf den Kandidaten eine Principal Component Analysis ausgeführt. Das Verfahren funktioniert derzeit nur mit eindimensionalen Daten.

Die Demo fällt nur kurz aus, da jemand vor Beginn des Talks die externe Festplatte mit den laufenden Services entfernt hat. Trotzdem werden einige interessante Sponsorings von amerikanischen Ärzten durch Pharmafirmen als Outlier identifiziert.

Paddling Up the Stream (Enterprise)

Der Talk gibt einen kurzen Überlick über Spark Streaming sowie einige der üblichsten Fehlermeldungen, denen man in Streaming-Jobs begegnet, und wie man sie lösen kann.

Spark Streaming at Bing Scale (Experience and Use Cases)

Das Bing-Team bei Microsoft verarbeitet mit Spark Streaming in etwa eine Billion Requests pro Monat, was mehreren 10 TB die Stunde entspricht. Die Daten stammen aus mehreren Kafka-Datacentern und werden miteinander und mit zusätzlichen Daten korreliert. Eingehende Events werden dazu miteinander kombiniert und die Ergebnisse wieder nach Kafka geschrieben. Der Talk geht hauptsächlich auf die Probleme ein, denen man in dieser Größenordnung begegnet.

Unausgeglichene Partitionen - in den unterschiedlichsten Kafka Topics können Daten in unterschiedlichen Volumina anfallen. Der KafkaDirectStream mappt die Partitionen 1:1 auf Spark-Partitionen, so dass man auch in seinem Spark-Job mit unterschiedlich großen Partitionen zu kämpfen hat. Das Team hat dazu ein eigenes Kafka-RDD geschrieben, das Partitionen gleichmäßig verteilt, ohne ein repartition() dafür zu benötigen.

Langsame Broker - der Zugriff auf die verschiedenen Kafka-Instanzen kann unterschiedlich schnell sein, so dass in einem Streaming Batch eventuell nicht alle Daten zur rechten Zeit eintreffen. Man hat hier ein vom Business definiertes Window von 10 Minuten über die Daten gelegt, und alle Events, die älter sind, werden ignoriert. Um dieses Problem zu lösen, werden Daten aus den Brokern in einem eigenen Thread im Voraus geladen und gecacht. Es ist jedoch unklar, warum man in diesem Szenario nicht Mirror Maker einsetzt, um die unterschiedlichen Latenzen der Datencenter etwas anzugleichen.

Offsets finden - die Anzahl der Offsets nach einem Neustart ist bei einer solchen Datenmenge ebenfalls sehr groß. Um das zu beschleunigen werden auch die Offsets in einem separaten Thread geladen und gecacht.

Join - aktuell sind Joins nur nach Batch-Zeit möglich, nicht nach Business-Zeit (dies ist erst für Spark 2.1 geplant). Um das zu lösen muss man den Join selber in updateStateByKey implementieren und die richtigen Events herausfiltern.

Dieser Talk enthält einige Parallelen zu How We Built an Event-Time Merge of Two Kafka-Streams with Spark Streaming, der am ersten Tag von Otto vorgetragen wurde.

SparkOscope (Developer)

SparkOscope (ein Wortspiel mit Stethoskop) ist ein Tool um Bottlenecks in Spark-Jobs zu finden. Dazu muss zunächst Sigar auf allen Nodes installiert werden, um systemweite CPU und Memoryauslastung zu ermitteln und in das Spark Monitoring Framework einfließen zu lassen. Eine Erweiterung des Spark UIs ermöglicht es, die diversen Spark Metriken (sowohl die von Spark als die von SparkOscope erfassten) für einen Job als Graph anzeigen zu lassen. Weitere Features sind in Planung.

Problem Solving Recipes Learned from Supporting Spark (Experience and Use Cases)

Lightbend bietet kommerziellen Spark-Support an und fasst in diesem Talk einige der üblichen Probleme und Lösungen zusammen.

OOM - zum einen kann man hier spark.memory.fraction und spark.storage.memoryFraction tunen, wobei die Defaults bereits als gute Richtwerte dienen. Als wichtigerer Tipp dient das Vermeiden von zu vielen instanziierten Objekten.

NoSuchMethodError - ein durch Kollision von Dependencies erzeugtes Problem, wenn sich Methodensignaturen von verwendeten Bibliotheken von der Version von Spark (oder anderen Abhängigkeiten) unterscheidet. Wenn Spark das Problem ist, kann man per --driver-classpath Spark mitteilen, welches JAR verwendet werden soll. Wenn Spark dann aber selber nicht mehr funktionieren sollte, muss man shaden.

Speculation - einzelne langsame Tasks können spekulativ auf anderen Nodes ausgeführt werden. Dazu gibt es einige Threshold-Parameter, damit das nicht zu schnell geschieht und nicht unnötig Ressourcen verbraucht werden.

Strategize Joins - hier werden kurz die verschiedenen Joins vorgestellt, wobei der Broadcast Join nach wie vor der Interessanteste ist. Sort Merge Join scheint zudem nicht immer so performant zu sein wie gedacht.

Safe Stream Recovery - ein Hinweis wie man RDDs korrekt initialisiert, um Checkpoints wiederherstellen zu können.

Extending Spark with Java Agents (Developer)

Der Talk gibt einen sehr kurzen Überblick, wie man mit Java Agents Code instrumentieren kann. Java Agents werden dynamisch zur Laufzeit eingebunden und können sowohl eigenen Code injizieren als auch vorhandene Klassen umschreiben und sind schwer wart- und debuggbar. Man kann so aber auf interne Spark-Datenstrukturen zugreifen, Metriken sammeln ohne dass man seine Business-Logik anpassen muss, und dynamisch RDDs cachen. Eine Hilfe stellt das vorgestellte BTrace dar, eine Java Annotations-basierte DSL. Ansonsten wird das eigene Produkt zum Analysieren von Spark-Jobs vorgestellt, das zu einem großen Teil auf Java Agents basiert.

No One Puts Spark in the Container (Developer)

In diesem Grundlagen-Talk erklärt Jörg Schad von Mesosphere, worauf Docker basiert. Er zeigt, wie Isolation durch Namespaces und Control Groups funktioniert, und welche Fallstricke es im Zusammenspiel mit der JVM gibt. Vorsichtig muss man bei den zugewiesenen CPU-Ressourcen sein, da eine JVM sonst eventuell eine falsche Zahl an Kernen sieht.

Der Talk liefert zudem ein Argument, auch JVMs in einem Container laufen zu lassen, nämlich um zu vermeiden, dass der Metaspace das komplette System herunterzieht. Eine hartes Speicherlimit in den Control Groups führt dazu, dass ein Container abgeschossen wird, wenn der Speicherbedarf überschritten wird.

Gesamteindruck

Developer - Entwickler sind von Sparks API und dem einfachen Einstieg nach wie vor begeistert. Das Interesse ist mit rund 1200 Teilnehmern auch noch mal gestiegen.

Ökosystem - in Sparks Ökosystem tut sich aktuell viel. Viele Firmen nutzen Spark nicht mehr für Proof of Concepts, sondern für leicht fortgeschrittene Use Cases mit steigenden Datenmengen. Sie haben nun stärkeren Bedarf zu verstehen, warum Jobs langsam laufen oder abstürzen.

Data Science - im Bereich Machine Learning ging es bei den Vorträgen dieses Jahr ein wenig zurück zu den Grundlagen. Aber auch hier hat sich Spark in vielen Bereichen bereits etabliert.

Unternehmen - Sparks Verbreitung hat weiter zugenommen und ist nun in vielen verschiedenen Bereichen zu finden, von Finanzinstituten, Telcos, über E-Commerce, Biotech bis hin zu namhaften Größen wie Facebook und Netflix.

Diesen Post teilen

RSS-Feed

Neue Posts direkt im Newsreader.

RSS-Feed abonnieren

Newsletter

Neue Posts sowie Neuigkeiten rund um Big Data, Spark, und Scala. Maximal eine E-Mail im Monat.

Kommentare