E-NO
Laboratoire local HDFS 7 min de lecture

Mise en place d'un laboratoire HDFS local avec exemples pratiques : un guide pratique

calendar_today Publié : 2026-09-13
update Dernière mise à jour : 2026-09-13
analytics Efficacité SEO : 100%
Illustration du guide technique pour « Mise en place d'un laboratoire HDFS local avec exemples pratiques : un guide pratique ».

Introduction

Le système de fichiers distribué Hadoop (HDFS) est l'épine dorsale du stockage de nombreuses plateformes de mégadonnées, mais son apprentissage et son dépannage peuvent être intimidants sans un environnement sûr pour s'exercer. Un laboratoire HDFS local offre un environnement contrôlé pour expérimenter les configurations, simuler des pannes et développer des applications sans risquer les données de production ni engendrer de coûts cloud. Ce guide vous accompagne dans la mise en place d'un laboratoire HDFS local pratique, de la sélection de la version à la vérification et à la récupération. Que vous soyez un développeur prototypant un pipeline de données ou un ingénieur d'exploitation perfectionnant ses compétences en dépannage, cette approche pratique vous aidera à gagner en confiance et en expertise.

Inventaire des versions et de l'environnement

Avant de commencer, établissez les versions, la topologie et les prérequis de votre laboratoire. Choisissez une distribution Hadoop qui correspond à votre environnement de production ou à vos objectifs d'apprentissage. Pour ce guide, nous utilisons Apache Hadoop 3.3.6, une version stable avec une documentation abondante.

