HDFS - d'autres points importants

Hadoop et MapReduce en Java

Ce site ne sera plus alimenté de contenu après août 2014. Tous les nouveaux articles seront redigés pour www.waitingforcode.com
Précédemment on a vu les interactions entre namenode et datanode dans HDFS. Cependant, ces interactions ne sont pas les seules composants de l'HDFS.

A travers cet article on verra d'autres aspects liés à ce système de fichiers distribué. Au début on regardera les points importants, tels que la synchronisation, la réplication, la compression et la sérialisation. Ensuite on montrera comment namenode localise les fichiers à retourner au client. A la fin on expliquera pourquoi HDFS n'est pas adapté au grand nombre de petits fichiers. On dira également comment cette limitation peut être contournée.

Points importants de l'HDFS
D'autres notions importantes de l'HDFS à connaître sont majoritairement liées au caractère robuste du système. On y retrouve :

  1. la réplication : c'est grâce à elle que l'HDFS peut resister à toutes les failles hardware. Le mécanisme est très simple. Lors de l'écriture d'un nouveau fichier, chaque block peut être répliqué sur plusieurs machines (nombre à définir dans la configuration). Au moment de la lecture, si la machine du datanode choisi par namenode est indisponible, namenode va aller chercher le fragment manquant sur d'autres machines le contenant.Comment sont choisies les machines qui stockeront les blocks répliqués ? La première machine qui va le faire correspond à la machine de la JVM. La seconde copie est placée dans un cluster (groupe d'ordinateurs) différent. Le choix est alors aléatoire. La dernière copie (si 3 replicatas configurés), est sauvegardée dans une machine différente du cluster choisi pour la 2e copie.

  2. la sérialisation : ce processus consiste à transformer les objets informatiques en un stream des bytes pour pouvoir les transmettre via le réseau ou pour pouvoir les sauvegarder d'une manière persistante. Chez HDFS on peut utiliser la gestion de sérialisation proposée en natif. Elle se base sur l'interface Writable. L'autre méthode consiste à l'utilisation des outils tiers, comme Apache Avro.

  3. la compression : ce traitement vise à limiter la quantité des données à manipuler et à stocker. Cependant, on ne devrait pas utiliser n'importe quel mécanisme de compression sur HDFS. Il est très préférable d'utiliser ceux qui rendent possible la division des fichiers compressés. Cela veut dire que l'on peut accéder à n'importe quel point du stream de fichier envoyé et, par exemple, commencer sa lecture au milieu à la place du début. Le format supportant la division est bzip2. Les autres (DEFLATE, gzip) peuvent poser des problèmes au niveau de la rapidité de traitement. Dans ce cas, il y aura beaucoup moins de fonctions map qui traiteront le fichier envoyé. Il n'y aura qu'une ou quelques-unes, en fonction de la taille du fichier.



Localisation des fichiers dans HDFS
Comment namenode sait où chercher les blocks les plus proches, ce qui améliore forcément le temps de réponse ? Il calcule la distance entre les datanodes placés sur les machines. Si le datanode se trouve sur la même machine, la distance est 0. S'il est placé sur une autre machine, mais dans le même rack, leur distance est plus grande.

Cependant, ce n'est pas distance la plus grande. Namenode et datanodes peuvent se trouver dans les machines placées dans des racks différents. Du coup, leur distance est encore plus grande. Pareil s'ils sont stockés dans les machines issues de différents datacenter (centres de traitement des données).

Pourquoi ne pas utiliser HDFS pour beaucoup de petits fichiers ?
HDFS est inefficace pour beaucoup de petits fichiers. Les méta-données du namenode sont stockées dans la mémoire. La taille de mémoire disponible impose donc la limite des données qu'on peut stocker dans le système. Chaque fichier, répertoire et block y sont représentés et occupent de la place. Chacun prend à peu près 150 bytes de la mémoire. Quand on connaît ce chiffre, il peut vite s'averer qu'aurait besoin de quelque chose de plus que "machine ordinaire" pour faire fonctionner Hadoop et HDFS.

Une des solutions à ce problème peut être l'utilisation des fichiers d'archives, HAR. C'est lui qui permet de regrouper plusieurs petits fichiers en un seul, plus grand. Cependant, il faut rester vigilant. L'archive copie le fichier. Le système contiendra alors 2 fichiers identiques ce qui, dans le cas d'une multiplication, peut mettre en danger l'espace disque. C'est pourquoi après chaque archivage, les fichiers initiaux doivent être supprimés. Deuxièment, les archives ne sont pas modifiables. On ne peut y rajouter des fichiers que par le désarchivage et un nouvel archivage, avec des fichiers supplémentaires.

On a bien vu que l'HDFS n'est pas une baguette magique où tout est possible et imaginable. Dans certaines situations, comme celle de beaucoup de petits fichiers, il faut essayer de différentes combinaisons afin de correspondre aux caractéristiques de ce système de fichiers. Le système qui reste néanmoins intelligent, aussi bien à travers ses mécanismes de protection qu'à travers ses performances.
Bartosz KONIECZNY 08-09-2013 16:10 Hadoop
Moi

Développeur d'applications Internet et journaliste passionné par l'adjectif français. Un aigle polonais orienté vers la progression, volant très haut et écoutant du zouk après les matches du foot français.

Vous appréciez mon travail ?

Pour contribuer au développement de ce site, ou pour remercier pour des articles rédigés, vous pouvez faire un don.

Un conseil Android

Comment résoudre le problème de «Unknow Android Packaging Problem" » dans Eclipse ?

Une simple manipulation dans le menu Project->Clean devrait aider.