HDFS (Hadoop Distributed File System) est
avant tout un système de fichier écrit en java. Pour pouvoir stocker les données structurées sur un
périphérique, on utilise un format qui les représente sous la forme d'une
succession de blocs de données : c'est le job principal d'un un système de fichiers. Contrairement aux autres systèmes de fichiers, HDFS ne fait pas de mise à jour de fichier.
Les systèmes de
fichiers les plus courants sont ReFS, NTFS et
FAT32 (pour les stockages Windows) ou bien ext3, ext4 (pour les stockages
Linux), iso 9660 (cd) et udf (dvd).
HDFS en plus
d’être un file system, il est distribué c’est-à-dire qu’il divise les
données d’un fichier par paquet (64 Mo par défaut) et les stocke sur
plusieurs machines. Il est
toutefois possible de monter à 128 Mo, 256 Mo, 512 Mo voire 2 Go ce qui
permet de réduire le seek time (temps d’accès à un bloc). À titre de
comparaison, le système de gestion de fichiers Linux ext3 a une taille de blocs
de 4 ou 8 Ko.
La distribution
des données est une abstraction pour l’utilisateur. En effet, l’utilisateur ne
perçoit pas la distribution des données car il accède aux fichiers HDFS de
manière classique au travers d’une arborescence classique sous
la forme répertoire/sous-répertoire/fichier.extension. Cependant, les données
des fichiers sont bien réparties sur plusieurs nœuds pour plus de performance
avec un mécanisme de réplication pour une tolérance aux pannes. Cette
performance est d’autant plus meilleure que lorsqu’on travaille sur des
fichiers de taille importante (100 Mo ou plus) (des millions de fichiers de grande taille plutôt
que des milliards de fichiers de petite taille).
Il existe 3
composants principaux : Name Node, Secondary Name
Node et Data Node
Name Node orchestre
le processus de stockage des données. Il sauvegarde l'emplacement de tous les
fichiers dans le système de fichiers local. Le client communique avec lui
à chaque fois qu'il demande un fichier à travers des opérations de lecture
et d'écriture. Il dispose entre autre d’un fichier edits contenant toutes les
opérations effectuées dans le système. A l’aide du fuchier edits, le
Name Node enregistre le moindre changement du système de
fichiers. Si par exemple, un fichier est supprimé de HDFS, le Name Node le consigne immédiatement dans ce journal. Le fichier edits sert un peu comme le
backup qui doit permettre à reconstruire l'état de fichiers si le système
plante.
Le Name Node est
également responsable de gérer la réplication des blocs des fichiers. Tout
changement du facteur de réplication de l’un des blocs sera consigné par le
Name Node dans le fichier de log edits. Il reçoit régulièrement un ping
et un rapport sur les blocs (Bloclreport) de tous les Data Nodes (voir section Data Node) dans
le cluster afin de s’assurer que les data nodes fonctionnent correctement. Un
Bloclreport contient une liste de tous les blocs d’un Data Node. En cas de
défaillance du data node, le Name Node choisit de nouveaux data nodes pour de
nouvelles réplications de blocs de données.
Pour accélér
l'accès aux informations des blocs d'un fichier (nom de fichier,
répertoire, association block/fichier, position des blocks, nombre de réplicas,
permissions, localisation d’un bloc…), le
Name Node les stocke dans la mémoire RAM. Ces informations consomment environ
200 octets de RAM.
Data Node peut
être vu comme un nœud client (ou slave, aussi appelé worker). Il
effectue les opérations demandées par name node. Il stocke chaque bloc de données
HDFS dans des fichiers séparés dans son système de fichiers local et retrouve
les blocks demandés par name node. Il apporte également au name node, un rapport contenant une liste
des blocks stockés. Ce rapport est envoyé périodiquement pour signaler l’état
de santé global de HDFS.
Secondary namenode joue le rôle de backup régulier de
l'image de Name Node. Un check de l'état de name node
est périodiquement effectué au cours duquel les fichiers
de méta-données sont copiés : edits.... Le check intervient à un
intervalle régulier appelé checkpoint (point de
contrôle; par exemple une fois par heure). Les informations collectées ne sont donc pas forcément à jour. Secondary namenode n'est pas une réplication du name node
principal et il peut contenir des données périmées suite à des opérations
effectuées après la création de son point de contrôle. L'intervalle de création
du checkpoint peut être précisé dans la propriété de
configuration fs.checkpoint.period.
Aucun commentaire:
Enregistrer un commentaire