14 Septembre 2016

Correction du bug dans le programme de crossmatch

Page JavaDoc

Le bug est lié à un changement dans la bibliothèque org.apache.spark.api.java où une méthode devais retourner un Iterable dans la version 1.6 mais doit retourner un Iterator dans la version 2.11

Fonctionnement du programme de crossmatch

Maintenant que le programme fonctionne on peut essayer de comprendre son fonctionnement.

Pour commencer lors du lancement du programme la classe cds.xmatch.spark.CrossMatch est appellée ce sera notre point de départ.

Fonctionnement de base de Spark avec Java
Fonctionnement crossmatch (EN)

Preprocess

• Les données sont ordonnée dans un RDD (objet Spark)
• Le ciel est divisé en pixel avec healpix afin de subdiviser en partie plus petites pour faciliter le crossmatch (chaque pixel correspond à une zone losange et peut contenir des objets stellaires).
• Les données ainsi ordonnées sont stockées sur le système de fichier distribué hdfs

Crossmatch

• Les données des deux catalogues précédement analysés sont chargées dans un RDD
• Les objets pouvant se trouver dans plusieurs pixels (le rayon définit au lancement dépasse sur d’autre pixels) sont dupliqués afin de pouvoir êtres associés à des objets des pixels voisins.
• Il est alors possible d’apliquer la methode join entre ces deux objet pour avoir une correspondance par rapport aux pixels
• On applique ensuite imédiatement la méthode filter qui permet de calculer précisement si les rayons coincident
• Le résultat est stocké sur hdfs

Test de performance

Commande pour modifier le nombre de noeuds :

docker service scale spark-worker=5

Attention ces tests sont effectués sur 6 machines de bureau dont la configuration et les logiciels (ou services) installés peuvent influer sur les résultats. Pour avoir des résultats plus fiables il faudrais avoir des serveurs dédiés à Docker.

6 workers :

• 147.498 sec
• 275.872 sec
• 213.979 sec

20 workers :

Est-il efficace de démarer énormément de workers plutot que un par noeud

• 186.609 sec
• 189.156 sec

Ces résultats semblent plus constants (une bonne solution serait peut-être un worker par core)

5 workers :

• 198.511 sec

Docker s’est mis à avoir des bugs à partir de la (normalement corrigés dans la prochaine version qui devrais sortir d’ici peu)

Réseau

Les différentes machines sont cablées en 100 MBit/s cela constitue le principal facteur limitant comme on peut l’observer sur ce graphique la vitesse du réseau arrive à un palier (entre 11 et 12 Mo/s, par rapport à 12,5 en théorique):

Améliorations possibles

• stockage de l’état du namenode sur un système de fichier distribué décentralisé (type infinit ou glusterfs) afin de pouvoir résister à une panne. Cette solution est probablement plus simple à mettre en oeuvre qu’une redondance du namenode tout en offrant plus de sécurité.