Principes fonctionnels, idées de conception, conception d'architecture et analyse du code source de HBase

Auteur : Zen et l'art de la programmation informatique

1. Introduction

1.1 Qu'est-ce que HBase ?
HBase est un système de stockage de données NoSQL open source sous la Fondation Apache. Il peut fonctionner dans l'environnement Hadoop et fournir des services de lecture et d'écriture de données de haute fiabilité et de hautes performances. HBase possède une structure flexible de familles de colonnes, prend en charge les requêtes aléatoires de données massives et convient à divers scénarios d'analyse de données non relationnelles.
Depuis le développement de Hadoop, l'un des projets phares d'Apache en 2007, jusqu'à son déclin ces dernières années, et maintenant son entrée dans l'incubateur Apache, HBase est devenu un produit open source unique en termes d'intérêts commerciaux et de besoins des utilisateurs.
1.2 Pourquoi devrions-nous apprendre le code source de HBase ?
Après avoir acquis les connaissances de base de HBase, nous devons mieux comprendre ses idées de conception, sa conception architecturale et son code source. L'apprentissage du code source de HBase peut nous aider à mieux comprendre le mécanisme de fonctionnement de HBase et peut également approfondir notre compréhension du développement. Par exemple, pour les débutants familiers avec le langage Java mais pas avec Hadoop, Zookeeper ou HDFS, la lecture du code source de HBase peut les aider à comprendre rapidement l'architecture et les principes de base de HBase. De plus, la lecture du code source de HBase peut être utile à certains développeurs, car HBase est développé en Java et la connaissance du langage Java est cruciale pour comprendre le code de HBase.
1.3 Les objectifs d'apprentissage de cette série de didacticiels
Cette série de didacticiels se concentre principalement sur l'apprentissage du code source de HBase. Grâce à l'analyse des principes fonctionnels, des idées de conception, de la conception de l'architecture et du code source de HBase, il peut aider les lecteurs à mieux comprendre HBase et Être capable d'appliquer les connaissances acquises et de résoudre de vrais problèmes. Les objectifs spécifiques d’apprentissage sont les suivants :

  • Comprendre la présentation fonctionnelle et les fonctionnalités de HBase.
  • Maîtrisez les principes de fonctionnement de HBase, notamment l'architecture de cluster, le modèle de données, la conception de tables et la stratégie de partitionnement.
  • Découvrez l'API Java de HBase et ses principes de mise en œuvre.
  • Compréhension approfondie des mécanismes internes de HBase, y compris l'équilibrage de charge, le fractionnement et la fusion de RegionServer, les protocoles de cohérence des données, le traitement des transactions, etc.
  • Développez vos compétences en programmation grâce à la lecture et à la pratique du code source.

2. Concepts de base et terminologie

2.1 Notions de base

2.1.1 NoSQL

NoSQL (Not Only SQL) signifie « pas seulement SQL » et fait référence aux bases de données non relationnelles. Différent des bases de données relationnelles traditionnelles, NoSQL sépare le stockage des données et le calcul, rendant les données plus flexibles et plus faciles à développer. NoSQL stocke les données sous forme de paires clé-valeur, et la valeur correspondante peut être obtenue via une simple clé. Grâce à son format clé-valeur, NoSQL peut stocker un grand nombre de types de données différents sans avoir besoin d'un schéma prédéfini. En général, NoSQL est généralement utilisé pour créer des bases de données clé-valeur distribuées, telles qu'Apache Cassandra, MongoDB et Redis.

2.1.2 Hadoop

Hadoop est un framework qui intègre les ressources matérielles sous-jacentes et fournit un ensemble d'opérations simple et unifié. Le calcul distribué et le stockage d'ensembles de données à grande échelle peuvent être réalisés via Hadoop. Hadoop repose sur trois piliers : HDFS, MapReduce et YARN. HDFS (Hadoop Distributed File System) est un système de fichiers distribué utilisé pour stocker des fichiers volumineux. MapReduce (Hadoop Map Reduction) est un framework informatique distribué qui permet aux utilisateurs d'écrire des tâches simultanées ou séquentielles basées sur Map et Reduction. YARN (Yet Another Resource Negotiator) est un cadre de gestion des ressources utilisé pour allouer des ressources de cluster.

