Un nouvel outil s’installe dans le paysage de la gestion des ressources du calcul distribué : Spark. Plusieurs actions ont démarré depuis un an, à l’IN2P3 et à l’université Paris-Sud (U-PSud), ayant comme objectif de comprendre et évaluer ce nouvel éco-système de programmation et de calcul distribué. En effet, Spark semble proposer des solutions tout à fait complémentaires aux outils de calcul intensif et haut-débit (HPC, HTC) déjà implantés dans nos environnements.

Spark a démarré comme projet de recherche à l’université UC Berkeley en 2009, puis a été pris en charge par la fondation Apache. Il est maintenant une plateforme logicielle Open Source de traitement des données. Développé en Scala, il s’interface naturellement avec les langages Java, Python et R (et Scala). Spark se propose d’optimiser et d’élargir le concept déjà bien connu de « Map-Reduce » (déployé dans le framework Hadoop), tout en optimisant de façon cohérente l’utilisation de la mémoire et les communications entre processus, grâce à une analyse du graphe (DAG) des tâches et des transferts de jeux de données, en s’appuyant largement sur la programmation fonctionnelle. L’importance de cette technologie nous est apparue en mars 2016 lors d’une journée Loops organisée par Julien Nauroy (à l’époque à l’U-PSud), où avait été présenté un travail effectué au CDS (Centre de Données astronomiques) de Strasbourg sous la conduite de André Schaaff et François-Xavier Pineau. Puis, Cécile Germain (du LRI) a lancé un projet ERM-MRM de l’U-PSud centré sur Spark, s’appuyant sur la plate-forme mutualisée VirtualData des laboratoires de physique d’Orsay (dont le LAL) et réunissant plusieurs équipes de recherche (Astrophysique - LSST, Génomique – [Médecine, Bio-Informatique], Ecologie, Machine Learning). Ce projet (ERM-MRM Spark) a été officiellement lancé en janvier 2017 avec la mise en place d’une structure collaborative autour d’une plateforme OpenStack (pilotée par l’équipe d’exploitation du LAL autour de Guillaume Philippon), et moi-même (Christian Arnault) pour l’animation (Liste de diffusion, Wiki, réunions techniques récurrentes, formation Spark) et la liaison avec LSST.

Architecture SPARK

Un cluster SPARK se compose d’un ensemble de machines (workers) homogènes ou hétérogènes dont les ressources sont pilotées par un gestionnaire de ressource (master).

Pour utiliser SPARK, c’est aussi simple qu’une connexion à une base de données, il vous suffit de charger dans votre code JAVA, PYTHON ou SCALA les librairies SPARK pour accéder à l’ensemble des ressources de votre plateforme SPARK. Lorsque vous établissez une connexion à une plateforme SPARK, votre programme va tout d’abord discuter avec le gestionnaire de ressources pour réclamer ce dont il a besoin en mémoire et en CPU. Une fois les ressources obtenues, votre programme est compilé par le driver SPARK afin de construire un graphe de tâches (DAG). Ce graphe indique l’ordre et les relations entre toutes les tâches à effectuées par SPARK. C’est aussi le SPARK Driver qui est en charge de la coordination et l’exécution des tâches sur les workers.

Architecture Spark

Les développements pour LSST

Dans la perspective des grandes quantités d’images en provenance du futur télescope LSST, un axe de R&D consiste à confronter les flots de traitements de données avec les logiques de distribution du calcul proposées par Spark.

Notre objectif ici sera d’évaluer les performances de Spark, en fonction de ses multiples paramètres d’optimisation. Pour y parvenir, une application émulant l’architecture proposée par la plateforme standard de traitement des images (Stack) a été développée, permettant de personnaliser à volonté le dimensionnement des données, les étapes de calcul, les transferts entre nœuds du graphe de calcul.

Des outils de monitoring peuvent être associés avec l’environnement Spark (ex : Ganglia) et offrent de puissants outils de visualisation des performances (Mémoire, IO, CPU, Network, Disque).

Un exemple de flots de traitement des données pour LSST

Nous pourrons de plus, étudier la collaboration entre Spark et MongoDB à travers la production et l’utilisation de catalogues d’objets. En effet, un connecteur pour cette base de données NoSQL est disponible. Ainsi une vision ensembliste des données structurées par MongoDb est accessible, avec les opérateurs traditionnels des bases SQL (Jointures, groupes, tris, …).

Evidemment, cette étude se structure autour de la communauté astrophysique, incluant en particulier la collaboration LSST, ou d’autres projets associés comme le projet Petasky à Clermont, et en collaboration naturelle avec les experts du CC-IN2P3.

Organisation d’une école Spark

Pour initier le projet ERM-MRM Spark, une école Spark a été organisée au LAL les 14 et 15 mars 2017, avec l’aide d’un intervenant extérieur d’une société partenaire de Databricks (un des contributeurs d’origine du logiciel Spark). Trente étudiants étaient présents, essentiellement les membres des équipes de recherche du projet ERM-Spark, mais aussi quelques personnes de la communauté IN2P3. Cette école s’est structurée autour d’une plateforme pédagogique basée sur les notebooks Jupyter, opérée sur le cluster OpenStack de VirtualData.

Statut de la plateforme

Le cluster de développement Spark est mis à disposition sous forme de machines virtuelles sur la plateforme OpenStack de VirtualData avec un certain nombre d’outils logiciels :

• API standards : Scala, Python, Java
• Built-In Components :
• SparkR (programation R)
  • Spark SQL
  • MLib (librairie pour le Machine Learning)
  • Spark GraphX (traitement des graphes)
• Mongo (–> Mongo sharded),
• Genomics/Adam (plateforme pour la génomique)
• Système de fichier distribué HDFS
• ssh, Jupyter notebook
• HT Condor (pour la gestion des ressources de plusieurs clusters Spark)
• Ganglia, pour le monitoring

Le cluster Spark sur la plateforme Virtual Data

A ce stade, nous avançons dans la compréhension du paramétrage de Spark (équilibrage de la mémoire, des I/O, des cœurs, …). La collaboration avec les experts du génome, qui démarre cet été, va nous permettre d’explorer une plateforme quasiment opérationnelle, en mesurant les performances réalistes sur des données de taille significative (1To). D’un autre côté, l’exploration de plusieurs cas d’utilisation dans le contexte LSST va permettre de comprendre comment l’architecture d’une application de calcul et d’analyse mais aussi les structures de données, vont devoir s’adapter à la nouvelle façon de penser une application distribuée, où la programmation fonctionnelle joue un rôle central.

Références

• Apache Spark, http://spark.apache.org/
• Apache Hadoop, hpp ://hadoop.apache.org/
• Spark : Cluster Computing with Working Sets, Matei Zaharia, Mosharaf Chowdhury, Michael J. Franklin, Scop Shenker, Ion Stoica, University of California, Berkeley, http://static.usenix.org/legacy/eve...
• Application en astrophysique, « crossmatch » de catalogues de sources, https://reseau-loops.github.io/pres...
• LSST, http://lsst.in2p3.fr/
• MongoDb, https://www.mongodb.com/fr
• Plateforme VirtualData du Mésocentre U-Psud, www.mesocentre.u-psud.fr
• France génomique, https://www.france-genomique.org/

Christian ARNAULT (LAL) et Osman AIDEL (CC-IN2P3)