Avec le développement continu de l'économie mondiale, l'ère du Big Data est arrivée tranquillement, et Hadoop est le fondement de l'environnement du Big Data. Si vous voulez entrer dans l'industrie du Big Data, vous devez d'abord comprendre les connaissances de Hadoop. Au début de 2017, Apache a publié Hadoop 3.0, ce qui signifie également qu'un groupe de personnes optimise constamment Hadoop. Non seulement cela, mais de nombreuses entreprises utilisent les versions commerciales de Hadoop, ce qui confirme également sa valeur commerciale.

Les lecteurs peuvent avoir une compréhension complète de la technologie Hadoop en lisant la série d'articles "Comprendre Hadoop dans un article". Il couvre tous les points de connaissance du site officiel Hadoop et est facile à comprendre. Les lecteurs qui ne sont pas bons en anglais peuvent lire cet article pour comprendre Hadoop.

Le contenu exclusif de ce numéro de la série d'articles "Comprendre Hadoop en un seul article" Selon l'introduction de Hadoop, le cadre de tous les points de connaissance de HDFS, MAPREDUCE et YARN sera présenté en détail. Découpé en quatre numéros, le contenu sera poussé ces derniers jours. Restez à l'écoute pour le contenu de suivi.

Le contenu de ce numéro est d'expliquer HDFS en détail. En raison de la limitation du nombre de mots, cet article est divisé en deux parties, la première et la seconde, respectivement.

1. Avantages et inconvénients de HDFS

1.1 Avantages

1.1.1 Haute tolérance aux pannes

• Peut être constitué de centaines ou de milliers de machines serveurs, chacune stockant une partie des données du système de fichiers ;

• Les données sont automatiquement enregistrées en plusieurs copies ;

• Une fois la copie perdue, il peut détecter rapidement l'échec et récupérer automatiquement.

1.1.2 Adapté au traitement par lots

• l'informatique mobile et non les données ;

• L'emplacement des données est exposé au cadre informatique ;

• Haut débit d'accès aux données ;

• Les applications en cours d'exécution ont un accès en continu à leurs ensembles de données.

1.1.3 Adapté au traitement du Big Data

• Les tailles de fichier typiques vont de gigaoctets à téraoctets ;

• Prend en charge des dizaines de millions de fichiers dans une seule instance ;

• Plus de 10 000 nuds.

1.1.4 Peut être construit sur des machines bon marché

• Améliorez la fiabilité grâce à plusieurs copies ;

• Fournit des mécanismes de tolérance aux pannes et de récupération.

1.1.5 Forte portabilité sur des plates-formes matérielles et logicielles hétérogènes

• Portez facilement d'une plate-forme à une autre.

1.1.6 Modèle de cohérence simple

• L'application nécessite un modèle d'accès qui écrit une fois et lit de nombreux fichiers ;

• Pas besoin de modifier les fichiers qui ont été créés, écrits et fermés, à part les ajouter et les tronquer ;

• Simplifie les problèmes de cohérence des données et permet un accès aux données à haut débit ;

• Hautement configurable, avec des configurations par défaut idéales pour de nombreuses installations. La plupart du temps, vous n'avez besoin d'ajuster la configuration que pour les très grands clusters.

1.2 Inconvénients

1.2.1 Ne convient pas à l'accès aux données à faible latence

• HDFS est davantage conçu pour le traitement par lots que pour une utilisation interactive avec l'utilisateur. L'accent est mis sur un haut débit d'accès aux données, et non sur une faible latence d'accès aux données.

1.2.2 Ne convient pas à l'accès aux petits fichiers

• Occupe beaucoup de mémoire de NameNode ;

• Le temps de recherche dépasse le temps de lecture.

1.2.3 Impossible d'écrire simultanément, le fichier est immédiatement modifié

• Un fichier ne peut avoir qu'un seul écrivain ;

• Seuls l'ajout et la troncation sont pris en charge.

2. Composition de base

2.1 Noeud de nom

2.1.1 Accepter les services de lecture et d'écriture du client

Effectuez des opérations d'espace de noms de système de fichiers telles que l'ouverture, la fermeture et le changement de nom de fichiers et de répertoires.

2.1.2 Gestion des espaces de noms du système de fichiers

Enregistrez toutes les modifications apportées à l'espace de noms du système de fichiers ou à ses attributs.

2.1.3 composition des métadonnées

Les métadonnées sont les informations de métadonnées stockées sur le Namenode, et le nom de fichier qu'il stocke sur le disque est : fsimage. Et il existe un fichier appelé edits pour enregistrer le journal des opérations des métadonnées. En général, les fichiers fsimage et edits enregistrent les informations d'autorisation et l'arborescence du répertoire du système de fichiers dans les métadonnées, qui bloquent le fichier contient, déterminent le mappage des blocs aux DataNodes et sur quels DataNodes les blocs sont stockés (rapporté lorsque le DataNode est démarré) .

NameNode charge ces informations en mémoire et les assemble, ce qui devient une information de métadonnées complète.

2.1.4 Espaces de noms du système de fichiers

HDFS prend en charge l'organisation hiérarchique traditionnelle des fichiers. Les utilisateurs ou les applications peuvent créer des répertoires et stocker des fichiers dans ces répertoires. La hiérarchie de l'espace de noms du système de fichiers est similaire à la plupart des autres systèmes de fichiers existants : les fichiers peuvent être créés et supprimés, déplacés d'un répertoire à un autre ou renommés. HDFS prend en charge les quotas d'utilisateurs et les droits d'accès. Cependant, les liens matériels ou logiciels ne sont pas pris en charge.

Le NameNode maintient l'espace de noms du système de fichiers. Toutes les modifications apportées à l'espace de noms du système de fichiers ou à ses propriétés sont consignées par le NameNode. Les applications peuvent spécifier le nombre de copies de fichiers qui doivent être conservées par HDFS. Le nombre de copies d'un fichier est appelé facteur de réplication pour ce fichier. Ces informations sont stockées par le NameNode.

2.1.5 Persistance des métadonnées du système de fichiers

Les informations de métadonnées du NameNode seront chargées dans la mémoire après le démarrage. Étant donné que les données chargées dans la mémoire sont très peu sécurisées, elles disparaîtront après la mise hors tension. Par conséquent, les informations stockées dans la mémoire doivent être conservées.

L'espace de noms de HDFS est enregistré sur le Namenode. Toutes les opérations qui modifient les métadonnées du système de fichiers sont enregistrées par le Namenode à l'aide d'un journal des transactions appelé Edits. Par exemple, en créant un fichier dans HDFS, Namenode insèrera un enregistrement dans Edits pour le représenter ; de même, la modification du facteur de copie du fichier insèrera également un enregistrement dans Edits. Le Namenode stocke les modifications dans le système de fichiers du système d'exploitation local. L'espace de noms de l'ensemble du système de fichiers, y compris le mappage des blocs de données sur les fichiers, les attributs de fichier, etc., est stocké dans un fichier appelé FsImage, qui est également placé sur le système de fichiers local où se trouve le Namenode.

Namenode enregistre l'ensemble de l'espace de noms du système de fichiers et l'image de la carte des blocs de fichiers en mémoire. Cette structure de métadonnées clés est conçue pour être compacte, donc un Namenode avec 4G de mémoire est suffisant pour prendre en charge un grand nombre de fichiers et de répertoires. Lorsque le Namenode démarre, il lit les Edits et FsImage à partir du disque dur, applique toutes les transactions dans les Edits à la FsImage en mémoire, enregistre cette nouvelle version de la FsImage de la mémoire sur le disque local, puis supprime l'ancienne Edits , car cette ancienne transaction Edits a été appliquée à FsImage. Ce processus s'appelle un point de contrôle.

Datanode stocke les données HDFS sous forme de fichiers dans le système de fichiers local, il ne connaît pas les informations sur les fichiers HDFS. Il stocke chaque bloc de données HDFS dans un fichier séparé sur le système de fichiers local. Datanode ne crée pas tous les fichiers dans le même répertoire, en fait, il utilise des heuristiques pour déterminer le nombre optimal de fichiers par répertoire, et crée des sous-répertoires le cas échéant. La création de tous les fichiers locaux dans le même répertoire n'est pas optimale car le système de fichiers local peut ne pas être en mesure de prendre en charge efficacement un grand nombre de fichiers dans un seul répertoire. Lorsqu'un Datanode démarre, il analyse le système de fichiers local, produit une liste de tous les blocs de données HDFS correspondant à ces fichiers locaux et l'envoie sous forme de rapport au Namenode, qui est le rapport d'état du bloc.

2.2 NoeudNomSecondaire

Ce n'est pas la sauvegarde du NameNode, mais il peut être utilisé comme sauvegarde du NameNode. En cas de panne de courant ou d'endommagement du serveur, le fichier fsimage fusionné dans le SecondNameNode peut être utilisé comme fichier de sauvegarde à restaurer sur le NameNode, mais il est susceptible d'être perdu pendant le processus de fusion. Informations de modification nouvellement générées. Donc pas une sauvegarde complète.