2.1.3 HBase

HBase est un système de stockage de données NoSQL open source sous la Fondation Apache et développé par Hadoop. HBase offre des capacités de stockage et d'accès distribuées, évolutives, à faible latence et à haut débit, et convient au stockage et aux requêtes de données massives dans des environnements distribués. HBase prend en charge le stockage par famille de colonnes, l'écriture par lots, les requêtes en temps réel et d'autres fonctionnalités, et utilise le système de fichiers HDFS de Hadoop comme stockage sous-jacent, qui peut utiliser directement les clusters de serveurs existants sur Hadoop.

2.1.4 Grande table

Bigtable de Google est une base de données NoSQL, qui est un stockage de données structurées distribué utilisé pour stocker des données structurées, semi-structurées et non structurées. Le concept de conception de Bigtable consiste à diviser les données en fonction des lignes, des colonnes et des horodatages, et à garantir une haute disponibilité et des performances élevées. Son architecture de stockage est similaire à HDFS dans Hadoop. Bien que Bigtable présente certaines limites, telles que l'impossibilité de rechercher des colonnes spécifiques comme une base de données relationnelle, ses avantages sont l'efficacité, l'évolutivité et la fiabilité.

2.1.5 Cassandre

Apache Cassandra est une base de données NoSQL distribuée open source proposée par Facebook et est l'une des principales bases de données NoSQL. Cassandra prend en charge la haute disponibilité, la distribution, la mise à l'échelle élastique et une forte cohérence. Il s'agit d'un modèle multi-maître basé sur la réplication (c'est-à-dire que chaque nœud peut recevoir des requêtes de lecture et d'écriture), offrant un débit élevé et une faible latence. Cassandra est développé en langage Java et est extrêmement flexible et facile à utiliser. C'est désormais devenu un projet de haut niveau de la Fondation Apache.

2.1.6 Hypertable

Hypertable est une base de données NoSQL informatique distribuée en mémoire développée par Pinterest. Hypertable stocke les données en mémoire et offre des vitesses de lecture et d'écriture élevées via SSD. Il prend en charge la haute disponibilité, la sécurité des données, les transactions ACID, l'horizon partagé et la réplication. Son architecture de stockage est similaire à HDFS dans Hadoop. Hypertable s'appuie sur les concepts de conception de l'article F1 de Google et adopte une méthode d'indexation B+Tree unique dans son architecture.

2.1.7 Memcaché

Memcached est un système de mise en cache d'objets de mémoire distribuée hautes performances. Memcached, développé pour la première fois par Danga Interactive, est un système de stockage clé-valeur en mémoire haute performance utilisé pour la mise en cache ou le stockage de session. Ses hautes performances proviennent du fait que Memcached est stocké en mémoire, il est donc rapide et adapté aux applications multithread. Il prend en charge le modèle événementiel basé sur Libevent. Memcached s'appuie sur le protocole BSD et utilise un mécanisme de transmission de messages simple et léger. C'est désormais devenu un service du système d'exploitation Linux.

2.1.8 Redis

Redis est une base de données clé-valeur open source et hautes performances. Il prend en charge la persistance des données, la synchronisation maître-esclave, la haute disponibilité et d'autres fonctionnalités. Il s'agit d'une base de données clé-valeur hautes performances basée sur la mémoire qui prend en charge des types de données tels que des chaînes, des hachages, des listes, des ensembles et des ensembles ordonnés. Elle peut être utilisée dans des scénarios tels que la mise en cache, les files d'attente de messages, les compteurs et les classements. Il est développé en langage C et présente de très hautes performances. Redis est intrinsèquement orienté vers les données massives et peut gérer plus de 100 000 requêtes par seconde. Actuellement, Redis est en train de devenir la base de données NoSQL la plus populaire.

2.2 Modèle de données et conception du tableau

