Le modèle de compactage change radicalement avec CDH 5/HBase 0.96. Voici ce que vous devez savoir.
Apache HBase est un magasin de données distribué basé sur une arborescence de fusion structurée en journaux, de sorte que les performances de lecture optimales proviendraient d'un seul fichier par magasin (Column Family). Cependant, cet idéal n'est pas possible pendant les périodes de fortes écritures entrantes. Au lieu de cela, HBase essaiera de combiner HFiles pour réduire le nombre maximum de recherches de disque nécessaires pour une lecture. Ce processus est appelé compactage .
Les compactions choisissent des fichiers dans un seul magasin d'une région et les combinent. Ce processus implique la lecture de KeyValues dans les fichiers d'entrée et l'écriture de toutes les KeyValues qui ne sont pas supprimées, sont à l'intérieur de la durée de vie (TTL) et ne violent pas le nombre de versions. Le fichier combiné nouvellement créé remplace alors les fichiers d'entrée dans la région.
Désormais, chaque fois qu'un client demande des données, HBase sait que les données des fichiers d'entrée sont conservées dans un fichier contigu sur le disque. Par conséquent, une seule recherche est nécessaire, alors qu'auparavant une recherche pour chaque fichier pouvait être nécessaire. Mais les E/S de disque ne sont pas gratuites, et sans une attention particulière, la réécriture répétée des données peut entraîner une sursouscription grave du réseau et du disque. En d'autres termes, le compactage consiste à échanger certaines E/S de disque maintenant contre moins de recherches ultérieures.
Dans cet article, vous en apprendrez plus sur l'utilisation et les implications des compactages dans CDH 4, ainsi que sur les modifications apportées au modèle de compactage dans CDH 5 (qui sera rebasé sur HBase 0.96).
Compaction en CDH 4
Le compactage idéal sélectionnerait les fichiers qui réduiront le plus les recherches lors des lectures à venir tout en choisissant les fichiers qui nécessiteront le moins d'E/S. Malheureusement, ce problème ne peut être résolu sans connaissance de l'avenir. En tant que tel, c'est juste un idéal que HBase devrait viser et non quelque chose qui est vraiment réalisable.
Au lieu de l'idéal impossible, HBase utilise une heuristique pour essayer de choisir quels fichiers dans un magasin sont susceptibles d'être de bons candidats. Les fichiers sont choisis sur l'intuition que les fichiers similaires doivent être combinés avec des fichiers similaires - ce qui signifie que les fichiers qui ont à peu près la même taille doivent être combinés.
La politique par défaut dans HBase 0.94 (livrée dans CDH 4) parcourt la liste des HFiles, en essayant de trouver le premier fichier dont la taille est inférieure au total de tous les fichiers multiplié par hbase.store.compaction.ratio. Une fois ce fichier trouvé, le HFile et tous les fichiers avec des identifiants de séquence plus petits sont choisis pour être compactés.
Pour le cas par défaut où les fichiers les plus volumineux sont les plus anciens, cette approche fonctionne bien :
Cependant, cette hypothèse sur la corrélation entre l'âge et la taille des fichiers est erronée dans certains cas, ce qui conduit l'algorithme actuel à choisir de manière sous-optimale. Au lieu de cela, les fichiers chargés en bloc peuvent et parfois sont triés très différemment des fichiers HFiles plus normalement vidés, ils constituent donc d'excellents exemples :
Changements de compactage dans CDH 5
Les compactages ont changé de manière significative ces derniers temps. Pour HBase 0.96 et CDH 5, l'algorithme de sélection de fichiers a été rendu configurable via HBASE-7516, il est donc désormais possible d'avoir des politiques de compactage fournies par l'utilisateur. Ce changement permet aux utilisateurs plus expérimentés de tester et d'itérer sur la façon dont ils souhaitent exécuter les compactages.
L'algorithme de sélection de compactage par défaut a également été remplacé par ExploringCompactionPolicy. Cette politique est différente de l'ancienne règle par défaut en ce sens qu'elle garantit que chaque fichier d'un compactage proposé respecte le ratio donné. De plus, il ne se contente pas de choisir le premier ensemble de fichiers dont la taille correspond au taux de compactage ; au lieu de cela, il examine tous les ensembles possibles qui ne violent aucune règle, puis choisit quelque chose qui semble avoir le plus d'impact pour le moins d'E/S attendu. Pour ce faire, ExploringCompactionPolicy choisit un compactage qui supprimera le plus de fichiers dans le ratio, et s'il y a égalité, la préférence est donnée à l'ensemble de fichiers dont la taille est inférieure :
D'autres modifications sont prévues pour les futures versions, notamment le compactage par niveaux, le compactage par bandes et le compactage par niveau.
Conclusion
Pour certains cas d'utilisation, ce travail n'aura aucun impact. C'est une bonne chose, car les compactages étaient déjà assez bien étudiés. Cependant, pour les utilisateurs qui ont des pics de trafic importants ou qui utilisent des chargements en masse, ce travail peut apporter de grandes améliorations dans les temps d'attente d'E/S et dans la latence des demandes. Pour un cas d'utilisation spécifique de chargement en bloc, nous avons constaté une réduction de 90 % des E/S de disque en raison des compactages.
Voici les résultats d'un cas de test dans PerfTestCompactionPolicies de HBase :
Découvrez ce travail dans CDH 5 (en version bêta au moment d'écrire ces lignes) lorsqu'il s'agit d'un cluster près de chez vous.
Autres lectures :
- Exploration de la politique de compactage
- https://hbase.apache.org/book/regions.arch.html#compaction.file.selection
- https://issues.apache.org/jira/browse/HBASE-7516
- https://issues.apache.org/jira/browse/HBASE-7678
- https://issues.apache.org/jira/browse/HBASE-7667
- https://issues.apache.org/jira/browse/HBASE-7055
- http://www.hbasecon.com/sessions/compaction-improvements-in-apache-hbase/