Étant donné que le NameNode fusionne uniquement le fsimage et modifie les fichiers au démarrage, le fichier journal des modifications peut devenir très volumineux avec le temps sur un cluster occupé. Un autre effet secondaire des fichiers d'édition plus volumineux est que le prochain redémarrage du NameNode prend plus de temps. La fonction principale de SecondNameNode est d'aider NameNode à fusionner les modifications et les fichiers fsimage, réduisant ainsi le temps de démarrage de NameNode.

2.2.1 Synchronisation de fusion d'exécution SNN

• L'intervalle de temps fs.checkpoint.period configuré selon le fichier de configuration est par défaut de 1 heure ;

• dfs.namenode.checkpoint.txns, le paramètre par défaut est 1 million, c'est-à-dire que lorsque le nombre de transactions dans Edits atteint 1 million, une fusion sera déclenchée, même si la période de point de contrôle n'est pas atteinte.

2.2.2 Processus de fusion SNN

• Générez d'abord un fichier nommé edits.new pour enregistrer les informations de journal générées pendant le processus de fusion ;

• Lorsqu'un certain timing est déclenché (l'intervalle de temps atteint 1 heure ou le nombre de transactions dans Edits atteint 1 million), le SecondaryNamenode lit le fichier d'édition et le fichier fsimage du NameNode au SecondNamenode ;

• Fusionnez le fichier d'édition et fsimage dans un fichier fsimage.ckpt ;

• Convertissez le fichier fusionné généré fsimage.ckpt en NameNode ;

• Remplacez le fichier fsimage.ckpt par le fichier fsimage sur le NameNode pour remplacer le fichier fsimage d'origine sur le NameNode, et remplacez le fichier edits.new par le fichier d'édition pour remplacer le fichier d'édition d'origine sur le NameNode.

SNN existe toujours dans l'état non haute disponibilité de hadoop2.x et supérieur, mais SNN n'existe pas dans l'état haute disponibilité de hadoop2.x et supérieur, et dans l'état haute disponibilité de hadoop2.x et supérieur, il est dans standby Le NameNode de l'état pour effectuer l'opération de fusion.

2.3 Nuds de données

• Gérez le stockage attaché aux nuds sur lesquels ils s'exécutent et autorisez le stockage des données utilisateur dans des fichiers ;

• En interne, le fichier est divisé en un ou plusieurs blocs (Block), et ces blocs sont stockés dans un ensemble de DataNodes ;

• Responsable du traitement des demandes de lecture et d'écriture des clients du système de fichiers ;

• Effectuer la création et la suppression de blocs ;

• Les informations de bloc seront signalées à NN lorsque le processus DN est lancé ;

• Restez en contact avec le NN en envoyant des battements de cur (une fois toutes les 3 secondes). Si le NN ne reçoit pas de battement de cur du DN pendant 10 minutes, il est considéré que le DN a été perdu et le bloc qu'il contient est copié vers d'autres DN.

2.3.1 Unité de stockage HDFS (bloc)

2.3.1.1 Le fichier est divisé en blocs de données de taille fixe

• La taille de bloc de données par défaut est de 64 Mo (hadoop1.x), 128 Mo (hadoop2.x), 256 Mo (hadoop3.x), configurable ;

• Si la taille du fichier est inférieure à la taille d'un bloc, il est stocké en tant que bloc seul et le bloc de bloc est un concept logique. La taille du fichier correspond à l'espace qu'il occupe.

2.3.1.2 Une méthode de stockage de fichiers

• Il est divisé en différents blocs selon leur taille et stocké sur différents nuds ;

• Par défaut, chaque bloc a 3 copies ;

• La taille de bloc et le nombre de copies sont définis lorsque le fichier est téléchargé côté client. Une fois le fichier téléchargé avec succès, le nombre de copies peut être modifié, mais la taille de bloc ne peut pas être modifiée.

2.3.1.3 Pensée conceptuelle

Le gros fichier est divisé en blocs de 256 Mo, et chaque bloc est stocké de manière aléatoire sur un nud différent, évitant ainsi le problème de distorsion des données, mais dans le processus de développement, si l'algorithme et le programme ne sont pas bien écrits, le même sera Il y a un problème d'asymétrie des données.

2.3.2 Données complexe système

2.3.2.1 Présentation de la réplication de données

HDFS est conçu pour stocker de manière fiable des fichiers très volumineux sur des machines dans un grand cluster. Il stocke chaque fichier sous la forme d'une série de blocs, qui ont tous la même taille sauf le dernier. Pour la tolérance aux pannes, tous les blocs de données du fichier sont répliqués. La taille de bloc et le facteur de copie sont configurables pour chaque fichier. Une application peut spécifier le nombre de copies d'un fichier. Le facteur de copie peut être spécifié lors de la création du fichier ou il peut être modifié ultérieurement. Les fichiers dans HDFS sont tous à écriture unique, et il existe une exigence stricte selon laquelle il ne peut y avoir qu'un seul graveur à la fois.

Le Namenode gère entièrement la réplication des blocs de données et reçoit périodiquement des signaux de pulsation et des rapports d'état de bloc (Blockreport) de chaque Datanode du cluster. La réception d'un signal de pulsation signifie que le Datanode fonctionne correctement. Le rapport d'état de bloc contient une liste de tous les blocs de données sur le Datanode.

Nuds de données HDFS

2.3.2.2 Stratégie de placement de copie de bloc

Le stockage de réplication est la clé de la fiabilité et des performances HDFS. La stratégie de stockage de copie optimisée est une caractéristique importante qui distingue HDFS de la plupart des autres systèmes de fichiers distribués. Cette fonctionnalité nécessite beaucoup de réglage et d'expérience. HDFS utilise une stratégie appelée rack-aware pour améliorer la fiabilité des données, la disponibilité et l'utilisation de la bande passante du réseau. La stratégie de stockage des répliques actuellement mise en uvre n'est que la première étape dans cette direction. L'objectif à court terme de la mise en uvre de cette stratégie est de valider son efficacité dans un environnement de production, d'observer son comportement et de jeter les bases de tests et de recherches pour mettre en uvre des stratégies plus avancées.

Les grandes instances HDFS s'exécutent généralement sur des clusters d'ordinateurs répartis sur plusieurs racks, et la communication entre deux machines sur des racks différents doit passer par un commutateur. Dans la plupart des cas, la bande passante entre deux machines d'un même rack sera supérieure à la bande passante entre deux machines de racks différents.

Grâce à un processus compatible avec le rack, le Namenode peut déterminer l'ID de rack auquel appartient chaque Datanode. Une stratégie simple mais non optimisée consiste à conserver les répliques sur différents racks. Cela peut empêcher efficacement la perte de données lorsque le rack entier tombe en panne et permet une utilisation complète de la bande passante de plusieurs racks lors de la lecture des données. Ce paramètre de stratégie peut répartir uniformément les répliques dans le cluster, ce qui est propice à l'équilibrage de charge en cas de défaillance d'un composant. Cependant, étant donné qu'une opération d'écriture de cette stratégie nécessite de transférer des blocs de données vers plusieurs racks, cela augmente le coût d'écriture.

Dans la plupart des cas, le facteur de réplique est de 3, et la stratégie de stockage HDFS consiste à stocker une réplique sur un nud du rack local, une réplique sur un autre nud du même rack et la dernière réplique sur un rack différent sur le nud. . Cette stratégie réduit les transferts de données entre les racks, ce qui augmente l'efficacité des opérations d'écriture. Les racks ont beaucoup moins d'erreurs que les nuds, donc cette stratégie n'affecte pas la fiabilité et la disponibilité des données. Dans le même temps, étant donné que les blocs de données ne sont placés que sur deux (et non trois) racks différents, cette stratégie réduit la bande passante de transfert réseau globale nécessaire pour lire les données. Dans le cadre de cette stratégie, les répliques ne sont pas réparties uniformément sur les différents racks. Un tiers des répliques se trouvent sur un nud, les deux tiers des répliques se trouvent sur un rack et les autres répliques sont réparties uniformément entre les racks restants. Cette stratégie ne compromet pas la fiabilité des données ni les performances de lecture. Performances d'écriture améliorées.

2.3.2.3 Sélection de copie

Afin de réduire la consommation globale de bande passante et la latence de lecture, HDFS essaiera de laisser le lecteur lire la copie la plus proche. S'il y a une réplique sur le même rack que le lecteur, alors lisez cette réplique. Si un cluster HDFS s'étend sur plusieurs centres de données, les clients liront également le réplica du centre de données local en premier.

2.3.2.4 Mode sans échec

• Lorsque le NameNode démarre, il entre dans un état spécial appelé mode sans échec : il charge d'abord le fichier image (fsimage) en mémoire et effectue diverses opérations dans le journal d'édition (edits) ;

• Une fois que le mappage des métadonnées du système de fichiers est établi avec succès en mémoire, créez un nouveau fichier fsimage (cette opération ne nécessite pas SecondNameNode) et un journal d'édition vide ;

• À ce moment, le namenode fonctionne en mode sans échec, c'est-à-dire que le système de fichiers du namenode est en lecture seule pour le client, et il ne parviendra pas à écrire, supprimer et renommer le répertoire, le contenu du fichier, etc. ;

• A ce stade, le namenode collecte les rapports de chaque datanode. Lorsque le bloc de données atteint le nombre minimum de répliques, il sera considéré comme "sûr". Après qu'un certain pourcentage des blocs de données soient considérés comme sûrs (peut être défini), après une certaine période de temps, le mode sans échec se termine ;

• Lorsqu'il est détecté que le nombre de répliques est insuffisant pour un bloc de données, le bloc sera répliqué jusqu'à ce que le nombre minimum de répliques soit atteint. La position du bloc de données dans le système n'est pas maintenue par le namenode, mais est stockée dans le datanode sous la forme d'une liste de blocs.

2.4 Organisation des données

2.4.1 Blocs de données

HDFS est conçu pour prendre en charge des fichiers volumineux et HDFS convient aux applications qui doivent traiter de grands ensembles de données. Ces applications n'écrivent les données qu'une seule fois, mais les lisent une ou plusieurs fois, et la vitesse de lecture doit pouvoir répondre aux besoins de la lecture en continu. HDFS prend en charge la sémantique "write once read many" pour les fichiers. Une taille de bloc de données typique est de 256 Mo. Par conséquent, les fichiers dans HDFS sont toujours divisés en différents blocs selon 256M, et chaque bloc est stocké dans différents Datanodes autant que possible.

2.4.2 Segmentation

La demande du client pour créer un fichier n'est pas envoyée immédiatement au Namenode. En fait, au début, le client HDFS mettra en cache les données du fichier dans un fichier temporaire local. Les écritures d'application sont redirigées de manière transparente vers ce fichier temporaire. Lorsque la quantité de données accumulées dans ce fichier temporaire dépasse la taille d'un bloc de données, le client contactera le Namenode. Le Namenode insère le nom de fichier dans la hiérarchie du système de fichiers et lui alloue un bloc de données. Renvoyez ensuite l'identifiant du Datanode et le bloc de données cible au client. Ensuite, le client télécharge cette donnée du fichier temporaire local vers le Datanode spécifié. Lorsque le fichier est fermé, les données non téléchargées restant dans le fichier temporaire seront également transférées vers le Datanode spécifié. Le client indique alors à Namenode que le fichier est fermé. À ce moment, le Namenode soumet l'opération de création de fichier au journal pour le stockage. Si le Namenode tombe en panne avant la fermeture du fichier, le fichier sera perdu.

L'approche ci-dessus est le résultat d'un examen attentif de l'application cible exécutée sur HDFS. Ces applications nécessitent des écritures en continu dans les fichiers. Si le cache client n'est pas utilisé, le débit sera fortement affecté en raison de la vitesse et de la congestion du réseau. Cette approche n'est pas sans précédent et les premiers systèmes de fichiers, tels que AFS, utilisaient la mise en cache côté client pour améliorer les performances. Afin d'améliorer l'efficacité du téléchargement des données, les exigences de la norme POSIX ont été assouplies.

2.4.3 Réplication du pipeline

Lorsqu'un client écrit des données dans un fichier HDFS, il écrit initialement dans un fichier temporaire local. En supposant que le facteur de copie du fichier est défini sur 3, lorsque le fichier temporaire local atteint la taille d'un bloc de données, le client obtiendra une liste de Datanodes du Namenode pour stocker des copies. Ensuite, le client commence à transmettre des données au premier Datanode, le premier Datanode reçoit les données en petites parties (4 Ko), écrit chaque partie dans l'entrepôt local et transmet simultanément la partie au deuxième Datanode dans le nud de liste. Il en va de même pour le deuxième Datanode, recevant des données en petites portions, les écrivant dans le référentiel local et les transmettant au troisième Datanode en même temps. Enfin, le troisième Datanode reçoit les données et les stocke localement. Par conséquent, un Datanode peut recevoir des données du nud précédent de manière pipeline et les transmettre au nud suivant en même temps, et les données sont copiées du Datanode précédent vers le suivant de manière pipeline.

3. Processus de lecture et d'écriture

3.1 Processus de lecture HDFS

• Tout d'abord, le client de HDFS passe le DistributedFileSystem ;

• Demandez le NameNode via DistributedFileSystem, envoyez les informations utilisateur et les informations de nom de fichier au NameNode, et revenez au DistributedFileSystem où se trouve le bloc contenu dans le fichier.

• Le client HDFS lit les informations de bloc dans le DataNode en séquence via le FSDataInputStream (il sélectionnera le DataNode avec la charge la plus faible ou le DataNode le plus proche du client pour lire le bloc) ;

• FSDataInputStream lit un par un dans l'ordre jusqu'à ce que tous les blocs soient lus ;

• FSDataInputStream sera fermé lorsque la lecture sera terminée.

3.2 Processus d'écriture HDFS

• Tout d'abord, le client de HDFS passe le Distributed FileSystem (un objet dans l'API de HDFS) ;

• Envoyer la demande du client au NameNode via le Distributed FileSystem (le NameNode accepte principalement les demandes des clients) et l'envoyer au NameNode avec des informations telles que l'emplacement du fichier à enregistrer, le nom du fichier et le nom d'utilisateur de l'opération ;

• Le NameNode renvoie un FSDataOutputStream au client et renvoie également dans quel DataNode le fichier doit être écrit (avec une charge inférieure) ;

• L'opération d'écriture est effectuée via FSDataOutputStream, et le fichier est divisé avant l'écriture, et le fichier est divisé en plusieurs blocs. La première opération d'écriture est écrite sur le DataNode avec une faible charge, et le bloc est copié vers d'autres DataNodes ;

• Lorsque toutes les copies de blocs sont copiées, elles seront renvoyées à FSDataOutputStream ;

• Lorsque toutes les copies de bloc sont copiées, le flux FSDataOutputStream peut être fermé ;

• Mettez à jour les informations de données source dans NameNode via Distributed FileSystem.

4.Architecture

4.1 NameNode et DataNode

HDFS adopte l'architecture maître/travailleur. Un cluster HDFS est composé d'un Namenode et d'un certain nombre de Datanodes. Namenode est un serveur central responsable de la gestion de l'espace de noms du système de fichiers et de l'accès client aux fichiers. Le Datanode dans le cluster est généralement un nud, responsable de la gestion du stockage sur le nud où il se trouve. HDFS expose l'espace de noms du système de fichiers sur lequel les utilisateurs peuvent stocker des données sous forme de fichiers. En interne, un fichier est en fait divisé en un ou plusieurs blocs de données, qui sont stockés sur un ensemble de Datanodes. Namenode effectue des opérations d'espace de noms de système de fichiers, telles que l'ouverture, la fermeture et le changement de nom de fichiers ou de répertoires. Il est également chargé de déterminer le mappage des blocs de données sur des nuds Datanode spécifiques. Les nuds de données sont responsables de la gestion des demandes de lecture et d'écriture des clients du système de fichiers. La création, la suppression et la réplication des blocs de données sont effectuées sous la planification unifiée de Namenode.

Architecture HDFS

Namenode et Datanode sont conçus pour fonctionner sur des machines courantes. Ces machines exécutent généralement le système d'exploitation (OS) GNU/Linux. HDFS est développé en Java, de sorte que toute machine compatible Java peut déployer Namenode ou Datanode. Grâce au langage Java hautement portable, HDFS peut être déployé sur différents types de machines. Un scénario de déploiement typique est qu'une seule instance de Namenode s'exécute sur une machine, tandis que les autres machines du cluster exécutent chacune une instance de Datanode. Cette architecture peut également exécuter plusieurs Datanodes sur une seule machine, mais cela est moins courant.

La structure d'un seul Namenode dans le cluster simplifie grandement l'architecture du système. Namenode est le gestionnaire de toutes les métadonnées HDFS, les données utilisateur ne transitent jamais par Namenode.

4.1.1 Protocole de communication

Tous les protocoles de communication HDFS reposent sur le protocole TCP/IP. Le client se connecte au Namenode via un port TCP configurable et interagit avec le Namenode via le protocole ClientProtocol. Le Datanode utilise le protocole DatanodeProtocol pour interagir avec le Namenode. Un modèle d'appel de procédure distante (RPC) est abstrait pour encapsuler les protocoles ClientProtocol et Datanodeprotocol. De par sa conception, le Namenode n'initie pas de RPC, mais répond aux demandes RPC des clients ou des Datanodes.

4.2 Infrastructures

Le système de fichiers distribués Hadoop (HDFS) est conçu pour être un système de fichiers distribué qui s'exécute sur du matériel à usage général. Il a beaucoup en commun avec les systèmes de fichiers distribués existants. Mais en même temps, la différence entre celui-ci et les autres systèmes de fichiers distribués est également évidente. HDFS est un système hautement tolérant aux pannes adapté au déploiement sur des machines peu coûteuses. HDFS peut fournir un accès aux données à haut débit, ce qui convient parfaitement aux applications sur des ensembles de données à grande échelle. HDFS assouplit certaines contraintes POSIX pour atteindre l'objectif de diffusion en continu des données du système de fichiers. HDFS a été initialement développé comme infrastructure pour le projet de moteur de recherche Apache Nutch. HDFS fait partie du projet Apache Hadoop Core.

