FAQ HadoopConsultez toutes les FAQ

HDFS (Hadoop Distributed File System) est la couche de stockage de Hadoop. Il reprend de nombreux concepts proposés par des systèmes de fichiers classiques comme ext2 pour Linux ou FAT pour Windows. Nous retrouvons donc la notion de blocs (la plus petite unité que l'unité de stockage peut gérer), les métadonnées qui permettent de retrouver les blocs à partir d'un nom de fichier, les droits ou encore l'arborescence des répertoires.

Toutefois, HDFS se démarque d'un système de fichiers classique pour les principales raisons suivantes.

• HDFS n'est pas solidaire du noyau du système d'exploitation. Il assure une portabilité et peut être déployé sur différents systèmes d'exploitation. Un des inconvénients est de devoir solliciter une application externe pour monter une unité de disque HDFS.
• HDFS est un système distribué. Sur un système classique, la taille du disque est généralement considérée comme la limite globale d'utilisation. Dans un système distribué comme HDFS, chaque nœud d'un cluster correspond à un sous-ensemble du volume global de données du cluster. Pour augmenter ce volume global, il suffira d'ajouter de nouveaux nœuds. On retrouvera également dans HDFS, un service central appelé Namenode qui aura la tâche de gérer les métadonnées.
• HDFS utilise des tailles de blocs largement supérieures à ceux des systèmes classiques. Par défaut, la taille est fixée à 64 Mo dans Hadoop 1 (128 Mo dans Hadoop 2). Il est toutefois possible de monter à 128 Mo, 256 Mo, 512 Mo voire 1 Go. Alors que sur des systèmes classiques, la taille est généralement de 4 Ko, l'intérêt de fournir des tailles plus grandes permet de réduire le temps d'accès à un bloc. Notez que si la taille du fichier est inférieure à la taille d'un bloc, le fichier n'occupera pas la taille totale de ce bloc.
• HDFS fournit un système de réplication des blocs dont le nombre de réplications est configurable. Pendant la phase d'écriture, chaque bloc correspondant au fichier est répliqué sur plusieurs nœuds. Pour la phase de lecture, si un bloc est indisponible sur un nœud, des copies de ce bloc seront disponibles sur d'autres nœuds.

Un Namenode est un service central (généralement appelé aussi maître) qui s'occupe de gérer l'état du système de fichiers. Il maintient l'arborescence du système de fichiers et les métadonnées de l'ensemble des fichiers et répertoires d'un système Hadoop. Le Namenode a une connaissance des Datanodes (étudiés juste après) dans lesquels les blocs sont stockés. Ainsi, quand un client sollicite Hadoop pour récupérer un fichier, c'est via le Namenode que l'information est extraite. Ce Namenode va indiquer au client quels sont les Datanodes qui contiennent les blocs. Il ne reste plus au client qu'à récupérer les blocs souhaités.

Toutes ces métadonnées, hormis la position des blocs dans les Datanodes, sont stockées physiquement sur le disque système dans deux types de fichiers spécifiques edits_xxx et fsimage_xxx.

La connaissance de la position des blocs dans les Datanodes est reconstruite à chaque démarrage du Namenode dans un mode appelé safe mode. Pendant le safe mode, l'écriture sur HDFS est impossible, le Namenode charge les fichiers edits_xxx et fsimage_xxx et attend le retour des Datanodes sur la position des blocs. Une fois toutes les opérations réalisées, le safe mode est relâché et l'accès en écriture est de nouveau autorisé. Soyez patient sur la durée du safe mode. Celui-ci peut être très long si vous avez beaucoup de fichiers à traiter.

Comme vous l'aurez remarqué, le Namenode charge tout en mémoire. Cela devient donc problématique si vous avez énormément de petits fichiers à gérer. D'après la documentation officielle de Cloudera, chaque fichier, répertoire et bloc dans HDFS est représenté comme un objet dans la mémoire et occupe 150 octets. Si, par exemple, vous avez 10 millions de fichiers à gérer, le Namenode devra disposer d'un minimum de 1,5 Go de mémoire. C'est donc un point important à prendre en compte lors du dimensionnement de votre cluster. Le Namenode est relativement gourmand en mémoire.

Le Namenode dans l'architecture Hadoop est un point unique de défaillance (Single Point of Failure en anglais). Si ce service est arrêté, il n'y a pas moyen de pouvoir extraire les blocs d'un fichier donné. Pour répondre à cette problématique, un Namenode secondaire appelé Secondary Namenode a été mis en place dans l'architecture Hadoop. Son fonctionnement est relativement simple puisque le Namenode secondaire vérifie périodiquement l'état du Namenode principal et copie les métadonnées via les fichiers edits_xxx et fsimage_xxx. Si le Namenode principal est indisponible, les administrateurs peuvent redémarrer manuellement un nouveau NameNode et utiliser les métadonnées copiées par le NameNode secondaire pour reconstituer l'état de HDFS.

Nous avons vu qu'un Datanode contient les blocs de données. Les Datanodes sont sous les ordres du Namenode et sont surnommés les Workers. Ils sont donc sollicités par les Namenodes lors des opérations de lecture et d'écriture. En lecture, les Datanodes vont transmettre au client les blocs correspondant au fichier à transmettre. En écriture, les Datanodes vont retourner l'emplacement des blocs fraîchement créés. Les Datanodes sont également sollicités lors de l'initialisation du Namenode et aussi de manière périodique, afin de retourner la liste des blocs stockés.

Pas automatiquement, HDFS ne déplacera pas des blocs vers les nouveaux nœuds. Cependant, il est probable que les blocs des nouveaux fichiers se placeront sur les nouveaux nœuds.

Il existe plusieurs façons de rééquilibrer le cluster manuellement.

1. Choisissez un sous-ensemble de fichiers qui prend un bon pourcentage de votre espace disque ; copiez-les sur de nouveaux emplacements dans HDFS ; supprimez les anciens exemplaires ; renommez les nouvelles copies avec leurs anciens noms.
2. Une façon plus simple, sans interruption de service, est d'activer la réplication des fichiers, d'attendre que les transferts se stabilisent, puis de désactiver la réplication.
3. Une autre façon de faire est de désactiver le nœud de données qui est plein, d'attendre que ses blocs soient répliqués, puis de le réactiver. Les blocs sur-répliqués seront effacés de façon aléatoire des différents nœuds, si bien qu'ils sont réellement rééquilibrés, pas seulement supprimés du nœud courant.
4. Enfin, vous pouvez utiliser la commande bin/start-balancer.sh pour lancer un processus automatique de rééquilibrage et de déplacement des blocs sur le cluster. Voir : HDFS User Guide: Rebalancer.

Oui. HDFS met à disposition une API permettant de spécifier la taille d'un bloc au moment de la création d'un fichier. Voir FileSystem.create(Path, overwrite, bufferSize, replication, blockSize, progress).

HDFS ne supporte que les écritures exclusives.

Quand le premier client contacte le nœud de noms pour ouvrir un fichier en écriture, le nœud de noms lui accorde le droit de créer le fichier. Si un autre client essaie d'ouvrir le même fichier en écriture, le nœud de noms verra qu'il a déjà accordé le droit à un autre client et rejettera la demande d'ouverture du second client.

Non. Comme HDFS n'écrit pas des blocs physiques bruts sur le disque, il y a en définitive deux tailles de blocs utilisés dans HDFS : la taille des blocs HDFS et la taille des blocs du système d'exploitation sous-jacent. HDFS crée des fichiers ne dépassant pas la taille des blocs HDFS (ainsi que le métafichier contenant le checksum CRC32 de ce bloc). Le système d'exploitation sous-jacent stocke ce fichier par incréments de la taille de ses blocs sur le disque physique, comme pour n'importe quel autre fichier.

Une fois HDFS monté par l'intermédiaire de la commande mount, vous pourrez alors utiliser les commandes standards fournies par le système de fichiers Linux. Ceci offre l'avantage de simplifier la manipulation d'HDFS, car il n'y aura plus besoin d'utiliser les sous-commandes Hadoop.

Pour monter HDFS vous devez installer Fuse. La configuration de Fuse pour Hadoop se fait facilement avec la distribution de Cloudera. La même chose via la distribution Apache Hadoop n'est pas si facile.

Pour l'installation de Fuse pour Hadoop, il vous suffit d'installer le package fourni par Cloudera.

$ sudo apt-get install hadoop-hdfs-fuse

1
2
$ cd /home/hduser
$ mkdir hdfs

1
2
3
$ sudo hadoop-fuse-dfs dfs://localhost:9000 /home/hduser/hdfs/
INFO /var/lib/jenkins/workspace/generic-package-ubuntu64-12-04/CDH5beta1-Packaging-Hadoop-2013-10-27_17-04-57/hadoop-2.2.0+cdh5.0.0+353-0.cdh5b1.p0.79~precise/hadoop-hdfs-project/hadoop-hdfs/src/main/
native/fuse-dfs/fuse_options.c:164 Adding FUSE arg /home/hduser/hdfs/

Un cluster HDFS simple peut avoir un seul NameNode principal (appelé simplement NameNode), assisté par un NameNode secondaire. Un cluster à haute disponibilité, quant à lui, contient deux NameNodes dans Hadoop 2.x : un NameNode actif et un NameNode de secours. Dans Hadoop 3.x, il est possible de configurer plusieurs NameNodes de secours. Notez que lorsque la haute disponibilité est activée, vous ne pouvez pas utiliser le NameNode secondaire.

Le NameNode secondaire est une aide pour le NameNode. Il récupère les journaux de modification (EditLogs) du NameNode à intervalles de temps réguliers et les applique à l'image du système de fichiers (FsImage). La nouvelle FsImage créée est renvoyée au NameNode qui la charge en mémoire. Le NameNode utilisera également cette FsImage au prochain redémarrage afin de reconstituer l'état de HDFS, ce qui réduira le temps de démarrage. Cependant, le NameNode secondaire ne peut pas remplacer le NameNode. En cas de défaillance du NameNode, Hadoop sera hors service. Les administrateurs doivent redémarrer manuellement un nouveau NameNode à partir des métadonnées du NameNode secondaire.

Hadoop 2.0, avec la haute disponibilité, introduit donc un NameNode de secours, qui prend automatiquement le relais en cas de défaillance du NameNode actif. Notons que l'activation de la haute disponibilité n'est pas obligatoire. Mais, lorsqu'elle est activée, vous ne pouvez pas utiliser de NameNode secondaire.

Une FsImage (File system Image) est une image de l'état du système de fichiers à un moment donné de son fonctionnement. Le fichier FsImage, stocké sur le système de fichiers du système d'exploitation, contient la structure de répertoires complète (espace de noms) du HDFS avec des informations telles que la liste des blocs stockés sur chaque nœud.

Un EditLog ou journal de modifications est quant à lui un fichier dans lequel sont stockées les modifications apportées au système de fichiers HDFS ou toute action effectuée sur le cluster (création, réplication, suppression d'un bloc, etc.) depuis la création de la dernière FsImage.

Autrement dit, on a le dernier état de HDFS en appliquant les modifications enregistrées dans l'EditLog à la FsImage. Ces deux fichiers sont donc importants pour la reconstitution de l'état de HDFS juste avant un arrêt volontaire ou non : lorsque le NameNode démarre, il lit l'état de HDFS à partir du fichier FsImage, puis il applique les modifications qui ont été effectuées sur ce fichier image telles qu'indiqué par l'EditLog. Il enregistre ensuite le dernier état de HDFS en créant un nouveau fichier image. L'EditLog est alors vidé pour enregistrer les nouvelles modifications. Étant donné que l'EditLog est susceptible de se remplir très rapidement en mode production, le NameNode n'attend pas le prochain démarrage pour les fusionner, mais le fait de manière régulière selon un intervalle de temps configurable.

La tolérance aux pannes dans HDFS est la capacité du système à continuer à fonctionner dans des conditions défavorables (plantage d'un nœud, défaillance matérielle, etc.). Dans HDFS, elle est principalement assurée grâce à la réplication des blocs de données. HDFS stocke les fichiers de très grande taille en les divisant en blocs de données qui sont répartis sur différentes machines du cluster. Par défaut, HDFS crée 3 copies de chaque bloc sur d'autres machines du cluster. Ainsi, si une machine du cluster tombe en panne ou rencontre un problème qui ne permet pas d'accéder aux données qui y sont stockées, les clients pourront toujours accéder facilement à ces données à partir d'autres machines du cluster sur lesquelles une copie du bloc est présente.

La réplication entraînera la consommation de beaucoup plus d'espace. Mais l'utilisateur peut toujours ajouter plus de nœuds au cluster si nécessaire. Sinon, il peut modifier le facteur de réplication pour économiser de l'espace HDFS ou utiliser différents codecs fournis par Hadoop pour compresser les données. La réplication des données ne permet pas d'assurer la tolérance aux pannes en cas de défaillance du NameNode, d'où l'introduction d'un mécanisme de haute disponibilité dans Hadoop 2.

Dans Hadoop 1.0, le NameNode est un point de défaillance unique (Single Point of Failure, en abrégé SPOF). Si le NameNode rencontre un problème, les clients ne pourront plus lire/écrire des fichiers. Le système Hadoop entier serait alors hors service jusqu'à ce qu'un NameNode soit en place.

Hadoop 2.0 vient résoudre ce problème en prenant en charge plusieurs NameNodes. La fonctionnalité de haute disponibilité introduit un NameNode supplémentaire dans l'architecture Hadoop. Cette fonctionnalité permet de basculer automatiquement à un autre NameNode (Standby-NameNode ou NameNode de secours) si le principal NameNode (NameNode actif) tombe en panne, de sorte que le cluster continue de fonctionner. Hadoop 3.0 va plus loin en permettant d'utiliser plusieurs NameNodes en stand-by.

Les grandes instances HDFS s'exécutent sur un cluster d'ordinateurs qui est généralement réparti sur de nombreux racks ou baies. Le Rack awareness est une fonctionnalité importante qui permet de répliquer les données sur des serveurs et baies de sorte à garantir de meilleures performances de lecture et écriture.

En règle générale, la bande passante (et par conséquent les performances réseau) entre les machines d'un même rack est supérieure à la bande passante entre des machines de racks différents. Grâce à la fonctionnalité de Rack awareness, le NameNode est capable de déterminer l'ID du rack auquel appartient chaque DataNode. Lors de la réplication des blocs, il essaie donc de réduire le trafic d'écriture inter-racks (et, par conséquent, améliorer les performances d'écriture) en utilisant un nombre de racks inférieur au nombre de copies. Par exemple, lorsque le facteur de réplication est de trois, deux copies sont placées sur un même rack et la troisième se trouve sur un rack différent. Pour minimiser la consommation globale de bande passante et la latence de lecture, HDFS va également essayer de satisfaire à une demande de lecture à partir de la copie la plus proche du client. Si une copie existe sur le même rack que le nœud du client, c'est cette copie qui est utilisée pour satisfaire la demande de lecture.

Les DataNodes communiquent avec le NameNode en lui envoyant des pulsations et rapports de blocs. Le rapport de bloc, transmis toutes les six heures, contient une liste de tous les blocs sur un DataNode. Une pulsation ou heartbeat dans Hadoop est quant à elle un signal que les DataNodes envoient toutes les 3 secondes (par défaut) au NameNode pour montrer qu'ils fonctionnent (qu'ils sont vivants). Les pulsations d'un DataNode contiennent des informations sur la capacité de stockage totale, la fraction de stockage utilisée et le nombre de transferts de données en cours. Si, après un certain temps, le NameNode ne reçoit pas de signal d'un DataNode, alors il considère que ce dernier n'est plus opérationnel (il est mort). Le NameNode procède alors à la réplication des blocs que contenait ce DataNode sur d'autres DataNodes.

La principale limitation de l'implémentation HDFS dans Hadoop 1 est qu'elle n'autorise qu'un seul NameNode. Hadoop 2 introduit donc la fédération HDFS, qui est basée sur plusieurs NameNodes / espaces de noms indépendants.

Les avantages de la fédération HDFS sont la scalabilité et les performances de l’espace de noms : l’ajout de plus de NameNodes au cluster augmente le débit des opérations de lecture et écriture du système de fichiers. Un autre avantage est l'isolation : un seul NameNode n'offre aucune isolation dans un environnement multi-utilisateur. Une application expérimentale peut donc surcharger le NameNode et ralentir les applications en production. Avec plusieurs NameNodes, différentes catégories d'applications et d'utilisateurs peuvent être isolées dans différents espaces de noms.

Les NameNodes sont indépendants et ne nécessitent pas de coordination les uns avec les autres. Les DataNodes sont utilisés comme stockage commun des blocs par tous les NameNodes. Chaque DataNode s'enregistre auprès de tous les NameNodes du cluster, envoie périodiquement des pulsations et des rapports de blocs, et exécute les commandes des NameNodes.

Un espace de noms fonctionne sur un ensemble de blocs (un pool de blocs). Bien qu'un pool soit dédié à un espace de noms spécifique, les données réelles peuvent être allouées à n'importe lequel des DataNodes du cluster. Chaque pool de blocs est géré indépendamment et une défaillance d'un NameNode n'empêche pas les DataNodes de servir les autres NameNodes dans le cluster.

Lorsqu'un client souhaite écrire un fichier dans HDFS, il communique d'abord avec le NameNode pour obtenir les adresses des DataNodes où écrire. Si le fichier n'existe pas déjà et que le client dispose des droits nécessaires pour le créer, le NameNode retourne une liste de DataNodes avec lesquels le client peut interagir directement pour l'écriture des données. Le NameNode fournit également au client un jeton de sécurité qu'il doit montrer aux DataNodes pour s'authentifier.

Le fichier est divisé en blocs, et les opérations d'écriture des blocs se font en parallèle sur l'ensemble des DataNodes pour une écriture plus rapide du fichier. Pour un facteur de réplication de 3 (valeur par défaut), le NameNode enverra une liste de 3 DataNodes pour stocker chaque bloc du fichier. Ces DataNodes forment un pipeline pour transférer les blocs de données d'un DataNode à un autre : le client écrit un bloc de données dans le premier DataNode du pipeline. Celui-ci stocke le bloc de données reçu et le transmet au deuxième DataNode du pipeline, qui va à son tour le stocker puis le transmettre au troisième DataNode du pipeline. Ce dernier va simplement stocker le bloc de données sans le transférer à un autre DataNode, le facteur de réplication étant atteint. Une fois que l'opération d'écriture du bloc est terminée, une confirmation d'écriture est envoyée au NameNode, puis au client. Le même processus est répété pour chaque bloc du fichier, mais les opérations d'écriture des blocs se font en parallèle.

Lorsqu'un client veut lire un fichier dans HDFS, il communique d'abord avec le NameNode pour obtenir l'emplacement des DataNodes contenant les blocs de données du fichier. Si le client dispose des droits nécessaires pour cette opération, le NameNode retourne, pour chaque bloc de données du fichier à lire, l'emplacement des DataNodes sur lesquels ils sont stockés. Le NameNode fournit également au client un jeton de sécurité qu'il doit montrer aux DataNodes pour s'authentifier. Le client peut alors interagir directement avec les DataNodes. Il envoie une demande de lecture aux DataNodes les plus proches. Une fois que le client reçoit tous les blocs de données, il les combine pour former un fichier.

L'équilibreur dans HDFS est un outil qui permet d'assurer la répartition uniforme des données entre les DataNodes. En effet, pour différentes raisons (ajout d'un nouveau DataNode au cluster, beaucoup de suppressions et d'écritures, remplacement de disque), il est possible que les données ne soient pas toujours réparties uniformément entre les DataNodes dans HDFS. L'équilibreur analyse donc le placement et l'équilibre des blocs sur les DataNodes, et il déplace les blocs entre les DataNodes jusqu'à ce que le cluster soit considéré comme équilibré.

L'équilibreur de disque est un outil en ligne de commande, qui distribue les données de manière uniforme sur tous les disques d'un DataNode. C'est un équilibreur de données intranœud. Cet outil fonctionne sur un DataNode donné et déplace des blocs d'un disque à un autre. L'équilibreur de disque fonctionne en créant et en exécutant un plan (ensemble d'instructions) sur le DataNode. Un plan comprend plusieurs étapes, dont une étape de déplacement qui spécifie le disque source, le disque de destination et le nombre d'octets à déplacer. Le plan s'exécutera sur un DataNode opérationnel. Par défaut, l'équilibreur de disque n'est pas activé.

