Introduction
Les fichiers du commerçant ont des noms et des répertoires, mais les machines doivent aussi stocker leur contenu quelque part. Comment un gros fichier peut-il être réparti entre des nœuds de stockage ? Que copie HDFS lorsqu’il conserve une réplique, et un bloc presque vide réserve-t-il l’équivalent d’un bloc entier sur le disque ?
Vous savez déjà organiser et préserver les fichiers. Dans ce lab, vous regarderez au-delà de leurs chemins. Un bloc HDFS est une portion de fichier que HDFS suit et stocke. Le NameNode conserve les métadonnées des fichiers et des emplacements de blocs ; les DataNodes contiennent les données des blocs. Une réplique est une autre copie stockée d’un bloc, et non un nouvel enregistrement de vente ou un autre fichier visible par l’utilisateur.
Vous téléverserez deux fichiers préparés avec une taille de bloc volontairement petite et valide, prévoirez leurs nombres de blocs et examinerez les emplacements réels. Cet environnement à un seul DataNode utilise un facteur de réplication de 1. Il fournit de véritables observations sans prétendre démontrer la récupération entre plusieurs machines. Toutes les données et tous les services sont préparés indépendamment. Utilisez le Terminal ; aucune programmation n’est nécessaire.
Relier la taille d’un fichier aux blocs
Dans cette étape, vous téléverserez un fichier avec une taille de bloc connue et examinerez ses métadonnées.
Un chemin de système de fichiers nomme un fichier logique. HDFS divise son contenu en blocs pour que différentes parties puissent être stockées sur différents DataNodes dans un cluster plus grand. La taille configurée d’un bloc est une taille maximale de données pour ce bloc, et non la garantie que chaque bloc est plein.
Commencez dans le répertoire du projet :
cd /home/labex/project
La commande locale wc -c compte les octets. Utilisez-la sur le premier fichier préparé :
wc -c /home/labex/project/data/products-a.txt
Le résultat commence par 1572864 : exactement 1,5 MiB. Un MiB représente 1 048 576 octets. Ce fichier répète un simple libellé de produit pour que l’expérience de stockage ne comporte aucune règle métier compliquée.
Créez un répertoire HDFS personnel :
hdfs dfs -mkdir -p /user/labex/block-study
Pour cette démonstration, -Ddfs.blocksize=1048576 remplace le paramètre de taille de bloc du client pour le téléversement suivant. -D fournit une propriété de configuration pour cette commande ; il ne modifie pas les fichiers de configuration partagés. Un MiB respecte la limite minimale de taille de bloc de cette image et garde la démonstration de petite taille :
hdfs dfs -Ddfs.blocksize=1048576 -put /home/labex/project/data/products-a.txt /user/labex/block-study/products-a.txt
Prévoyez la répartition : 1,5 MiB avec une taille de bloc de 1 MiB nécessite un bloc plein et un bloc à moitié plein, soit deux blocs.
L’opération HDFS -stat affiche des métadonnées sélectionnées. Dans son format entre apostrophes, %b désigne la longueur du fichier en octets, %o la taille de bloc et %r le facteur de réplication :
hdfs dfs -stat 'bytes=%b blocksize=%o replication=%r' /user/labex/block-study/products-a.txt
Valeurs attendues :
bytes=1572864 blocksize=1048576 replication=1
La longueur du fichier reste de 1,5 MiB. Un facteur de réplication de 1 signifie une copie stockée par bloc, et non un bloc pour le fichier entier. Enregistrez les métadonnées réelles :
hdfs dfs -stat 'bytes=%b blocksize=%o replication=%r' /user/labex/block-study/products-a.txt > /home/labex/project/output/file-a-metadata.txt
Si le fichier existe déjà après un téléversement terminé, examinez-le avant de répéter le téléversement ; ne supprimez pas un fichier simplement parce que -put signale une destination existante.
Examiner les emplacements et prévoir un changement
Dans cette étape, vous trouverez les blocs réels du premier fichier et testerez votre prévision avec un fichier plus grand.
La commande hdfs fsck peut examiner l’état de stockage d’un fichier. Dans l’examen en lecture seule suivant, -files inclut les détails des fichiers, -blocks les informations sur les blocs et -locations les DataNodes détenant chaque bloc. Aucune de ces options ne répare ni ne supprime de fichiers :
hdfs fsck /user/labex/block-study/products-a.txt -files -blocks -locations
Repérez la ligne de longueur du fichier, les entrées de blocs et le champ Total blocks (validated) du récapitulatif. Il doit y avoir deux blocs. L’un contient 1 048 576 octets et l’autre 524 288 octets. Les identifiants de blocs, les adresses et les horodatages varient. Le récapitulatif final de l’état du système de fichiers doit indiquer HEALTHY.
Enregistrez cet examen :
hdfs fsck /user/labex/block-study/products-a.txt -files -blocks -locations > /home/labex/project/output/file-a-blocks.txt
Un résultat sain signifie que cette vérification a trouvé les blocs et les répliques requis. Avec une seule réplique par bloc sur une seule machine, cela ne signifie pas que le fichier survivra à la perte de cette machine.
Examinez maintenant la taille du second fichier local :
wc -c /home/labex/project/data/products-b.txt
Sa longueur est de 2621440 octets, soit 2,5 MiB. Avant de le téléverser, prévoyez le nombre et les tailles de ses blocs avec la même taille de bloc de 1 MiB. Seule la longueur du fichier change :
hdfs dfs -Ddfs.blocksize=1048576 -put /home/labex/project/data/products-b.txt /user/labex/block-study/products-b.txt
Examinez le résultat :
hdfs fsck /user/labex/block-study/products-b.txt -files -blocks -locations
Vous devriez trouver trois blocs : deux blocs pleins et un bloc de 524 288 octets. Tous les emplacements désignent le même DataNode dans ce lab. Enregistrez l’observation :
hdfs fsck /user/labex/block-study/products-b.txt -files -blocks -locations > /home/labex/project/output/file-b-blocks.txt
Dans un cluster plus grand, les blocs peuvent se trouver sur des machines différentes. Le NameNode fournit les métadonnées d’emplacement aux clients ; ce n’est pas un tuyau central par lequel doit passer chaque octet du contenu des fichiers.
Interpréter l’espace, les répliques et le trajet des données
Dans cette étape, vous relierez les observations des blocs à la taille des fichiers et au rapport réel du nœud de stockage.
Un dernier bloc à moitié plein ne réserve pas un MiB entier d’espace de données simplement parce que la taille de bloc configurée est de 1 MiB. Utilisez -du sans -h pour conserver les nombres exacts d’octets :
hdfs dfs -du /user/labex/block-study
Les deux premières colonnes de chaque fichier doivent être :
1572864 1572864 .../products-a.txt
2621440 2621440 .../products-b.txt
La première colonne est la longueur logique du fichier ; la seconde tient compte de la réplication. Elles correspondent ici, car la réplication vaut 1. Ces valeurs décrivent les données des fichiers HDFS, et non chaque octet de métadonnées du système de fichiers ni l’utilisation totale du disque de la VM. Enregistrez les lignes :
hdfs dfs -du /user/labex/block-study > /home/labex/project/output/block-report.txt
Consultez le rapport réel du nœud de stockage avec la commande d’administration en lecture seule présentée dans le lab sur l’environnement :
sudo -u hdfs /usr/local/bin/hdfs dfsadmin -report
Repérez Live datanodes (1). Régler la réplication sur 3 ne créerait pas trois machines ; ce lab conserve la réplication à 1 plutôt que de laisser des blocs attendre des répliques indisponibles.
Reliez ces observations au trajet des données :
Écriture : le client demande au NameNode de créer un fichier, puis envoie les données des blocs au(x) DataNode(s).
Lecture : le client demande les emplacements au NameNode, puis lit les données des blocs depuis le(s) DataNode(s).
Avec plusieurs répliques dans un cluster plus grand, un client peut utiliser une copie disponible, et un framework de traitement peut essayer d’exécuter le travail près des données. Cette notion s’appelle la localité des données. Une copie nommée créée avec -cp est un second fichier logique ; les répliques sont des copies de stockage des blocs à l’intérieur d’un fichier logique. Elles résolvent des problèmes différents.
Votre exercice de prévision a modifié la taille du fichier, et non le facteur de réplication. Le fichier A a toujours deux blocs, le fichier B en a trois, et chacun dispose d’une réplique par bloc. Vous découvrirez ensuite pourquoi un fichier peut être présent et sain tout en étant illisible pour un utilisateur donné : les permissions d’accès.
Résumé
Vous avez prévu et observé comment des fichiers de 1,5 MiB et de 2,5 MiB se répartissent en deux et trois blocs de 1 MiB. Vous avez examiné les emplacements réels des blocs et distingué la longueur logique du fichier, le stockage des répliques et les fichiers nommés supplémentaires.
Vous avez également relié ces résultats aux métadonnées du NameNode et aux transferts du DataNode. L’environnement à un seul nœud illustre ces responsabilités, tout en laissant l’exploration de la capacité et de la tolérance aux pannes sur plusieurs machines pour plus tard.
