Présentation Hadoop Distributed File System

hadoop-hdfs
Hadoop est une implémentation open source en Java du MapReduce distribuée par la fondation Apache. Il a été mis en avant par des grands acteurs du web tels que Yahoo! et Facebook. Les deux caractéristiques principales de Hadoop sont le framework MapReduce et le Hadoop Distributed File System (qui s’inspire du Google File System). Le HDFS permet de distribuer les données et de faire des traitements performants sur ces données grâce au MapReduce en distribuant une opération sur plusieurs nœuds afin de la paralléliser.

 

Source :

http://mbaron.developpez.com/tutoriels/bigdata/hadoop/introduction-hdfs-map-reduce
http://fr.slideshare.net/hugfrance/introduction-hdfs
http://pagesperso-systeme.lip6.fr/Jonathan.Lejeune/documents/cours_hadoop.pdf

Qu’est-ce que HDFS ? :

HDFS (Hadoop Distributed File System) 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. Utilisation de FUSE.
  • 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. 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.

 

Le NameNode (Noeud maître)

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 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.
Elles sont ensuite montées en mémoire et aucune pagination n’est faite. Les différents types de métadonnées :

  • liste des fichiers
  • liste des blocs pour chaque fichier
  • liste des DataNodes pour chaque bloc
  • Attributs de fichiers, dernier accès, facteur de réplication.

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.

Le Namenode charge tout en mémoire. Cela devient donc problématique si vous avez énormément de petits fichiers à gérer. 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 Secondary NameNode (Noeud maître secondaire)

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, le Namenode secondaire prend sa place.

Le DataNode (Noeud de données, Noeud Esclave)

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 Datenodes 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.

HDFS

 

Pourquoi choisir HDFS ? :

Pour son système de fichier large et distribué.

  • Ex Yahoo! 10000 Noeuds utilisés, 100 Millions de fichiers, 10 Po (Péta Octets, 10000 To, 10000000 Go). De plus la scalabilité permet de faire encore plus.
  • Fonctionne sur tous types de machine, même des machines rackables (commode).
  • La réplication de fichiers fait partie du mécanisme interne de HDFS.
  • Détection des échecs, et failback inclut.

Optimisé pour le traitement par lots.

  • Emplacements des données connues
  • Taille de la bande passante utilisée réduite.

Le fait d’utiliser un seul espace de nom pour l’ensemble du cluster permet une meilleure cohérence des données.

Pour une réplication efficace des données

L’optimisation du système d’écriture de HDFS permet des accès à la donnée rapide. L’utilisation du mode bloc de grande taille (128Mo en général, jusqu’à 1Go) permet des accès rapide à la donnée.

Ces mêmes blocs sont en plus répliqués sur plusieurs noeuds (configurable, mais au moins 3 recommandées), ce qui assure une grande disponibilité de la donnée.
La réplication se fait de la sorte :

  • Un répliqua sur un noeud aléatoire dans le rack local.
  • Un répliqua sur un noeud aléatoire dans un rack distant
  • Un répliqua sur un noeud aléatoire sur le même rack distant
  • Un répliqua additionnel placé aléatoirement.

Lors de la lecture, les clients utilisent le répliqua le plus proche.

Pour une tolérance aux fautes

HDFS supporte très bien le crash d’un DataNode. Si le NameNode ne voit plus de « heartbeat » provenant du DataNode, il utilisera les répliquas des autres DataNode pour les prochaines lectures.
Un nouveau lot de répliqua sera alors mis en place sur les DataNode restant.

Comme vu précédemment le NameNode peut être secondé. Il peut aussi profiter du HA avec une mise en cluster « traditionnel ».
Il y a une sauvegarde des logs de transaction sur un support stable. Il sera donc possible de redémarrer sur la dernière image du HDFS et d’appliquer les logs de transaction.

HDFS-redemarrage

Pour une API performante

L’API de HDFS intelligente qui permet l’accès directe au données depuis le DataNode et de rechercher l’emplacement des blocs.

Flux de lecture et d’écriture dans HDFS

La lecture dans HDFS

Le client récupère la liste des DataNodes sur lesquels les blocs sont situés.
Il va ensuite chercher les blocs sur les différents DataNodes.

HDFS-Read

L’écriture dans HDFS

Le client récupère la liste des DataNodes sur lesquels placer les différents répliquas. Ensuite il écrit le bloc sur le premier DataNode.
Le premier DataNode écrit le bloc et transfère ensuite les données au prochain DataNode dans le pipeline.
Quand l’ensemble des répliquas sont écrits, le client recommence la procédure pour les blocs suivants.

HDFS-write

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

11 + onze =