Comme mentionné précédemment, Christian Arnault prend la suite de Julien Nauroy comme animateur de la communauté Spark d'Orsay, et des réunions bimestrielles associées.
Ces activités sont associées à un Equipement de Recherche Mutualisé (ERM) et des Moyens de Recherche Mutualisés (MRM), sources de financement destinées respectivement à l'achat de matériel et au financement de personnels et de missions. Le budget de ces entités est de l'ordre de 100 k€.
Christian utilise ces moyens pour monter une infrastructure de recherche sur Spark, qui regroupe des personnes de milieux très hétérogènes comme des physiciens, des informaticiens, et des biologistes. Cela soulève des problématiques de communication très intéressantes.
Une école de Spark est en cours de préparation. Elle se déroulera en deux jours, plus ou moins également répartis entre présentations et TDs. Christian est actuellement en train de chercher des intervenants et de constituer le programme, il y aura à priori de la place pour intégrer des étudiants allant au-delà de la communauté LoOPS.
Il n'y a pas vraiment de communauté Spark française actuellement, par contre les réseaux internationaux sont bien développés, et donnent accès à des infos sur les nouveautés logicielles, ainsi que les conférences et formations se montant un peu partout dans le monde.
Il existe une collaboration existante entre VirtualData et des équipes de l'Institut des Systèmes Complexes de Paris et de l'IGN. Christian pense qu'il serait pertinent de l'intégrer à l'ERM.
A plus grande échelle, Christian essaye aussi, depuis les JI, de lancer une réflexion sur Spark et ses domaines d'application à l'IN2P3.
Christian participe aussi à la refonte actuelle du modèle de calcul LSST, qui étudie des opportunités de parallélisation au-delà de leurs prototypes séquentiels actuels. Guy s'interroge sur la capacité de ce modèle à gérer des scénarios de visualisation. Apparemment, le modèle ne sera pas optimisé pour minimiser la latence temps réel, mais plutôt pour maximiser le flux de données traitable.
Christian a aussi exploré un binding pour l'intégration de MongoDB comme couche de stockage des données. Pour rappel, Apache Spark fonctionne en décomposant les données à traiter en blocs, qui sont distribués de façon redondante sur le cluster de calcul : on parle de "Resident Distributed Dataset" ou RDD. Cette décomposition suppose une certaine connaissance du format de données sous-jacent. Spark supporte nativement les fichiers textes et un certain nombre de données tabulées, mais l'intégration MongoDB apporte le support de BSON, un format binaire qui permet de bien meilleures performances de calcul et de stockage dans le cas courant où les machines du cluster ont une architecture matérielle similaire.
Cette intégration s'effectue au niveau d'Avro, le composant Spark responsable des problématiques de sérialisation. Ce composant est assez souple pour gérer des données hétérogènes, comme par exemple un fichier texte contenant du JSON, et il y a eu une présentation à CHEP d'un binding Avro permettant la manipulation de fichiers ROOT avec Spark.
Guy rappelle que pour tirer profit du parallélisme, il faut que le traitement de données que l'on effectue s'y prête. Par exemple, on peut a priori décomposer le traitement d'une image en blocs indépendants, ou le traitement d'un jeu de données HEP en événements indépendants, mais en pratique il y a toutes sortes de problématiques supplémentaires à gérer (recouvrement des blocs, conditions...) qui peuvent dans des cas graves détruire l'efficacité du calcul parallèle.
Ce genre de questions a été explorée à Strasbourg, où un système de cross-matching permettant de comparer des données célestes issues de plusieurs catalogues de ciel (et donc de plusieurs instruments) a été porté vers Spark. Le problème de cross-matching n'a rien d'évident: il faut par exemple gérer les transformations de coordonnées entre instruments, et le suivi d'objets célestes sur des périodes de temps très longues. Mais en pratique, le code résultant passe bien à l'échelle dans le scénario où l'équipe l'a testé, c'est à dire une exécution sur des ressources cloud Amazon EC2. Ces ressources sont plus rentables et performantes pour l'équipe de Strasbourg que le maintien d'un cluster local, mais il a été mentionné qu'une comparaison plus juste reste à effectuer avec les moyens Spark du CCIN2P3.
Guy et Christian travaillent également avec Réza Ansari, un enseignant-chercheur du LAL qui contribue à LSST. Ce dernier a mis au point en freelance, bien avant LSST, un framework C++ d'analyse de données orienté astrophysique qui est comparable par certains points à ROOT, Sophya.
Le format de données traditionnel de la communauté de l'astronomie est le FITS. Ce dernier possède une spécification publiquement accessible et des implémentations libres, qui permettent de décoder facilement les en-têtes et données de fichiers provenant de toutes sortes d'expériences astronomiques.
Pour encore plus d'interopérabilité, l'observatoire virtuel IVOA travaille à homogénéiser les schémas de données utilisés par différentes expériences, afin de s'assurer par exemple que les en-têtes et colonnes de tables suivent des convention de nommages communes. Il s'agit en réalité d'une activité très ancienne, puisque la communauté scientifique tient des catalogues d'astronomie depuis plusieurs siècles, où ces problématiques se sont posées très tôt.
Les avantages pratiques d'une telle standardisation, dont on rêve encore en physique des particules, sont évidents. Par exemple, dans le cadre de ses enseignements pour le master NPAC, Christian a fait travailler ses étudiants sur des programmes qui, bien que très simples, sont capables de manipuler des données d'astronomie réelles au moyen de bibliothèques standardisées. Ce serait impossible à envisager dans d'autres domaines.
Il y a eu pas mal de discussions sur HDF5, format binaire généraliste aujourd'hui très répandu, et qui pourrait à terme remplacer le FITS en astrophysique. Ce format pourrait notamment gérer des NTuples comparables à ceux de ROOT, permettant la persistence d'objets arbitraires.
Une différence avec ROOT, toutefois, est que les bibliothèques HDF5 ne peuvent pas générer automatiquement du code de sérialisation pour une classe C++ arbitraire. Mais est-ce vraiment désirable? Ne devrait-on pas, de toutes façons, passer du temps à réfléchir à son format de données sur disque et concevoir un schéma de données adapté à la persistence et au calcul?
Christian a récemment découvert que la société Databricks travaille sur l'utilisation de GPUs dans des programmes Spark. Leur activité est très centrée sur le deep learning, avec notamment l'intégration de la bibliothèque TensorFlow, mais elle pourrait avoir des retombées plus générales au niveau infrastructure: intégrer des GPUs au sein d'un cluster de machines virtuelles n'a rien d'évident, et ce serait très bien qu'ils oeuvrent à simplifier les choses à ce niveau.
Guy mentionne la sortie récente du Surface Studio, une tentative directe de Microsoft de marcher sur les plate-bandes d'Apple. Il s'agit d'un ordinateur fixe tout-en-un destiné à des tâches créatives, avec un design qui n'est pas sans rappeler celui des iMac G4, mais qui innove beaucoup au niveau de l'ergonomie.
On y trouve ainsi...
Microsoft ont aussi présenté le Surface Dial, un périphérique d'interface utilisateur Bluetooth de forme cylindrique qui peut jouer un rôle de potentiomètres virtuel ou donner accès à des menus de commandes secondaires.
Il faudra voir l'exécution et le support logiciel en pratique, mais force est de constater que tout ceci est plus innovant qu'un MacBook Pro dépourvu de la connectique la plus essentielle et n'offrant pour nouveauté qu'un petit bandeau tactile au-dessus du clavier.