Le modèle de données HBase est similaire à une base de données relationnelle traditionnelle, avec le concept de table. Chaque table est composée de plusieurs colonnes et chaque colonne correspond à une famille de colonnes (Column Family). Chaque ligne correspond à une clé de ligne (Row Key), qui détermine de manière unique les données de cette ligne. Il existe deux types de familles de colonnes dans HBase :

  • Famille de colonnes primaires : Il ne peut y avoir qu'une seule famille de colonnes de clé primaire, généralement nommée « cf ». Chaque table doit avoir une famille de colonnes de clé primaire, car le but de cette famille de colonnes est le tri et les analyses de plage.
  • Autres familles de colonnes (famille de colonnes non primaires) : il peut y avoir plusieurs autres familles de colonnes, qui sont utilisées pour stocker d'autres données en plus de la clé primaire.
    Chaque famille de colonnes peut stocker n'importe quelle quantité de données, y compris les valeurs NULL. Les données de toutes les familles de colonnes de chaque ligne seront enregistrées ensemble. Localisez les données via les clés de ligne, les familles de colonnes et les qualificatifs de colonne.

2.3 Architecture HDFS

HDFS (Hadoop Distributed File System) est un système de fichiers distribué qui fournit des services de stockage de fichiers à haute tolérance aux pannes et à haut débit. HDFS est un sous-projet du projet Hadoop. HDFS se compose de deux composants principaux : NameNode et DataNode. Le NameNode est responsable de la gestion de l'espace de noms du système de fichiers et constitue un point de défaillance unique. DataNode stocke les blocs de données de fichiers. HDFS prend en charge la lecture et l'écriture aléatoires de fichiers. HDFS est conçu pour stocker de grandes quantités de fichiers, mais ne prend pas en charge la modification aléatoire des fichiers. Toutes les données sont stockées dans des blocs et le système de fichiers accède aux données sous forme de flux. HDFS offre une tolérance aux pannes élevée, une fiabilité élevée et une détection automatique des racks.
HDFS possède les fonctionnalités importantes suivantes :

  • Tolérance élevée aux pannes : HDFS utilise une architecture maître-esclave pour fournir une tolérance aux pannes élevée. Une fois qu'un DataNode tombe en panne, d'autres DataNodes prendront en charge son travail et continueront à fournir des services.
  • Haut débit : HDFS peut gérer un grand nombre de requêtes de lecture et d'écriture avec un débit élevé.
  • Transmission de données fiable : HDFS utilise des connexions TCP/IP déployées indépendamment et les données sont transmises via la vérification CRC.
  • Adapté au traitement par lots : HDFS est conçu pour stocker un grand nombre de petits fichiers qui ne seront pas modifiés et convient au traitement par lots.

2.4 Gardien de zoo

Apache Zookeeper est un sous-projet du projet Apache Hadoop et est un service collaboratif distribué. Il fournit des services de cohérence pour les applications distribuées. Zookeeper est utilisé pour garantir l'exactitude des processus distribués. Il s'agit d'un outil de coordination distribué open source qui fournit diverses fonctions pour les applications distribuées, notamment la maintenance de la configuration, les services de noms de domaine, le routage logiciel, le basculement et les notifications, etc. Le rôle de Zookeeper est de conserver les fichiers de configuration dans les systèmes distribués, de détecter si les nœuds sont actifs et d'informer les autres serveurs pour maintenir la cohérence des informations du cluster. Le mode de fonctionnement de Zookeeper repose sur un groupe de serveurs appelés services Zookeeper, qui sont généralement constitués d'un serveur maître et de plusieurs serveurs esclaves. Lorsque le serveur maître tombe en panne, zookeeper élira un nouveau serveur maître. L'ensemble du système garantit une cohérence éventuelle, ce qui signifie que l'état de tous les serveurs finira par atteindre un état cohérent.

3. Principes de conception

3.1 Conception distribuée

HBase est une base de données distribuée. Il ne s'agit pas d'une base de données autonome, mais d'un système distribué composé de plusieurs serveurs. Il fournit des services distribués hautement disponibles. HBase peut évoluer horizontalement, ce qui signifie que les performances du service peuvent être améliorées en ajoutant des nœuds. Il existe un nœud maître dans HBase, qui est responsable de la surveillance de l'état de RegionServer et de l'allocation des régions. Il dispose également d'un ensemble de nœuds de serveur exécutés sur RegionServer, qui sont responsables du stockage des données.

