Tags:
create new tag
, view all tags
-- 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

Topic revision: r3 - 2017-10-16 - CorentinSanchez
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback