Comment HDFS gère les fichiers distribués Hadoop ?

Hadoop hdfs 3370

Le système de fichiers distribués Hadoop (HDFS) est basé sur le système de fichiers Google (GFS) et fournit une conception conçu pour fonctionner sur du matériel standard. Il présente de nombreuses similitudes avec les systèmes de fichiers distribués existants. Cependant, les différences par rapport aux autres systèmes de fichiers distribués sont importantes. Il est très tolérant aux pannes et est conçu pour être déployé sur du matériel à faible coût. Il fournit un accès à haut débit aux données d'application et convient aux applications ayant de grands ensembles de données. C’est ainsi que nous allons détailler dans cet article la problématique à laquelle répond la HDFS, ses caractéristiques , objectifs, architecture ainsi que quelques commandes utiles.

Table de matière

1. Les fichiers systèmes et la problématique de gestion des données distribuées

1.1. Définition d’un fichier système

Un fichier système définit les composantes essentielles au bon fonctionnement d’un système d’exploitation donné. Ces fichiers système ont ainsi de diverses fonctionnalités et on en distingue plusieurs types, à savoir :

  • Les fichiers d’amorçage : ils sont localisés à la racine de la partition active et ont pour rôle principal d’amorcer le système d’exploitation (les fichiers IO.SYS, MSDOS.SYS du DOS).
  • Les fichiers noyau : ces fichiers sont le cœur d’un système d’exploitation et sont localisés généralement dans le répertoire système. Dans ce cas, ces fichiers contiennent les commandes internes du système.
  • Les fichiers configuration : Ces fichiers gèrent la configuration du matériel et logiciels installés.

On cite à titre d’exemple les fichiers système les plus répandus tel que : IO, MSDOD, CONIG etc …



1.2. Problématique

Dans un environnement BIG Data, la problématique qui se pose est la nécessité de déplacer les Workers vers les données vu le volume considérable des données que nous traitons et analysons. Ceci nécessite alors un stockage des données dans le disque local des nœuds dans le cluster.

Le gain principal de ce processus est d’éviter le trafic réseau , dépasser la limite de la RAM qui est généralement insuffisante pour contenir toutes les données en mémoire et finalement l’accès au disque qui est très lent. La question qui se pose est la suivante : Comment dépasser les limites citées et réaliser le processus de distribution des données ?

2. Les fichiers systèmes distribués

2.1. Définition d’un fichier système distribué

En réponse à la problématique cité ci-dessus , il faut dire que la solution typique à ce problème est l’utilisation de fichiers systèmes distribués. Un système de fichiers distribués est un système qui permet le partage de fichiers à une multitude d’utilisateurs. Contrairement à un système de fichiers local, l’utilisateur interagit avec le système de fichiers via un protocole adéquat et n’a pas accès au système de stockage.

Parmi les fichiers de systèmes distribués les plus connus et performants , on distingue les GFS ( Google File System) pour Google’s MapReduce et HDFS (Hadoop Distributed File System) pour Hadoop.

hdfs stockage distribue 3370

2.2. Caractéristiques des systèmes de fichiers distribués

Commençons d’abord par énumérer les principales caractéristiques des GFS:

  • Le stockage en morceaux (Chunks de taille 64 MB):
  • La fiabilité par réplication : Chaque Chunck est répliqué sur trois chunckservers ou plus.
  • Un seul master est désigné pour coordonner l’accès et garder les métadatas. Ceci représente un manager central simple de contrôle.
  • La possibilité de lecture en flux (streaming) ce qui permet d’éviter la présence des données en cache.
  • Simplification de l’API.

En se basant sur les caractéristiques du système de fichiers distribués GFS, on peut dire que l’HDFS est un simple GFS cloné avec le même principe , idée et des caractéristiques semblables.