Le premier est un équilibreur de données internœuds, il essaie de répartir les données de manière uniforme sur l'ensemble des DataNodes du cluster. Le second est un équilibreur de données intranœud, il essaie de répartir les données de manière uniforme sur l'ensemble des disques d'un DataNode.

Le scanner de blocs vérifie si les blocs de données stockés sur chaque DataNode sont corrects ou non. Lorsque le scanner de blocs détecte un bloc de données corrompu, le DataNode en informe le NameNode, qui commencera alors le processus de réplication en utilisant une copie non corrompue présente sur d'autres DataNodes. Lorsque le nombre de réplications de la copie non corrompue correspond au facteur de réplication défini (par défaut égal à 3), le DataNode supprime le bloc corrompu.

Le Safemode ou mode sécurisé dans Hadoop est un état de maintenance pendant lequel le NameNode n'autorise aucune modification du système de fichiers : le cluster HDFS est en lecture seule et ne réalise aucune réplication ni suppression de blocs. Le NameNode entre automatiquement en mode sécurisé lors de son démarrage.

Au démarrage, le NameNode charge les fichiers FsImage et EditLog qu'il fusionne pour créer un nouvel espace de noms qui donne le dernier état du système de fichier avant son arrêt. Le NameNode attend ensuite les rapports de blocs qui lui sont envoyés par les DataNodes et qui lui permettent de connaitre l'emplacement des blocs de données. Le NameNode quitte le mode sécurisé après que les DataNodes ont rapporté que la plupart des blocs sont disponibles.