3.1.1 Maître

Le nœud Maître de HBase a principalement les fonctions suivantes :

  • Stockage des métadonnées : le nœud maître stocke les métadonnées sur la distribution des données. Il stocke sur quels serveurs régionaux les données se trouvent et quelles régions sont distribuées sur quels serveurs.
  • Gestion de l'espace de noms : le nœud maître suit le dernier état de toutes les tables dans HBase. Il peut créer de nouvelles tables, supprimer des tables existantes et mettre à jour les propriétés des tables.
  • Routage des requêtes : le nœud maître est acheminé vers le RegionServer correspondant en fonction de la demande de requête de l'utilisateur.
  • Équilibrage de charge : lorsque les ressources du cluster sont limitées, le nœud maître distribuera les requêtes aux différents serveurs régionaux.

3.1.2 Serveur de région

Le nœud RegionServer de HBase stocke les données dans HBase. Il est principalement chargé des tâches suivantes :

  • Stockage des données : RegionServer stocke les données dans HBase. RegionServer divise les données selon la région pour utiliser l'espace de stockage plus efficacement. RegionServer peut stocker des données sur des disques locaux ou utiliser des systèmes de stockage de données distants tels qu'Amazon S3.
  • Découpe et fractionnement des données : RegionServer peut diviser dynamiquement les données pour utiliser pleinement les ressources de stockage du cluster. Lorsqu'une région sur RegionServer est surpeuplée, elle divise la région en deux nouvelles régions, puis coupe et répartit uniformément les données entre les deux nouvelles régions.
  • Gestion des copies : Les données dans HBase sont stockées sur chaque RegionServer. Afin d'assurer la redondance et la fiabilité des données, il copiera les données sur plusieurs serveurs.
  • Routage des demandes : lorsque RegionServer reçoit une demande client, il trouvera la région correspondante pour répondre en fonction de la demande de requête.
  • Basculement : lorsqu'un RegionServer échoue, HBase redirigera les requêtes vers un autre RegionServer.

3.1.3 Protocole de communication

Lorsqu'un client envoie une demande à HBase, la demande sera d'abord acheminée vers le nœud maître. Le nœud maître sélectionnera un nœud RegionServer puis acheminera la demande vers le RegionServer spécifié. Le nœud RegionServer est responsable du traitement des demandes et du renvoi des résultats au client. Les RegionServers communiquent entre eux à l'aide du protocole Thrift, qui est un protocole de communication réseau multilingue hautes performances. Thrift peut mapper des structures complexes au codage binaire pour réduire la consommation de bande passante du réseau.

3.2 Mécanisme de partage

Les données dans HBase sont distribuées sur différents RegionServers pour utiliser plus efficacement les ressources du cluster. Les données sont divisées en plusieurs régions sur le RegionServer et les régions sont distribuées sur différents RegionServers. Les régions sont découpées en morceaux de taille fixe appelés StoreFiles. StoreFile est la plus petite unité physique de HBase et est également l'unité de stockage des données sur disque. Une région se compose généralement de plusieurs StoreFiles. StoreFile peut être placé sur un disque local ou sur un système de stockage de données distant tel qu'Amazon S3.
Lorsqu'un enregistrement est inséré dans HBase, il sera d'abord acheminé vers la région correspondante. La région divisera les enregistrements en plusieurs StoreFiles et écrira les StoreFiles sur le disque correspondant ou le système de stockage de données distant. Si un enregistrement doit être mis à jour, HBase doit rechercher la région correspondante et trouver le StoreFile correspondant, puis écrire les données modifiées dans le StoreFile. Si l'enregistrement doit être supprimé, supprimez-le simplement du StoreFile correspondant. Cela garantit l’intégrité des données et la haute disponibilité.

3.3 Protocole de cohérence

