Cloudera Data Platform (CDP) fournit une solution prête à l'emploi qui permet aux déploiements Apache HBase d'utiliser Amazon Simple Storage Service (S3) comme couche de persistance principale pour enregistrer les données des tables. Amazon S3 est un magasin d'objets qui offre un haut degré de durabilité avec une structure de coût à l'utilisation. Il n'y a aucun composant côté serveur à exécuter ou à gérer pour S3 - tout ce qui est nécessaire est la bibliothèque cliente S3 et les informations d'identification AWS. Cependant, HBase nécessite un système de fichiers cohérent et atomique, ce qui signifie qu'il ne peut pas utiliser directement S3 car il s'agit d'un magasin d'objets cohérent à terme. CDH et HDP n'ont fourni HBase qu'en utilisant uniquement HDFS, car il existe des obstacles de longue date qui empêchent HBase d'utiliser nativement S3. Pour résoudre ces problèmes, nous avons créé une solution prête à l'emploi que nous proposons pour la première fois via CDP. Lorsque vous lancez un cluster de base de données opérationnelle (HBase) sur CDP, HBase StoreFiles (les fichiers de sauvegarde des tables HBase) sont stockés dans S3 et les journaux d'écriture anticipée HBase (WAL) sont stockés dans une instance HDFS exécutée avec HBase comme d'habitude.
Nous décrirons brièvement chaque composant qui entre dans cette architecture et le rôle que chacun remplit.
L'adaptateur de système de fichiers S3A est fourni par Hadoop pour accéder aux données dans S3 via les API FileSystem standard. L'adaptateur S3A permet aux applications écrites sur les API Hadoop d'accéder aux données dans S3 en utilisant un URI de la forme "s3a://my_bucket/" au lieu de "hdfs://namenode:8020/" comme avec HDFS. La possibilité de spécifier un « système de fichiers » par défaut à utiliser rend extrêmement simples les migrations de type « lift-and-shift » des clusters sur site avec HDFS vers des clusters basés sur le cloud avec S3. HBase peut être configuré avec un emplacement de stockage de base (par exemple, un répertoire dans HDFS ou un compartiment S3) pour toutes les données d'application, ce qui permet à HBase de fonctionner de la même manière, que ces données soient dans HDFS ou S3.
S3Guard fait partie du projet Apache Hadoop qui fournit une liste de répertoires et un statut d'objet cohérents pour l'adaptateur S3A, transparents pour l'application. Pour ce faire, S3Guard utilise une base de données cohérente et distribuée pour suivre les modifications apportées à S3 et garantit qu'un client voit toujours l'état correct de S3. Sans S3Guard, HBase peut ne pas voir un nouveau StoreFile qui a été ajouté à une table HBase. Si HBase, même temporairement, n'a pas observé un fichier, cela pourrait entraîner une perte de données dans HBase. Cependant, S3guard ne fournit pas tout ce dont HBase a besoin pour utiliser S3.
HBase Object Store Semantics (ou simplement "HBOSS") est un nouveau projet logiciel dans le cadre du projet Apache HBase spécialement conçu pour combler le fossé entre S3Guard et HBase. HBOSS est une façade au-dessus de l'adaptateur S3A et de S3Guard qui utilise un verrou distribué pour garantir que les opérations HBase peuvent atomiquement manipuler ses fichiers sur S3. Un exemple où HBase nécessite l'atomicité est un changement de nom de répertoire. Avec le client S3, un changement de nom est mis en œuvre sous la forme d'une copie des données source vers la destination, suivie d'une suppression des données source. Sans le verrouillage fourni par HBOSS, HBase peut voir l'opération de changement de nom en cours, ce qui peut entraîner une perte de données. Pour réaliser ce verrouillage distribué, HBOSS utilise Apache ZooKeeper. La réutilisation de ZooKeeper est intentionnelle puisque HBase nécessite déjà une instance de ZooKeeper pour garantir que tous les services HBase fonctionnent ensemble. Ainsi, l'intégration de HBOSS ne nécessite aucune charge de gestion de service supplémentaire et comble l'écart sur ce dont HBase a besoin pour utiliser S3 avec S3Guard.
La configuration de HBase pour utiliser S3 pour ses StoreFiles présente de nombreux avantages pour nos utilisateurs. L'un de ces avantages est que les utilisateurs peuvent découpler leur stockage et leur calcul. S'il y a des moments où aucun accès à HBase n'est nécessaire, HBase peut être arrêté proprement et toutes les ressources de calcul récupérées pour éliminer tout coût de fonctionnement. Lorsque l'accès à HBase est à nouveau nécessaire, le cluster HBase peut être recréé, pointant vers les mêmes données dans S3. Au démarrage, HBase peut se réinitialiser uniquement à partir des données de S3.
L'utilisation de S3 pour stocker HBase StoreFiles présente certains défis. L'un de ces problèmes est la latence accrue pour une recherche aléatoire d'un fichier dans S3 par rapport à HDFS. Une latence accrue dans l'accès S3 entraînerait un temps d'obtention et d'analyse HBase plus long qu'il ne le faudrait normalement avec HDFS. Les latences S3 varient de 10 à 100 millisecondes par rapport à la plage de 0,1 à 9 millisecondes avec HDFS. CDP peut réduire l'impact de cette latence S3 en configurant automatiquement HBase pour utiliser le BucketCache. Lorsque le BucketCache est activé, les latences S3 ne sont rencontrées que la première fois qu'un StoreFile est lu à partir de S3. Une fois que HBase a lu un fichier, il essaie de mettre en cache les données brutes pour remplacer les lectures S3 lentes par des lectures rapides de la mémoire locale. Lorsqu'un cluster HBase est lancé via CDP, il est automatiquement configuré pour mettre en cache les données récemment lues à partir de S3 en mémoire afin de fournir des lectures plus rapides des données "chaudes".
Nous sommes extrêmement heureux de fournir ces nouvelles fonctionnalités à nos utilisateurs. Essayez dès aujourd'hui HBase exécuté sur S3 dans le modèle de base de données opérationnelle de CDP !
