Chapitre 1 Introduction à HBase
1.1 Définition de la HBase
HBase est une base de données NoSQL distribuée et évolutive qui prend en charge un stockage de données massif.
Modèle de données 1.2HBase
Logiquement, le modèle de données de HBase est très similaire à celui d'une base de données relationnelle. Les données sont stockées dans une table avec des lignes et des colonnes. Mais du point de vue de la structure de stockage physique (KV) sous-jacente de HBase, HBase ressemble plus à une carte multidimensionnelle.
1.2.1 Structure logique HBase
1.2.2 Structure de stockage physique HBase
1.2.3 Modèle de données
1) L'espace de noms est similaire au concept de DatabBase dans les bases de données relationnelles. Il y a plusieurs tables sous chaque espace de noms. HBase possède deux espaces de noms intégrés, hbase et default. HBase stocke les tables HBase intégrées et la table par défaut est l'espace de noms utilisé par défaut par l'utilisateur.
2) La région est similaire au concept de table d'une base de données relationnelle. La différence est que HBase n'a besoin de déclarer la famille de colonnes que lors de la définition de la table et qu'il n'est pas nécessaire de déclarer des colonnes spécifiques. Cela signifie que lors de l'écriture de données dans HBase, les champs peuvent être spécifiés dynamiquement et à la demande. Par conséquent, par rapport aux bases de données relationnelles, HBase peut facilement faire face aux changements de champ.
3) Chaque ligne de données de la table Row HBase se compose d'une RowKey et de plusieurs colonnes. Les données sont stockées dans l'ordre lexicographique de la RowKey et ne peuvent être extraites qu'en fonction de la RowKey lors de l'interrogation des données. RowKey est très important.
4) Chaque colonne de la colonne HBase est qualifiée par ColumnFamily (famille de colonnes) et ColumnQualifier (qualificatif de colonne), comme info: nom, info: âge. Lors de la création d'une table, il vous suffit de spécifier la famille de colonnes et le qualificatif de colonne n'a pas besoin d'être défini à l'avance.
5) L'horodatage est utilisé pour identifier différentes versions de données. Lorsque chaque élément de données est écrit, si vous ne spécifiez pas d'horodatage, le système y ajoute automatiquement ce champ, et sa valeur est l'heure à laquelle il a été écrit. HBase.
6) Cell La cellule est uniquement déterminée par {rowkey, columnFamily: columnQualifier, timeStamp}. Les données de la cellule n'ont pas de type et sont toutes stockées au format bytecode.
1.3 Architecture de base HBase
incomplet!
Rôle architectural:
1) Region Server RegionServer est le gestionnaire de la région, et sa classe d'implémentation est HRegionServer. Ses principales fonctions sont les suivantes: opérations sur les données: obtenir, mettre, supprimer; opérations sur les régions: splitRegion, compactRegion.
2) Master Master est le gestionnaire de tous les RegionServers, et sa classe d'implémentation est HMaster. Ses principales fonctions sont les suivantes: Pour les opérations de table: créer, supprimer, modifier Pour les opérations RegionServer: Attribuer des régions à chaque RegionServer, surveiller l'état de chaque RegionServer , Équilibrage de charge et basculement.
3) Zookeeper HBase utilise Zookeeper pour assurer la haute disponibilité du Master, la surveillance du RegionServer, la saisie des métadonnées et la maintenance de la configuration du cluster.
4) HDFS HDFS fournit le service de stockage de données sous-jacent ultime pour HBase, et en même temps fournit une prise en charge haute disponibilité pour HBase.
Chapitre 2 Démarrage rapide de HBase
2.1 Installation et déploiement de HBase
Peut se référer à mon blog:
Installation et configuration de la plateforme Big Data - HBase
Conseil: si le temps de nœud entre les clusters n'est pas synchronisé, le serveur de régions ne peut pas être démarré et une exception ClockOutOfSyncException sera émise.
2.2 Fonctionnement HBaseShell
2.2.1 Fonctionnement de base
1. Entrez la ligne de commande du client HBase
[root@m1 bin]# hbase shell2. Afficher les commandes d'aide
hbase(main):001:0> help3. Afficher les tables de la base de données actuelle
hbase(main):002:0> list
2.2.2 Fonctionnement de la table
Peut se référer à mon blog:
Chapitre 3 HBase Advanced
3.1 Principe d'architecture
1) StoreFile stocke les fichiers physiques des données réelles StoreFile est stocké sur HDFS sous la forme de HFile. Chaque magasin a un ou plusieurs StoreFiles (HFile) et les données sont classées dans chaque StoreFile.
2) Cache d'écriture MemStore. Étant donné que les données dans HFile doivent être triées, les données sont d'abord stockées dans MemStore. Après le tri, elles seront flashées dans HFile lorsque le temps de clignotement est atteint. Chaque clignotement formera un Le nouveau HFile.
3) Les données WAL doivent être triées par MemStore avant d'être vidées dans HFile, mais le stockage des données dans la mémoire a une forte probabilité de provoquer une perte de données. Afin de résoudre ce problème, les données seront écrites dans un fichier appelé Write-Ahead fichier journal, puis écrivez dans MemStore. Ainsi, lorsque le système tombe en panne, les données peuvent être reconstruites via ce fichier journal.
3.2 Processus d'écriture
Processus d'écriture:
1) Le client accède d'abord à zookeeper pour obtenir le RegionServer où se trouve la table hbase: meta.
2) Accédez au serveur de région correspondant, obtenez la table hbase: meta et interrogez la région dans laquelle RegionServer les données cibles se trouvent en fonction de l'espace de noms: table / rowkey de la demande de lecture. Les informations de région de la table et les informations de localisation de la méta-table sont mises en cache dans la méta-cache du client pour faciliter l'accès suivant.
3) Communiquer avec le RegionServer cible;
4) Ecrire (ajouter) des données séquentiellement dans WAL;
5) Écrivez les données dans le MemStore correspondant, et les données seront triées dans le MemStore;
6) Envoyez un accusé de réception au client;
7) Après avoir atteint le temps de clignotement de MemStore, flashez les données dans HFile.
3.3MemStoreFlush
Synchronisation du flash MemStore:
1. Lorsque la taille d'un memstroe atteint hbase.hregion.memstore.flush.size (la valeur par défaut est 128 Mo), tous les memstores de la région seront vidés. Lorsque la taille du memstore atteint hbase.hregion.memstore.flush.size (valeur par défaut 128M) * hbase.hregion.memstore.block.multiplier (valeur par défaut 4), cela empêchera d'écrire des données dans le memstore.
2. Lorsque la taille totale du magasin de mémoire dans le serveur de région atteint java_heapsize * hbase.regionserver.global.memstore.size (valeur par défaut 0,4) * hbase.regionserver.global.memstore.size.lower.limit (valeur par défaut 0,95), le region will follow Tous les memstores sont flashés par ordre de taille (du grand au petit). Jusqu'à ce que la taille totale de tous les magasins de mémoire du serveur de région soit réduite en dessous de la valeur ci-dessus. Lorsque la taille totale du magasin de mémoire dans le serveur de région atteint java_heapsize * hbase.regionserver.global.memstore.size (la valeur par défaut est 0,4), cela empêchera de continuer à écrire des données dans tous les magasins de mémoire.
3. Lorsque l'heure du clignotement automatique est atteinte, le memstoreflush est également déclenché. L'intervalle d'actualisation automatique est configuré par cette propriété hbase.regionserver.optionalcacheflushinterval (la valeur par défaut est 1 heure).
4. Lorsque le nombre de fichiers WAL dépasse hbase.regionserver.max.logs, la région sera vidée dans l'ordre chronologique jusqu'à ce que le nombre de fichiers WAL soit réduit à hbase.regionserver.max.log (ce nom d'attribut est obsolète et non plus nécessaire Réglé manuellement, la valeur maximale est 32).
3.4 Processus de lecture
Processus de lecture
1) Le client accède d'abord à zookeeper pour obtenir le RegionServer où se trouve la table hbase: meta.
2) Accédez au serveur de région correspondant, obtenez la table hbase: meta et interrogez la région dans laquelle RegionServer les données cibles se trouvent en fonction de l'espace de noms: table / rowkey de la demande de lecture. Les informations de région de la table et les informations de localisation de la méta-table sont mises en cache dans la méta-cache du client pour faciliter l'accès suivant.
3) Communiquer avec le RegionServer cible;
4) Interrogez les données cibles dans BlockCache (cache de lecture), MemStore et StoreFile (HFile) respectivement, et fusionnez toutes les données trouvées. Toutes les données ici se réfèrent à différentes versions (horodatage) ou à différents types (Put / Delete) du même élément de données.
5) Mettez en cache le bloc de données (bloc, unité de stockage de données HFile, la taille par défaut est de 64 Ko) interrogé du fichier vers BlockCache.
6) Renvoyez le résultat final combiné au client.
3.5StoreFileCompaction
Comme memstore génère un nouveau HFile à chaque fois qu'il est flashé, et que différentes versions (horodatage) et différents types (Put / Delete) du même champ peuvent être distribués dans différents HFiles, il est nécessaire de parcourir tous les HFiles lors de l'interrogation.
Afin de réduire le nombre de fichiers HFiles et de nettoyer les données expirées et supprimées, StoreFileCompaction sera exécuté. Le compactage est divisé en deux types, à savoir MinorCompaction et MajorCompaction. MinorCompaction fusionnera plusieurs HFiles plus petits adjacents en un seul HFile plus grand, mais ne nettoiera pas les données expirées et supprimées. MajorCompaction fusionnera tous les HFiles d'un magasin en un seul grand HFile et nettoiera les données expirées et supprimées.
StoreFile Compaction：
3.6 Division de la région
Par défaut, chaque table n'a qu'une seule région au début. Au fur et à mesure que les données sont écrites en continu, la région sera scindée automatiquement. Lors du fractionnement, les deux sous-régions sont situées dans le RegionServer actuel, mais pour des considérations d'équilibrage de charge, HMaster peut transférer une région vers un autre RegionServer.
Calendrier de RegionSplit:
1. Lorsque la taille totale de tous les StoreFiles sous un Store dans une région dépasse hbase.hregion.max.filesize, la région sera fractionnée (avant la version 0.94).
2. Lorsque la taille totale de tous les StoreFiles d'un Store dans une région dépasse Min (R ^ 2 * "hbase.hregion.memstore.flush.size", hbase.hregion.max.filesize "), la région se divise, où R est le numéro de la table dans le RegionServer actuel (après la version 0.94).
Région Split：
Chapitre 4 HBaseAPI
À suivre