Vue d'ensemble de la fédération d'architecture de cluster Hadoop 2.0

Fédération d'architecture de cluster Hadoop 2.0

Introduction:

Dans ce blog, je vais approfondir la fédération d'architecture de cluster Hadoop 2.0. Apache Hadoop a beaucoup évolué depuis la sortie d'Apache Hadoop 1.x. Comme vous le savez d'après mon blog précédent, le suit la topologie maître / esclave où NameNode agit comme un démon maître et est responsable de la gestion des autres nœuds esclaves appelés DataNodes. Dans cet écosystème, ce seul Master Daemon ou NameNode devient un goulot d'étranglement et au contraire, les entreprises doivent avoir NameNode qui est hautement disponible. Cette raison même est devenue la base de l'architecture de la fédération HDFS et Architecture HA (haute disponibilité) .

Les sujets que j'ai abordés dans ce blog sont les suivants:

• L'architecture HDFS actuelle
• Limitations de l'architecture HDFS actuelle
• Architecture de fédération HDFS

Vue d'ensemble de l'architecture HDFS actuelle:

Comme vous pouvez le voir dans la figure ci-dessus, le HDFS actuel a deux couches:

• Espace de noms HDFS (NS): Cette couche est responsable de la gestion des répertoires, des fichiers et des blocs. Il fournit toutes les opérations du système de fichiers liées à l'espace de noms comme la création, la suppression ou la modification des fichiers ou des répertoires de fichiers.
• Couche de stockage: Il comprend deux éléments de base.
  1. Gestion des blocs : Il effectue les opérations suivantes:
     • Vérifie périodiquement les pulsations des DataNodes et gère l'appartenance de DataNode au cluster.
     • Gère les rapports de bloc et maintient l'emplacement du bloc.
     • Prend en charge les opérations de bloc comme la création, la modification, la suppression et l'attribution de l'emplacement du bloc.
     • Maintient le facteur de réplication cohérent dans tout le cluster.

2. Stockage physique : Il est géré par DataNodes qui sont responsables du stockage des données et fournissent ainsi un accès en lecture / écriture aux données stockées dans HDFS.

Ainsi, l'architecture HDFS actuelle vous permet d'avoir un seul espace de noms pour un cluster. Dans cette architecture, un seul NameNode est responsable de la gestion de l'espace de noms. Cette architecture est très pratique et facile à mettre en œuvre. En outre, il offre une capacité suffisante pour répondre aux besoins du petit cluster de production.

java créer un tableau d'objets

Limitations du HDFS actuel:

Comme indiqué précédemment, le HDFS actuel a suffi aux besoins et aux cas d'utilisation d'un petit cluster de production. Mais, de grandes organisations comme Yahoo, Facebook ont ​​trouvé certaines limites alors que le cluster HDFS augmentait de façon exponentielle. Jetons un coup d'œil à quelques-unes des limitations:

1. L'espace de noms est pas évolutif comme DataNodes. Par conséquent, nous ne pouvons avoir que ce nombre de DataNodes dans le cluster qu'un seul NameNode peut gérer.
2. Les deux couches, c'est-à-dire la couche d'espace de nom et la couche de stockage sont couplage étroit ce qui rend la mise en œuvre alternative de NameNode très difficile.
3. Les performances de l'ensemble du système Hadoop dépendent de la débit du NameNode. Par conséquent, toutes les performances de toutes les opérations HDFS dépendent du nombre de tâches que le NameNode peut gérer à un moment donné.
4. Le NameNode stocke tout l'espace de noms dans la RAM pour un accès rapide. Cela conduit à des limitations en termes de taille mémoire c'est-à-dire le nombre d'objets d'espace de noms (fichiers et blocs) qu'un seul serveur d'espace de noms peut gérer.
5. De nombreuses organisations (fournisseur) disposant d'un déploiement HDFS permettent à plusieurs organisations (locataires) d'utiliser leur espace de noms de cluster. Donc, il n'y a pas de séparation de l'espace de noms et par conséquent, il y a pas d'isolement parmi les organisations de locataires qui utilisent le cluster.

