Compte rendu du Spark Summit 2016

Le 26 et 27 Octobre, nous nous sommes rendus à Bruxelles afin d'assister au Spark Summit, la conférence de référence sur Apache Spark.

Durant ces journées de talks et keynotes, deux sujets de fond ont été régulièrement abordés : les nouveautés de la release de Spark 2.0 et comment assurer le suivi de Spark en production.

Spark 2.0

La valse des conférences a été lancée par Simplifying Big Data Applications with Apache Spark 2.0 présenté par Matei Zaharia qui n'est autre que le fondateur d'Apache Spark. Après avoir décrit les grosses améliorations apportées par la nouvelle version de l'outil (Structured Streaming, Projet Tungsten, etc.), nous avons découvert avec intérêt le notebook de Databricks, qui permet – à la manière de Jupiter ou de Zepplin – d’interagir directement avec un cluster Spark et de réaliser du reporting à la volée à l'aide d'une interface épurée et intuitive.

Côté utilisation, cette nouvelle release de Spark 2.0 n'apporte en réalité que peu de changements notables, hormis le fait qu'il est conseillé d'utiliser les DataSet et DataFrame (déjà introduit avec Spark 1.6) en lieu et place des RDD. Les véritables changements sont sous le capot :

• Un sérialisation off-heap destinée à éliminer l'overhead causé par la JVM et sa gestion de la mémoire ;
• La "Whole-Stage Code Generation" qui permet dans certains cas d'outrepasser le classique Volcano Model en générant du code à la volée qui permet de profiter au mieux des optimisations liées au hardware (registre des CPU, etc.) ;
• Le moteur d'optimisation de requêtes Catalyst présenté par Herman van Hovell de Databricks tout au long de son talk A Deep Dive into the Catalyst Optimizer (dont on peut retrouver les grandes lignes dans ce post directement sur le blog de Databricks)

Ces différentes évolutions s'inscrivaient dans le cadre de la seconde phase du projet Tungsten dont l'objectif est d'améliorer les performances des traitements Spark en place sans avoir à adapter un code déjà écrit pour les versions précédentes (la quasi-totalité des API étant rétrocompatibles).

Visiblement, la promesse est tenue : à en croire le talk Performance Improvements Investigated With Flame Graphs pendant lequel Luca Canali nous présente une analyse du déploiement de Spark 2.0 dans le CERN Hadoop Service qui confirme la sacalabilité du moteur Spark SQL et l'accélération par un facteur 10 des requêtes en CPU bound, le tout sur un lake de 1,2 Po de données.

L'environnement de production

L'utilisation de Spark en production peut être une douleur (c'est l'expérience qui parle...) et Databricks a mis un point d'honneur à crever l'abcès en organisant des talks sur ce sujet.

Que ce soit avec l'allocation dynamique des executors afin de lisser la charge du cluster, détaillée lors du talk Dynamic Resource Allocation, Do More With Your Cluster de Luc Bourlier de Lightbend ; ou bien l'utilisation des listeners pour suivre le cycle de vie des applications déployées au sein d'un cluster décrit par Jacek Laskowski lors du talk Deep Dive into Monitoring Spark Applications, il est clair que des solutions existent aujourd'hui pour monitorer et dimensionner les clusters… Néanmoins, on regrettera qu'il n'existe pas encore (à notre connaissance !) de solutions clés en main pour régler ce genre de problématiques de manière industrielle.

Deux mentions spéciales :

