Introduction
Vous savez téléverser un fichier dans HDFS, mais où votre terminal l’a-t-il réellement envoyé ? Le fichier quotidien d’un commerçant peut se trouver sur un ordinateur portable, sur le serveur actuel ou dans un stockage partagé. Lire la mauvaise copie peut produire un calcul parfaitement valide sur les mauvaises données. Avant de gérer davantage de fichiers, vous devez reconnaître le stockage utilisé par vos commandes.
Hadoop répartit les responsabilités. Hadoop Common fournit des bibliothèques et des utilitaires partagés. HDFS stocke les fichiers. MapReduce décrit et exécute les tâches de traitement par lots. YARN attribue des ressources aux applications, notamment aux traitements MapReduce. Vous utiliserez progressivement ces noms ; aujourd’hui, vous examinerez le stockage et la configuration, sans exécuter de calcul ni installer de services.
Ce lab poursuit trois objectifs : découvrir le système de fichiers par défaut, démontrer qu’un même chemin écrit peut désigner des fichiers différents et identifier les services HDFS en cours d’exécution. Vous terminerez avec des observations recueillies dans votre propre environnement. Toutes les données d’exercice sont préparées indépendamment du lab précédent. Utilisez le Terminal ; aucune programmation n’est nécessaire.
Découvrir la destination configurée
Dans cette étape, vous trouverez le système de fichiers par défaut et lirez le choix d’exécution configuré pour MapReduce.
Votre terminal exécute une commande cliente. Un client demande à un service d’effectuer une opération ; ce service peut se trouver sur cette machine ou sur une autre. La configuration relie la commande courte du client à la bonne destination. Commencez dans votre espace de travail local :
cd /home/labex/project
La commande hdfs getconf lit la configuration Hadoop. Son option -confKey demande un paramètre nommé. fs.defaultFS désigne le système de fichiers utilisé par défaut lorsqu’un chemin de système de fichiers Hadoop n’a pas de schéma explicite :
hdfs getconf -confKey fs.defaultFS
Valeur attendue :
hdfs://localhost:9000
Il s’agit d’une URI, une adresse qui indique comment accéder à une ressource. Ici, hdfs sélectionne HDFS, localhost désigne cette machine et 9000 est le port de connexion du service. Un port identifie un point de communication réseau utilisé par un service. Vous n’avez pas besoin d’ouvrir ce port vous-même.
Enregistrez la valeur observée. Comme dans le premier lab, > écrit la sortie d’une commande dans un fichier local en remplaçant son contenu précédent :
hdfs getconf -confKey fs.defaultFS > /home/labex/project/output/default-filesystem.txt
Les fichiers de configuration Hadoop utilisent XML : une propriété possède un name et une value. Vous n’avez besoin de lire qu’une propriété pour le moment. grep sélectionne les lignes de texte correspondantes, et -A 1 inclut la ligne située immédiatement après une correspondance :
grep -A 1 '<name>mapreduce.framework.name</name>' /etc/labex-bigdata/hadoop/mapred-site.xml
Les deux lignes pertinentes sont :
<name>mapreduce.framework.name</name>
<value>yarn</value>
yarn signifie que les applications MapReduce sont configurées pour utiliser YARN pour la gestion des ressources. Ce paramètre seul ne prouve pas qu’une application est en cours d’exécution. HDFS est démarré pour ce lab ; les services de calcul seront utilisés lorsque vous apprendrez à soumettre un traitement.
Enregistrez ces lignes de configuration comme preuve, plutôt que de saisir vous-même la valeur attendue :
grep -A 1 '<name>mapreduce.framework.name</name>' /etc/labex-bigdata/hadoop/mapred-site.xml > /home/labex/project/output/execution-setting.txt
Pour une minuscule table temporaire, votre système de fichiers local peut suffire. Pour des archives partagées par des traitements Hadoop, la destination HDFS est importante. Le choix d’un outil part d’un besoin, plutôt que du téléversement automatique de tous les fichiers dans Hadoop.
Résoudre le même chemin dans deux systèmes de fichiers
Dans cette étape, vous lirez deux fichiers préparés dont les chemins s’écrivent de façon identique, et démontrerez quel système de fichiers chaque commande sélectionne.
Uniquement pour cette comparaison, la préparation a placé un fichier différent à l’emplacement /home/labex/project/data/location.txt dans chaque système de fichiers. C’est possible, car le système de fichiers local et HDFS ont des arborescences distinctes. L’espace de travail HDFS habituel du cours est /user/labex ; les chemins identiques d’aujourd’hui rendent la différence facile à voir.
Une URI file:/// sélectionne explicitement le système de fichiers local. Les trois barres obliques réunissent le séparateur du schéma et un chemin absolu. Avant d’exécuter la commande suivante, prévoyez si elle lira la version locale ou partagée :
hdfs dfs -cat file:///home/labex/project/data/location.txt
Sortie attendue :
Local store: draft product file
Même si vous avez utilisé le client Hadoop, l’URI a sélectionné un fichier local. Sélectionnez maintenant explicitement HDFS avec l’adresse du service observée à l’étape 1 :
hdfs dfs -cat hdfs://localhost:9000/home/labex/project/data/location.txt
Sortie attendue :
HDFS store: shared product file
Enfin, omettez le schéma et l’adresse du service. Prévoyez quelle version le choix par défaut de l’étape 1 sélectionnera :
hdfs dfs -cat /home/labex/project/data/location.txt
La version HDFS partagée apparaît. Un chemin absolu fixe l’emplacement dans un système de fichiers ; il ne choisit pas à lui seul ce système de fichiers. La commande Linux habituelle cat /home/labex/project/data/location.txt lirait toujours la version locale.
Enregistrez séparément les trois résultats pour comparer vos prévisions à des preuves :
hdfs dfs -cat file:///home/labex/project/data/location.txt > /home/labex/project/output/local-result.txt
hdfs dfs -cat hdfs://localhost:9000/home/labex/project/data/location.txt > /home/labex/project/output/hdfs-result.txt
hdfs dfs -cat /home/labex/project/data/location.txt > /home/labex/project/output/default-result.txt
Les résultats HDFS et par défaut doivent correspondre. Utilisez diff, qui n’affiche rien lorsque les fichiers sont identiques :
diff /home/labex/project/output/hdfs-result.txt /home/labex/project/output/default-result.txt
Cette expérience explique pourquoi un chemin seul peut être trompeur lors d’un diagnostic : vérifiez à la fois le chemin et le système de fichiers auquel il appartient.
Identifier les services de stockage
Dans cette étape, vous relierez les opérations sur les fichiers aux rôles du NameNode et du DataNode et rassemblerez vos observations sur l’environnement.
HDFS sépare les informations de nom et d’emplacement d’un fichier de ses données. Le NameNode gère l’arborescence et sait quels DataNodes détiennent les blocs du fichier. Les DataNodes stockent ces blocs et fournissent le contenu des fichiers. Pensez au catalogue et aux rayonnages d’une bibliothèque : le catalogue aide à trouver un livre ; les rayonnages contiennent ses pages.
Client HDFS → NameNode : demander où se trouvent les données du fichier
Client HDFS ↔ DataNode : transférer les données du fichier
Un bloc est une portion de fichier gérée par HDFS. Plus tard, vous examinerez directement les blocs et les répliques. Pour l’instant, vérifiez que les services assurant ces deux rôles sont actifs. systemctl is-active demande au système d’exploitation l’état de chaque service nommé ; cette commande ne fait qu’observer l’état :
systemctl is-active labex-hdfs-namenode labex-hdfs-datanode
Vous devriez voir deux lignes active, une pour chaque service. Enregistrez cette observation :
systemctl is-active labex-hdfs-namenode labex-hdfs-datanode > /home/labex/project/output/storage-services.txt
HDFS fournit aussi sa propre vue des nœuds de stockage. dfsadmin -report est un rapport d’administration en lecture seule. La commande suivante utilise l’identité de service hdfs préparée, via sudo -u hdfs, uniquement pour lire ce rapport ; effectuez les opérations ordinaires sur les fichiers avec votre propre identité labex :
sudo -u hdfs /usr/local/bin/hdfs dfsadmin -report
Repérez Live datanodes (1) et un nœud dont le Decommission Status est Normal. La capacité, l’espace utilisé, les identifiants d’hôte et les horodatages varient ; ces valeurs n’ont pas besoin de correspondre à celles de la VM d’un autre apprenant. Un nœud actif communique avec le NameNode, tandis que Normal signifie qu’il n’est pas en cours de retrait du service.
Enregistrez le rapport :
sudo -u hdfs /usr/local/bin/hdfs dfsadmin -report > /home/labex/project/output/storage-report.txt
Il s’agit du mode pseudo-distribué sur un seul nœud : des processus de service Hadoop distincts s’exécutent sur une même machine. En mode local, un programme peut utiliser des fichiers locaux sans services HDFS ; dans un cluster de plusieurs machines, les services et le stockage sont répartis entre les hôtes. La présence d’un DataNode ici ne démontre pas la capacité à survivre à la panne d’une machine entière.
Lorsque vous soumettrez un traitement plus tard, le ResourceManager de YARN attribuera les ressources et un NodeManager gérera le travail sur chaque machine de travail. Les observations de stockage d’aujourd’hui ne nécessitent aucun traitement en cours.
Créez un petit rapport en concaténant vos observations enregistrées. cat accepte plusieurs chemins d’entrée locaux dans l’ordre ; > enregistre leur contenu combiné :
cat /home/labex/project/output/default-filesystem.txt /home/labex/project/output/execution-setting.txt /home/labex/project/output/storage-services.txt /home/labex/project/output/storage-report.txt > /home/labex/project/output/environment-report.txt
Relisez-le :
cat /home/labex/project/output/environment-report.txt
Repérez l’URI du système de fichiers, le paramètre yarn, les deux états de service et le nombre de nœuds actifs. Vous disposez maintenant de preuves reliant vos commandes à l’environnement réel. Vous apprendrez ensuite à gérer le cycle de vie d’un fichier dans le bon système de fichiers.
Résumé
Vous avez examiné le système de fichiers et le choix d’exécution configurés, puis utilisé des chemins locaux, HDFS explicites et par défaut pour prouver l’origine des données. Vous avez relié ces résultats au rôle de gestion des métadonnées du NameNode et au rôle de stockage du DataNode, et reconnu les limites d’un environnement d’apprentissage sur une seule machine.
Votre prochaine tâche consiste à gérer les entrées de manière réfléchie : copier, archiver, exporter, mesurer et supprimer uniquement les fichiers temporaires prévus.
