FAQ HadoopConsultez toutes les FAQ

Nombre d'auteurs : 3, nombre de questions : 41, dernière mise à jour : 4 septembre 2014  Ajouter une question

 

Cette faq a été réalisée à partir des questions fréquemment posées sur les forums de http://www.developpez.com et de l'expérience personnelle des auteurs et de la traduction de la documentation officielle d'Hadoop.

Nous tenons à souligner que cette faq ne garantit en aucun cas que les informations qu'elle propose sont correctes. Les auteurs font leur maximum, mais l'erreur est humaine. Cette faq ne prétend pas non plus être complète. Si vous trouvez une erreur, ou que vous souhaitez nous aider en devenant rédacteur, lisez ceci.

Sur ce, nous vous souhaitons une bonne lecture.

L'équipe Big Data


SommaireHDFS (10)
précédent sommaire suivant
 

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

Mis à jour le 3 septembre 2014 Mickael Baron

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.

Mis à jour le 3 septembre 2014 Mickael Baron

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.

Mis à jour le 3 septembre 2014 Mickael Baron

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

Mis à jour le 3 septembre 2014 Mickael Baron

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 ;
    • HDFS Tutorial: Rebalancing ;
    • HDFS Commands Guide: balancer.

Mis à jour le 3 septembre 2014 Mickael Baron

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

Mis à jour le 3 septembre 2014

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.

Mis à jour le 3 septembre 2014

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.

Mis à jour le 3 septembre 2014

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.

Code : Sélectionner tout
$ sudo apt-get install hadoop-hdfs-fuse
Nous allons créer un répertoire hdfs depuis le répertoire utilisateur hduser qui servira de répertoire de montage. Les opérations se feront depuis un utilisateur sudoers.

Code : Sélectionner tout
1
2
$ cd /home/hduser 
$ mkdir hdfs
La dernière étape consiste à réaliser le montage, à proprement parler en considérant que l'utilisateur courant est hduser.

Code : Sélectionner tout
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/
Pour tester, connectez-vous via l'utilisateur hduser et déplacez-vous dans le répertoire /home/hduser/hdfs.

Mis à jour le 3 septembre 2014 Mickael Baron

Code : Sélectionner tout
$ hdfs namenode -format

Mis à jour le 3 septembre 2014 Mickael Baron

Proposer une nouvelle réponse sur la FAQ

Ce n'est pas l'endroit pour poser des questions, allez plutôt sur le forum de la rubrique pour ça


Réponse à la question

Liens sous la question
précédent sommaire suivant
 

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2017 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

 
Contacter le responsable de la rubrique Big Data