Prérequis :

  • Une machine Linux ou macOS avec au moins 4 Go de RAM et 10 Go d'espace disque libre (les utilisateurs Windows peuvent utiliser WSL2).
  • Java 8 ou 11 (OpenJDK recommandé). Vérifiez avec java -version.
  • Client et serveur SSH (pour l'accès à distance de Hadoop). Sur Debian/Ubuntu : sudo apt install openssh-server openssh-client.
  • Familiarité de base avec la ligne de commande.

Topologie : une configuration pseudo-distribuée à nœud unique où tous les démons HDFS s'exécutent sur une seule machine. Cela suffit pour la plupart des expériences de laboratoire.

Inventaire des versions :

ComposantVersionNotes
Apache Hadoop3.3.6HDFS et YARN de base
JavaOpenJDK 8 ou 11Environnement d'exécution requis
Système d'exploitationLinux/macOSWindows via WSL2

Mise en place de l'environnement :

  • Créez un utilisateur dédié pour Hadoop (par exemple, hadoopuser) pour éviter les problèmes de permissions.
  • Installez Java et définissez JAVA_HOME.
  • Configurez la connexion SSH sans mot de passe à localhost :
  ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
  cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
  chmod 600 ~/.ssh/authorized_keys
  ssh localhost

Testez avec ssh localhost ; vous devriez vous connecter sans demande de mot de passe.

Chemin de configuration sûr

Nous utiliserons une configuration minimale qui maintient les données isolées et faciles à réinitialiser. Téléchargez l'archive binaire Hadoop depuis le site officiel Apache et extrayez-la dans un répertoire tel que /opt/hadoop. Par exemple :

wget https://downloads.apache.org/hadoop/common/hadoop-3.3.6/hadoop-3.3.6.tar.gz
sudo tar -xzf hadoop-3.3.6.tar.gz -C /opt
sudo mv /opt/hadoop-3.3.6 /opt/hadoop
sudo chown -R hadoopuser:hadoopuser /opt/hadoop

Structure des répertoires :

/opt/hadoop/
├── etc/hadoop/   # fichiers de configuration
├── bin/          # commandes utilisateur
├── sbin/         # scripts des démons
├── logs/         # fichiers journaux
└── data/         # répertoires de données HDFS (créés manuellement)

Fichiers de configuration principaux :

Modifiez etc/hadoop/core-site.xml :

<configuration>
  <property>
    <name>fs.defaultFS</name>
    <value>hdfs://localhost:9000</value>
  </property>
</configuration>

Modifiez etc/hadoop/hdfs-site.xml :

<configuration>
  <property>
    <name>dfs.replication</name>
    <value>1</value>
  </property>
  <property>
    <name>dfs.namenode.name.dir</name>
    <value>file:///opt/hadoop/data/namenode</value>
  </property>
  <property>
    <name>dfs.datanode.data.dir</name>
    <value>file:///opt/hadoop/data/datanode</value>
  </property>
</configuration>

Définissez les variables d'environnement dans ~/.bashrc :

export HADOOP_HOME=/opt/hadoop
export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin
export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop

Puis exécutez source ~/.bashrc pour appliquer.

Initialisez le NameNode :

hdfs namenode -format

Résultat attendu : confirmation que le répertoire de stockage a été formaté, se terminant par un message du type « Storage directory /opt/hadoop/data/namenode has been successfully formatted. »

Démarrez les démons HDFS :

start-dfs.sh

Cela démarre le NameNode, le DataNode et le SecondaryNameNode. Vérifiez avec jps.

Vérification et diagnostic

Vérifiez que le cluster est sain à l'aide des outils en ligne de commande et de l'interface web.

Vérifiez les démons :

jps

Résultat attendu : identifiants de processus pour NameNode, DataNode et SecondaryNameNode (et Jps lui-même). Par exemple :

12345 NameNode
12456 DataNode
12567 SecondaryNameNode
12678 Jps

Listez la racine HDFS :

hdfs dfs -ls /

Si elle est vide, elle ne renvoie rien mais se termine avec le code 0.

Créez un répertoire et téléversez un fichier :

hdfs dfs -mkdir /test
hdfs dfs -put /etc/hosts /test/hosts
hdfs dfs -cat /test/hosts

Résultat attendu : le contenu de /etc/hosts s'affiche dans la console. Par exemple :

127.0.0.1   localhost

Exécutez une vérification du système de fichiers :

hdfs fsck / -files -blocks

Affiche les informations sur les blocs de fichiers et l'état de santé. Une sortie saine inclut une ligne comme « Status: HEALTHY » et « Total blocks (validated): 1 (avg. block size 134217728 B) ».

Interface web : accédez à http://localhost:9870 pour les informations du NameNode et à http://localhost:9864 pour les informations du DataNode. Ces interfaces fournissent des tableaux de bord pour la santé du cluster, les nœuds actifs et la navigation dans le système de fichiers.

Modes de défaillance et récupération

Comprendre les défaillances courantes aide à renforcer la résilience. Voici des problèmes potentiels et les étapes de récupération.

Le NameNode ne démarre pas

Consultez les journaux dans $HADOOP_HOME/logs/. Cause courante : JAVA_HOME mal configuré ou permissions de répertoire inadéquates.

Exemple d'extrait de journal :

ERROR org.apache.hadoop.hdfs.server.namenode.NameNode: Failed to start namenode.
java.io.FileNotFoundException: /opt/hadoop/data/namenode (Permission denied)

Récupération :

  1. Vérifiez que JAVA_HOME est correctement défini dans etc/hadoop/hadoop-env.sh.
  2. Assurez-vous que les répertoires de données existent et sont accessibles en écriture par l'utilisateur Hadoop :
   sudo mkdir -p /opt/hadoop/data/namenode
   sudo chown -R hadoopuser:hadoopuser /opt/hadoop/data
  1. Si le NameNode a déjà été formaté mais que les métadonnées sont corrompues, reformatez (après avoir sauvegardé toute donnée importante) :
   hdfs namenode -format

Le DataNode ne se connecte pas

Vérifiez les paramètres réseau et de pare-feu. Le DataNode écoute sur le port 9866.

Récupération :

  • Exécutez hdfs dfsadmin -report pour voir l'état du DataNode. Si aucun DataNode n'est répertorié, consultez les journaux du DataNode pour les erreurs de connexion.
  • Assurez-vous que le DataNode peut résoudre et se connecter au NameNode. En mode pseudo-distribué, ils communiquent via localhost ; vérifiez /etc/hosts pour la correspondance localhost correcte.
  • Vérifiez que le service DataNode est en cours d'exécution avec jps. Sinon, démarrez-le manuellement : hdfs --daemon start datanode.

Bloc corrompu

Simulez en supprimant un fichier de bloc dans le répertoire du DataNode. Ensuite, exécutez :

hdfs fsck / -files -blocks -locations

Cela identifie la corruption, montrant des blocs manquants ou sous-répliqués. Par exemple :

/user/hadoop/testfile:  Under replicated BP-123456789-127.0.0.1-1610000000000:blk_1073741825_1001. Target Replicas is 1 but found 0 live replica(s), 0 decommissioned replica(s), 0 decommissioning replica(s).

Récupération :

  • Si vous disposez d'une sauvegarde, restaurez le fichier ou téléversez-le à nouveau.
  • Si le bloc provient d'un fichier de test, vous pouvez supprimer le fichier et le recréer :
  hdfs dfs -rm /test/hosts
  hdfs dfs -put /etc/hosts /test/hosts
  • Pour les données critiques, implémentez un facteur de réplication supérieur à 1 en production ; dans le laboratoire, vous pouvez augmenter dfs.replication pour simuler la réplication et tester la récupération automatique.

Retour en arrière (rollback)

Pour réinitialiser le cluster :

stop-dfs.sh
rm -rf /opt/hadoop/data/namenode /opt/hadoop/data/datanode
hdfs namenode -format
start-dfs.sh

Cela efface toutes les données HDFS et repart de zéro.

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour vous assurer que votre laboratoire reste sain et utile.

TâcheCommandeRésultat attenduResponsableFréquence
Démarrer HDFSstart-dfs.shTous les démons démarrentVous (administrateur du labo)À chaque session
Vérifier les démonsjpsListe NameNode, DataNode, SecondaryNameNodeVousAprès le démarrage
Lister la racinehdfs dfs -ls /Aucune erreurVousHebdomadaire
Téléverser un fichier de testhdfs dfs -put file /test/Le fichier apparaît dans la listeVousLors des tests
Exécuter fsckhdfs fsck /État de santé OKVousHebdomadaire
Arrêter HDFSstop-dfs.shTous les démons s'arrêtent proprementVousFin de session

Régulièrement également :

  • Surveillez l'utilisation de l'espace disque avec df -h /opt/hadoop/data.
  • Sauvegardez les métadonnées du NameNode si nécessaire. Pour un laboratoire, vous pouvez périodiquement copier le répertoire namenode vers un emplacement sûr.
  • Nettoyez les fichiers de test inutilisés : hdfs dfs -rm -r /test/*.

Pièges courants et comment les éviter

1. Utiliser le mauvais utilisateur Hadoop

Pourquoi cela arrive : exécuter des commandes HDFS en tant que root ou un autre utilisateur peut entraîner des erreurs de permission ou une propriété incohérente des répertoires de données.

Comment l'éviter : utilisez toujours l'utilisateur Hadoop dédié (par exemple, hadoopuser). Basculez avec su - hadoopuser ou exécutez les commandes avec sudo -u hadoopuser.

Récupération : si vous avez accidentellement exécuté une commande en tant qu'un autre utilisateur, rétablissez la propriété :

sudo chown -R hadoopuser:hadoopuser /opt/hadoop

2. Ne pas formater le NameNode avant le premier démarrage

Pourquoi cela arrive : les nouveaux utilisateurs oublient souvent l'étape hdfs namenode -format, ce qui entraîne des erreurs comme « NameNode is not formatted. »

Comment l'éviter : formatez toujours avant le premier démarrage, et ne formatez que lors de la configuration d'un nouveau cluster ou d'une réinitialisation intentionnelle. Le formatage supprime toutes les métadonnées et données !

Récupération : si vous avez oublié de formater, arrêtez HDFS, formatez et redémarrez.

3. Mauvaise configuration SSH

Pourquoi cela arrive : les scripts de démarrage de Hadoop utilisent SSH pour lancer les démons sur différents nœuds, même en mode pseudo-distribué. Si le SSH sans mot de passe n'est pas configuré, les scripts peuvent se bloquer ou échouer avec des erreurs d'authentification.

Comment l'éviter : testez le SSH sans mot de passe avec ssh localhost avant d'exécuter start-dfs.sh. Si un mot de passe est demandé, générez des clés et ajoutez-les à authorized_keys comme décrit précédemment.

Récupération : si le SSH est mal configuré, corrigez-le puis redémarrez HDFS avec stop-dfs.sh et start-dfs.sh.

4. Manque d'espace disque

Pourquoi cela arrive : HDFS accumule des données à partir de tests répétés et les métadonnées du NameNode augmentent. Dans un laboratoire, vous ne surveillez peut-être pas l'utilisation du disque.

Comment l'éviter : configurez une tâche cron pour vérifier l'espace disque chaque semaine et nettoyer les fichiers de test :

0 0 * * 0 du -sh /opt/hadoop/data && df -h /opt/hadoop

Récupération : supprimez les fichiers inutiles dans HDFS et les répertoires de données locaux. Si le disque est plein, envisagez de déplacer les données vers une partition plus grande ou d'augmenter la taille du disque.

5. Ignorer les fichiers journaux

Pourquoi cela arrive : lorsque quelque chose ne va pas, les nouveaux utilisateurs devinent souvent au lieu de lire les journaux.

Comment l'éviter : prenez l'habitude de consulter $HADOOP_HOME/logs/ pour les messages d'erreur détaillés. Le journal du NameNode est généralement hadoop-hadoopuser-namenode-<hostname>.log, et celui du DataNode est similaire.

Récupération : naviguez vers le répertoire des journaux et utilisez tail -f pour surveiller pendant que vous reproduisez le problème.

Conclusion

Vous disposez désormais d'un laboratoire HDFS local entièrement fonctionnel. Cet environnement vous permet d'expérimenter en toute sécurité, de simuler des pannes et de valider des configurations avant de toucher à la production. Utilisez la liste de contrôle des opérations pour maintenir la cohérence, et n'oubliez pas d'attribuer des responsabilités claires et des fréquences de révision à chaque tâche. Commencez par des expériences petites et mesurables, et laissez votre laboratoire devenir un bac à sable pour l'innovation et l'apprentissage.

Recherches connexes

Score de qualité de l’article

Utilité pour le lecteur 100%
  • check_circle Guide prêt à lire
  • check_circle Exemples pratiques inclus
  • check_circle URL d’article optimisée pour le SEO