Le namenode stocke ses informations dans /hadoop/dfs/name. Il faut donc monter ce dossier sur le GlusterFS afin de préserver ses données entre chaque machine.
Les Datanodes stockent les blocs dans /hadoop/dfs/data. On utilise donc un volume qui va rester sur chaque machine et qui sera remonté au démarage du datanode. Attention par contre il n’est pas possible de démarer plusieurs datanode par machine, cela créerais des conflits. Il est aussi déconseillé d’utilisé le mode réplica qui peut lui aussi aboutir à plusieurs datanode par machine (plutot créer des contraintes)
Une fois cela fait il est possible de supprimer les service namenode et datanode, de les recréer et on se retrouve avec exactement le même état. Cela peut donc servire en cas de mise à jour de Hadoop (docker service update –image …)
Article d’un développeur Spark - astuces Comment faire un Join sans shuffle Explication Broadcast
Attention le broadcast en efficace quand un fait un join entre une petite table et un grande en broadcastant la plus petite. Sinon il y a un gros risque de Out of Memory en plus d’utiliser probablement encore plus de ressources qu’un shuffle.
La solution serais que chaque noeud accède directement aux partitions necessaires pour limiter le shuffling on va donc utiliser la fonction repartition.
Pour accéder aux interfaces des différents worker plutot que de créer plusieurs dixaines d’entrée dans le proxy Nginx j’ai préféré utiliser un proxy Squid :
docker service create --name squid \
--publish 3128:3128 \
--network spark-net \
sameersbn/squidIl suffit ensuite de s’y connecter avec par exemple FoxyProxy et d’indiquer cds-stage-ms4:3128 dans l’adresse du proxy ou l’adresse de n’importe quelle machine du Docker Swarm.