• L'initiative SparkOscope d'IBM présentée par Yiannis Gkoufas qui permet de corréler les métriques de Spark et du système (en utilisation SIGAR) directement au sein de la web-UI de Spark (hélas, c'est un fork et non un plugin / module, donc un peu difficile de proposer cela en production chez un client) ;
• L'architecture proposée par Wiliam Benton de Redhat destinée à lancer de multiples clusters Spark à l'aide de Kubernetes (au lieu d'augmenter le nombre de worker sur un seul cluster multi-tenant) pour gérer les débordements lors du besoin de ressources.

Et pour demain, quoi de prévu ?

A court-terme, Andy Steinbach de NVIDIA a parlé lors de son talk The Potential of GPU-Driven High Performance Analytics in Spark de l'utilisation du GPU avec Spark au travers de l'utilisation des TensorFrame qui encapsulent l'utilisation de la librairie TensorFlow sur les RDD.

L'avenir plus long-terme a été abordé lors de la keynote de Ion Stoica expliquant la transition de AMPLab de Berkeley (connu notamment pour avoir créé Spark et Mesos) vers le RISELab, dont l'ambition est de réaliser de l'aide à la décision en temps réel, rien que ça. C'est donc avec intérêt que nous avons pu découvrir les premiers travaux exposés à la lumière du jour :

• Drizzle : L'héritier de Spark Streaming dans tous ses aspects, qui nous promet des performances supérieures grâce à une meilleur stratégie pour gérer les traînards (stragglers) qui sont aujourd'hui responsables des 30% ~ 40% des temps passé dans une tâche, et qui en même temps nous fera profiter d'une planification par groupe de tâches, nous rapprochant encore plus du grail, sans perdre la tolérance aux pannes qui a popularisé Spark. La latence de traitement a été nettement améliorée et devient comparable aux stacks les plus performantes (Flink, Storm, ...), notamment par l'optimisation du positionnement des agrégations, tout en obtenant une meilleure vitesse de recouvrement de la résilience.
• Opaque : Une sécurité à l'état de l'art. Aujourd'hui dans nos applications, nous n'avons pas de protection contre un système d'exploitation infecté, un hyperviseur compromis et à la fin, même avec des données chiffrées, le modèle d'accès peut être déduit avec un écouteur réseau. Opaque cherche à combler ses besoins de sécurité, avec l'aide d'Intel SGX, en proposant une série d'opérateurs relationnels comprenant notamment de l'authentification et de l'encryption statique et à la volée, avec un impact sur la performance minimisé quel que soit le mode d'encryption prévu.

Affaire à suivre, donc.

Du côté des développeurs

Nous attendions avec un intérêt tout particulier les talks How to Connect Spark to Your Own Datasource de Ross Lowley de MongoDB et Spark and Couchbase de Michael Nitschinger de Couchbase censés apporter un peu de formalisation quant à l'implémentation de connecteurs Spark personnalisés. Ces deux conférences n'ont fait que conforter ce que nous pensions à ce sujet : c'est tout à fait réalisable, mais la documentation est quasi-inexistante et il est nécessaire de mettre les mains dans le cambouis pour comprendre ce qui a déjà été fait et s'en inspirer (l'implémentation du connecteur de Cassandra par DataStax est revenue plusieurs fois).

Au niveau tactique, les hacks utiles foisonnent, comme le travail Nimbus Goehausen (Automatic Checkpointing in Spark), qui propose une solution permettant la reprise d'un processus Spark à partir d'une phase spécifique, sans relancer toute la chaîne de traitement si les phases en amont n'ont pas changé, en exploitant un checkpoiting "intelligent" à base de hashs de classes et de dépendances.

Une présentation assez intéressante dans Dynamic Repartionning (par Zlotàn Zvara, Ericsson) propose une élégante gestion de la distribution du partionnement de données "skewées" (à distribution asymétrique) et cela dynamiquement, à la volée, scalable et agnostique à la distribution, le tout avec un overhead minime.

A voir aussi, le monitoring et le tuning étant de plus en plus critiques et complexes sous Spark, mais déshérités devant la pauvreté de l'UI Spark, Simon Whitear a présenté le projet sparklint qui augmente cette UI, a priori sans fork, avec de l'analyse événementielle de logs, des vues live des process batch et streaming, ou encore des stats et graphes d'utilisation de Core, de localité de tâches.

En parlant de tuning, la présentation Apache Spark at Scale... de Sital Kedia de Facebook vaut vraiment le détour tant elle est pleine de retours d'expérience et de tips bien sentis.

Côté data scientist

Même si les TensorFrames étaient le sujet du moment, nous avons aussi eu l'opportunité d'assister à des talks mettant en avant d'autres approches:

• Des projets d'analyse de séries temporelles avec des moyennes mobiles et d'écarts moyens absolus dans le talk Finding Outliers in Streaming Data: A Scalable Approach et les RDD spécialisés que Two Sigma propose ;
• L'utilisation de scikit-learn en batch mais aussi en temps réel avec un modèle mutable.

L'approche de stockage des modèles de Machine Learning (déjà entraînés) est une problématique de plus en plus récurrente chez les utilisateurs de Spark. Databricks a abordé le sujet en expliquant comment créer un Sink des modèles utilisant l'écosystème Spark (Spark ML, Structured Streaming API, etc.) et nous rappelle la complexité de cette approche qui a déjà été attaquée par IBM et qui manque de cadres et d'exemples dans la communauté open-source.

Avec Spakling Water, Michal Molohlava propose une intégration de H2O dans l'écosystème Spark. Elle permet d'avoir un contexte H2O adossé au contexte Spark dans le même exécuteur, permettant de s'intégrer dans des pipelines Spark ML et d'être opérationnel pour du Machine Learning en streaming, le tout en supportant Zeppelin notebook. A l'avenir, il est même promis d'interfacer directement le cluster Spark à un cluster H2O.

Enfin, la question d'interopérabilité des systèmes a été abordée : Databricks a pour ambition de faire évoluer Spark pour sauvegarder ses modèles dans des schémas standard qu'on peut partager avec d'autres outils (PMML, PFA). Mais aujourd'hui le format par défaut est propre à Spark et beaucoup de travail reste à réaliser, bien que les équipes de Databricks et la communauté avancent (il y a déjà certains modèles exportables).

En conclusion

On peut dire que le Spark Summit était une conférence dense, mais complète et équilibrée : les améliorations apportées par Databricks sur Spark ont été détaillées et des pointeurs intéressants et pertinents ont été donnés quant à l'utilisation optimale de Spark pour profiter au mieux de ces innovations.

C'était aussi une invitation à rejoindre la communauté Spark et à participer à son développement et celle de son écosystème. Avec une moyenne de 5 pull requests acceptées par jour, Spark est un des projets Big Data open source les plus actifs et il encourage l'interopérabilité entre différentes technologies.

Pour aller plus loin :

• Les talks ont été filmés et les vidéos sont présentes sur le site du Spark Summit ;
• La bible de Jacek Laskovski sur Apache Spark.