Par ailleurs, il existe cependant de légères différences entre le GFS et l’HDFS qui s’inscrivent dans la différence au niveau de la terminologie : GFS master = Hadoop NameNode et le GFS chunkservers = Hadoop DataNodes. D’un autre côté , le modèle de cohérence entre les deux systèmes de fichiers distribués est diffèrent pour les fichiers ajoutés et on distingue également une différence au niveau de l’implémentation et la performance.

3. La solution HDFS

Comme défini, le système de fichiers distribués Hadoop (HDFS) est un système conçu pour fonctionner principalement sur du matériel standard. Ce dernier définit également les notions de bases des systèmes de fichiers distribués existants à savoir : la notion de blocs , les métadonnées, l’arborescence , les droits et les répertoires.

3.1. Les caractéristiques de HDFS

En addition des caractéristiques générales des systèmes de fichiers distribués , HDFS est caractérisé particulièrement par :



  • La haute tolérance aux pannes.
  • Le déploiement sur du matériel à faible coût.
  • L’accès haut débit aux données d’application.
  • L’accomplissement des exigences POSIX pour un accès continu aux données du système.
  • La conception d’infrastructure pour la fondation Apache ( moteur de recherche Web Apache Nutch).
  • Les hypothèses et objectifs :

En réponse à la problématique de gestion, HDFS vient répondre à des hypothèses et objectifs visant le bon traitement et analyse des données massives. Ces hypothèses sont les suivantes :

3.2. La défaillance matérielle

Dans l’optique de l’HDFS, la défaillance matérielle est la norme plutôt que l’exception. Une instance HDFS peut comprendre plusieurs serveurs, chacun stockant une partie considérable des données du système des fichiers. Le fait qu’il existe un nombre considérable de composants et que chacun d’entre eux a une probabilité de défaillance, implique que certains composants de l’HDFS sont non fonctionnels.

  • L’accès aux données en streaming :

Les applications qui fonctionnent sur HDFS ont besoin d'un accès en continu a? leurs données. Dans ce cadre, HDFS est davantage conçu pour le traitement par lots plutôt que pour une utilisation interactive. C’est ainsi que l'accent est mis sur le débit élevé? d'accès aux données plutôt que sur la faible latence de l'accès aux données.

  • Les larges data-sets

Les applications qui fonctionnent sur HDFS ont de grands ensembles de données avec des fichiers typiques d’une taille allant de giga-octets a? téraoctets.

  • Un modèle de cohérence simplifié

Les applications HDFS ont besoin d’un modèle d’accès « write-once-read-many » pour leurs fichiers .Un fichier crée? et stocké sur HDFS n’a pas besoin d’être modifie?, sauf s’il s’agit des ajouts ou des tronçons. Dans ce contexte, l’ajout du contenu a? la fin des fichiers est pris en charge mais ne peut pas être mis a? jour a? tout moment.

Cette hypothèse a pour objectif principal de simplifier les problèmes de cohérence des données et de permettre un accès aux données a? haut débit.

  • Probabilité sur des plateformes matérielles et logicielles hétérogènes

HDFS a été? conçu principalement pour être facilement portable d'une plateforme a? une autre .Cela facilite l'adoption générale de HDFS en tant que plateforme de choix pour un grand nombre d'applications.

3.3. L’architecture HDFS 

HDFS adopte une architecture maître/esclave. Dans ce sens, un cluster HDFS consiste en un seul NameNode qui est considéré comme étant le serveur maître destiné à la gestion de l'espace de noms du système de fichiers et régularise l'accès aux fichiers par les clients.

En outre, il existe plusieurs DataNodes, généralement un par nœud dans le cluster, qui gèrent le stockage attache? aux nœuds sur lesquels ils s'exécutent.

HDFS expose un espace de noms de système de fichiers et permet aux données utilisateur d'être stockées dans des fichiers.

architecture hdfs 3370

Dans les points suivants, nous allons détailler les composantes et étapes principales sur lesquelles se base l’architecture HDFS.



  • L’espace de noms HDFS 

