Présentation de HDFS Hadoop

Présentation de HDFS

HDFS (Hadoop Distributed File System) est le composant de Hadoop en charge du stockage des données dans un cluster Hadoop.

Outre la lecture et l’écriture de données, qui sont le lot commun de tout système de gestion de fichiers, HDFS présente quelques caractéristiques originales :

• HDFS est optimisé pour manipuler des blocs de taille importante, couramment 64 ou 128 Mo, ce qui permet de réduire le seek time. À titre de comparaison, le système de gestion de fichiers Linux ext3 a une taille de blocs de 4 ou 8 Ko. De ce fait :

• Les performances de HDFS sont meilleures lorsqu’il travaille sur des fichiers de taille importante (100 Mo ou plus).
• Les performances de HDFS sont meilleures lorsqu’il travaille sur un nombre "réduit" de fichiers (des millions de fichiers plutôt que des milliards de fichiers).

• En contrepartie, HDFS a été, et demeure encore largement, un système de gestion de fichiers du type "write once" : il n’est pas possible de gérer des écritures aléatoires dans un fichier HDFS.
• Chaque bloc est sauvegardé en trois exemplaires (cf. chapitre Une vue globale de Hadoop), et sur des nœuds distincts dans le cluster, ce qui contribue à en garantir la fiabilité et la disponibilité. Ce mécanisme est appelé "réplication" des blocs.
• HDFS s’appuie sur le système de gestion de fichiers natif. Sous Linux, ce sont ext3 ou ext4 le plus souvent.
• Dans la mesure où un cluster Hadoop se "contente" le plus souvent de machines de milieu de gamme (cf. chapitre Aspects matériels), HDFS offre un stockage redondant pour des volumes de données très importants, à un coût acceptable.

Principe de fonctionnement

Le fonctionnement de HDFS est assuré par trois types de deamons :

• Le NameNode (NN), qui est un nœud maître (master node) et qui dispose d’une machine dédiée.
• Le SecondaryNameNode (SNN), qui est aussi un nœud maître et qui dispose donc, lui aussi, d’une machine dédiée.
• Le DataNode (DN), qui est un nœud esclave (slave node) implanté sur chaque machine du cluster qui n’est pas un nœud maître.

Autrement dit, dans un cluster de 100 machines il y aura :

• Trois nœuds maîtres : le NN, le SNN et le JobTracker (nous étudierons le JobTracker au chapitre MapReduce).
• 100 - 3 = 97 nœuds esclaves, chacun avec une copie de DN et de TaskTracker (nous étudierons le TaskTracker au chapitre MapReduce).

Les daemons de HDFS dans la version 1 de Hadoop

1. Le NameNode

Dans un cluster Hadoop, le NN héberge des métadonnées HDFS :

• Correspondance entre un fichier et les blocs le constituant.
• Localisation de ces blocs dans le cluster (correspondance bloc <-> DN, avec trois DN pour un bloc par défaut).
• Informations sur les propriétaires de fichiers et les autorisations.

Les métadonnées sont stockées sur disque dur (fichier fsimage) et chargées dans la mémoire vive du NN lors du démarrage du cluster. Toutes les modifications qui interviennent dans un cluster en fonctionnement sont répercutées immédiatement dans la mémoire vive du NN. En outre, elles sont enregistrées dans un journal (fichier edits) stocké sur disque dur.

La localisation des blocs dans le cluster (la correspondance bloc <-> DN) n’est conservée ni dans le fichier fsimage, ni dans le fichier edits.

Le choix de ne pas sauvegarder ces informations au niveau du NN peut paraître surprenant, ne serait-ce que pour des raisons de performance. À la réflexion, ce choix permet à un administrateur Hadoop de modifier librement, dans une certaine mesure, la configuration d’un cluster Hadoop à l’arrêt. Il peut par exemple, sans que cela nuise à son fonctionnement :

• Enlever un ou deux disques durs dans un cluster à l’arrêt : HDFS est capable dans de telles conditions de lire la troisième réplique des données et d’en créer deux nouvelles dans le cluster.
• Intervertir autant de disques durs qu’il veut entre les nœuds dans un cluster à l’arrêt.

Les échanges d’informations qui ont lieu à chaque démarrage entre les DN et le NN permettent au NN de reconstruire une cartographie à jour de la localisation des blocs dans le cluster.

2. Le SecondaryNameNode

Contrairement à ce que son nom pourrait laisser penser, le SNN n’est pas une copie de secours (backup) du NN.

Le SNN effectue des tâches de maintenance pour le compte du NN. Plus précisément, le SNN consolide à intervalle régulier les modifications enregistrées dans le journal (fichier edits), et les reporte dans le fichier fsimage. Cela permet :

• De garder sous contrôle l’espace disque utilisé par le journal.
• De limiter la charge processeur du NN (le SNN le déchargeant de la tâche de maintenance).
• De réduire le temps de démarrage du NN, en limitant la taille du journal à "rejouer" au démarrage.

Le SNN intervient :

• Soit lorsque le fichier edits atteint une taille prédéfinie.
• Soit à intervalle régulier (par exemple une fois par heure).

Le paramétrage est effectué par l’administrateur Hadoop.

3. Le NN comme SPOF

Le NN est ce que l’on appelle dans le langage Hadoop un SPOF (Single Point Of Failure = maillon faible). Dans un cluster Hadoop "classique", une panne du NN entraîne en effet inéluctablement la panne de tout le cluster, dans la mesure où seul le NN possède la cartographie des données.

Jusqu’à Hadoop 2.0.0, la seule façon de parer à une défaillance du NN était :