• La requête du client tombe entièrement sur le NameNode ;

• Les informations de métadonnées existent dans NameNode ;

• Il n'y a qu'un seul NameNode à l'état Actif dans le cluster Hadoop ;

• SecondaryNameNode n'est pas un nud de sauvegarde ou un nud esclave de NameNode (pour être précis, il ne peut sauvegarder qu'une partie de NameNode, pas tout) ;

• Il existe un mécanisme de pulsation entre le NameNode et le DataNode, afin que le NameNode puisse connaître le fonctionnement et la charge du DataNode.

4.2.1 Robustesse

L'objectif principal de HDFS est d'assurer la fiabilité du stockage des données même en cas d'erreurs. Les trois conditions d'erreur courantes sont : l'erreur Namenode, l'erreur Datanode et la partition réseau.

4.2.1.1 Erreur de données de disque, détection de pulsation et re-réplication

Chaque Datanode envoie périodiquement un signal de pulsation au Namenode. Des raisons de réseau peuvent faire en sorte que certains Datanodes perdent le contact avec le Namenode. Le Namenode détecte cette situation par l'absence de signaux heartbeat, et marque ces Datanodes qui n'envoient plus de signaux heartbeat comme down, et ne leur enverra pas de nouvelles requêtes IO. Toutes les données stockées sur un Datanode en panne ne seront plus valides. L'indisponibilité du Datanode peut faire en sorte que le facteur de réplication de certains blocs de données soit inférieur à la valeur spécifiée. Le Namenode détecte en permanence ces blocs de données qui doivent être répliqués et démarre l'opération de réplication une fois trouvé. Une re-réplication peut être nécessaire dans les situations suivantes : un Datanode tombe en panne, une réplique est corrompue, une erreur de disque dur sur le Datanode ou le facteur de réplication d'un fichier augmente.

4.2.1.1.1 Disques échangeables à chaud DataNode

Datanode prend en charge les disques remplaçables à chaud. Les volumes de données HDFS peuvent être ajoutés ou remplacés sans arrêter le DataNode. Voici une brève description d'un pilote hot-plug typique :

• Si de nouveaux répertoires de stockage existent, ils doivent être formatés et montés de manière appropriée ;

• Mettez à jour le répertoire du volume de données vers la configuration DataNode dfs.datanode.data.dir ;

• Faites en sorte que le répertoire que nous avons configuré prenne effet en exécutant dfsadmin -reconfig datanode HOST:PORT start, et vous pouvez utiliser dfsadmin -reconfig datanode HOST:PORT status pour interroger l'état d'exécution de la tâche de reconfiguration ;

• Une fois la tâche de reconfiguration terminée, nous pouvons démonter en toute sécurité, supprimer le répertoire du volume de données et retirer physiquement le disque.

4.2.1.2 Équilibrage de charge

L'architecture de HDFS prend en charge les stratégies d'équilibrage des données. Si l'espace libre sur un Datanode est inférieur à un certain point critique, le système déplacera automatiquement les données de ce Datanode vers d'autres Datanodes inactifs selon la stratégie d'équilibrage. En cas de forte demande soudaine pour un fichier particulier, ce schéma peut créer dynamiquement des répliques supplémentaires et rééquilibrer d'autres données dans le cluster.

4.2.1.2.1 Équilibreur

