Introduction
Vous avez suivi Map, Shuffle et Reduce et vérifié une véritable exécution locale de WordCount. Le commerçant souhaite maintenant appliquer la même règle de comptage à des fichiers HDFS, en utilisant les services de gestion des ressources de l’environnement. La question métier reste la même ; l’organisation du stockage et de l’exécution change.
YARN gère les ressources des applications. Son ResourceManager coordonne l’attribution des ressources, tandis qu’un NodeManager gère l’exécution sur une machine de travail. Chaque application soumise possède un ApplicationMaster qui coordonne son travail, et exécute ce travail dans des conteneurs attribués, c’est-à-dire des allocations de ressources contenant des processus. Ces conteneurs YARN ne sont pas nécessairement des conteneurs Docker.
Vous soumettrez le JAR WordCount préparé, identifierez sa véritable application YARN, examinerez son état terminé et ses journaux, puis vérifierez les résultats HDFS. Une seconde exécution utilisera un chemin de sortie différent pour conserver l’entrée originale et le premier résultat. Le lab prépare ses propres données et démarre les services ; vous n’avez besoin ni des fichiers du lab précédent ni de compétences en programmation Java. Utilisez le Terminal.
Soumettre l’algorithme connu à YARN
Dans cette étape, vous préparerez une entrée HDFS et soumettrez le même algorithme WordCount avec le framework YARN configuré.
Commencez dans votre espace de travail local :
cd /home/labex/project
Lisez l’entrée préparée :
cat /home/labex/project/data/product-words.txt
Il s’agit des six mêmes lignes que celles utilisées pour expliquer l’algorithme. Les totaux attendus restent folder=3, notebook=4 et pen=4. Créez un répertoire HDFS brut et un parent distinct pour les résultats :
hdfs dfs -mkdir -p /user/labex/yarn-batch/raw /user/labex/yarn-batch/results
Téléversez l’entrée :
hdfs dfs -put /home/labex/project/data/product-words.txt /user/labex/yarn-batch/raw/product-words.txt
Vous avez déjà appris que -put conserve l’original local. Le répertoire HDFS raw est l’entrée du traitement ; results doit rester à l’extérieur pour éviter de lire les sorties précédentes comme de nouvelles entrées.
Le JAR d’exemples et le nom wordcount sont identiques à ceux de l’exécution locale. Cette fois, omettez les paramètres imposant le mode local : la configuration installée utilise mapreduce.framework.name=yarn et HDFS comme système de fichiers par défaut. Les deux derniers arguments ci-dessous sont donc des chemins HDFS. Le traitement crée son propre répertoire de sortie run-1, qui ne doit pas déjà exister :
hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.5.0.jar wordcount /user/labex/yarn-batch/raw /user/labex/yarn-batch/results/run-1
Attendez la fin de la commande. Elle affiche un identifiant d’application soumise, puis la progression du traitement et un message de réussite. Les identifiants d’application et de traitement, les durées et l’ordre des messages de progression varient. Vous n’avez pas besoin de saisir l’état instantané RUNNING ; les applications terminées peuvent encore être examinées.
Reliez la commande aux rôles :
Le client soumet l’application → Le ResourceManager attribue les ressources
L’ApplicationMaster coordonne MapReduce → Le NodeManager exécute les conteneurs
Les tâches lisent les entrées HDFS → Les tâches écrivent les résultats HDFS
Il s’agit toujours d’un environnement d’apprentissage sur une seule machine. Les rôles YARN sont réels, même si leurs processus partagent une machine. Vous demanderez ensuite à YARN une preuve directe de la réussite de l’application.
Examiner l’application terminée
Dans cette étape, vous conserverez le véritable identifiant de l’application et l’utiliserez pour consulter son état et ses journaux agrégés.
YARN attribue un identifiant d’application (Application ID) lorsqu’il accepte une application. Il est différent d’un chemin HDFS ou d’un nom de fichier de résultat. Listez tous les états d’application, y compris les applications terminées :
yarn application -list -appStates ALL
Cet environnement neuf contient une application soumise. Son type doit être MAPREDUCE, son état FINISHED et son statut final SUCCEEDED. FINISHED seul ne prouve pas la réussite : le statut final compte aussi.
Enregistrez le véritable identifiant d’application sans copier une valeur d’exemple. Le pipeline suivant utilise grep -o pour afficher uniquement une partie correspondante. Dans ce motif, [0-9]* correspond aux séquences de chiffres d’un identifiant d’application :
yarn application -list -appStates ALL | grep -o 'application_[0-9]*_[0-9]*' > /home/labex/project/output/application-id.txt
Lisez l’identifiant recueilli :
cat /home/labex/project/output/application-id.txt
Vous devriez voir une ligne commençant par application_. Le reste est attribué par cet environnement ; n’utilisez pas l’identifiant d’un autre apprenant.
Pour insérer cette valeur enregistrée dans une commande, $(cat ...) exécute cat et lui substitue sa sortie. Les guillemets doubles maintiennent la valeur substituée dans un seul argument. Interrogez cette application réelle :
yarn application -status "$(cat /home/labex/project/output/application-id.txt)"
Repérez State, Final-State et Application-Type. Les valeurs attendues sont FINISHED, SUCCEEDED et MAPREDUCE. Enregistrez le rapport :
yarn application -status "$(cat /home/labex/project/output/application-id.txt)" > /home/labex/project/output/application-status.txt
YARN recueille également les journaux des conteneurs. La commande logs -applicationId les lit pour l’application sélectionnée. Enregistrez les journaux localement pour pouvoir en examiner une portion raisonnable :
yarn logs -applicationId "$(cat /home/labex/project/output/application-id.txt)" > /home/labex/project/output/application.log
Utilisez la commande locale tail -n 20 pour afficher les vingt dernières lignes :
tail -n 20 /home/labex/project/output/application.log
Les messages exacts des journaux varient. Les en-têtes de conteneurs et les messages des tâches relient l’application au travail réellement exécuté par YARN. Les journaux aident à expliquer le comportement ; un état de réussite accompagné de résultats métier corrects constitue une preuve plus solide qu’une seule ligne de journal rassurante. Dans le prochain lab, vous utiliserez ces mêmes outils de diagnostic sur des échecs.
Vérifier et relancer sans polluer les entrées
Dans cette étape, vous vérifierez les données de résultat, les exporterez et relancerez le traitement vers un second chemin de sortie.
Listez le premier répertoire de résultats :
hdfs dfs -ls /user/labex/yarn-batch/results/run-1
Le marqueur _SUCCESS indique que la production des sorties est terminée. Les fichiers part-* contiennent les comptages. Comme précédemment, utilisez un motif HDFS entre apostrophes et triez les enregistrements pour stabiliser l’examen :
hdfs dfs -cat '/user/labex/yarn-batch/results/run-1/part-*' | sort
Résultat attendu :
folder 3
notebook 4
pen 4
Enregistrez un export local trié avec la technique de relecture :
hdfs dfs -cat '/user/labex/yarn-batch/results/run-1/part-*' | sort > /home/labex/project/output/run-1-counts.txt
Avant l’exécution suivante, prévoyez si une autre exécution sur des entrées identiques doit changer les comptages. Elle ne le doit pas. Un nouveau chemin de sortie conserve le premier résultat et évite l’erreur de sortie déjà existante :
hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.5.0.jar wordcount /user/labex/yarn-batch/raw /user/labex/yarn-batch/results/run-2
Après la réussite, lisez et enregistrez les comptages triés de la seconde exécution :
hdfs dfs -cat '/user/labex/yarn-batch/results/run-2/part-*' | sort > /home/labex/project/output/run-2-counts.txt
Comparez les deux exports locaux :
diff /home/labex/project/output/run-1-counts.txt /home/labex/project/output/run-2-counts.txt
Aucune différence ne doit apparaître. Les résultats sont dans des répertoires voisins extérieurs au répertoire d’entrées brutes ; relancer le traitement n’a donc pas ajouté l’ancienne sortie au lot d’entrée suivant. Vous avez maintenant vérifié une véritable application, ses journaux, ses résultats et son comportement reproductible sans changer l’algorithme.
Résumé
Vous avez déplacé un algorithme de comptage connu d’une exécution locale vers HDFS et YARN. Vous avez identifié une véritable application MapReduce, examiné sa réussite et les journaux de ses conteneurs, puis vérifié des résultats corrects dans deux chemins de sortie.
L’algorithme n’a pas changé, tandis que son organisation de stockage et de gestion des ressources a changé. Vous apprendrez ensuite à distinguer les problèmes côté client des échecs d’une application déjà soumise et à effectuer la réparation minimale appropriée.
