C'est vrai ... on en a beaucoup discuté.
Cependant, il y a beaucoup d'ambiguïté et certaines des réponses fournies ... y compris la duplication des références jar dans la configuration ou les options jars / executor / driver.
Les détails ambigus et / ou omis
Suite à l'ambiguïté, les détails peu clairs et / ou omis doivent être clarifiés pour chaque option:
- Comment ClassPath est affecté
- Chauffeur
- Executor (pour les tâches en cours)
- Tous les deux
- pas du tout
- Caractère de séparation: virgule, deux-points, point-virgule
- Si les fichiers fournis sont automatiquement distribués
- pour les tâches (à chaque exécuteur testamentaire)
- pour le pilote distant (s'il est exécuté en mode cluster)
- type d'URI accepté: fichier local, hdfs, http, etc.
- S'il est copié dans un emplacement commun, où se trouve cet emplacement (hdfs, local?)
Les options sur lesquelles il affecte:
--jars
SparkContext.addJar(...)
méthodeSparkContext.addFile(...)
méthode--conf spark.driver.extraClassPath=...
ou--driver-class-path ...
--conf spark.driver.extraLibraryPath=...
, ou--driver-library-path ...
--conf spark.executor.extraClassPath=...
--conf spark.executor.extraLibraryPath=...
- à ne pas oublier, le dernier paramètre du spark-submit est également un fichier .jar.
Je sais où je peux trouver la documentation principale de Spark , et en particulier sur la façon de soumettre , les options disponibles, ainsi que le JavaDoc . Cependant, cela m'a laissé encore pas mal de trous, même si cela a répondu partiellement aussi.
J'espère que ce n'est pas si complexe et que quelqu'un pourra me donner une réponse claire et concise.
Si je devais deviner à partir de la documentation, il semble que --jars
, et les méthodes SparkContext
addJar
et addFile
sont celles qui distribueront automatiquement les fichiers, tandis que les autres options ne font que modifier le ClassPath.
Serait-il prudent de supposer que pour plus de simplicité, je peux ajouter des fichiers jar d'application supplémentaires en utilisant les 3 options principales en même temps:
spark-submit --jar additional1.jar,additional2.jar \
--driver-library-path additional1.jar:additional2.jar \
--conf spark.executor.extraLibraryPath=additional1.jar:additional2.jar \
--class MyClass main-application.jar
J'ai trouvé un bel article sur une réponse à une autre publication . Cependant, rien de nouveau n'a été appris. L'affiche fait une bonne remarque sur la différence entre le pilote local (yarn-client) et le pilote distant (yarn-cluster). Il est absolument important de garder à l'esprit.
Réponses:
ClassPath:
ClassPath est affecté en fonction de ce que vous fournissez. Il existe plusieurs façons de définir quelque chose sur le chemin de classe:
spark.driver.extraClassPath
ou c'est un alias--driver-class-path
pour définir des chemins de classe supplémentaires sur le nœud exécutant le pilote.spark.executor.extraClassPath
pour définir un chemin de classe supplémentaire sur les nœuds Worker.Si vous voulez qu'un certain JAR soit effectué à la fois sur le maître et sur le travailleur, vous devez les spécifier séparément dans les DEUX indicateurs.
Caractère de séparation:
En suivant les mêmes règles que la JVM :
:
--conf "spark.driver.extraClassPath=/opt/prog/hadoop-aws-2.7.1.jar:/opt/prog/aws-java-sdk-1.10.50.jar"
;
--conf "spark.driver.extraClassPath=/opt/prog/hadoop-aws-2.7.1.jar;/opt/prog/aws-java-sdk-1.10.50.jar"
Distribution de fichiers:
Cela dépend du mode sous lequel vous exécutez votre travail:
Mode client - Spark déclenche un serveur Netty HTTP qui distribue les fichiers au démarrage pour chacun des nœuds de travail. Vous pouvez le voir lorsque vous démarrez votre tâche Spark:
Mode cluster - En mode cluster, Spark a sélectionné un nœud Worker leader sur lequel exécuter le processus Driver. Cela signifie que le travail ne s'exécute pas directement à partir du nœud maître. Ici, Spark ne définira pas de serveur HTTP. Vous devez rendre manuellement votre JARS disponible à tous les nœuds de travail via HDFS / S3 / Autres sources qui sont disponibles pour tous les nœuds.
URI acceptés pour les fichiers
Dans "Soumettre des demandes" , la documentation Spark explique bien les préfixes acceptés pour les fichiers:
Comme indiqué, les fichiers JAR sont copiés dans le répertoire de travail de chaque nœud Worker. Où est-ce exactement? C'est généralement sous
/var/run/spark/work
, vous les verrez comme ceci:Et quand vous regardez à l'intérieur, vous verrez tous les JAR que vous avez déployés:
Options affectées:
La chose la plus importante à comprendre est la priorité . Si vous passez une propriété via le code, elle prévaudra sur toute option que vous spécifiez via
spark-submit
. Ceci est mentionné dans la documentation Spark:Assurez-vous donc de définir ces valeurs aux bons endroits, de sorte que vous ne serez pas surpris si l'une a priorité sur l'autre.
Permet d'analyser chaque option en question:
--jars
vsSparkContext.addJar
: Ils sont identiques, un seul est défini via la soumission d'étincelle et un via le code. Choisissez celui qui vous convient le mieux. Une chose importante à noter est que l'utilisation de l'une de ces options n'ajoute pas le JAR au chemin de classe de votre pilote / exécuteur , vous devrez les ajouter explicitement en utilisant laextraClassPath
configuration sur les deux.SparkContext.addJar
vsSparkContext.addFile
: utilisez le premier lorsque vous avez une dépendance qui doit être utilisée avec votre code. Utilisez ce dernier lorsque vous souhaitez simplement transmettre un fichier arbitraire à vos nœuds de travail, ce qui n'est pas une dépendance d'exécution dans votre code.--conf spark.driver.extraClassPath=...
ou--driver-class-path
: ce sont des alias, peu importe celui que vous choisissez--conf spark.driver.extraLibraryPath=..., or --driver-library-path ...
Idem que ci-dessus, alias.--conf spark.executor.extraClassPath=...
: Utilisez cette option lorsque vous avez une dépendance qui ne peut pas être incluse dans un JAR uber (par exemple, car il y a des conflits de compilation entre les versions de bibliothèque) et que vous devez charger au moment de l'exécution.--conf spark.executor.extraLibraryPath=...
Ceci est passé commejava.library.path
option pour la JVM. Utilisez cette option lorsque vous avez besoin d'un chemin de bibliothèque visible par la JVM.Vous pouvez supposer cela en toute sécurité uniquement pour le mode client et non pour le mode cluster. Comme je l'ai déjà dit. De plus, l'exemple que vous avez donné contient des arguments redondants. Par exemple, passer des fichiers JAR à
--driver-library-path
est inutile, vous devez les transmettre àextraClassPath
si vous voulez qu'ils soient sur votre chemin de classe. En fin de compte, ce que vous voulez faire lorsque vous déployez des JAR externes sur le pilote et le worker est:la source
MANIFEST.MF
fichier)?assemblyMergeStrategy
et en sélectionnant les classes dont j'ai besoin s'il y a des conflits. Je recommande généralement la même chose.--jars
drapeau et au chemin de classe du pilote / exécuteur.zeppelin-env.sh
et ajouté--jars
àSPARK_SUBMIT_OPTIONS
. Ça a marché. Le format URI que j'utilise est--jars=local:///mnt/dir/file.jar
.Une autre approche
spark 2.1.0
consiste à utiliser--conf spark.driver.userClassPathFirst=true
pendant Spark-submit qui change la priorité de la charge de dépendance, et donc le comportement du Spark-Job, en donnant la priorité aux jars que l'utilisateur ajoute au class-path avec l'--jars
option.la source
Les autres options Spark configurables relatives aux fichiers jars et classpath, en cas de
yarn
mode de déploiement, sont les suivantes.
Les utilisateurs peuvent configurer ce paramètre pour spécifier leurs fichiers JAR, qui inturn sont inclus dans le chemin de classe du pilote Spark.
la source
Lorsque vous utilisez spark-submit avec --master yarn-cluster, le fichier jar de l'application ainsi que tous les fichiers jar inclus avec l'option --jars seront automatiquement transférés vers le cluster. Les URL fournies après --jars doivent être séparées par des virgules. Cette liste est incluse dans les chemins de classe du pilote et de l'exécuteur
Exemple :
spark-submit --master yarn-cluster --jars ../lib/misc.jar, ../lib/test.jar --class MainClass MainApp.jar
https://spark.apache.org/docs/latest/submitting-applications.html
la source
Il y a une restriction sur l'utilisation
--jars
: si vous souhaitez spécifier un répertoire pour l'emplacement dujar/xml
fichier, cela n'autorise pas les extensions de répertoire. Cela signifie que vous devez spécifier un chemin absolu pour chaque fichier jar.Si vous spécifiez
--driver-class-path
et que vous exécutez en mode cluster de fils, la classe de pilote n'est pas mise à jour. Nous pouvons vérifier si le chemin de classe est mis à jour ou non sous Spark ui ou Spark History Server sous l'onglet environnement.L'option qui a fonctionné pour moi pour passer des jars contenant des extensions de répertoire et qui fonctionnait en mode cluster de fils était une
--conf
option. Il est préférable de transmettre les chemins de classe du pilote et de l'exécuteur en tant que--conf
, ce qui les ajoute à l'objet de session Spark lui-même et ces chemins sont reflétés sur la configuration Spark. Mais assurez-vous de placer les fichiers JAR sur le même chemin à travers le cluster.la source
Alors que nous soumettons des travaux Spark à l'aide de l'utilitaire spark-submit, il existe une option
--jars
. En utilisant cette option, nous pouvons passer un fichier jar pour déclencher des applications.la source
—jar
option a été mentionné par l'affiche originale, plus discuté de manière beaucoup plus détaillée par plus d'une réponse. Il ne semble pas que vous fournissiez quelque chose de nouveau?