hadoop hdfs hadoop distributed file system
Ce didacticiel explique Hadoop HDFS - Système de fichiers distribués Hadoop, composants et architecture de cluster. Vous découvrirez également l'algorithme de sensibilisation du rack:
Comme nous l'avons appris dans le tutoriel précédent, le plus gros problème avec le Big Data est de le stocker dans un système existant. Et même si nous en stockions une partie dans un système existant, le traitement de ces BigData prenait des années.
Les résultats que vous vouliez en quelques minutes ont pris des semaines ou peut-être des mois et à cause de cela, la valeur de ce résultat a été perdue.
=> Regardez la série de formation Simple BigData ici.
Ce que vous apprendrez:
Système de fichiers distribués Hadoop
Pour résoudre ce problème ou pour faire face à ce problème, nous avons maintenant HADOOP. Hadoop a résolu ce problème de Big Data en utilisant Hadoop HDFS.
Hadoop HDFS résolu le problème de stockage du Big Data et Réduire la carte Hadoop a résolu les problèmes liés au traitement d'une partie du Big Data.
Maintenant, nous savons que Hadoop a essentiellement un système de fichiers distribués… MAIS POURQUOI?
jms entretien questions et réponses pour expérimenté
Pourquoi Hadoop est-il un système de fichiers distribué?
Essayons de comprendre ce qu'est un système de fichiers distribués et de comprendre les avantages du système de fichiers distribués.
Système de fichiers distribué
Prenons un exemple de lecture de 1 To de données. Nous avons un serveur qui est un bon serveur haut de gamme qui a 4 canaux d'E / S (entrée de sortie) et chaque canal a une bande passante de 100 Mo / s, en utilisant cette machine, vous pourrez lire ces données de 1 To en 43 Minutes.
Maintenant, si nous introduisons 10 N ° de machines exactement comme celle-ci, que se passera-t-il?
Temps réduit à exactement 4,3 minutes. C'est parce que tout l'effort a été divisé en 10 machines et c'est pourquoi le temps nécessaire pour traiter 1 To de données est réduit à 1/10.esoit 4,3 minutes.
De même, lorsque nous considérons BigData, ces données sont divisées en plusieurs segments de données et nous traitons ces données séparément et c'est pourquoi Hadoop a choisi le système de fichiers distribué sur un système de fichiers centralisé.
Composants de Hadoop
Hadoop HDFS a 2 composants principaux pour résoudre les problèmes avec BigData.
- Le premier composant est le Hadoop HDFS pour stocker le Big Data.
- Le deuxième composant est le Hadoop Map Reduce pour traiter le Big Data.
Maintenant, quand on voit l'architecture de Hadoop (image ci-dessous), il a deux ailes là où se trouve l'aile gauche 'Espace de rangement' et la droite est 'Traitement' . Cela signifie que l'aile gauche est le HDFS, c'est-à-dire le système de fichiers de distribution Hadoop et que l'aile droite est YARN et Map Reduce, c'est-à-dire la partie de traitement.
En utilisant HDFS, Hadoop nous permet de stocker des Big Data et en utilisant YARN & Map Reduce, Hadoop nous permet de traiter les mêmes Big Data que nous stockons dans HDFS.
Comme vous pouvez le voir dans l'image ci-dessus, HDFS a deux démons principaux ou vous pouvez les appeler comme des processus ou des threads qui ne sont rien d'autre que des processus JAVA, c'est-à-dire s'exécutant dans une JVM - NameNode et DataNode.
NameNode est un démon maître qui s'exécute sur Master Machine, c'est-à-dire une machine haut de gamme essentiellement et DataNode est une machine esclave qui fonctionne sur du matériel de base. Il peut y avoir plus de DataNode car les machines esclaves sont plus qu'une machine maître.
Nous avons donc toujours un NameNode et plusieurs DataNode fonctionnant sur des machines esclaves.
De même, nous avons YARN de l'autre côté qui a encore deux démons, l'un est le gestionnaire de ressources qui s'exécute sur la machine maître et le gestionnaire de nœuds qui s'exécute sur la machine esclave tout comme le DataNode. Ainsi, chaque machine esclave a deux démons - l'un est le DataNode et l'autre est Node Manager.
La machine maître a le NameNode en cours d'exécution et Resource Manager en cours d'exécution. NameNode est responsable de la gestion des données sur le système de fichiers distribués Hadoop et le gestionnaire de ressources est responsable de l'exécution des tâches de traitement sur ces données stockées.
NameNode et DataNode
Nous allons approfondir l'architecture HDFS et il est donc important de comprendre ce qu'est un NameNode et un DataNode car ce sont les deux principaux démons qui exécutent réellement le HDFS.
NomNœud
- C'est un maître démon.
- Gérer et maintenir les DataNodes.
- Enregistre les métadonnées.
- Reçoit les rapports de pulsation et de blocage de tous les DataNodes.
DataNode
- C'est un démon esclave.
- Les données réelles sont stockées ici.
- Sert les demandes de lecture et d'écriture des clients.
Concentrez-vous simplement sur le diagramme, comme vous pouvez le voir, il existe un nœud de nom de machine centralisé qui contrôle divers DataNode qui s'y trouvent, c'est-à-dire du matériel de base. Donc Name Node n'est rien d'autre que le Master Daemon qui gère tous les DataNode.
Ces NameNode contiennent toutes les informations sur les données stockées dans le DataNode. DataNode, comme son nom l'indique, stocke les données présentes dans le cluster Hadoop.
NameNode ne dispose que des informations sur les données stockées sur quel DataNode. Donc, ce que nous pouvons dire, c'est que NameNode stocke les métadonnées des données stockées sur les DataNodes.
DataNode effectue également une autre tâche, c'est-à-dire qu'il renvoie régulièrement le battement de cœur au NameNode. Les pulsations indiquent en fait au NameNode que ce DataNode est toujours en vie.
Par exemple, DataNodes renvoie un battement de cœur au NameNode et de cette façon NameNode a l'image que ces DataNodes sont actifs, donc NameNode peut utiliser ces DataNode pour stocker plus de données ou lire les données de ces DataNodes.
Maintenant, nous arrivons au DataNode, DataNode n'est rien d'autre que les démons esclaves qui stockent réellement les données qui sont envoyées au cluster Hadoop. Ces DataNodes sont ceux qui servent réellement la demande de lecture et d'écriture faite par les clients.
Si quelqu'un souhaite lire les données du cluster Hadoop, ces requêtes sont en fait traitées par les DataNodes où résident les données.
Architecture de cluster Hadoop
Dans la rubrique précédente relative à NameNode et DataNode, nous avons utilisé le terme «Hadoop Cluster». Jetons un coup d'œil à ce que c'est exactement?
L'image ci-dessus montre la vue d'ensemble d'une architecture de cluster Hadoop. Hadoop Cluster n'est rien d'autre qu'une topologie maître-esclave, dans laquelle il y a une machine maître comme vous pouvez le voir en haut, à savoir le cluster Hadoop. Dans cette machine maître, il y a un NameNode et le gestionnaire de ressources en cours d'exécution, c'est-à-dire les démons maîtres.
La machine maître est connectée à toutes les machines esclaves à l'aide des commutateurs principaux, c'est parce que ces DataNodes sont en fait stockés dans différents racks, donc comme vous pouvez voir Computer 1, Computer 2, Computer 3 jusqu'à Computer N.Ce n'est rien d'autre que l'esclave Machines ou DataNodes et ils sont tous présents dans un même rack.
«Le rack est en fait un groupe de machines présentes physiquement à un emplacement particulier et connectées les unes aux autres.»
Ainsi, la bande passante réseau entre chaque machine est la plus minimale possible. De même, il y a plus de racks, cependant, ils ne sont pas présents au même endroit, par conséquent, nous pouvons avoir un nombre «n» de racks et nous pouvons également avoir un nombre «n» de DataNodes ou d'ordinateurs ou de machines esclaves dans ces racks.
C'est ainsi que les machines esclaves sont réellement réparties sur le cluster, cependant, en même temps, elles sont connectées les unes aux autres.
Comment les données sont-elles stockées dans HDFS?
Nous entrons maintenant lentement dans les détails du fonctionnement de HDFS. Ici, nous allons explorer l'architecture de HDFS.
Quand nous disons, stocker un fichier dans HDFS, les données sont stockées sous forme de blocs dans HDFS. Le fichier entier n'est pas stocké dans HDFS, c'est parce que, comme vous le savez, Hadoop est un système de fichiers distribué.
Donc, si vous avez une taille de fichier de peut-être 1 Po (Peta Byte), alors ce type de stockage n'est pas présent sur une seule machine car le cluster Hadoop est fabriqué à l'aide du matériel standard. Le matériel d'une seule machine représenterait environ 1 To ou 2 To.
Ainsi, le fichier entier doit être décomposé en blocs de données appelés blocs HDFS.
- Chaque fichier est stocké sur HDFS sous forme de blocs.
- La taille par défaut de chaque bloc est d'environ 128 Mo dans Apache Hadoop 2.x (et 64 Mo dans la version précédente, à savoir Apache Hadoop 1.x).
- Il existe une possibilité d'augmenter ou de réduire la taille de fichier des blocs à l'aide du fichier de configuration, c'est-à-dire hdfssite.xml fourni avec le package Hadoop.
Prenons un exemple pour comprendre ce mécanisme et voir comment ces blocs sont créés.
Considérons un fichier de 248 Mo ici, maintenant si nous cassons ce fichier ou si nous déplaçons ce fichier dans Hadoop Cluster ie 2.x, alors ce fichier sera décomposé en un bloc, c'est-à-dire le bloc A de 128 Mo et un autre bloc B de 120 Mo.
Comme vous pouvez le voir, le premier bloc est de 128 Mo, c'est-à-dire que la toute première dalle y coupe et c'est pourquoi l'autre bloc est de 120 Mo et non de 128 Mo, c'est-à-dire qu'il ne perdra pas d'espace si la taille de fichier restante est plus petite que la taille de bloc par défaut.
Maintenant, nous avons un autre problème devant nous, c'est-à-dire est-il sûr d'avoir une seule copie de chaque bloc?
meilleur VPN pour la Chine
La réponse est NON car il y a un risque que le système tombe en panne et ce n'est rien d'autre que du matériel de base en raison duquel nous pourrions avoir de gros problèmes. Pour surmonter ce problème, Hadoop HDFS a une bonne solution, c'est-à-dire «La réplication du bloc».
Réplication de blocs d'architecture Hadoop
Hadoop crée les répliques de chaque bloc qui est stocké dans le système de fichiers distribué Hadoop et c'est ainsi que Hadoop est un système à tolérance de pannes, c'est-à-dire que même si votre système échoue ou que votre DataNode échoue ou qu'une copie est perdue, vous aurez plusieurs autres copies présent dans les autres DataNodes ou dans les autres serveurs afin que vous puissiez toujours choisir ces copies à partir de là.
Comme le montre le diagramme ci-dessus qui représente la réplication de blocs, il existe cinq blocs différents d'un fichier, à savoir le bloc 1, 2,3,4,5. Vérifions d'abord avec le bloc 1, et vous trouverez des copies du bloc 1 dans le nœud 1, le nœud 2 et le nœud 4.
De même, le bloc 2 a également trois copies, à savoir le nœud 2, le nœud 3 et le nœud 4 et donc la même chose pour les blocs 3, 4 et 5 dans les nœuds respectifs.
Ainsi, à part les répliques créées, chaque bloc a été répliqué trois fois, c'est-à-dire que Hadoop suit un facteur de réplication par défaut de trois, ce qui signifie que tout fichier que vous copiez dans le système de fichiers de distribution Hadoop est répliqué trois fois.
En d'autres termes, si vous copiez 1 Go d'un fichier dans Hadoop Distribution File System, il stocke en fait 3 Go d'un fichier dans HDFS. La bonne partie est que le facteur de réplication par défaut est modifiable en modifiant les fichiers de configuration de Hadoop.
Comment Hadoop décide-t-il où stocker les répliques?
Hadoop suit en fait le concept de Rack Awareness pour décider où stocker quelle réplique d'un bloc.
Vous trouverez ci-dessous le diagramme illustrant l'algorithme de détection de rack.
Il existe trois racks différents, à savoir Rack-1, Rack-2 et Rack-3.
Rack-1 a quatre DataNodes, tout comme Rack-2 et Rack-3, donc au total, l'ensemble du cluster Hadoop comprendra les trois racks et il y aura 12 DataNodes.
Supposons que le bloc A soit copié sur DataNode 1 dans le rack-1, selon le concept de Rack Awareness, la réplique du bloc A ne peut pas être créée dans le même rack, et il doit être créé dans n'importe quel autre rack en dehors du rack-1 comme le fichier principal existe déjà dans Rack-1.
Si nous créons les répliques du bloc A dans le même rack-1 et au cas où l'ensemble du rack-1 échouerait, nous perdrions les données à coup sûr, les répliques doivent donc être stockées dans n'importe quel autre rack mais pas dans le rack-1.
La réplique va donc être créée dans DataNode 6 et 8 de Rack-2. De même, pour le bloc B et le bloc C, les répliques vont être créées dans différents racks, comme indiqué dans le diagramme ci-dessus.
Conclusion
Nous avons appris avec les pointeurs suivants de ce tutoriel-
- Hadoop HDFS résout le problème de stockage de BigData.
- Hadoop Map Reduce résout les problèmes liés au traitement des BigData.
- NameNode est un démon maître et est utilisé pour gérer et maintenir les DataNodes.
- DataNode est un démon esclave et les données réelles sont stockées ici. Il sert à lire et à écrire les requêtes des clients.
- Dans Hadoop Cluster, un rack est en fait un groupe de machines présentes physiquement à un emplacement particulier et connectées les unes aux autres.
- Chaque fichier est stocké sur HDFS sous forme de blocs.
- La taille par défaut de chaque bloc est d'environ 128 Mo dans Apache Hadoop 2.x (64 Mo dans la version précédente, à savoir Apache Hadoop 1.x)
- Il existe une possibilité d'augmenter ou de réduire la taille de fichier des blocs à l'aide du fichier de configuration, c'est-à-dire hdfssite.xml fourni avec le package Hadoop.
Dans le prochain didacticiel sur HDFS, nous en apprendrons davantage sur l'architecture HDFS et les mécanismes de lecture et d'écriture.
=> Visitez ici pour voir la série de formations BigData pour tous.
lecture recommandée
- Qu'est-ce que Hadoop? Tutoriel Apache Hadoop pour les débutants
- Manipulation de fichiers sous Unix: présentation du système de fichiers Unix
- Caractères spéciaux ou métacaractères Unix pour la manipulation de fichiers
- Autorisations d'accès aux fichiers Unix: Unix Chmod, Chown et Chgrp
- Ranorex Test Suite, création de modules de test, fichier UserCode, Xpath et liaison de données
- Objets de fichier VBScript: CopyFile, DeleteFile, OpenTextFile, lecture et écriture de fichier texte
- Opérations de sortie de fichier d'entrée en C ++
- Déploiement Java: création et exécution d'un fichier JAR Java