Dans un système distribué, l'état de chaque nœud peut être incohérent. Afin de maintenir la cohérence des données sur chaque nœud, HBase adopte le protocole Two Phase Commits pour garantir la cohérence des données. Le protocole de cohérence utilisé dans HBase est le protocole Paxos. Le protocole Paxos garantit la cohérence des données entre plusieurs nœuds.
Avant d'exécuter le protocole Paxos, HBase doit déterminer un super maître, qui est le seul nœud maître du cluster HBase. Le super maître est responsable de la coordination des demandes d'opération HBase, de la gestion de l'adhésion et de la sortie des RegionServers et des modifications de configuration associées aux tables. Chaque fois qu'un nœud RegionServer démarre, il s'enregistre auprès du super maître. Lorsqu'un nœud RegionServer échoue, il se déconnecte du super maître.
Chaque fois qu'une demande client est envoyée à HBase, un ID de transaction est généré, qui est l'horodatage lorsque le client initie la demande. Lorsque le client termine la demande, il envoie un message de préparation au RegionServer, qui contient la demande du client, l'ID de transaction et le temps de soumission maximum attendu par le client. Les messages de préparation seront collectés par RegionServer, puis les messages de validation seront envoyés au RegionServer principal. Le message Commit ne sera envoyé qu'après confirmation des messages de préparation de tous les participants (y compris le serveur régional principal et le serveur régional secondaire). Si l'un des participants ne répond pas correctement, le client réessayera la demande.
Si tous les participants répondent avec succès, RegionServer enverra un message d'acceptation à tous les participants. Le message d'acceptation contient la demande du client, l'ID de transaction, l'heure de soumission et d'autres informations. Lorsque l'un des participants accepte le message Accepter, RegionServer conservera les données sur le disque. Si l'un des participants rejette le message Accepter, le client réessayera la demande.

3.4 Commande de numérisation

La commande Scan est utilisée dans HBase pour récupérer les données de plusieurs tables. La commande Scan spécifie le nom de la table, les conditions d'analyse, les conditions de filtrage des résultats, les colonnes pour renvoyer les résultats, les conditions de tri, etc. Lorsque le client lance la commande Scan, il envoie une requête RPC aux RegionServers spécifiés, et les RegionServers traitent la demande et renvoient les résultats de la requête. Après avoir reçu les résultats renvoyés, le client effectue le filtrage, l'agrégation et le tri des données en fonction des conditions de filtrage des résultats, des colonnes et des conditions de tri. Enfin, le client renvoie les résultats à l'utilisateur.

4. Analyse du code source

Cette section analysera le code source de HBase en détail. Tout d'abord, nous présenterons plusieurs modules importants dans HBase : HMaster, HRegionServer, HLog, WAL et Client. Ensuite, l'architecture de stockage de HBase est décrite en détail, le processus de stockage de HBase et le processus d'écriture de HBase sont introduits. Enfin, le processus de lecture/écriture de HBase et le mécanisme de verrouillage impliqué sont expliqués.

4.1 Présentation du module

4.1.1 HMaster

HMaster est le processus maître de HBase, qui est le contrôleur central de l'ensemble du cluster HBase. Ses principales responsabilités sont les suivantes :

  • Conservez les informations de métadonnées du cluster HBase, y compris l'emplacement de la table, l'état de la table, l'état du RegionServer, etc.
  • Traitez les demandes de lecture et d'écriture du client et acheminez les demandes vers le RegionServer correspondant.
  • Prendre des décisions sur les scissions et les fusions de régions.
  • Effectuez les modifications de configuration liées à HBase.
  • Gérer les services HBase.

4.1.2 Serveur HRégion

HRegionServer est un processus RegionServer de HBase. Ses principales responsabilités sont les suivantes :

  • Stockez les données dans des tables HBase.
  • Répondre aux demandes de lecture et d'écriture des clients.
  • Gérer la région.
  • Effectuez le basculement.

4.1.3 HLog

HLog est le fichier journal utilisé par HBase pour WAL (Write Ahead Log). Il s'agit du journal avancé lorsque les données HBase sont mises à jour. HLog a deux fonctions principales :

  • Persistance des données : lorsque le RegionServer tombe en panne, il peut récupérer les données via le journal WAL.
  • Récupération de panne : lorsque le RegionServer échoue, il peut récupérer les métadonnées via le journal WAL.

4.1.4 WAL

