Discussion :

[grunt2000]

En utilisant Spring boot et le plugin Maven spring-boot-maven-plugin,
je suis parvenu à déployer une application Spark autonome et auto-exécutable qui sur appel d'un service REST réalise les transformations dont j'ai besoin, et produit les résultats que j'attends.

À présent, il me faut la mettre en cluster, car elle n'a pour le moment qu'un seul noeud.

Aujourd'hui, mon application a ce fichier de configuration-ci au démarrage :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
spark.home=.
master.uri=local
server.port = 9090

Et ceux-ci servent dans la construction de mon sparkConf, associé à mon SparkContext :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SparkConf sparkConf = new SparkConf().setAppName("Mon application").setSparkHome(this.sparkHome).setMaster(this.masterUri);

J'ai également dans mon fichier de propriétés un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

deploy.mode=cluster

Mais qui n'est employé à rien, et n'a pas d'effet.
Lorsque l'application s'exécute, si je vais sur la page d'administration spark/jobs, je vois un job et les RDD qui vivent, mais pas de cluster ni de workers.

Comme l'application est déployée et déjà prête à faire le boulot sur commande, il n'y pas d'instructions shell
spark-master ou spark-submit à lancer en complément. Son fichier de propriétés semble suffire.
Dès qu'elle est déployée, elle peut fonctionner. Ça, je trouve que c'est un très grand agrément de Spring boot.

Mais maintenant, j'aimerais déployer cette application sur d'autres instances, en faisant varier le fichier de configuration, pour qu'elles puissent se mettre en cluster.
Comment dois-je m'y prendre ?

1) Dois-je déclarer une de mes machines Spark, arbitrairement, comme master et faire pointer toutes les autres dessus ?

2) Cette machine master a t-elle le droit d'avoir l'application elle aussi, ou doit-elle au contraire être vide, et ne contenir que Spark ?

3) Pourquoi un logiciel comme Zookeeper peut-il intervenir ? Il aurait l'air de pouvoir déclarer le cluster Spark à la place de Spark ? Ou je me trompe du tout au tout ?
De quelle manière, et pourquoi serait-ce intéressant ?

Merci beaucoup de votre aide,
je suis en défrichage, là. J'essaie de comprendre et de ranger les choses.

[Jidefix]

Hello,
comment compte-tu gérer ton cluster? Les principaux modes sont "standalone", "Yarn", "Mesos" et mainternant Kubernetes depuis Spark 2.3
J'imagine que tu veux commencer en standalone pour faire plus simple, du coup as-tu bien suivi cette procédure: https://spark.apache.org/docs/latest...tandalone.html ?

La première étape est d'avoir réellement un cluster qui tourne. Sur l'UI, voit-tu bien tous tes noeuds "workers" ? Pas la peine de lancer un job tant que tu ne vois pas les workers démarrés et connectés à ton master

Zookeeper est-un KeyValue store qui sert principalement à faire de la haute disponibilité sur divers composants (comme le spark master par exemple). Je te conseille de ne pas te pencher dessus tant que tu n'auras pas un cluster actif à plein temps, et que la haute disponibilité ne sera pas un pré-requis.

Jidéfix

[grunt2000]

J'essaie de mettre en place un cluster standalone.
J'ai compris que Zookeeper ne m'apporterait rien immédiatement, mais mes choix m'ont fait rencontrer des difficultés.

J'ai cru pouvoir déployer mon application sur des containers Docker : l'un master, les autres workers.
Mais quels que furent mes efforts en réglage de fichiers hosts, en définition de drivers, de binding adress, de local ip, rien n'aboutissait :
le résultat était toujours le même : le master se lançait, un worker tentait de le joindre, le master refusait la connexion.

J'ai compris que Docker "en mode normal" n'était peut-être pas ce qu'il fallait. Peut-être Docker compose permettrait de mettre en place un cluster plus facilement, mais j'ai quand même vu des gens qui avaient des difficultés avec, sur différents sites Internet où ils disaient leur expérience.

En un mot, je crois que je suis allé trop loin, trop compliqué.
Je vais me limiter à déployer le master sur une VM, un worker sur une autre VM, sans y mettre du Docker, et régler cela jusque ça fonctionne.

[Jidefix]

L'interet de docker est de pouvoir créer des images qui marche et les dupliquer X fois.
Créer une image qui correspond à ce que tu veux est vraiment la difficulté, et comme tu l'a bien conclus, une chose à la fois

La solution de la VM est pas mal, tant que ta machine le permet. Note que tu devrais aussi pouvoir lancer un master et un worker directement en local (une sorte de mono-cluster). Ça te permettrait de valider simplement ta config.

[grunt2000]

À mes débuts, j'avais fait une application Spark en Spring-boot auto-exécutable, qui embarquait son Tomcat (je pense) et tout allait bien.
En autonome, elle proposait un service REST et sitôt que l'utilisateur invoquait une de ses méthodes avec un argument, elle exécutait le nécessaire pour produire des résultats attendus :
l'application était déployée prête, sans passer par le shell Spark.

J'ai trouvé que c'était très agréable.
En conséquence, je ne voyais pas de workers. Je voyais la page jobs et stages et c'était tout. Impossible de voir si mes mes partitionnements, si mes stratégies d'interrogations étaient bonnes.
J'ai voulu débuter un cluster pour voir ce qui se passait réellement en condition plus proche de la réalité.
J'ai cru qu'il me suffisait de dire : "Très bien ! Maintenant, Je déploie une deuxième instance de cette application." et qu'avec quelques paramètres variant dans son application.properties, l'affaire serait jouée.
Ça n'est pas aussi simple que cela quand Docker est utilisé.

Mais ce que je voudrais autant que possible, c'est éviter de passer par le shell. Il me semble – mais je m'illusionne peut-être – que je devrais pourvoir déployer une instance de mon application en profil Spring "maître" et quelques-unes en profil Spring "worker", et qu'elles devraient être capables de se repérer, sans que je doivent en passer par le shell...

... que je n'ai encore jamais utilisé !

[Jidefix]

De notre côté on a développé un WebService REST qui publie des jobs sur un cluster distant (on n'utilise pas Spring en revanche, on a fait ça en mode commando).
Ça marche plutôt pas mal mais on a passé BEAUCOUP de temps à peaufiner tout ce qui est classpath, jar, config du job etc.
Mais c'est de l'enrobage, une fois que tu a creusé un peu le bouzin, tu vois qu'au fin fond des API java se cache toujours un "spark-submit", c'est pour ça que je te conseille de rester le plus simple possible au début: une fois que tu maîtrise la base c'est plus simple de passer par un framework plus complexe. Si tu fais les choses dans l'autre sens tu n'es pas prêt de pouvoir réagir en cas d'erreur.

Nous on utilise Yarn, mais il faut dire qu'en plus de Spark on utilise aussi la stack Hadoop (HDFS, Yarn, HBase). Du coup je maîtrise pas trop le Spark standalone