Ce message a été initialement publié via blogs.apache.org, nous le republions ici sous une forme légèrement modifiée pour votre commodité :
À première vue, l'architecture Apache HBase semble suivre un modèle maître/esclave où le maître reçoit toutes les requêtes mais le vrai travail est fait par les esclaves. Ce n'est pas vraiment le cas, et dans cet article je décrirai quelles tâches sont en fait gérées par le maître et les esclaves.
Régions et serveurs de région
HBase est le gestionnaire de stockage Hadoop qui fournit des lectures et des écritures aléatoires à faible latence sur HDFS, et il peut gérer des pétaoctets de données. L'une des fonctionnalités intéressantes de HBase est le partitionnement automatique, ce qui signifie simplement que les tables sont distribuées dynamiquement par le système lorsqu'elles deviennent trop volumineuses.
L'unité de base de l'évolutivité horizontale dans HBase est appelée une région . Les régions sont un sous-ensemble des données de la table et elles sont essentiellement une plage contiguë et triée de lignes qui sont stockées ensemble.
Initialement, il n'y a qu'une seule région pour une table. Comme indiqué ci-dessous, lorsque les régions deviennent trop grandes après l'ajout de plusieurs lignes, la région est divisée en deux au niveau de la clé du milieu, créant ainsi deux moitiés à peu près égales.
Dans HBase, les esclaves sont appelés Region Servers . Chaque serveur de région est chargé de desservir un ensemble de régions, et une région (c'est-à-dire une plage de lignes) ne peut être desservie que par un seul serveur de région.
L'architecture HBase comporte deux services principaux :HMaster qui est chargé de coordonner le cluster et d'exécuter les opérations administratives, et le HRegionServer responsable du traitement d'un sous-ensemble des données de la table.
HMaster, affectation de région et équilibrage
Comme mentionné précédemment, le maître HBase coordonne le cluster HBase et est responsable des opérations administratives.
Un serveur de région peut desservir une ou plusieurs régions. Chaque région est affectée à un serveur de région au démarrage et le maître peut décider de déplacer une région d'un serveur de région à un autre à la suite d'une opération d'équilibrage de charge. Le maître gère également les défaillances du serveur de région en attribuant la région à un autre serveur de région.
Le mappage des régions et des serveurs de région est conservé dans une table système appelée META. En lisant META, vous pouvez identifier quelle région est responsable de votre clé. Cela signifie que pour les opérations de lecture et d'écriture, le maître n'est pas du tout impliqué et les clients peuvent accéder directement au serveur de région chargé de servir les données demandées.
Localisation d'une clé de ligne :quel serveur de région est responsable ?
Pour mettre ou obtenir une ligne, les clients n'ont pas besoin de contacter le maître, les clients peuvent contacter directement le serveur de région qui gère la ligne spécifiée, ou en cas d'analyse client, peuvent contacter directement l'ensemble des serveurs de région responsables de la gestion de l'ensemble de clés :
Pour identifier le serveur de région, le client effectue une requête sur la table META.
META est une table système utilisée pour suivre les régions. Il contient le nom du serveur et un identifiant de région comprenant un nom de table et la clé de ligne de démarrage. En examinant la clé de démarrage et la clé de démarrage de la région suivante, les clients sont en mesure d'identifier la plage de lignes contenues dans une région particulière.
Le client conserve un cache pour les emplacements de région. Cela évite aux clients d'accéder à la table META chaque fois qu'une opération sur la même région est émise. En cas de division de région ou de déplacement vers un autre serveur de région (en raison d'un équilibrage ou de politiques d'attribution), le client recevra une exception en réponse et le cache sera actualisé en récupérant les informations mises à jour à partir de la table META :
META étant une table comme les autres, le client doit identifier sur quel serveur META se trouve. Les emplacements META sont stockés dans un nœud ZooKeeper sur affectation par le maître, et le client lit directement le nœud pour obtenir l'adresse du serveur de région qui contient META.
La conception originale de HBase était basée sur BigTable, avec une autre table appelée -ROOT- contenant les emplacements META et Apache ZooKeeper pointant vers elle. HBase 0.96 a supprimé cet arrangement en faveur de ZooKeeper uniquement, car META ne peut pas être divisé et se compose donc d'une seule région.
API client :responsabilités du maître et des régions
L'API client HBase Java possède deux interfaces principales :
- Administrateur HBase permet l'interaction avec le "schéma de table" en créant/supprimant/modifiant des tables, et il permet l'interaction avec le cluster en attribuant/désattribuant des régions, en fusionnant des régions, en appelant à un vidage, etc. Cette interface communique avec le Maître.
- HTable permet au client de manipuler les données d'une table spécifiée en utilisant get, put, delete et toutes les autres opérations de données. Cette interface communique directement avec les serveurs régionaux chargés de gérer le jeu de clés demandé.
Ces deux interfaces ont des responsabilités distinctes :HBaseAdmin n'est utilisé que pour exécuter des opérations d'administration et communiquer avec le maître, tandis que la HTable est utilisée pour manipuler des données et communiquer avec les régions.
Conclusion
Comme nous l'avons vu ici, avoir une architecture Maître/Esclave ne signifie pas que chaque opération passe par le maître. Pour lire et écrire des données, le client HBase va en fait directement au serveur de région spécifique chargé de gérer les clés de ligne pour toutes les opérations de données (HTable). Le maître est utilisé par le client uniquement pour les opérations de création, de modification et de suppression de table (HBaseAdmin).
Bien que le concept de maître existe, le client HBase n'en dépend pas pour les opérations de données et le cluster peut continuer à servir des données même si le maître tombe en panne.
Matteo Bertozzi est ingénieur logiciel au sein de l'équipe de la plate-forme et committer HBase.
Si vous êtes intéressé par HBase, assurez-vous de vous inscrire à HBaseCon 2013 (13 juin, San Francisco) - L'événement communautaire pour les contributeurs, développeurs, administrateurs et utilisateurs de HBase. L'espace est limité !