• De lui affecter une machine à haute tolérance aux pannes (cf. chapitre Aspects matériels), tout comme le SNN d’ailleurs.
• D’avoir une machine "miroir", prête à démarrer en cas de défaillance du NN (ce qui peut se faire en une demi-heure environ).

À partir de la version 2 de Hadoop, cette notion de machine "miroir" a été institutionnalisée (cf. chapitre Les apports de la version 2 de Hadoop). 

4. Lecture d’un fichier HDFS par un programme Hadoop

La lecture d’un fichier HDFS par un programme Hadoop comporte les grandes étapes suivantes (les fonctions de gestion de fichiers sont issues du package Java org.apache.hadoop) :

• Le programme Hadoop fait une demande d’ouverture du fichier à HDFS, par le biais d’une instruction open().
• HDFS envoie au NN une demande de localisation des premiers blocs constituant le fichier, par le biais d’un appel de type RPC (Remote Procedure Call).
• Le NN s’assure que le programme dispose de droits suffisants pour lire le fichier. 
• Si tel est le cas (dans le cas contraire, une exception IOException est générée), le NN renvoie à HDFS trois adresses pour chaque bloc (cf. facteur de réplication), triées selon leur proximité par rapport à la JVM dans laquelle s’exécute le programme.
• HDFS renvoie une instance de FSDataInputStream au programme, ce qui permet à ce dernier d’accéder au fichier en lecture, par le biais de l’instruction read().
• Lorsque l’intégralité d’un bloc a été lue, HDFS ferme la connexion avec le DN concerné, et en ouvre une nouvelle pour lire le bloc suivant.
• Si un problème de lecture intervient au niveau d’un bloc :

• HDFS est en mesure de le détecter.
• HDFS essaye de lire le bloc concerné sur l’un ou l’autre des deux autres DN qui hébergent une copie.

• Enfin, lorsque la lecture du fichier est achevée, le programme Hadoop envoie close() à FSDataInputStream.

Lors de la lecture d’un fichier, l’essentiel de la communication se fait directement entre le(s) programme(s) et les DN. Le NN n’est sollicité que pour connaître les adresses des blocs à lire : cela représente un volume d’information assez faible et, qui plus est, cette information est stockée en RAM par le NN et est donc traitée très rapidement.

Cette disposition de Hadoop explique que les performances du cluster restent relativement constantes, quel que soit le nombre de DN.

Elle explique aussi pourquoi Hadoop est plus efficace pour traiter un nombre limité de "gros" fichiers plutôt qu’un grand nombre de "petits" fichiers : en effet, chaque information relative à un fichier (nom de fichier, permissions, localisation d’un bloc…) consomme environ 200 octets de RAM.

Un fichier de 1 Go avec une taille de bloc de 128 Mo consommera :

• 200 octets pour le nom de fichier.
• 8 * 3 * 200 = 4 800 octets pour la localisation des blocs (8 = nombre de blocs, 3 = nombre de répliques pour chaque bloc).

soit un total de 5 000 octets de RAM.

Dans les mêmes conditions, 1 000 fichiers de 1 Mo consommeront :

• 1 000 blocs pour les noms de fichiers.
• 1 000 * 3 * 200 = 4 800 octets pour la localisation des blocs (1 000 = nombre de blocs, 3 = nombre de répliques pour chaque bloc).

soit un total de 600 000 octets de RAM.

Le détail d’une opération de lecture par un programme Hadoop (source : Vijay Thakorlal, http://vijayjt.blogspot.fr/, licence CC 3.0)

5. Création d’un fichier HDFS par un programme Hadoop

La création d’un fichier HDFS par un programme Hadoop comporte les grandes étapes suivantes :

• Le programme Hadoop fait une demande de création du fichier à HDFS, par le biais d’une instruction create().
• HDFS envoie une demande de création de fichier au NN, par le biais d’un appel de type RPC.
• Le NN s’assure :

• Que le fichier n’existe pas déjà.
• Que le programme dispose de droits suffisants pour créer le fichier.

• Si tel est le cas (dans le cas contraire, une exception IOException est générée) :

• Le NN intègre le nouveau fichier dans sa cartographie des données du cluster.
• HDFS renvoie une instance de FSDataOutputStream au programme, ce qui lui permet d’accéder au fichier en écriture.

• Les enregistrements envoyés à HDFS pour écriture dans le fichier sont découpés en paquets (packets) et stockés temporairement dans une file d’attente (data queue), qui est prise en charge par une instance de DataStreamer :

• DataStreamer demande au NN les adresses de trois blocs sur trois DN différents (cf. facteur de réplication) pour y stocker les données qui sont en attente dans la file d’attente.
• Chaque fois qu’un paquet de données a été stocké avec succès sur un DN, un accusé de réception du paquet (packet acknowledged) est envoyé à FSDataOutputStream. 

• Lorsqu’un groupe de trois blocs est plein, DataStreamer demande au NN trois nouvelles adresses.
• Si un problème d’écriture intervient au niveau d’un DN :

• HDFS est en mesure de le détecter car il manquera un accusé de réception pour le paquet concerné.
• HDFS dispose de mécanismes permettant de rétablir une situation normale, c’est-à-dire l’affectation d’un bloc de remplacement dans le cluster et la réécriture de tous les paquets susceptibles d’être affectés par le problème d’écriture dans ce nouveau bloc.

• Enfin, lorsque le dernier paquet a été écrit avec succès sur trois DN différents, le programme Hadoop envoie close() à FSDataOutputStream.

Le détail d’une opération d’écriture par un programme Hadoop (source : Vijay Thakorlal, http://vijayjt.blogspot.fr/, licence CC 3.0)