web-dev-qa-db-fra.com

Apache Spark: Différences entre les modes de déploiement client et cluster

TL; DR: Dans un Spark cluster autonome, quelles sont les différences entre les modes de déploiement du client et du cluster? Je règle le mode d'exécution de mon application?

Nous avons un Spark cluster autonome avec trois machines, toutes avec Spark 1.6.1:

  • Une machine maître, où notre application est également exécutée en utilisant spark-submit
  • 2 machines de travail identiques

Dans le Spark Documentation , je lis:

(...) Pour les clusters autonomes, Spark prend actuellement en charge deux modes de déploiement. En mode client, le pilote est lancé dans le même processus que le client qui soumet l'application. Cependant, en mode cluster , le pilote est lancé à partir de l’un des processus Worker du cluster et le processus client se ferme dès qu’il s’acquitte de sa responsabilité de soumettre la demande sans attendre la fin de celle-ci.

Cependant, je ne comprends pas vraiment les différences pratiques en lisant ceci et je ne comprends pas quels sont les avantages et les inconvénients des différents modes de déploiement.

De plus, lorsque je lance mon application avec start-submit, même si je définis la propriété spark.submit.deployMode à "cluster", l’interface utilisateur de mon contexte Spark) affiche l’entrée suivante:

Context UI

Je ne suis donc pas en mesure de tester les deux modes pour voir les différences pratiques. Cela étant dit, mes questions sont les suivantes:

1) Quelles sont les différences pratiques entre le mode de déploiement Spark en mode autonome client et le mode cluster? Quels sont les avantages et les inconvénients de l'utilisation de chacun?

2) Comment choisir l’application sur laquelle mon application sera exécutée, en utilisant spark-submit?

apache-sparkapache-spark-standalone
36
Daniel de Paula

Quelles sont les différences pratiques entre Spark Mode de déploiement du client autonome et mode de déploiement du cluster? Quels sont les avantages et les inconvénients de chaque utilisation?

Essayons de regarder les différences entre le mode client et le mode cluster.

Client:

  • Le pilote s'exécute sur un serveur dédié (nœud principal) au sein d'un processus dédié. Cela signifie qu'il dispose de toutes les ressources disponibles pour exécuter les travaux.
  • Le pilote ouvre un serveur HTTP Netty dédié et distribue les fichiers JAR spécifiés à tous les nœuds de travail (gros avantage).
  • Étant donné que le nœud principal possède ses propres ressources dédiées, vous n'avez pas besoin de "dépenser" des ressources de travail pour le programme Driver.
  • Si le processus du pilote meurt, vous avez besoin d'un système de surveillance externe pour réinitialiser son exécution.

Grappe:

  • Le pilote s'exécute sur l'un des nœuds de travail du cluster. Le travailleur est choisi par le maître leader
  • Le pilote s’exécute en tant que processus autonome dédié à l’intérieur du travailleur .
  • Les programmes de pilote prennent au moins 1 cœur et une quantité de mémoire dédiée de l’un des travailleurs (celle-ci peut être configurée).
  • Le programme du pilote peut être surveillé à partir du nœud maître à l’aide de l’indicateur --supervise Et être réinitialisé au cas où il mourrait.
  • Lorsque vous travaillez en mode cluster, tous les fichiers JAR liés à l'exécution de votre application doivent être accessibles au public pour tous les travailleurs. Cela signifie que vous pouvez les placer manuellement dans un emplacement partagé ou dans un dossier pour chacun des travailleurs.

Quel est le meilleur? Pas sûr, c'est à vous d'expérimenter et de décider. Ce n’est pas une meilleure décision ici, vous gagnez des choses de l’ancien à l’autre, c’est à vous de voir lequel convient le mieux à votre cas d’utilisation.

Comment choisir celui sur lequel mon application sera exécutée, en utilisant spark-submit

Le moyen de choisir le mode dans lequel exécuter est en utilisant l'indicateur --deploy-mode. À partir de la page Spark Configuration :

/bin/spark-submit \
  --class <main-class>
  --master <master-url> \
  --deploy-mode <deploy-mode> \
  --conf <key>=<value> \
  ... # other options
  <application-jar> \
  [application-arguments]
53
Yuval Itzchakov

Supposons que vous effectuiez un envoi spark dans EMR en faisant SSH sur le nœud maître). Si vous fournissez l'option --deploy-mode cluster, les événements suivants se produiront.

  1. Vous ne pourrez pas voir les journaux détaillés dans le terminal.
  2. Le pilote n'étant pas créé dans le maître lui-même, vous ne pourrez pas terminer le travail à partir du terminal.

Mais dans le cas du client --deploy-mode:

  1. Vous pourrez voir les journaux détaillés dans le terminal.
  2. Vous pourrez terminer le travail à partir du terminal lui-même.

Ce sont les choses fondamentales que j'ai remarquées jusqu'à présent.

2
Suman Sushovan

J'ai aussi le même scénario, ici le nœud maître utilise un cluster ec2 autonome. Dans cette configuration, le mode client est approprié. Dans ce pilote est lancé directement avec dans le processus spark-submit qui agit en tant que client pour le cluster. L’entrée et la sortie de l’application sont rattachées à la console. Ce mode est donc particulièrement adapté aux applications qui impliquent le REPL.

Sinon, si votre application est soumise à partir d'une machine éloignée des machines subordonnées, il est assez courant d'utiliser le mode cluster pour réduire le pilote et l'exécuteur n/b de latence du réseau.

1
jeevan kishore