Architecture de fédération HDFS:

• Dans l'architecture de fédération HDFS, nous avons une évolutivité horizontale du service de noms. Par conséquent, nous avons plusieurs NameNodes qui sont fédérés, c'est-à-dire indépendants les uns des autres.
• Les DataNodes sont présents en bas, c'est-à-dire la couche de stockage sous-jacente.
• Chaque DataNode s'enregistre auprès de tous les NameNodes du cluster.
• Les DataNodes transmettent des pulsations périodiques, bloquent les rapports et gèrent les commandes des NameNodes.

La représentation graphique de l'architecture de fédération HDFS est donnée ci-dessous:

Avant d'aller de l'avant, permettez-moi de parler brièvement de l'image architecturale ci-dessus:

• Il existe plusieurs espaces de noms (NS1, NS2,…, NSn) et chacun d'eux est géré par son NameNode respectif.
• Chaque espace de noms a son propre pool de blocs (NS1 a Pool 1, NSk a Pool k et ainsi de suite).
• Comme le montre l'image, les blocs du pool 1 (bleu ciel) sont stockés sur DataNode 1, DataNode 2 et ainsi de suite. De même, tous les blocs de chaque pool de blocs résideront sur tous les DataNodes.

Voyons maintenant en détail les composants de l'architecture de fédération HDFS:

Bloc Pool:

Le pool de blocs n'est rien d'autre qu'un ensemble de blocs appartenant à un espace de noms spécifique. Nous avons donc une collection de pool de blocs où chaque pool de blocs est géré indépendamment de l'autre. Cette indépendance où chaque pool de blocs est géré indépendamment permet à l'espace de noms de créer des ID de bloc pour de nouveaux blocs sans coordination avec d'autres espaces de noms. Les blocs de données présents dans tout le pool de blocs sont stockés dans tous les DataNodes. Fondamentalement, le pool de blocs fournit une abstraction de sorte que les blocs de données résidant dans les DataNodes (comme dans l'architecture d'espace de nom unique) peuvent être regroupés en fonction d'un espace de noms particulier.

Volume de l'espace de noms:

Le volume d'espace de noms n'est rien d'autre qu'un espace de noms avec son pool de blocs. Par conséquent, dans la fédération HDFS, nous avons plusieurs volumes d'espace de noms. C'est une unité de gestion autonome, c'est-à-dire que chaque volume d'espace de noms peut fonctionner indépendamment. Si un NameNode ou un espace de noms est supprimé, le pool de blocs correspondant qui réside sur les DataNodes sera également supprimé.

Démo sur la fédération d'architecture de cluster Hadoop 2.0 | Edureka

Maintenant, je suppose que vous avez une assez bonne idée de l'architecture de fédération HDFS. Il s'agit plus d'un concept théorique et les gens ne l'utilisent généralement pas dans un système de production pratique. Il existe des problèmes d'implémentation avec la fédération HDFS qui rendent son déploiement difficile. Par conséquent, la Architecture HA (haute disponibilité) est préférable pour résoudre le problème du point de défaillance unique. J'ai couvert le Architecture HDFS HA dans mon prochain blog.

java est une relation

Maintenant que vous avez compris l'architecture de la fédération Hadoop HDFS, consultez le par Edureka, une entreprise d'apprentissage en ligne de confiance avec un réseau de plus de 250 000 apprenants satisfaits répartis dans le monde entier. Le cours de formation à la certification Edureka Big Data Hadoop aide les apprenants à devenir des experts dans les domaines HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume et Sqoop en utilisant des cas d'utilisation en temps réel sur le commerce de détail, les médias sociaux, l'aviation, le tourisme et la finance.

Vous avez une question pour nous? Veuillez le mentionner dans la section commentaires et nous vous recontacterons.