WAL (Write Ahead Log) est le journal avancé lorsque les données HBase sont mises à jour. WAL est un mécanisme qui garantit la persistance des données en écrivant d'abord les journaux, puis en vidant le disque. Lorsque RegionServer reçoit une demande de mise à jour des données, il écrit la mise à jour dans le fichier WAL avant de vider le disque. Si le RegionServer tombe en panne, il peut récupérer les données via les données du fichier WAL.

4.1.5 Client

Client est la bibliothèque client de HBase. Le client fournit les versions Java et Python de l'interface. Ses principales responsabilités sont les suivantes :

  • Encapsule l'interface client HBase.
  • Effectuer des opérations sur les données.

4.2 Architecture de stockage HBase

Les données dans HBase sont stockées sous la forme de RowKey et ColumnFamily:Qualifier. Parmi eux, RowKey est utilisé pour localiser les lignes, ColumnFamily est l'unité logique pour organiser les données et Qualifier est un élément de ColumnFamily. Les données HBase sont stockées sur RegionServer sous forme de tables. Une table se compose de plusieurs régions. La région est un tableau d'octets continu qui stocke un ensemble de lignes, chaque ligne étant constituée de plusieurs cellules. La cellule se compose de deux parties : valeur et horodatage. Value est la valeur de Cell et Timestamp est l’horodatage de la mise à jour de Cell. Chaque cellule possède un numéro de version correspondant. HBase utilise BlockCache pour mettre en cache le contenu des blocs (blocs de données) récemment consultés. BlockCache réduira le nombre d'accès HDFS et améliorera les performances.
Schéma de l'architecture de stockage HBase :

  • Une table (Table) peut contenir plusieurs régions.
  • Une région se compose de plusieurs StoreFiles et chaque StoreFile est une unité de stockage physique HBase.
  • Chaque StoreFile peut se trouver sur un disque local ou sur un système de stockage de données distant.
  • StoreFile contient une ou plusieurs familles de colonnes (ColumnFamily).
  • Chaque famille de colonnes se compose de plusieurs colonnes (Colonne).
  • Chaque cellule possède un numéro de version correspondant.

4.3 Processus de stockage

Lorsqu'un client lance une demande de lecture ou d'écriture de données, il vérifiera d'abord si le maître est sain. Le maître transmettra la demande au RegionServer correspondant. RegionServer trouvera la TableRegion correspondante en fonction du type de lecture et d'écriture demandé (lecture, écriture, analyse) et déterminera si la région existe ou est fermée. Si la région n'existe pas ou est fermée, RegionServer renverra un message d'erreur. Sinon, RegionServer effectue des opérations de lecture et d'écriture de données. S'il s'agit d'une opération d'écriture, RegionServer écrira les données dans WAL et conservera le WAL.
Le flux de traitement des opérations d'écriture est le suivant :

1.客户端将数据写入 WAL。
2.RegionServer 检查 WAL 文件是否写满。
3.如果 WAL 文件写满,RegionServer 将 WAL 文件滚动并生成一个新的 HLog 文件。
4.RegionServer 将数据写入 HDFS 的一个 StoreFile 中。
5.如果数据没有损坏,RegionServer 会更新内存中的数据,同时向 MemStore 写入一个 MemStoreSize。
6.如果 MemStoreSize 达到了阀值,RegionServer 会将 MemStore 中的数据写入 HDFS 的一个 MemStore 文件中。
7.RegionServer 会将 MemStore 文件滚动并生成一个新的 HFile 文件。
8.如果 MemStore 文件满了,RegionServer 会将 MemStore 文件滚动并生成一个新的 MemStore 文件。
9.RegionServer 返回客户端操作成功。

Le flux de traitement de l’opération de lecture est le suivant :

1.客户端发送请求到 RegionServer。
2.RegionServer 查找 MemStore 和 HFile 文件中是否有符合条件的数据。
3.如果 MemStore 和 HFile 文件中都没有数据,RegionServer 会向邻居节点请求数据。
4.如果邻居节点有数据,RegionServer 会将数据合并后返回给客户端。
5.客户端获取数据并返回。

Le flux de traitement de l’opération Scan est le suivant :

