Configuration Talend ou Spark submit : quelle est la différence ?

Configuration Talend ou Spark submit : quelle est la différence ?

  • Petros Nomikos
    I have 3 years of experience with installation, configuration, and troubleshooting of Big Data platforms such as Cloudera, MapR, and HortonWorks. I joined Talend in 2014, and prior to Talend I held positions as manager of technical support, and project manager for data warehouse implementations. In my current role, I assist companies in understanding how to implement Talend in their Big Data Ecosystem.

Dans mon article précédent, « Talend et Apache Spark : Introduction technique », je vous ai expliqué l'équivalence entre les jobs Spark Talend et la commande Spark submit. Dans cet article, je souhaite continuer à évaluer les configurations Spark Talend et la commande Apache Spark submit. Nous allons tout d'abord voir comment vous pouvez mapper les options de l'onglet Spark Configuration (Configuration Spark) dans le job Spark Talend avec les arguments que vous pouvez passer dans une commande Spark submit, et discuter de leur utilisation. C'est parti.

Différences entre les commandes

Lorsque vous exécutez un job Apache Spark (comme l'un des exemples Apache Spark présentés par défaut dans le cluster Hadoop et utilisés pour vérifier que Spark fonctionne correctement) dans votre environnement, vous utilisez l'une des commandes suivantes :

export HADOOP_CONF_DIR=XXX./bin/spark-submit  --class org.apache.spark.examples.SparkPi --master yarn --deploy-mode client  --executor-memory 5G --num-executors 10 /path/to/examples.jar 1000

Les deux commandes ci-dessus définissent le répertoire à partir duquel notre job Spark submit lit les fichiers de configuration du cluster. Nous lançons ensuite notre commande Spark submit, qui exécute Spark sur un cluster YARN en mode client. Dix exécuteurs, avec chacun 5 Go de mémoire, sont utilisés pour exécuter notre exemple de job Spark.

Voyons maintenant comment ce même exemple de job Spark s'exécute dans Talend. Lorsque nous exécutons un exemple de job Talend, comme celui présenté ci-dessus, toutes les informations de configuration Spark sont entrées dans l'onglet suivant :

Figure 1

Cela pose quelques questions. Comment les informations que nous entrons dans Talend sont-elles mappées à ce que nous entrons sur le terminal pour exécuter un job Spark ? Comment pouvons-nous savoir de combien d'exécuteurs et de quelle quantité de mémoire nous avons besoin ? Qu'en est-il du dépannage ? Nous répondrons à toutes ces questions dans cet article.

Avant toute chose, je souhaite vous présenter des options Spark submit qui seront utilisées tout au long de cet article. Selon la documentation Apache Spark, il s'agit des options les plus fréquemment passées à un script Spark submit :

--class : il s'agit du point d'entrée principal pour votre application Spark.

--master : dans cette option, vous indiquez si votre maître Spark est en mode Standalone ou si vous utilisez Spark sur YARN.

--deploy-mode : comme indiqué dans l'article précédent, cette option se rapporte aux deux différents modes YARN disponibles et spécifie comment votre pilote Spark sera déployé.

--conf : dans cette option, vous passez des informations de configuration Spark supplémentaires pour votre job, par exemple spark.executor.userClassPathFirst=true.

--application-jar : il s'agit du chemin d'accès à votre code compilé Spark qu'Apache Spark doit exécuter.

--application-arguments : dans cette option, vous passez les arguments spécifiques à votre code Spark.

Voyons à présent comment les options ci-dessus sont utilisées dans un job Spark Talend. Vous remarquerez que, dans l'onglet Spark Configuration (Configuration Spark), les différentes options disponibles sont classées par catégories :

  1. Cluster Version (Version du cluster)
  2. Configuration
  3. Authentication (Authentification)
  4. Tuning (Mise au point)
  5. Spark History (Historique Spark)

Cluster Version (Version du cluster)

Commençons par l'une des premières options disponibles dans la catégorie Cluster Version (Version du Cluster) pour un job Talend. Il s'agit de l'option « Spark Mode » (Mode Spark).

Dans cette option, vous pouvez indiquer si votre maître Spark est sur YARN ou si vous utilisez Spark en mode Standalone. Cette option correspond à l'option --deploy-mode précédemment décrite pour Spark submit, ainsi qu'à l'option --master. Par exemple, si vous sélectionnez le mode Spark YARN Client (Client YARN) dans Talend, cela équivaut à spécifier dans Spark submit --master yarn --deploy-mode client. Si vous sélectionnez le mode Standalone, Talend vous demande d'entrer les informations de votre URL maître Spark, comme vous le feriez pour Spark submit. Cela revient à passer l'argument suivant dans Spark submit : --master spark://127.0.0.1:7077.

Configuration

Dans Talend, la catégorie Configuration regroupe les informations suivantes :

Pour ces premières options, vous devez entrer des informations sur le gestionnaire de ressources, l'adresse de l'ordonnanceur, l'adresse de l'historique du job et le répertoire de préparation.

Dans une commande Spark submit, toutes ces informations sont données au job Spark via HADOOP_CONF_DIR. Nous pouvons soit définir cette variable d'environnement avant d'exécuter notre script Spark submit, soit la configurer comme une variable d'environnement permanente dans /etc/environment ou /etc/profile. Notez que toutes ces variables d'environnement sont également définies dans un script shell d'environnement, consulté par les jobs Spark lors de l'exécution d'une commande Spark submit. Ce fichier est nommé « spark-env.sh » et est toujours situé dans le répertoire /etc/spark/conf sur les hôtes Spark. Voici un exemple de ce fichier de configuration dans le cluster :

L'option suivante vous propose de définir le répertoire principal Hadoop, car cela est parfois nécessaire pour les jobs Spark. Dans les jobs Spark submit, cette information est passée de la même manière, mais le nom de la variable d'environnement est HADOOP_HOME. Dans un job Spark Talend, les options représentées par les cases à cocher ont la même fonction que le fichier spark-env.sh pour le script Spark submit, qui se procure ces valeurs au moment de l'exécution de votre job Spark.

La dernière option de cette catégorie dans la configuration Spark Talend permet de définir le nom d'hôte ou l'adresse IP du pilote Spark. Cette option est utile lorsque le système sur lequel le job Spark est exécuté utilise des adresses IP internes et externes, ou en cas de problèmes de résolution du nom d'hôte qui pourraient empêcher le maître et les exécuteurs Spark de se connecter à leur tour au pilote Spark.

Par défaut, si cette case n'est pas cochée, le job essaiera d'utiliser le nom d'hôte local et de résoudre son adresse IP. Comme mentionné dans l'article précédent, Talend utilise actuellement YARN en mode client : le pilote Spark s'exécute donc toujours sur le système depuis lequel le job Spark est démarré. Dans une commande Spark submit, cela reviendrait à utiliser l'option --conf, puis à fournir la paire clé-valeur spark.driver.host=127.0.0.1. Vous connaissez à présent toutes les options du sous-menu « Configuration » de l'onglet de configuration Spark.

Authentication (Authentification)

Dans la catégorie «Authentication » (Authentification), une option propose de sélectionner la méthode d’authentification utilisée par notre cluster Hadoop :

Si nous ne cochons pas cette case, le job suppose qu’une authentification simple est utilisée par le cluster et tente de se connecter au cluster Hadoop avec le nom d'utilisateur correspondant. Dans une commande Spark submit, ces informations seraient incluses dans la configuration Spark de l’application que nous envoyons.

Si au contraire nous sélectionnons l’option Use Kerberos authentication (Utiliser l'authentification Kerberos), le système nous demande les informations suivantes :

Ces deux premiers champs correspondent aux noms des principaux de service utilisés par le gestionnaire de ressources et l’historique du job. Si l’option « keytab » n’est pas sélectionnée, le job en s’exécutant recherche le cache de tickets Kerberos dans le système sur lequel il s'exécute, et recherche également des tickets Kerberos valides à utiliser dans le cache spécifique à l’utilisateur ayant démarré le job.

Si l’option « keytab » est sélectionnée, vous devez spécifier le keytab à utiliser ainsi que le nom de principal de l’utilisateur correspondant. Ainsi, lorsque le job démarre, il génère un ticket Kerberos basé sur le keytab pour le principal qui sera utilisé par le job. Pour une commande Spark submit, dans votre application, vous passez dans la configuration Spark que vous définissez le code que Kerberos utilise pour l’authentification. Avant d’exécuter la commande Spark submit, vous exécutez la commande Kerberos kinit pour générer un ticket si vous n’utilisez pas de keytab. Si vous en utilisez un, vous pouvez soit exécuter la commande kinit avec les indicateurs nécessaires pour utiliser un keytab pour la génération de ticket, soit spécifier d'utiliser le keytab pour la connexion dans votre code d’application Spark.

Tuning (Mise au point)

Passons maintenant à la catégorie Tuning (Mise au point). Talend propose l’option Set tuning properties (Configurer les propriétés de mise au point), qui est toujours désactivée par défaut. Lorsque cette option Set tuning properties (Configurer les propriétés de mise au point) est activée, des options supplémentaires s’affichent automatiquement :

Voyons quelle est l’équivalence de chacune de ces options pour une commande Spark submit.

La première option, Set application master tuning properties (Définir les propriétés de mise au point du maître d’application) permet à un utilisateur de définir la quantité de mémoire et le nombre de cœurs que le maître d’application YARN doit utiliser.

Le but de l’instance maître d’application YARN est de négocier les ressources depuis le gestionnaire de ressources, puis de communiquer avec les gestionnaires de nœuds pour surveiller l’utilisation des ressources et exécuter les conteneurs. Si cette option n’est pas définie, 512 Mo et 1 cœur sont attribués par défaut. Dans une commande Spark submit, cela équivaut à utiliser l’option --conf, puis à lui passer les deux paires clé-valeur « spark.yarn.am.memory=512m,spark.yarn.am.cores=1 ».

Nous pouvons également définir d’autres paramètres, dont le nombre d’exécuteurs, la quantité de mémoire et le nombre de cœurs par exécuteur, ainsi que la quantité de surcharge mémoire qui peut être allouée à chaque exécuteur.

Les valeurs par défaut sont de deux exécuteurs, 1 Go de mémoire par exécuteur et 1 cœur par exécuteur. La surcharge mémoire par défaut est de 10 % de la mémoire de l’exécuteur, avec un minimum de 384 Mo. Pour réaliser la même chose dans une commande Spark submit, nous avons deux façons de procéder. La première est d’utiliser, comme dans l’exemple ci-dessus, --executor-memory 5G --num-executors 10. La seconde est de passer les valeurs à l’aide d’une option --confpuis d’utiliser les paires clé-valeur « spark.executor.instances=2, spark.executor.cores=1, spark.executor.memory=2, spark.yarn.executor.memoryOverhead=384m ».

L’option suivante dans Talend concerne l’allocation des ressources YARN.

Les valeurs proposées sont Auto, Fixed (Fixe) et Dynamic (Dynamique). Que cela signifie-t-il ? Spark nous permet de choisir l’allocation des exécuteurs.

Si la valeur Auto est sélectionnée, l’option permettant de définir le nombre d’exécuteurs disparaît : deux exécuteurs sont utilisés (le nombre alloué par défaut par YARN). Si la valeur est Fixed (Fixe), nous pouvons définir le nombre d’exécuteurs que notre job doit demander. La dernière valeur, Dynamic (Dynamique), nous permet d'utiliser le mécanisme proposé par Spark permettant d’ajuster de manière dynamique le nombre d’exécuteurs alloués à notre job Spark, selon les besoins au moment de l’exécution. Cela signifie que notre application peut demander plus d’exécuteurs si nécessaire au cours de son exécution, puis les libérer pour YARN lorsqu’elle n’en a plus besoin. Lorsque cette option est sélectionnée, elle présente la configuration suivante :

Nous pouvons sélectionner le nombre d'exécuteurs à demander à YARN au départ, et spécifier le nombre minimum d’exécuteurs pour le job ainsi que le maximum selon la charge de travail de notre job lorsqu’il est exécuté par Spark. Afin de passer l’option dynamique dans Spark submit, vous devez utiliser l’option --conf puis les paires clé-valeur « spark.dynamicAllocation.enabled=true, spark.shuffle.service.enabled=true ». Comme indiqué dans la documentation Spark (https://spark.apache.org/docs/1.6.1/job-scheduling.html#dynamic-resource-allocation target="_blank"), ces deux propriétés sont requises pour utiliser cette fonctionnalité.

Toujours dans cette catégorie « Tuning » (Mise au point) dans l’onglet « Spark Configuration » (Configuration Spark) de Talend, l’option suivante est Set Web UI port (Configurer le port de l’interface Web). Lorsqu’elle est sélectionnée, elle permet de spécifier un port, la valeur par défaut étant 4040. Lorsque cette option est sélectionnée et que votre application Spark s’exécute, le pilote Spark démarre une interface Web qui peut être utilisée pour surveiller votre job Spark en cours et inspecter l’exécution du job. Si l’option n’est pas sélectionnée, l’application essaie d’utiliser le port par défaut mentionné ci-dessus et augmente le numéro de port jusqu'à ce qu'elle trouve un port ouvert. Cette option est utile si vous savez que le port 4040 n’est pas disponible dans le système sur lequel vous exécutez votre job Spark et que vous souhaitez spécifier un port à utiliser, plutôt que de laisser l'application Spark tenter de trouver un port ouvert. Dans Spark submit, vous utilisez l’option --conf puis la paire clé/valeur « spark.ui.port=4041» pour définir une fonctionnalité équivalente.

L’option suivante est Broadcast Factory (Fabrique de diffusion) et elle propose différentes valeurs.

Alors, quelle est la fonction de cette option Broadcast Factory (Fabrique de diffusion)? Elle permet de définir la diffusion des variables entre les exécuteurs du cluster. L’objectif ici est de distribuer rapidement et efficacement une variable pour éviter qu'un seul nœud se charge de toutes les tâches. Trois valeurs sont proposées pour cette option. La première, « Auto », ne modifie pas le comportement par défaut. La deuxième et la troisième permettent de choisir Torrent ou HTTP comme fabrique de diffusion. Dans Spark submit, cela équivaut à passer l’option --conf puis à utiliser la paire clé/valeur « spark.broadcast.factory=org.apache.spark.broadcast.TorrentBroadcastFactory » si vous ne souhaitez pas que la fabrique de diffusion par défaut (généralement Torrent) soit utilisée.

La dernière option de cette catégorie propose de personnaliser le sérialiseur Spark à utiliser :

Comme décrit dans la documentation Spark (https://spark.apache.org/docs/latest/tuning.html#data-serialization), la sérialisation dans Spark est un processus important permettant de sérialiser les données entre exécuteurs pour augmenter les performances dans un environnement distribué. Si cette option n’est pas sélectionnée, Talend utilise par défaut la sérialisation Kryo, considérée comme la plus efficace. Cela revient dans Spark submit à utiliser l’option --conf et à spécifier la paire clé/valeur «spark.serializer=org.apache.spark.serializer.KryoSerializer ». Si aucune valeur n’est spécifiée dans Spark submit, le sérialiseur Java est utilisé par défaut ; si le serveur Thrift Spark SQL est utilisé, la sérialisation par défaut est Kryo.

Spark History (Historique Spark)

Passons maintenant à la dernière catégorie, Spark History (Historique Spark). Lorsque nous activons la journalisation Spark, plusieurs options supplémentaires sont disponibles :

Lorsque la journalisation d’événements est activée, vous pouvez spécifier un répertoire dans HDFS où les fichiers d’historique du job pourront être lus par le serveur d’historique Spark, et spécifier l’adresse du serveur d’historique. Dans Spark submit, il faut passer les paires clé/valeur suivantes à l’option --conf pour l’activer et la configurer : « spark.eventLog.enabled=true,spark.eventLog.dir=hdfs://namenode_host:namenode_port/user/spark/applicationHistory,spark.yarn.historyServer.address=http://spark_history_server:history_port ».

Configuration supplémentaire

Maintenant que nous avons détaillé toutes les catégories sous l’onglet « Spark Configuration » (Configuration Spark), voyons les trois dernières options. La première est Spark “scratch” directory (Répertoire « brouillon » Spark). Cette option permet de définir un répertoire de travail, ou « brouillon », qui est utilisé par le disque local de votre système où le job Spark est démarré tant que votre application est en cours d’exécution. Dans Spark submit, nous utiliserions --conf pour ensuite passer « spark.local.dir=/tmp ». Par défaut, c’est le répertoire /tmp qui sera utilisé.

L’option suivante est utilisée pour activer les points de validation Spark. Elle permet une reprise depuis un point spécifique en cas d’échec du job Spark. Lorsqu’elle est activée, elle permet de définir un répertoire d’enregistrement sur le système de fichiers local ou sur HDFS. Si nous devions faire la même chose dans Spark submit, il faudrait le faire dans notre code Spark, comme indiqué dans la documentation Spark. Consultez l’exemple présenté ici : https://spark.apache.org/docs/1.6.0/streaming-programming-guide.html#checkpointing.

La dernière option est intitulée « Propriétés avancées ». Elle nous permet d’ajouter toutes les propriétés Spark que nous souhaitons passer dans notre application sous forme de paire clé/valeur. Cette fonctionnalité est similaire à celle proposée dans Spark submit, qui permet de passer des propriétés dans l’option --conf.

Notez que, si vous observez votre cluster Hadoop et l’un des nœuds de passerelle Spark, vous remarquerez que plusieurs des sélections par défaut mentionnées ci-dessus sont déjà spécifiées dans un fichier nommé « spark-defaults.conf », qui sera utilisé à l’exécution de votre commande Spark submit. Ce fichier est situé sous /etc/spark/conf. Si vous l’ouvrez, vous y verrez la plupart des propriétés mentionnées ici. Vous pouvez toujours les remplacer comme expliqué ci-dessus, en les passant comme options dans votre commande Spark submit. Voici un exemple :

Conclusion

Talend propose toutes les options possibles pour configurer votre application Spark. Grâce aux cases à cocher et aux menus déroulants, vous pouvez facilement spécifier les options que vous souhaitez activer et définir les valeurs à utiliser par défaut. Je vous invite à parcourir ces différents paramètres pour vos jobs Spark Talend, et vous verrez par vous-même à quel point il est facile de les configurer et de les optimiser pour votre environnement.

Références

https://spark.apache.org/docs/latest/submitting-applications.html

https://spark.apache.org/docs/1.6.0/streaming-programming-guide.html#checkpointing

https://spark.apache.org/docs/latest/tuning.html#data-serialization

https://spark.apache.org/docs/1.6.1/job-scheduling.html#dynamic-resource-allocation

Participer aux discussions

0 Comments

Laisser un commentaire

Your email address will not be published. Required fields are marked *