--
CorentinSanchez - 2017-10-16
Exposition du problème
Lors du crossmatch spark, on est face à un problème de collocation de données : Pour limiter le schuffle, on voudrait stocker les mêmes partitions du ciel de chaque catalogue sur les mêmes Datanodes. Ainsi, lorsde l'exécution des jobs spark, chaque worker pourrait charger les partitions des deux catalogue-source présentes sur son datanode local sans avoir à les rapatrier depuis l'autre bout du cluster. On aurait ainsi un gain considérable en temps d'exécution, le réseau était bien plus lent que les acces disque. Il reste toujours le problème de schuffle pour la duplication des sources, mais nous le considérons comme nécéssaire.
On recherche donc un moyen de contraindre hdfs à adopter, quand c'est possible, une distribution arrangeante, diminuant le scuffle à l'exécution.
Méthode "bricolage en python", déjà visitée par Paul
Cette méthode consiste à ecrire un script en python qui :
-éteind hdfs
-désactive le balancer
-procède au block schuffling à la main
-rallume hdfs
Comme on peut s'en apperçevoir, c'est vraiment du bricolage, on voudrait trouver une méthode plus sérieuse.
Autre piste de bricolage possible : Influencer la localisation des jobs spark.
https://ofirm.wordpress.com/2014/01/18/exploring-hdfs-block-placement-policy/
Il y a toujours une réplique qui est sauvegardée sur le datanode qui a ordonné l'enregistrement. Si une meme partition du ciel est toujours traitée par un meme worker spark, on aura toujours une réplique de la zone du ciel en question de chaque catalogue sur le bon datanode.
Mais... ça parait compliqué de forcer Spark à localiser ses jobs selon notre stratégie
Piste : Le block pinning natif d'hdfs
hdfs dispose d'une foctionnalité de block pinning, qui consiste à garder ce block au même endroit ( plus d'action du balancer sur lui ) dès qu'il arrive à un endroit stratégique. Le problème est de définir cette stratégie. Je ne suis pas sur que ce soit possible, mis à part la stratégie native qui prend en compte la balance du cluster et la provenance du block.
https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.0/bk_hdfs-administration/content/configuring_balancer.html
Piste : la hadoop block placement policy
Il semblerait qu'on puisse customiser la politique de placement d'hdfs
https://stackoverflow.com/questions/33978825/when-is-the-block-placement-policy-used
il faudrait réécrire une politique de placement qui hérite de cette classe abstraite :
https://github.com/facebookarchive/hadoop-20/blob/master/src/hdfs/org/apache/hadoop/hdfs/server/namenode/BlockPlacementPolicy.java
Piste : Hive et Bucketting
Piste : Les DataFrames Spark et le Bucketting