Apache HBase est la base de données Hadoop, et est basée sur le système de fichiers distribués Hadoop (HDFS ). HBase permet d'accéder et de mettre à jour de manière aléatoire les données stockées dans HDFS, mais les fichiers dans HDFS ne peuvent être ajoutés et sont immuables qu'après leur création. Alors vous vous demandez peut-être comment HBase fournit des lectures et des écritures à faible latence ? Dans cet article de blog, nous expliquons cela en décrivant le chemin d'écriture de HBase - comment les données sont mises à jour dans HBase.
Le chemin d'écriture est la façon dont une HBase effectue les opérations d'insertion ou de suppression. Ce chemin commence au niveau d'un client, se déplace vers un serveur de région et se termine lorsque les données sont finalement écrites dans un fichier de données HBase appelé HFile . La conception du chemin d'écriture comprend des fonctionnalités utilisées par HBase pour empêcher la perte de données en cas de défaillance d'un serveur de région. Par conséquent, la compréhension du chemin d'écriture peut donner un aperçu du mécanisme natif de prévention des pertes de données de HBase.
Chaque table HBase est hébergée et gérée par des ensembles de serveurs répartis en trois catégories :
- Un serveur maître actif
- Un ou plusieurs serveurs maîtres de sauvegarde
- De nombreux serveurs régionaux
Les serveurs de région contribuent à la gestion des tables HBase. Étant donné que les tables HBase peuvent être volumineuses, elles sont divisées en partitions appelées régions. Chaque serveur de région gère une ou plusieurs de ces régions. Notez que, comme les serveurs de région sont les seuls serveurs qui servent les données de la table HBase, une panne du serveur maître ne peut pas entraîner de perte de données.
Les données HBase sont organisées de la même manière qu'une carte triée, l'espace de clé trié étant partitionné en différentes partitions ou régions. Un client HBase met à jour une table en appelant des commandes put ou delete. Lorsqu'un client demande une modification, cette demande est immédiatement acheminée vers un serveur de région par défaut. Cependant, par programmation, un client peut mettre en cache les modifications du côté client et vider ces modifications sur les serveurs de région dans un lot, en désactivant le rinçage automatique. Si le rinçage automatique est désactivé, les modifications sont mises en cache jusqu'à ce que flush-commits soit appelé, ou le tampon est plein en fonction de la taille du tampon définie par programme ou configurée avec le paramètre "hbase.client.write.buffer".
Étant donné que la clé de ligne est triée, il est facile de déterminer quel serveur de région gère quelle clé. Une demande de modification concerne une ligne spécifique. Chaque clé de ligne appartient à une région spécifique qui est desservie par un serveur de région. Ainsi, en fonction de la clé put ou delete, un client HBase peut localiser un serveur de région approprié. Dans un premier temps, il localise l'adresse du serveur de région hébergeant la région -ROOT- à partir du quorum ZooKeeper. A partir du serveur de région racine, le client trouve l'emplacement du serveur de région hébergeant la région -META-. À partir du serveur de méta-région, nous localisons enfin le serveur de région réel qui dessert la région demandée. Il s'agit d'un processus en trois étapes, de sorte que l'emplacement de la région est mis en cache pour éviter cette série d'opérations coûteuses. Si l'emplacement mis en cache n'est pas valide (par exemple, nous obtenons une exception de région inconnue), il est temps de relocaliser la région et de mettre à jour le cache.
Une fois la demande reçue par le bon serveur de région, la modification ne peut pas être écrite immédiatement dans un HFile, car les données d'un HFile doivent être triées par clé de ligne. Cela permet de rechercher efficacement des lignes aléatoires lors de la lecture des données. Les données ne peuvent pas être insérées de manière aléatoire dans le HFile. Au lieu de cela, la modification doit être écrite dans un nouveau fichier. Si chaque mise à jour était écrite dans un fichier, de nombreux petits fichiers seraient créés. Une telle solution ne serait ni évolutive ni efficace pour fusionner ou lire ultérieurement. Par conséquent, les modifications ne sont pas immédiatement écrites dans un nouveau HFile.
Au lieu de cela, chaque modification est stockée dans un endroit de la mémoire appelé memstore , qui prend en charge les écritures aléatoires de manière économique et efficace. Les données du magasin de mémoire sont triées de la même manière que les données d'un HFile. Lorsque le magasin de mémoire accumule suffisamment de données, l'ensemble trié complet est écrit dans un nouveau HFile dans HDFS. L'exécution d'une tâche d'écriture volumineuse est efficace et tire parti des atouts de HDFS.
Bien que l'écriture de données dans le memstore soit efficace, elle introduit également un élément de risque :les informations stockées dans le memstore sont stockées dans une mémoire volatile, donc si le système tombe en panne, toutes les informations du memstore sont perdues. Pour aider à atténuer ce risque, HBase enregistre les mises à jour dans un journal à écriture anticipée (WAL ) avant d'écrire les informations dans memstore. De cette manière, si un serveur de région tombe en panne, les informations stockées dans le magasin de mémoire de ce serveur peuvent être récupérées à partir de son WAL.
Remarque :Par défaut, WAL est activé, mais le processus d'écriture du fichier WAL sur le disque consomme certaines ressources. WAL peut être désactivé, mais cela ne devrait être fait que si le risque de perte de données n'est pas un problème. Si vous choisissez de désactiver WAL, envisagez d'implémenter votre propre solution de reprise après sinistre ou préparez-vous à la possibilité de perte de données.
Les données d'un fichier WAL sont organisées différemment de HFile. Les fichiers WAL contiennent une liste d'éditions, une édition représentant un seul ajout ou suppression. La modification inclut des informations sur la modification et la région à laquelle la modification s'applique. Les modifications sont écrites chronologiquement, donc, pour la persistance, les ajouts sont ajoutés à la fin du fichier WAL qui est stocké sur le disque. Parce que les fichiers WAL sont classés par ordre chronologique, il n'est jamais nécessaire d'écrire à un endroit aléatoire dans le fichier.
Au fur et à mesure que les WAL grandissent, ils sont finalement fermés et un nouveau fichier WAL actif est créé pour accepter des modifications supplémentaires. C'est ce qu'on appelle « rouler » le fichier WAL. Une fois qu'un fichier WAL est lancé, aucune modification supplémentaire n'est apportée à l'ancien fichier.
Par défaut, le fichier WAL est roulé lorsque sa taille est d'environ 95 % de la taille du bloc HDFS. Vous pouvez configurer le multiplicateur à l'aide du paramètre :"hbase.regionserver.logroll.multiplier" et la taille du bloc à l'aide du paramètre :"hbase.regionserver.hlog.blocksize". Le fichier WAL est également roulé périodiquement en fonction de l'intervalle configuré "hbase.regionserver.logroll.period", une heure par défaut, même la taille du fichier WAL est inférieure à la limite configurée.
La limitation de la taille des fichiers WAL facilite la relecture efficace des fichiers si une récupération est nécessaire. Ceci est particulièrement important lors de la relecture du fichier WAL d'une région car pendant la relecture d'un fichier, la région correspondante n'est pas disponible. L'intention est d'écrire éventuellement toutes les modifications de chaque fichier WAL sur le disque et de conserver ce contenu dans un HFile. Après cela, le fichier WAL peut être archivé et il est finalement supprimé par le thread démon LogCleaner. Notez que les fichiers WAL servent de mesure de protection. Les fichiers WAL n'ont besoin d'être relus que pour récupérer les mises à jour qui seraient autrement perdues après un plantage du serveur de région.
Un serveur de région dessert de nombreuses régions, mais n'a pas de fichier WAL pour chaque région. Au lieu de cela, un fichier WAL actif est partagé entre toutes les régions desservies par le serveur de région. Étant donné que les fichiers WAL sont remplacés périodiquement, un serveur de région peut avoir plusieurs fichiers WAL. Notez qu'il n'y a qu'un seul WAL actif par serveur de région à un moment donné.
En supposant que la racine HBase par défaut est "/hbase", tous les fichiers WAL d'une instance de serveur de région sont stockés dans le même dossier racine, qui est le suivant :
/hbase/.logs/<host>, <port>,<startcode>
Par exemple :
/hbase/.logs/srv.example.com,60020,1254173957298
Les fichiers journaux WAL sont nommés comme suit :
/hbase/.logs/<host>, <port>,<startcode>/<host>%2C <port>%2C<startcode>.<timestamp>
Par exemple :
/hbase/.logs/srv.example.com,60020,1254173957298/srv.example.com%2C60020%2C1254173957298.1254173957495
Chaque modification dans le fichier WAL a un identifiant de séquence unique. Cet identifiant augmente pour préserver l'ordre des modifications. Chaque fois qu'un fichier journal est lancé, l'identifiant de séquence suivant et l'ancien nom de fichier sont placés dans une carte en mémoire. Ces informations sont utilisées pour suivre l'identifiant de séquence maximum de chaque fichier WAL afin que nous puissions facilement déterminer si un fichier peut être archivé ultérieurement lorsqu'un memstore est vidé sur le disque.
Les modifications et leurs identifiants de séquence sont uniques dans une région. Chaque fois qu'une édition est ajoutée au journal WAL, l'identifiant de séquence de l'édition est également enregistré en tant que dernier identifiant de séquence écrit. Lorsque le magasin de mémoire est vidé sur le disque, le dernier identifiant de séquence écrit pour cette région est effacé. Si le dernier identifiant de séquence écrit sur le disque est le même que l'identifiant de séquence maximal d'un fichier WAL, on peut en conclure que toutes les modifications d'un fichier WAL pour cette région ont été écrites sur le disque. Si toutes les modifications pour toutes les régions d'un fichier WAL ont été écrites sur le disque, il est clair qu'aucune division ou relecture ne sera nécessaire, et le fichier WAL peut être archivé.
Le roulement de fichier WAL et le vidage de mémoire sont deux actions distinctes et ne doivent pas nécessairement se produire ensemble. Cependant, nous ne voulons pas conserver trop de fichiers WAL par serveur de région afin d'éviter une récupération fastidieuse en cas de défaillance d'un serveur de région. Par conséquent, lorsqu'un fichier WAL est roulé, HBase vérifie s'il y a trop de fichiers WAL et décide quelles régions doivent être vidées afin que certains fichiers WAL puissent être archivés.
Dans cet article, nous expliquons le chemin d'écriture HBase, qui est la façon dont les données dans HBase sont créées et/ou mises à jour. Certaines parties importantes de celui-ci sont :
- Comment un client localise un serveur de région,
- Memstore qui prend en charge les écritures aléatoires rapides,
- Les fichiers WAL comme moyen d'éviter la perte de données en cas de défaillance du serveur de région.
Nous parlerons des formats HFile, du fractionnement de fichiers WAL, etc. dans les articles suivants.