1.客户端发送 Scan 请求到 RegionServer。
2.RegionServer 获取 MemStore 和 HFile 文件中的数据。
3.RegionServer 对数据进行过滤、排序等操作。
4.RegionServer 返回过滤、排序后的结果给客户端。

4.4 Processus d'écriture

Organigramme d'écriture :
étapes détaillées de l'opération d'écriture :

  • Le client envoie une requête Put au Maître.
  • Le maître envoie une requête au RegionServer correspondant.
  • RegionServer vérifie si le fichier MemStore est plein.
  • Si le fichier MemStore est plein, RegionServer lance le fichier MemStore et génère un nouveau fichier MemStore.
  • RegionServer écrit des données dans MemStore.
  • RegionServer détermine si le fichier MemStore actuel est plein.
  • Si le fichier MemStore est plein, RegionServer lance le fichier MemStore et génère un nouveau fichier MemStore.
  • RegionServer génère un nouveau fichier Hlog et écrit les données dans le fichier Hlog.
  • RegionServer conserve les fichiers Hlog sur le disque.
  • Si l'opération d'écriture réussit, RegionServer écrit les données sur HDFS.

4.5 Processus de lecture et d'écriture

Organigramme de lecture et d'écriture :
étapes détaillées des opérations de lecture et d'écriture :

  • Le client envoie une requête Get/Put au maître.
  • Le maître envoie une requête au RegionServer correspondant.
  • RegionServer vérifie si le fichier MemStore contient des données et, si tel est le cas, renvoie les données directement.
  • Si le fichier MemStore ne contient aucune donnée, RegionServer vérifiera le fichier StoreFile dans HDFS, fusionnera les données et les renverra au client.
  • S'il n'y a aucune donnée correspondante, RegionServer renverra une exception Not Found au client.
  • Le client renvoie le résultat de la réponse.

4.6 Mécanisme de verrouillage

Afin d'éviter les conflits provoqués par plusieurs clients mettant à jour les mêmes données en même temps, HBase utilise le verrouillage optimiste et le verrouillage pessimiste.

  • Verrouillage pessimiste : le verrouillage pessimiste estime qu'un seul client peut mettre à jour les données à la fois. Chaque fois que le verrou est acquis, il vérifiera si les données actuelles ont été modifiées par d'autres clients.
  • Verrouillage optimiste : le verrouillage optimiste estime que le client n'entrera pas en conflit et compare le numéro de version des données à chaque fois qu'il tente de mettre à jour les données.
    Les mécanismes de verrouillage utilisés dans HBase sont les suivants :
  • Verrouillage global : Le verrouillage global est un type particulier de verrouillage pessimiste. Sa fonction est de contrôler l'accès simultané à l'ensemble du cluster HBase. Lorsqu'un client obtient un verrou global, les autres clients ne peuvent pas obtenir le verrou jusqu'à ce que le client actuel le libère.
  • Verrouillage au niveau des lignes : le verrouillage au niveau des lignes est un verrou pessimiste, sa fonction est de contrôler l'accès simultané aux lignes spécifiées.
  • Verrouillage au niveau de la famille de colonnes : le verrouillage au niveau de la famille de colonnes est un verrou pessimiste, sa fonction est de contrôler l'accès simultané à la famille de colonnes spécifiée.
  • Verrou personnalisé : un verrou personnalisé est un verrou pessimiste qui permet aux clients de spécifier eux-mêmes la granularité du verrouillage et permet à plusieurs clients de détenir des verrous avec des granularités différentes en même temps.

Résumer

Cet article fournit une présentation des fonctionnalités, des termes clés et de l'architecture de stockage de HBase. En analysant le code source de HBase, j'ai une compréhension approfondie des principes fonctionnels, des idées de conception, de la conception de l'architecture, du processus de stockage, du processus d'écriture, du processus de lecture et d'écriture et du mécanisme de verrouillage de HBase. J'espère que chacun pourra être inspiré par le processus d'apprentissage et être capable d'utiliser les connaissances acquises pour résoudre des problèmes pratiques dans son travail quotidien.

Je suppose que tu aimes

Origine blog.csdn.net/universsky2015/article/details/132158164
conseillé
Classement