Les données de HDFS peuvent ne pas être réparties de manière très homogène dans chaque DataNode. Une raison courante est que de nouveaux DataNodes sont souvent ajoutés à un cluster existant. Lors de l'ajout d'un bloc de données (les données d'un fichier sont stockées dans une série de blocs), le NameNode prendra en compte de nombreux facteurs avant de sélectionner le DataNode pour recevoir le bloc de données. Certaines de ces considérations sont :

• Placez une copie du bloc de données sur le nud qui écrit le bloc de données ;

• Essayez de répartir différentes copies de blocs de données sur différents racks, afin que le cluster puisse survivre à la perte complète d'un rack ;

• Une réplique est généralement placée sur un nud dans le même rack que le nud écrivant le fichier, ce qui réduit les E/S réseau sur les racks ;

• Essayez de répartir uniformément les données HDFS entre les DataNodes du cluster.

4.2.1.2.2 Équilibreur de disque

Diskbalancer est un outil de ligne de commande qui distribue uniformément les données sur tous les disques d'un nud de données. Cet outil diffère de l'équilibreur en ce qu'il est responsable de l'équilibrage des données à l'échelle du cluster. Les données peuvent être réparties de manière inégale sur les disques d'un nud pour plusieurs raisons. Cela peut se produire en raison d'écritures et de suppressions intensives ou en raison du remplacement du disque. L'outil opère sur un codage de données donné et déplace les blocs d'un disque à l'autre.

4.2.1.2.2.1 Architecture

L'équilibreur de disque fonctionne en créant un plan, puis en exécutant le plan sur les nuds de données. Un plan est un ensemble d'instructions décrivant le déplacement de données entre deux disques. Un plan se compose de plusieurs étapes. Une étape de déplacement a un disque source, un disque de destination et le nombre d'octets à déplacer. Les plans peuvent être exécutés sur des nuds de données opérationnels.

Au total 3 étapes sont incluses, Discover (découverte) à Plan (planning), puis de Plan (planning) à Execute (exécution) :

4.2.1.2.2.1.1 Découvrir

Ce que fait la phase de découverte est en fait de calculer l'utilisation du disque dans chaque nud, puis d'obtenir une liste des disques qui ont besoin d'équilibrer les données. Ici, le concept de densité d'utilisation du disque Volume Data Density sera utilisé comme critère d'évaluation, et cette norme valeur sera Prendre le taux d'utilisation total du nud comme valeur de comparaison. Par exemple, si le taux d'utilisation total d'un nud est de 75 %, soit 0,75, et que le taux d'utilisation du disque A est de 0,5 (50 %), alors la valeur de densité de volumeDataDensity du disque A est égale à 0,75-0,5 = 0,25. De même, si elle dépasse, la valeur de densité sera négative. Nous pouvons donc utiliser la valeur absolue de volumeDataDensity de chaque disque du nud pour juger de l'équilibre de données entre les disques dans ce nud, si la somme des valeurs absolues totales Plus la valeur est élevée, plus les données sont déséquilibrées, ce qui est similaire au concept de variance. Les objets de connecteur suivants seront utilisés dans la phase de découverte :

• DBNameNodeConnectorDBNameNodeConnector

• Connecteur Json

• NullConnector

Le premier objet appellera l'objet NameNodeConnector sous le package Balancer pour lire le nud du cluster et les données du disque.

4.2.1.2.2.1.2 Régime

Après avoir obtenu les données de résultat du rapport de l'étape précédente, le plan d'exécution sera généré. Le plan n'est pas la plus petite unité d'exécution et son intérieur est composé de différentes étapes. Les disques source et cible sont spécifiés dans l'étape. L'objet disque ici C'est une couche d'objets enveloppés : DiskBalancerVolume, pas le FsVolume d'origine. Au fait, voici la transformation de concepts tels que les nuds de disque dans DiskBalancer :

• DiskBalancerCluster.Grâce à cet objet, les informations sur les nuds du cluster peuvent être lues et les informations sur les nuds sont présentées ici sous la forme de DiskBalancerDataNode ;

• DiskBalancerDataNode. Cet objet représente un DataNode encapsulé ;

• Objets disque DiskBalancerVolume et DiskBalancerVolumeSet.DataNode et collections d'objets disque. Le type de répertoire de stockage sur disque dans DiskBalancerVolumeSet doit être le même StorageType.

4.2.1.2.2.1.3 Exécuter

La dernière partie est la phase d'exécution. Une fois tous les plans de plan générés, il viendra à la phase d'exécution. Ces plans seront soumis à leurs DataNodes respectifs, puis exécutés dans la classe DiskBalancer. Il existe des objets de classe spéciaux dans le DiskBalancer classe pour les disques. Le nom de cette classe est appelé DiskBalancerMover. Dans le processus d'équilibrage des données entre les disques, le disque à forte utilisation déplacera les blocs de données vers le disque à utilisation relativement faible. Lorsqu'une certaine relation de seuil est atteinte, DiskBalancer va progressivement Pendant la phase d'exécution de DiskBalancer, les points suivants doivent être notés :

• Limite de bande passante DiskBalancer peut également prendre en charge la limite de bande passante, la valeur par défaut est 10M, qui est contrôlée en configurant dfs.disk.balancer.max.disk.throughputInMBperSec;

• La limite du nombre d'échecs. Il y aura un contrôle du nombre d'échecs dans DiskBalancer. Lors de la copie du bloc de données de bloc, une exception IOException se produit et le décompte cumulé du nombre d'échecs sera effectué. Si la tolérance maximale est dépassée, DiskBalancer se fermera également ;

• Contrôle du seuil d'équilibrage des données. DiskBalancer peut fournir un seuil d'équilibrage des données entre les disques comme critère pour continuer à équilibrer les données. L'élément de configuration est dfs.disk.balancer.block.tolerance.percent.

4.2.1.3 Intégrité des données

Les blocs de données obtenus à partir d'un Datanode peuvent être corrompus, et la corruption peut être causée par des erreurs dans le périphérique de stockage du Datanode, des erreurs de réseau ou des bogues logiciels. Le logiciel client HDFS implémente la vérification de la somme de contrôle du contenu des fichiers HDFS. Lorsque le client crée un nouveau fichier HDFS, il calcule la somme de contrôle de chaque bloc de données du fichier et enregistre la somme de contrôle dans un fichier caché séparé dans le même espace de noms HDFS. Lorsque le client obtient le contenu du fichier, il vérifie si les données obtenues à partir du Datanode correspondent à la somme de contrôle dans le fichier de somme de contrôle correspondant. Si cela ne correspond pas, le client peut choisir d'obtenir une copie du bloc de données à partir d'autres Datanodes.

4.2.1.3.1 Mécanisme de corbeille

4.2.1.3.1.1 Suppression et récupération de fichiers

Si la fonction Corbeille est activée, les fichiers supprimés par FS Shell ne sont pas immédiatement supprimés de HDFS. Au lieu de cela, déplacez-le dans le répertoire de recyclage (chaque utilisateur dans /user/ < Nom d'utilisateur > /.Trash a son propre répertoire de recyclage). Les fichiers peuvent être rapidement récupérés tant qu'ils restent dans la corbeille.

Déplacez les fichiers récemment supprimés vers le répertoire de recyclage actuel (/user/ < Nom d'utilisateur > /.Trash/Current), et à intervalles configurables, HDFS crée une paire de /user/ < Nom d'utilisateur > /.Poubelle/ < Date > Un point de contrôle sous le répertoire et supprimer les anciens points de contrôle après expiration.

Une fois qu'un fichier a expiré dans la corbeille, le NameNode supprimera le fichier de l'espace de noms HDFS. La suppression d'un fichier entraîne la libération des blocs associés à ce fichier. Il est à noter qu'il existe un délai important entre le moment où le fichier est supprimé par l'utilisateur et le moment où l'espace correspondant est libéré.

4.2.1.3.1.2 Réduire les répliques

Lorsque le facteur de réplique d'un fichier diminue, le NameNode choisit les répliques redondantes qui peuvent être supprimées. Le prochain heartbeat transmet ces informations au DataNode. Le DataNode supprime alors le bloc correspondant et libère l'espace correspondant. De plus, il existe un délai entre le moment où le facteur de réplication est défini et le moment où le nouvel espace apparaît dans le cluster.

4.2.1.4 Erreurs de disque de métadonnées

FsImage et Edits sont les structures de données de base de HDFS. Si ces fichiers sont corrompus, l'intégralité de l'instance HDFS échouera. Ainsi, le Namenode peut être configuré pour prendre en charge le maintien de plusieurs copies de FsImages et Edits. Toute modification apportée à FsImage ou aux modifications sera synchronisée avec leurs copies. Cette opération de synchronisation multi-réplica peut réduire le nombre de transactions d'espace de noms par seconde traitées par le Namenode. Cependant, ce coût est acceptable car même si les applications HDFS sont gourmandes en données, la quantité d'informations de métadonnées pour celles-ci n'est pas très importante. Lorsque le Namenode redémarre, il récupère le FsImage complet le plus récent et les modifications à utiliser.

4.2.1.4.1 Nud de point de contrôle

Le NameNode utilise deux fichiers pour stocker les informations d'espace de noms : fsimage, qui est l'information d'espace de noms du dernier point de contrôle effectué : edits, qui est le fichier journal des modifications d'espace de noms après l'exécution du point de contrôle. Lorsque le NameNode démarre, le fsimage et les modifications sont fusionnées pour fournir des métadonnées de système de fichiers à jour, et le NameNode écrit le nouvel état HDFS dans le fsimage et démarre un nouveau journal des modifications.

Le nud Checkpoint crée périodiquement des points de contrôle de l'espace de noms. Il télécharge le fsimage et les modifications à partir du NameNode, les fusionne localement et les renvoie au NameNode actif. Les nuds de point de contrôle ne se trouvent généralement pas sur la même machine que NameNode car ils ont les mêmes besoins en mémoire. Le nud Checkpoint est démarré par bin/hdfs namenode checkpoint dans le fichier de configuration.

L'emplacement du nud de point de contrôle (ou de sauvegarde) et de l'interface Web qui l'accompagne est spécifié par les paramètres dfs.namenode.backup.address et dfs.namenode.backup.http-address.

L'exécution du processus Checkpoint est contrôlée par deux paramètres de configuration :

• dfs.namenode.checkpoint.period, l'intervalle de temps maximal entre deux points de contrôle consécutifs, la valeur par défaut est de 1 heure ;

• dfs.namenode.checkpoint.txns, le nombre maximum de transactions qui n'effectuent pas de points de contrôle, le paramètre par défaut est de 1 million, c'est-à-dire que lorsque le nombre de transactions dans Edits atteint 1 million, une fusion sera déclenchée, même si le point de contrôle la période n'est pas atteinte ;

Le dernier point de contrôle enregistré sur le nud Checkpoint a la même structure de répertoires que sur le NameNode, de sorte que le NameNode peut toujours lire l'image du fichier du point de contrôle exécuté sur celui-ci si nécessaire. Plusieurs nuds Checkpoint peuvent être spécifiés dans le fichier de configuration du cluster.

4.2.1.4.2 Nud de sauvegarde

Le nud Backup fournit la même fonction de point de contrôle que le nud Checkpoint, sauf qu'il conserve également une copie du dernier espace de noms en mémoire, qui est synchronisé avec le NameNode. En plus de recevoir les modifications envoyées par le NameNode et de les enregistrer sur le disque, Backup utilise également les modifications dans sa propre mémoire, créant ainsi une sauvegarde de l'espace de noms.

Étant donné que le nud de sauvegarde conserve l'état du dernier espace de noms en mémoire, il n'a pas besoin de télécharger le fsimage et de modifier les fichiers du NameNode pour créer un point de contrôle, ce qui est une étape nécessaire pour un nud Checkpoint ou un NameNode de secours. Le processus de point de contrôle du nud de sauvegarde est plus efficace car il n'a besoin que d'enregistrer les informations d'espace de noms dans un fichier fsimage local et de réinitialiser les modifications.

Puisqu'une copie de l'espace de noms est conservée dans la mémoire du nud de sauvegarde, ses besoins en mémoire sont les mêmes que ceux du NameNode. NameNode ne prend en charge qu'un seul nud de sauvegarde à la fois. Les nuds Checkpont ne peuvent pas être enregistrés si la sauvegarde est en cours d'utilisation.

La configuration du nud de sauvegarde est la même que celle du nud Checkpoint, et il est démarré avec bin/hdfs namenode backup. L'emplacement du nud de sauvegarde (ou de vérification) et son interface Web sont spécifiés par les paramètres de configuration dfs.namenode.backup.address et dfs.namenode.backup.http-address.

Avec le nud de sauvegarde, le NameNode peut choisir de ne pas le stocker, laissant la responsabilité de maintenir l'état de l'espace de noms au nud de sauvegarde. À cette fin, dans la configuration du NameNode, utilisez l'option -importCheckpoint pour démarrer le NameNode, et ne définissez pas l'option d'emplacement de stockage dfs.namenode.edits.dir pour les modifications.

4.2.1.4.3 Importer des points de contrôle

Si tous les autres fichiers image et modifications sont perdus, le dernier point de contrôle peut être importé dans le NameNode. Pour ce faire, les étapes suivantes sont nécessaires :

• Créez un répertoire vide et configurez-le comme répertoire dans l'élément dfs.namenode.name.dir ;

• Définissez dfs.namenode.checkpoint.dir comme répertoire de point de contrôle ;

• Démarrez le NameNode avec l'option -importCheckpoint.

Le NameNode téléchargera le point de contrôle à partir du répertoire défini par dfs.namenode.checkpoint.dir et l'enregistrera dans le répertoire spécifié par dfs.namenode.name.dir. Si un fichier image existe dans dfs.namenode.name.dir, le NameNode ne démarrera pas et le NameNode vérifiera si le fichier image dans dfs.namenode.checkpoint.dir a des problèmes, mais dans tous les cas, le fichier ne sera pas être modifié.

4.2.1.4.4 Mode de récupération

En règle générale, vous configurez plusieurs emplacements de stockage de métadonnées et, lorsqu'un emplacement de stockage tombe en panne, vous pouvez lire les métadonnées à partir d'autres emplacements. Mais que se passe-t-il si le seul emplacement de stockage tombe en panne ? Dans ce cas, il existe un mode de démarrage spécial de NameNode, appelé mode de récupération, qui vous permet de récupérer la plupart des données. Vous pouvez lancer le mode de récupération comme ceci : namenode --recover. En mode de récupération, NameNode interagit avec vous sur la ligne de commande, vous montrant les actions possibles que vous pouvez entreprendre pour récupérer vos données. Si vous ne souhaitez pas utiliser le mode interactif, vous pouvez ajouter l'option -force, cette option forcera la première sélection à restaurer, généralement, c'est le choix le plus raisonnable. Étant donné que le mode de récupération peut entraîner une perte de données, vous devez sauvegarder le fichier journal des modifications et fsimage avant de l'utiliser.

4.2.1.4.5 Affichage du fichier de modifications hors ligne

La vue de fichier des modifications hors ligne est un outil d'analyse des fichiers journaux des modifications. Les processeurs actuels sont principalement utilisés pour la conversion entre différents formats, y compris XML, qui est lisible et plus facile à éditer que les formats binaires natifs. L'outil peut analyser le format de fichier journal des modifications (en gros Hadoop 0.19) et versions ultérieures. L'outil fonctionne uniquement sur les fichiers, il ne nécessite pas de cluster Hadoop en cours d'exécution.

Formats d'entrée pris en charge :

• binaire: Le format binaire natif utilisé en interne par Hadoop ;

• xml : Format XML, généré par le processeur xml, utilisé si le nom de fichier a une extension .xml (insensible à la casse).

La vue du fichier des modifications hors ligne fournit plusieurs processeurs de sortie (sauf indication contraire, la sortie des processeurs peut être reconvertie dans le fichier journal des modifications d'origine) :

• binaire: Le format binaire natif utilisé en interne par Hadoop ;

• xml : Format XML ;

• Statistiques: Imprime les statistiques, ne peut pas être reconvertie en fichier journal des modifications.

4.2.1.4.6 Affichage du fichier image hors ligne

Offline Image File View est un outil pour vider le contenu des fichiers hdfs fsimage dans un format lisible et fournit une API WebHDFS en lecture seule pour permettre l'analyse et l'inspection hors ligne des espaces de noms des clusters Hadoop. L'outil est capable de traiter des fichiers image très volumineux relativement rapidement. Cet outil gère les formats de mise en page inclus dans les versions 2.4 et ultérieures de Hadoop. Si vous souhaitez traiter des formats de mise en page plus anciens, vous pouvez utiliser la vue de fichier image hors ligne de la commande oiv_legacy. Si l'outil ne peut pas traiter le fichier fsimage, il se ferme complètement. De plus, les vues de fichiers image hors ligne ne nécessitent pas de cluster Hadoop en cours d'exécution. Cela fonctionne complètement hors ligne.

La vue de fichier image hors ligne fournit plusieurs processeurs de sortie :

• Web est le processeur de sortie par défaut. Il démarre un serveur HTTP qui expose une API WebHDFS en lecture seule. Les utilisateurs peuvent afficher les espaces de noms de manière interactive à l'aide de l'API REST HTTP ;

• XML crée un document XML de la fsimage et contient toutes les informations de la fsimage. La sortie de ce processeur peut être automatiquement traitée et analysée par des outils XML ;

• FileDistribution est un outil d'analyse de la taille des fichiers dans l'espace de noms Image. Pour exécuter l'outil, la plage d'entiers doit être définie en spécifiant maxSize et un pas. La plage d'entiers est divisée en segments de la taille de pas spécifiée : , et le processeur compte le nombre de fichiers du système qui appartiennent à chaque segment (s , s ). Notez que les fichiers plus grands que maxSize tombent toujours dans le dernier segment. Par défaut, les fichiers de sortie sont formatés sous la forme d'une liste de deux éléments séparés par des tabulations : Size et NumFiles. Où Size représente le début du segment, numFiles est le nombre de fichiers qui forment l'Image, et la taille tombe dans le segment. En spécifiant l'option -format, le fichier de sortie sera formaté de manière lisible ;

• Délimité : génère un fichier texte contenant tous les éléments communs aux inodes et aux inodes sous les inodes, séparés par des délimiteurs. Le délimiteur par défaut est \t, mais il peut être modifié par le paramètre -delimiter ;

• ReverseXML : à l'opposé de la fonction de processeur XML, il reconstruit fsimage à partir d'un fichier XML. Ce processeur peut facilement créer des fsimages pour les tests.

4.2.1.5 Instantané

Les instantanés HDFS sont des copies ponctuelles en lecture seule d'un système de fichiers. Les instantanés permettent à HDFS de récupérer un point correct connu dans le passé en cas de corruption des données. Des instantanés peuvent être pris d'une sous-arborescence d'un système de fichiers ou de l'ensemble du système de fichiers. Certains cas d'utilisation courants des instantanés sont la sauvegarde des données, la protection contre les erreurs de l'utilisateur et la reprise après sinistre.

La mise en uvre des instantanés HDFS est efficace :

• La création d'instantanés est instantanée : le coût est de O(1)*,* hors temps de recherche d'inode ;

• La mémoire supplémentaire est utilisée uniquement lorsque des modifications sont apportées par rapport à l'instantané : l'utilisation de la mémoire est O(M), où M est le nombre de fichiers/répertoires modifiés ;

• Ne copiez pas les blocs dans le datanode : le fichier d'instantané enregistre la liste des blocs et la taille du fichier. pas de réplication de données ;

• Les instantanés n'affectent pas négativement les opérations HDFS régulières : les modifications sont enregistrées dans l'ordre chronologique inverse afin que les données actuelles soient directement accessibles. Les données d'instantané sont calculées en soustrayant les modifications des données actuelles.

4.2.1.5.1 Répertoire de la table d'instantanés

Une fois qu'un répertoire est défini pour être instantané, n'importe quel répertoire peut être instantané. Le répertoire snaphottable peut contenir 65536 instantanés synchronisés. Il n'y a pas de limite au nombre de répertoires de snapshottable. Les administrateurs peuvent rendre n'importe quel répertoire instantanétable. S'il existe des instantanés dans le répertoire d'instantanés, le répertoire ne peut pas être supprimé ou renommé tant que tous les instantanés n'ont pas été supprimés.

Les répertoires snaphottables imbriqués ne sont actuellement pas autorisés. En d'autres termes, si l'ancêtre ou le descendant d'un répertoire est un répertoire snapttable, il ne peut pas être défini comme snapttable.

4.2.2 Fonctions auxiliaires

4.2.2.1 Interface du navigateur

Une installation HDFS typique configure un serveur Web pour exposer l'espace de noms HDFS via un port TCP configurable. Cela permet aux utilisateurs de naviguer dans l'espace de noms HDFS et d'afficher le contenu de leurs fichiers à l'aide d'un navigateur Web.

Le NameNode et le DataNode exécutent chacun un serveur Web interne pour afficher des informations de base sur l'état actuel du cluster. Si vous utilisez la configuration par défaut, la page d'accueil de NameNode se trouve à l'adresse (hadoop3.X). Elle répertorie les DataNodes dans le cluster et les statistiques de base du cluster L'interface web peut également être utilisée pour parcourir le système de fichiers (utilisez le lien "Parcourir le système de fichiers" sur la page d'accueil de NameNode).

4.2.2.2 Plugins

Il existe un moyen d'utiliser un plug-in pour accéder à ses données internes.Copiez le package hadoop-eclipse-plugin-version.jar dans le répertoire des plugins dans eclipse et configurez-le en conséquence, vous pouvez directement utiliser eclipse pour accéder aux données HDFS. Il fonctionne de la même manière que les fichiers d'exploitation dans l'environnement Windows.

4.2.2.3 Programmation JAVA

HDFS fournit une API Java FileSystem, qui prend en charge l'accès aux données HDFS en écrivant du code Java.

4.2.3 Évolutivité

Aujourd'hui, Hadoop s'exécute sur des milliers de clusters de nuds. Le cluster HDFS n'a qu'un seul nud NameNode. Actuellement, la quantité de mémoire disponible sur le NameNode est une limite de mise à l'échelle majeure. Dans les très grands clusters, l'augmentation de la taille moyenne des fichiers de stockage HDFS peut augmenter la taille du cluster sans augmenter la mémoire du NameNode. La configuration par défaut peut ne pas convenir aux très grands clusters.

4.2.4 Autorisations et sécurité des fichiers

Les autorisations de fichiers ici sont similaires à celles d'autres plates-formes courantes telles que Linux. L'autorisation R:read w:write x:execute x est ignorée pour les fichiers et indique s'il faut autoriser l'accès à son contenu pour les dossiers. Si zhangsan utilise la commande hadoop pour créer un fichier dans le système Linux, le propriétaire du fichier dans HDFS est zhangsan.

Actuellement, la sécurité ne se limite pas à de simples autorisations de fichiers. HDFS prend également en charge les protocoles d'authentification réseau (tels que Kerberos) pour authentifier l'identité de l'utilisateur et chiffrer les données à transmettre.

4.2.4.1 Directives d'autorisation HDFS

Le système de fichiers distribués Hadoop (HDFS) implémente un modèle d'autorisation pour le partage de fichiers et de répertoires de la plupart des modèles POSIX. Chaque fichier et répertoire est associé à un propriétaire et à un groupe. Un fichier ou un répertoire dispose d'autorisations distinctes pour l'utilisateur qui en est le propriétaire, pour les autres utilisateurs qui sont membres du groupe et pour tous les autres utilisateurs. Pour les fichiers, l'autorisation r est requise pour lire le fichier, et l'autorisation w est requise pour écrire ou ajouter au fichier. Pour les répertoires, l'autorisation r est requise pour répertorier le contenu du répertoire, l'autorisation w est requise pour créer ou supprimer des fichiers ou des répertoires, et l'autorisation x est requise pour accéder aux sous-répertoires du répertoire.

Contrairement au modèle POSIX, il n'y a pas de bit setuid ou setgid pour les fichiers, car il n'y a pas de concept d'exécutables. Pour les répertoires, il n'y a pas de répertoires setuid ou setgid bits par simplification. Empêcher toute personne autre que le superutilisateur, le propriétaire du répertoire ou le propriétaire du fichier de supprimer ou de déplacer des fichiers dans un répertoire. En général, les permissions d'un fichier ou d'un répertoire sont son mode. En règle générale, les conventions Unix pour représenter et afficher les modes seront utilisées, y compris l'utilisation de nombres octaux. Lorsqu'un fichier ou un répertoire est créé, son propriétaire est l'ID utilisateur du processus client et son groupe est le groupe du répertoire parent (règle BSD).

HDFS fournit également une prise en charge facultative des ACL POSIX (listes de contrôle d'accès) pour augmenter les autorisations de fichiers avec des règles précises pour des utilisateurs nommés spécifiques ou des groupes nommés. Chaque processus client accédant à HDFS possède une identité en deux parties composée d'un nom d'utilisateur et d'une liste de groupes. Chaque fois que HDFS doit effectuer une vérification des autorisations sur un fichier ou un répertoire foo auquel accède un processus client :

• Si le nom d'utilisateur correspond au propriétaire de foo, testez les autorisations du propriétaire ;

• Sinon, si le groupe de foo correspond à un membre de la liste des groupes, testez les autorisations du groupe ;

• Sinon, les autres autorisations de foo seront testées.

Si la vérification des autorisations échoue, l'opération client échoue.

4.3 Haute disponibilité HDFS (QJM)

Avant Hadoop 2.0.0, le NameNode était un point de défaillance unique (SPOF) dans un cluster HDFS. Chaque cluster a un NameNode, et si cette machine ou ce processus est indisponible, le cluster dans son ensemble sera indisponible jusqu'à ce que le NameNode soit redémarré ou démarré sur une machine distincte.

Cela affecte la disponibilité globale du cluster HDFS de deux manières principales :

• En cas d'événement imprévu tel qu'une panne d'ordinateur, le cluster sera indisponible jusqu'à ce que l'opérateur redémarre le NameNode ;

• Un événement de maintenance planifié (tel qu'une mise à niveau logicielle ou matérielle sur une machine NameNode) entraînera une fenêtre d'indisponibilité du cluster.

La fonctionnalité HDFS High Availability résout les problèmes ci-dessus en offrant la possibilité d'exécuter deux (et 3.0.0 ou plus) NameNodes redondants dans le même cluster dans une configuration maître/esclave avec sauvegarde à chaud. Cela permet un basculement rapide vers un nouveau NameNode en cas de panne de la machine ou à des fins de maintenance planifiée, initié de manière proactive par un administrateur.

4.3.1 Principe

Après hadoop2.x, Clouera a proposé QJM/Qurom Journal Manager, qui est une solution HDFS HA basée sur l'algorithme Paxos. Il fournit une meilleure solution et solution. Dans un cluster HA typique, deux ou plusieurs ordinateurs distincts sont configurés en tant que NameNodes . À tout moment, un seul NameNode est actif, tandis que les autres sont en veille. Le NameNode actif est responsable de toutes les opérations client dans le cluster, tandis que Standby ne maintient qu'un état suffisant pour fournir un basculement rapide si nécessaire. Le schéma de principe est le suivant :

Pour maintenir la synchronisation du nud de secours avec le nud actif, les deux nuds communiquent avec un ensemble de démons indépendants appelés « nuds de journal » (JN). Lorsqu'un nud actif effectue une modification d'espace de noms, il consigne de manière persistante l'enregistrement modifié dans la plupart de ces JN. Les nuds de secours sont capables de lire les modifications de JN.

Le principe de base est d'utiliser 2N + 1 JN pour stocker les modifications, et chaque opération d'écriture de données en contient la plupart ( > =N+1) Lorsque le retour est réussi, l'écriture est considérée comme réussie. Bien sûr, ce que cet algorithme peut tolérer, c'est qu'au plus N machines échouent. Si plus de N machines échouent, l'algorithme échouera. Ce principe est basé sur l'algorithme de Paxos.

Dans l'architecture HA, le rôle de SecondaryNameNode n'existe plus.Afin de maintenir la cohérence des métadonnées du NN de secours avec le NN actif principal, ils interagissent via une série de processus légers gardés, JournalNode.

Lorsqu'une opération de modification est effectuée sur Active NN, le processus JN enregistre également le journal des modifications dans au moins la moitié des JN. À ce moment, Standby NN surveille que le journal de synchronisation dans JN a changé et lit le journal des modifications dans JN, puis Synchronisez avec votre propre arborescence de miroirs de répertoires, comme indiqué ci-dessous :

Lorsqu'un défaut se produit, après que le NN actif raccroche, le NN de secours lira tous les journaux de modification dans le JN avant de devenir le NN actif, afin de s'assurer qu'il est cohérent avec l'arborescence miroir du répertoire du NN suspendu avec un niveau élevé. Il prend ensuite ses responsabilités en toute transparence et maintient les demandes des clients pour atteindre une haute disponibilité.

Afin de fournir un basculement rapide, il est également nécessaire que le nud de secours dispose d'informations à jour sur l'emplacement des blocs dans le cluster. Pour ce faire, les DataNodes sont configurés avec les emplacements de tous les NameNodes et envoient des informations sur l'emplacement des blocs et des battements de cur à tous les NameNodes.

4.3.2 Les principaux avantages de QJM

• Il n'est pas nécessaire de configurer un stockage supplémentaire à partage élevé, ce qui réduit la complexité et les coûts de maintenance ;

• supprimer le spof ;

• Le degré de robustesse du système est configurable ;

• Les JN n'affecteront pas la latence globale en raison du retard de l'un d'entre eux, et n'affecteront pas les performances en raison de l'augmentation du nombre de JN (car NN envoie des journaux aux JN en parallèle).

4.3.3 Un seul NN peut commander DN

• Lorsque chaque NN change d'état, il envoie son propre état et un numéro de séquence au DN ;

• Le DN conserve ce numéro de séquence pendant le fonctionnement. En cas de basculement, le nouveau NN renverra son propre état actif et un numéro de séquence plus grand lorsqu'il renverra le battement de cur du DN. Lorsque le DN reçoit ce retour, il considère le NN comme le nouvel actif ;

• Si le NN actif d'origine récupère à ce moment et que les informations de pulsation renvoyées au DN incluent l'état actif et le numéro de séquence d'origine, le DN rejettera la commande du NN.

4.3.4 Un seul NN répond au client

Les clients accédant directement à standby nn échouent. Une couche est encapsulée dans la couche RPC et le NN est connecté de manière à effectuer une nouvelle tentative via FailoverProxyProvider. En essayant de se connecter à un nouveau NN après avoir échoué plusieurs fois à se connecter à un NN, l'impact sur le client est d'augmenter un certain délai lors de la nouvelle tentative. Le client peut définir le nombre et l'heure des tentatives.

Hadoop fournit le rôle ZKFailoverController, qui est déployé sur chaque nud NameNode en tant que processus démon, abrégé en zkfc. L'exemple de diagramme est le suivant :

4.3.5 Composition du FailoverController

• Moniteur de santé : Surveille si le NameNode est dans l'état indisponible ou non sain. Actuellement, la méthode correspondante de NN est appelée via RPC pour se terminer ;

• Électeuractifde réserve : Gérez et surveillez votre propre statut dans ZK ;

• ZKFailoverController : Il s'abonne aux événements HealthMonitor et ActiveStandbyElector et gère l'état du NameNode.

4.3.6 Responsabilités du ZKFailoverController

• Surveillance de la santé : envoyez périodiquement des commandes de détection de la santé au NN qu'il surveille pour déterminer si un NameNode est dans un état sain. Si la machine est en panne et que le battement de cur échoue, zkfc le marquera comme étant dans un état malsain ;

• Gestion de session : si le NN est sain, zkfc maintiendra une session ouverte dans zookeeper. Si le NameNode est également dans l'état Actif, alors zkfc aura également un znode de type à court terme dans Zookeeper. Lorsque le NN raccroche, le znode sera supprimé et le NN de secours obtiendra le verrou, passera au NN principal et marquera l'état comme Actif ;

• Lorsque le NN en panne est nouvellement démarré, il enregistrera à nouveau zookeper et constatera qu'il existe déjà un verrou znode, et il passera automatiquement à l'état de veille.Ce cycle alternatif garantit une grande fiabilité.Actuellement, il peut prendre en charge plus de deux NN;

• Élection principale : comme mentionné ci-dessus, un mécanisme de verrouillage préemptif est mis en uvre en maintenant un znode de courte durée dans zookeeper pour déterminer quel NameNode est dans l'état Actif.

Notez que dans un cluster HA, le Standby NameNode effectue également des points de contrôle de l'état de l'espace de noms, il n'est donc pas nécessaire d'exécuter un Secondary NameNode, CheckpointNode ou BackupNode dans un cluster HA.

4.4 Haute disponibilité HDFS (NFS)

La configuration et le démarrage de HA en mode NFS sont fondamentalement les mêmes qu'en mode QJM, la seule différence est la façon dont le namenode actif et le namenode de veille partagent le fichier d'édition. La méthode QJM utilise journalnode pour partager le fichier de modifications, tandis que la méthode NFS utilise le répertoire partagé distant NFS pour partager le fichier de modifications.

NFS permet aux utilisateurs d'accéder à des systèmes de fichiers distants comme accéder à des systèmes de fichiers locaux. Après l'introduction de NFS dans HDFS, les utilisateurs peuvent lire et écrire des fichiers sur HDFS tout comme lire et écrire des fichiers locaux, ce qui simplifie grandement l'utilisation de HDFS. Ceci est réalisé en introduisant un service de passerelle NFS. Mis en uvre, le service peut convertir le protocole NFS en protocole d'accès HDFS, comme illustré dans la figure suivante.

4.5 Fédération HDFS

4.5.1 Les deux couches principales de HDFS

• Espaces de noms

• se compose de répertoires, de fichiers et de blocs ;

• Il prend en charge toutes les opérations du système de fichiers liées à l'espace de noms, telles que la création, la suppression, la modification et la liste des fichiers et des répertoires.

• service de stockage de blocs

Comprend deux parties :

• Gestion des blocs (exécutée dans Namenode)

Fournir l'appartenance au cluster Datanode en gérant l'enregistrement et les battements de cur périodiques ;

Traiter et maintenir la position du bloc ;

Prend en charge les opérations liées aux blocs, telles que la création, la suppression, la modification et l'obtention de l'emplacement du bloc ;

Gérez le placement des répliques, bloquez la réplication des blocs faiblement répliqués et supprimez les blocs surrépliqués.

• stockage

Fourni par Datanodes en stockant des blocs sur le système de fichiers local et en autorisant l'accès en lecture/écriture.

L'architecture HDFS précédente n'autorisait qu'un seul espace de noms pour l'ensemble du cluster. Dans cette configuration, un seul Namenode gère l'espace de noms. La fédération HDFS résout cette limitation en ajoutant la prise en charge de plusieurs nuds de noms/espaces de noms à HDFS.

4.5.2 Principe

L'architecture Active NN unique fait que HDFS a des problèmes potentiels d'évolutivité et de performances du cluster. Lorsque le cluster est volumineux dans une certaine mesure, la mémoire utilisée par le processus NN peut atteindre des centaines de G, et NN devient un goulot d'étranglement des performances.

La formule d'estimation couramment utilisée est que 1G correspond à 1 million de blocs. Si calculé selon la taille de bloc par défaut, il est d'environ 64T (cette proportion estimée est relativement importante et riche. En fait, même si chaque fichier ne comporte qu'un seul bloc , toutes les informations de métadonnées n'auront pas non plus 1 Ko/bloc).

Pour mettre à l'échelle horizontalement le service de noms, la fédération utilise plusieurs nuds de noms/espaces de noms indépendants. Les données gérées entre les Namenodes sont partagées, mais en même temps indépendantes, et n'ont pas besoin de se coordonner entre elles. Les Datanodes sont utilisés par tous les Namenodes comme stockage commun pour les blocs. Chaque Datanode enregistre tous les Namenodes du cluster. Les nuds de données envoient des battements de cur périodiques et bloquent les rapports. Ils gèrent également les commandes du Namenode.

Afin de résoudre ce problème, Hadoop 2.x et Hadoop 3.x fournissent la fédération HDFS. Le schéma de principe est le suivant :

Plusieurs NN partagent des ressources de stockage dans un cluster, et chaque NN peut fournir des services externes indépendamment.

Chaque NN définit un pool de stockage avec un ID distinct, et chaque DN fournit un stockage pour tous les pools de stockage.

Le DN rapportera les informations de bloc à son NN correspondant en fonction de l'ID du pool de stockage, et en même temps, le DN rapportera les ressources disponibles de stockage local à tous les NN.

Si vous avez besoin d'accéder facilement aux ressources sur plusieurs NN côté client, vous pouvez utiliser la table de montage client pour mapper différents répertoires sur différents NN, mais les répertoires correspondants doivent exister sur le NN.

4.5.3 Avantages de conception

• Les modifications sont minimes et compatibles ; le NN existant ne nécessite aucune modification de configuration ; si le client existant ne se connecte qu'à un certain NN, le code et la configuration n'ont pas besoin d'être modifiés ;

• Gestion séparée de l'espace de noms et de la gestion du stockage en mode bloc ;

• Table de montage client : correspond automatiquement à NN via le chemin, afin que les modifications de configuration de la fédération soient transparentes pour l'application.

4.5.4 VueF

View File System (ViewFs) permet de gérer plusieurs espaces de noms de système de fichiers Hadoop (ou volumes d'espace de noms). Il est particulièrement utile pour les clusters avec plusieurs espaces de noms dans la fédération HDFS. ViewF est similaire à la table d'installation du client dans certains systèmes Unix/Linux. ViewF peut être utilisé pour créer des vues d'espace de noms personnalisées ainsi que des vues communes par cluster.

Le système de fichiers View est présenté dans le contexte d'un système Hadoop avec plusieurs clusters, chacun pouvant être fédéré dans plusieurs espaces de noms pour fournir un espace de noms global par cluster afin que les applications puissent s'exécuter de la même manière que la pré-fédération.

4.5.4.1 Un seul cluster Namenode

Avant la fédération HDFS, les clusters avaient un espace de noms unique, donnant à ce cluster un espace de noms de système de fichiers unique. S'il y a plusieurs clusters. Ensuite, les espaces de noms du système de fichiers de chaque cluster sont complètement indépendants et disjoints. De plus, le stockage physique n'est pas partagé entre les clusters (c'est-à-dire que les nuds de données ne sont pas partagés entre les clusters).

4.5.4.2 Fédération et ViewF

S'il y a plusieurs clusters. Chaque cluster possède un ou plusieurs espaces de noms. Chaque namenode a son propre espace de noms. Le namenode appartient à un et un seul cluster. Mais contrairement à un cluster de namenode unique : les namenodes du même cluster partagent le stockage physique du cluster. Les espaces de noms dans le cluster sont indépendants comme avant.

Les opérations déterminent ce qui est stocké sur chaque namenode du cluster en fonction des exigences de stockage. Par exemple, ils peuvent stocker toutes les données utilisateur (/user/ < Nom d'utilisateur > ) dans un espace de noms, toutes les données de flux (/data) dans un autre espace de noms, tous les projets (/projects) dans un autre espace de noms, etc.

4.5.4.3 Espace de noms global par cluster utilisant ViewF

Pour assurer la transparence, le système de fichiers ViewF (c'est-à-dire la table de montage client) est utilisé pour créer une vue indépendante par cluster de l'espace de noms du cluster, similaire aux espaces de noms dans un seul cluster Namenode. Tables de montage client (comme les tables de montage Unix) et montez de nouveaux volumes d'espace de noms en utilisant l'ancienne convention de dénomination. La figure suivante montre la table de montage pour quatre volumes d'espace de noms /user, /data, /projects et /tmp :

ViewF implémente l'interface du système de fichiers Hadoop, tout comme HDFS et les systèmes de fichiers locaux. C'est un système de fichiers normal, il n'autorise que les liens vers d'autres systèmes de fichiers. Toutes les commandes shell fonctionnent avec ViewFS, comme avec HDFS et les systèmes de fichiers locaux.

5. Guide de commande

Toutes les commandes hadoop sont déclenchées par le script bin/hdfs. L'exécution du script hdfs sans spécifier d'arguments imprime les descriptions de toutes les commandes.

Utilisation : commande hdfs

Hadoop dispose d'un cadre d'analyse d'options pour analyser les options générales et exécuter des classes.

En raison de la limite de mots, cet article est divisé en deux parties, le haut et le bas, respectivement, dans le titre et le deuxième article. Pour la seconde moitié du contenu, veuillez vous référer aux deux articles d'aujourd'hui.

Pour un contenu plus passionnant sur les produits secs, veuillez rechercher et suivre la plate-forme publique officielle de l'Institut de science des données de Tsinghua-Qingdao "Data School THU"