Le nameNode maintient l'espace de noms du système de fichiers. Toute modification apportée a? l'espace de noms du système de fichiers ou a? ses propriétés fondamentales est

enregistrée par le NameNode central. Une application HDFS peut ainsi spécifier le nombre de répliques d'un fichier qui doit être géré? par HDFS, ce nombre de copies est appelé? facteur de réplication.

  • La réplication de données

HDFS est conçu pour stocker de manière fiable des fichiers très volumineux sur un grand cluster. Il stocke chaque fichier sous forme d'une séquence de blocs (chunck) tous les blocs d'un fichier. Ces blocs ont la même taille (64M par défaut) à l’exception du dernier bloc.

Le premier décideur par rapport à la réplication des données est le NameNode. Il reçoit périodiquement un battement de cœur (Heartbeat) et un rapport de bloc de chacun des DataNodes du cluster. La réception d'une pulsation (Heartbeat) implique que le DataNode fonctionne correctement. Et finalement, Un Blockreport est délivré qui contient une liste de tous les blocs sur un DataNode.

  • La persistance des métadonnées

L'espace de noms HDFS est stocke? par le NameNode. Ce dernier utilise un journal de transactions appelé? EditLog pour enregistrer de manière permanente toutes les modifications apportées aux métadonnées du système de fichiers.

Par exemple, la création d'un nouveau fichier dans HDFS amène le NameNode a? insérer un enregistrement dans le journal d'édition le signalant.

Tout l'espace de noms du système de fichiers, y compris le mappage des blocs en fichiers et les propriétés du système de fichiers, est stocke? dans un fichier appelé? « FsImage ».

« FsImage » est à son tour enregistre? en tant que fichier dans le système de fichiers local de NameNode.

  • La fédération de l’HDFS

La fédération de l’HDFS au fil du temps se divise en deux parties majeurs :

  • Avant Hadoop 2.0 :
    • Le NameNode était un point unique d’échec (single Point Of failure) et de limitation des opérations.
    • les clusters Hadoop comptaient généralement moins de clusters pouvant évoluer au-delà? de 3 000 ou 4 000 nœuds.
  • Après Hadoop 2.0 :
    • Plusieurs NameNodes peuvent être utilisés dans Hadoop 2.x.
    • La haute disponibilité? dans HDFS.

4. Quelques commandes utiles

Dans ce paragraphe , nous mettrons en place quelques commandes utiles pour le stockage et l’interrogation des fichiers sur HDFS. D’abord, il faut savoir que toutes les commandes hadoop sont appelés par le script bin/hadoop.

  • Hdfs fsck -files -blocks : liste les blocs qui composent chaque fichier sur HDFS.
  • Hadoop fs -file_cmd : la syntaxe générale de la commande shell du système de fichiers distribués de HDFS( similaire à celle de linux).
  • Hadoop fs -mkdir /user/repertoire : création du dossier /user/repertoire dans la racie de hdfs.
  • Hadoop fs –put file_name /user/repertoire :déplacer le fichier file_name stocké en local sur le dossier /user/repertoire localisé sur hdfs.
  • Hadoop fs –put data.txt /user/repertoire: déplacer le fichier tete data.txt stocké en local sur le dossier /user/repertoire localisé sur hdfs.
  • Hadoop fs -ls: lister les fichiers HDFS existants.

Conclusion

HDFS comprend un grand nombre de matériel de base. Par conséquent, il dispose de mécanismes de détection et de récupération rapides et automatiques des pannes. C’est dans ce contexte qu’il est appliqué par excellence pour la détection et récupération des pannes informatiques.



Aujourd’hui, HDFS est indispensable pour le stockage et traitement des données que ce soit en offline ou en streaming. Son utilisation ne cesse d’évoluer au fil du temps et ses échos sont de plus en plus répandus dans le monde du Big Data et gestion des données volumineux.