Spark cluster de fils vs client - comment choisir lequel utiliser?
Les spark docs ont le paragraphe suivant qui décrit la différence entre le client de fil et le groupe de fils:
Il existe deux modes de déploiement qui peuvent être utilisés pour lancer des applications Spark sur YARN. En mode cluster, le pilote Spark s'exécute à l'intérieur d'un processus maître d'application géré). par YARN sur le cluster et le client peut disparaître après le lancement de l'application. En mode client, le pilote s'exécute dans le processus client et le maître d'application n'est utilisé que pour demander des ressources à YARN.
Je suppose qu'il y a deux choix pour une raison. Si oui, comment choisissez-vous lequel utiliser?
Veuillez utiliser des faits pour justifier votre réponse afin que ces questions et réponses répondent aux exigences de stackoverflow.
Il y a quelques questions similaires sur stackoverflow, mais ces questions se concentrent sur la différence entre les deux approches, mais ne se concentrent pas sur le moment où une approche est plus appropriée que l'autre.
Une stratégie de déploiement courante consiste à soumettre votre application à partir d'une machine passerelle qui est physiquement colocalisée avec vos machines de travail (par exemple, nœud maître dans un cluster EC2 autonome). Dans cette configuration, le mode client est approprié. En mode client, le pilote est lancé directement dans le processus spark-submit qui agit en tant que client du cluster. L'entrée et la sortie de l'application sont attachées à la console. Ainsi, ce mode est particulièrement adapté aux applications qui impliquent le REPL (par exemple Spark Shell)).
Alternativement, si votre demande est soumise à partir d'une machine éloignée des machines de travail (par exemple localement sur votre ordinateur portable), il est courant d'utiliser le mode cluster pour minimiser la latence du réseau entre les pilotes et les exécuteurs. Notez que le mode cluster n'est actuellement pas pris en charge pour les clusters Mesos. Actuellement, seul YARN prend en charge le mode cluster pour les applications Python. "- Soumission des applications
Ce que je comprends de cela, c'est que les deux stratégies utilisent le cluster pour distribuer les tâches; la différence est où le "programme pilote" s'exécute: localement avec spark-submit, ou, également dans le cluster.
Quand vous devez utiliser l'un d'eux est détaillé dans la citation ci-dessus, mais j'ai aussi fait une autre chose: pour les gros pots, j'ai utilisé rsync pour les copier dans le cluster (ou même pour maîtriser le nœud) avec 100 fois le vitesse du réseau, puis soumis à partir du cluster. Cela peut être meilleur que le "mode cluster" pour les gros pots. Notez que le mode client ne transfère probablement pas le pot au maître. À ce stade, la différence entre les 2 est minime. Le mode client est probablement meilleur lorsque le programme du pilote est inactif la plupart du temps, pour utiliser pleinement les cœurs sur la machine locale et peut-être éviter de transférer le bocal vers le maître (même sur l'interface de bouclage, un gros bocal prend pas mal de secondes) . Et avec le mode client, vous pouvez transférer (rsync) le bocal sur n'importe quel nœud de cluster.
D'un autre côté, si le pilote est très intensif, en CPU ou en E/S, le mode cluster peut être plus approprié, pour mieux équilibrer le cluster (en mode client, la machine locale exécuterait à la fois le pilote et autant de travailleurs que possible , ce qui le rend surchargé et fait en sorte que les tâches locales seront plus lentes, ce qui fait que tout le travail peut finir par attendre quelques tâches de la machine locale).
Conclusion :
- Pour résumer, si je suis dans le même réseau local avec le cluster, j'utiliserais le mode client et le soumettrais depuis mon ordinateur portable. Si le cluster est éloigné, je soumettrais localement avec le mode cluster, ou
rsyncle pot au cluster distant et le soumettrais là, en mode client ou cluster, selon la lourdeur du programme pilote sur les ressources . *AFAIK Avec le programme du pilote exécuté dans le cluster, il est moins vulnérable aux déconnexions à distance qui font planter le pilote et l'ensemble du travail spark. Ceci est particulièrement utile pendant longtemps exécuter des travaux tels que des charges de travail de type traitement de flux.
Spark Jobs s'exécutant sur YARN
Lors de l'exécution de Spark sur YARN, chaque exécuteur Spark s'exécute comme un conteneur YARN. Où MapReduce planifie un conteneur et lance une machine virtuelle Java pour chaque tâche, Spark héberge plusieurs tâches dans le même conteneur. Cette approche accélère le démarrage de plusieurs tâches de plusieurs ordres de grandeur).
Spark prend en charge deux modes pour fonctionner sur YARN, le mode " yarn-cluster " et " yarn-client "mode. D'une manière générale, le mode cluster de fils a du sens pour les travaux de production, tandis que le mode client de fil a du sens pour les utilisations interactives et de débogage où vous souhaitez voir la sortie de votre application immédiatement.
Comprendre la différence nécessite une compréhension du concept Application Master de YARN. Dans YARN, chaque instance d'application a un processus Application Master, qui est le premier conteneur démarré pour cette application. L'application est chargée de demander des ressources au ResourceManager et, lorsqu'elle leur est allouée, de dire à NodeManagers de démarrer les conteneurs en son nom. Les maîtres d'application évitent d'avoir besoin d'un client actif - le processus de démarrage de l'application peut disparaître et la coordination se poursuit à partir d'un processus géré par YARN exécuté sur le cluster.
En mode cluster de fils , le pilote s'exécute dans le maître d'application. Cela signifie que le même processus est responsable de la conduite de l'application et de la demande de ressources à YARN, et ce processus s'exécute à l'intérieur d'un conteneur YARN. Le client qui démarre l'application n'a pas besoin de rester pendant toute sa durée de vie.
mode groupe de fils
Le mode de groupe de fils est pas bien adapté à l'utilisation de Spark interactivement, mais le mode client de fil est. Spark les applications qui nécessitent une entrée utilisateur, comme spark-Shell et PySpark, ont besoin du pilote Spark pour fonctionner à l'intérieur du processus client) qui lance l'application Spark. En mode client de fil, le maître d'application est simplement présent pour demander des conteneurs d'exécuteur à YARN. Le client communique avec ces conteneurs pour planifier le travail après leur démarrage:
mode client de fil
Ce tableau propose une liste concise des différences entre ces modes:
Référence: https://blog.cloudera.com/blog/2014/05/Apache-spark-resource-management-and-yarn-app-models/