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.
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 :
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'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 :
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 :
Affaire à suivre, donc.
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.
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:
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).
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 :