Activation de HBase sur Amazon S3 Utilisation d'un cluster réplica en lecture Suivi permanent des fichiers Considérations opérationnelles

HBase sur Amazon S3 (mode de stockage Amazon S3)

Lorsque vous exécutez HBase sur Amazon EMR version 5.2.0 ou ultérieure, vous pouvez activer HBase sur Amazon S3, ce qui offre les avantages suivants :

Le répertoire racine HBase est stocké dans Amazon S3, comprenant les fichiers de stockage HBase et les métadonnées de table. Ces données sont persistantes en dehors du cluster, et disponibles dans les zones de disponibilité Amazon EC2, vous n'avez pas besoin de les récupérer à l'aide d'instantanés ou d'autres méthodes.
Avec des fichiers de stockage dans Amazon S3, vous pouvez dimensionner votre cluster Amazon EMR plutôt en fonction de vos besoins de calcul qu'en fonction de vos besoins de données, avec une réplication x3 dans HDFS.
En utilisant une version 5.7.0 ou ultérieure d'Amazon EMR, vous pouvez définir un cluster de réplica en lecture, ce qui vous permet de conserver des copies en lecture seule de données dans Amazon S3. Vous pouvez accéder aux données à partir du cluster de réplica en lecture pour réaliser des opérations de lecture simultanément et, dans le cas ou le cluster principal devient indisponible.
Dans Amazon EMR version 6.2.0 et versions ultérieures, le suivi HFile persistant utilise une table système HBase appelée hbase:storefile pour suivre directement les chemins HFile utilisés pour les opérations de lecture. Cette fonctionnalité est activée par défaut et ne nécessite pas de migration manuelle.

L'illustration suivante présente les composants HBase adaptés à HBase dans Amazon S3.

Activation de HBase sur Amazon S3

Vous pouvez activer HBase sur Amazon S3 à l'aide de la console Amazon EMR, de l'AWS CLI ou de l'API Amazon EMR. La configuration est une option lors de la création du cluster. Lorsque vous utilisez la console, vous choisissez le paramètre à l'aide des Advanced options (Options avancées). Lorsque vous utilisez l'AWS CLI, utilisez l'option --configurations pour fournir un objet de configuration JSON. Les propriétés de l'objet de configuration précisent le mode de stockage et l'emplacement du répertoire racine dans Amazon S3. L'emplacement Amazon S3 que vous spécifiez doit être dans la même région que votre cluster Amazon EMR. Un seul cluster actif à la fois peut utiliser le même répertoire racine HBase dans Amazon S3. Pour les étapes de la console et un exemple create-cluster détaillé à l'aide de l'AWS CLI, consultez Création d'un cluster avec HBase. Un exemple d'objet de configuration apparaît dans l'extrait JSON suivant.



{
  "Classification": "hbase-site",
  "Properties": {
    "hbase.rootdir": "s3://my-bucket/my-hbase-rootdir"}
},
{
  "Classification": "hbase",
  "Properties": {
  "hbase.emr.storageMode":"s3"
  }
}

Note

Si vous utilisez un compartiment Amazon S3 comme rootdir pour HBase, vous devez ajouter une barre oblique à la fin de l'URI Amazon S3. Par exemple, vous devez utiliser "hbase.rootdir: s3://my-bucket/", au lieu de "hbase.rootdir: s3://my-bucket", pour éviter les problèmes.

Utilisation d'un cluster réplica en lecture

Après avoir défini un cluster principal en utilisant HBase sur Amazon S3, vous pouvez créer et configurer un cluster de réplica en lecture fournissant un accès en lecture seule aux mêmes données en tant que cluster principal. Cela est utile lorsque vous avez besoin d'un accès simultané à des données de requête ou d'un accès ininterrompu si le cluster principal devient indisponible. La fonctionnalité de réplica en lecture est disponible avec Amazon EMR version 5.7.0 et ultérieure.

Le cluster principal et le cluster de réplica en lecture sont définis de la même façon avec une différence significative. Les deux pointent le même emplacement hbase.rootdir. Cependant, la classification hbase pour le cluster de réplica en lecture comprend la propriété "hbase.emr.readreplica.enabled":"true".

Par exemple, étant donné la classification JSON pour le cluster principal comme précédemment montré dans la rubrique, la configuration pour un cluster de réplica en lecture est comme suit :



{
  "Classification": "hbase-site",
  "Properties": {
    "hbase.rootdir": "s3://my-bucket/my-hbase-rootdir"}
},
{
  "Classification": "hbase",
  "Properties": {
  "hbase.emr.storageMode":"s3",
  "hbase.emr.readreplica.enabled":"true"
  }
}

Synchronisation de réplica en lecture lors d'ajout de données

Comme le réplica en lecture utilise les StoreFiles et les métadonnées HBase que le cluster principal écrit sur Amazon S3, le réplica en lecture est seulement aussi courant que le stockage de données Amazon S3. Les conseils suivants vous aident à minimiser le retard entre le cluster principal et la réplica en lecture lorsque vous écrivez des données.

Chargez des données en bloc sur le cluster principal chaque fois que possible. Pour en savoir plus, consultez Chargement en bloc dans la documentation Apache HBase.
Un vidage qui écrit des fichiers de stockage dans Amazon S3 devrait être réalisé dès que possible après l'ajout des données. Procédez au vidage manuel ou configurez les paramètres de vidage pour minimiser le temps de retard.
Si les compactages doivent s'exécuter automatiquement, exécutez un compactage manuel afin d'éviter les incohérences lors du déclenchement des compactages.
Sur le cluster de réplica en lecture, lorsque des métadonnées ont changé (par exemple, lorsqu'un fractionnement ou des compactages de région HBase se produisent, ou lorsque des tables sont ajoutées ou supprimées) exécutez la commande refresh_meta.
Sur le cluster de réplica en lecture, exécutez la commande refresh_hfiles lorsque des enregistrements sont ajoutés vers ou modifiés dans une table.

Synchronisation de données avec un réplica en lecture HBase

Suivi permanent des fichiers

Le suivi HFile persistant utilise une table système HBase appelée hbase:storefile pour suivre directement les chemins HFile utilisés pour les opérations de lecture. De nouveaux chemins HFile sont ajoutés à la table au fur et à mesure que des données supplémentaires sont ajoutées à HBase. Cela supprime les opérations de renommage en tant que mécanisme de validation dans le chemin d'écriture critique des opérations HBase et améliore le temps de restauration lors de l'ouverture d'une région HBase en lisant dans la table système hbase:storefile plutôt que dans la liste des répertoires du système de fichiers. Cette fonctionnalité est activée par défaut sur Amazon EMR version 6.2.0 et ultérieure, et ne nécessite aucune étape de migration manuelle.

Note

Le suivi permanent de HFile à l'aide de la table système storefile de HBase ne prend pas en charge la fonctionnalité de réplication de région de HBase. Pour plus d'informations sur la réplication de la région HBase, consultez Lectures à haute disponibilité cohérentes avec la chronologie.

Désactivation du suivi permanent des fichiers

Le suivi permanent des fichiers HFile est activé par défaut à partir de la version 6.2.0 d'EMR. Pour désactiver le suivi permanent des fichiers HFile, spécifiez la modification de configuration suivante lors du lancement d'un cluster :


{
  "Classification": "hbase-site",
  "Properties": {
    "hbase.storefile.tracking.persist.enabled":"false",
    "hbase.hstore.engine.class":"org.apache.hadoop.hbase.regionserver.DefaultStoreEngine"
  }
}

Note

Lors de la reconfiguration du cluster Amazon EMR, tous les groupes d'instances doivent être mis à jour.

Synchronisation manuelle de la table Storefile

La table Storefile est mise à jour à mesure que de nouveaux HFiles sont créés. Toutefois, si la table Storefile n'est plus synchronisée avec les fichiers de données pour une raison quelconque, les commandes suivantes peuvent être utilisées pour synchroniser manuellement les données :

Synchroniser la table Storefile dans une région en ligne :

hbase org.apache.hadoop.hbase.client.example.RefreshHFilesClient <table>

Synchroniser la table Storefile dans une région hors connexion :

Supprimez la table Storefile znode.


echo "ls /hbase/storefile/loaded" | sudo -u hbase hbase zkcli
[<tableName>, hbase:namespace]
# The TableName exists in the list
echo "delete /hbase/storefile/loaded/<tableName>" | sudo -u hbase hbase zkcli
# Delete the Table ZNode
echo "ls /hbase/storefile/loaded" | sudo -u hbase hbase zkcli
[hbase:namespace]

Attribuez la région (exécutez dans « hbase shell »).
```
hbase cli> assign '<region name>'
```

Si l'assignation échoue.


hbase cli> disable '<table name>'
hbase cli> enable '<table name>'

Mise à l'échelle de la table Storefile

La table Storefile est divisée en quatre régions par défaut. Si la table Storefile est toujours soumise à une charge d'écriture importante, elle peut être divisée manuellement davantage.

Pour diviser une région chaude spécifique, utilisez la commande suivante (exécutée dans « hbase shell »).


hbase cli> split '<region name>'

Pour diviser la table, utilisez la commande suivante (exécutée dans « hbase shell »).


hbase cli> split 'hbase:storefile'

Considérations opérationnelles

Les serveurs de région HBase utilisent BlockCache pour stocker des lectures de données en mémoire et BucketCache pour stocker des lectures de données sur le disque local. De plus, les serveurs de région utilisent MemStore pour stocker les écritures de données en mémoire et utilisent des journaux WAL pour stocker des écritures de données dans HDFS avant que les données ne soient écrites dans des fichiers enregistrés HBase dans Amazon S3. Les performances de lecture de votre cluster dépendent de la fréquence à laquelle un enregistrement peut être récupéré à partir des caches en mémoire ou sur le disque. En cas d'échec de l'accès aux données du cache, l'enregistrement est lu à partir StoreFile dans Amazon S3, qui a une latence plus élevée et un écart type supérieur que lorsque la lecture est effectuée à partir de HDFS. De plus, les taux de demandes maximal pour Amazon S3 sont inférieurs à ce qui peut être réalisé à partir du cache local, la mise en cache de données peut donc être importante pour les charges de travail avec une forte densité de lectures. Pour plus d'informations sur les performances d'Amazon S3, consultez la section Optimisation des performances dans le Guide de l'utilisateur Amazon Simple Storage Service.

Pour optimiser les performances, nous vous recommandons de mettre le plus grand nombre de données possible en mémoire cache dans le stockage d'instances EC2. Etant donné que le BucketCache utilise le stockage d'instances EC2 du serveur de la région, vous pouvez choisir un type d'instance EC2 avec un stockage d'instances suffisant et ajouter un stockage Amazon EBS pour pouvoir prendre en compte la taille de cache requise. Vous pouvez également augmenter la taille BucketCache dans les stockages d'instances attachés et les volumes EBS à l'aide de la propriété hbase.bucketcache.size. Le paramètre par défaut est 8 192 MB.

Pour les écritures, la fréquence de vidage de MemStore et le nombre de StoreFiles présent pendant les compactages mineurs et majeurs peut énormément contribuer à une augmentation des temps de réponse des serveurs de la région. Pour des performances optimales, envisagez d'augmenter la taille du vidage de MemStore et du multiplicateur de blocs HRegion, ce qui permet d'augmenter le délai entre les principaux compactages, mais augmente aussi le retard de cohérence si vous utilisez un réplica en lecture. Dans certains cas, vous pouvez obtenir de meilleures performances en utilisant des tailles de blocs de fichiers plus importantes (néanmoins inférieures à 5 Go) pour déclencher la fonction de chargement partitionné d'Amazon S3 dans EMRFS. La taille de bloc par défaut d'Amazon EMR est de 128 Mo. Pour de plus amples informations, veuillez consulter Configuration HDFS. Nous voyons rarement des clients dépasser une taille de bloc de 1 Go lorsque nous comparons les performances avec des vidages et des compactages. De plus, les compactages HBase et les serveurs de la région fonctionnent de manière optimale lorsque le nombre de StoreFiles à compacter est moindre.

Les tables peuvent mettre du temps pour arriver dans Amazon S3, car des répertoires volumineux doivent être renommés. Envisagez la désactivation des tables plutôt que leur suppression.

Il existe un processus de nettoyage HBase qui élimine les anciens fichiers WAL et les fichiers stockés. Avec les version 5.17.0 et ultérieures d'Amazon EMR, l'appareil est activé dans le monde entier et les propriétés de configuration suivantes peuvent être utilisées pour contrôler un comportement plus propre.

Propriété de configuration	Valeur par défaut	Description
`hbase.regionserver.hfilecleaner.large.thread.count`	1	Le nombre de threads alloués pour nettoyer les gros HFiles expirés.
`hbase.regionserver.hfilecleaner.small.thread.count`	1	Le nombre de threads alloués pour nettoyer les petits HFiles expirés.
`hbase.cleaner.scan.dir.concurrent.size`	Défini sur un quart de tous les noyaux disponibles.	Nombre de threads pour analyser les répertoires oldWALs.
`hbase.oldwals.cleaner.thread.size`	2	Nombre de threads pour nettoyer les WALs dans le répertoire oldWALs.

Avec les versions 5.17.0 et ultérieures d'Amazon EMR, l'opération de nettoyage peut voir un impact sur les performances de requêtes lors de l'exécution d'importantes charges de travail. Nous vous recommandons donc d'activer le nettoyeur uniquement pendant les heures creuses. Le nettoyeur a les commandes shell HBase suivantes :

cleaner_chore_enabled vérifie si l'appareil est activé.
cleaner_chore_run exécute manuellement le nettoyeur pour supprimer les fichiers.
cleaner_chore_switch active ou désactive le nettoyeur et le remet à son état précédent. Par exemple, cleaner_chore_switch true active le nettoyeur.

Propriétés de réglage des performances pour HBase sur Amazon S3

Les paramètres suivants peuvent être ajustés pour personnaliser les performances de votre charge de travail lorsque vous utilisez HBase sur Amazon S3.

Propriété de configuration	Valeur par défaut	Description
`hbase.bucketcache.size`	8 192	La quantité d'espace sur le disque, en Mo, réservée dans les stockages d'instances Amazon EC2 et les volumes EBS du serveur de la région pour le stockage de BucketCache. Le paramètre s'applique à toutes les instances de serveur de la région. Les tailles plus importantes de BucketCache correspondent généralement à des performances optimisées
`hbase.hregion.memstore.flush.size`	134217728	La limite des données, en octets, à laquelle le vidage d'un memstore vers Amazon S3 est déclenché.
`hbase.hregion.memstore.block.multiplier`	4	Un multiplicateur qui détermine la limite supérieure MemStore au-delà de laquelle les mises à jour sont bloquées. Si le MemStore dépasse `hbase.hregion.memstore.flush.size` multipliée par cette valeur, les mises à jour sont bloquées. Le compactage et le vidage de MemStore peuvent parfois provoquer le déblocage des des mises à jour.
`hbase.hstore.blockingStoreFiles`	10	Le nombre maximum de StoreFiles qui peuvent résider dans un magasin avant que des mises à jour ne soient bloquées.
`hbase.hregion.max.filesize`	10737418240	La taille maximale d'une région avant que la région ne soit fractionnée.

Arrêt et restauration d'un cluster sans perte de données

Pour arrêter un cluster Amazon EMR sans perdre les données qui n'ont pas été écrites sur Amazon S3, vous devez vider votre cache MemStore vers Amazon S3 pour écrire de nouveaux fichiers de stockage. Tout d'abord, vous devez désactiver toutes les tables. La configuration de l'étape suivante peut être utilisée lorsque vous ajoutez une étape au cluster. Pour plus d'informations, consultez Utilisation des étapes à de l'AWS CLI et de la console dans le Guide de gestion d'Amazon EMR.


Name="Disable all tables",Jar="command-runner.jar",Args=["/bin/bash","/usr/lib/hbase/bin/disable_all_tables.sh"]

Vous pouvez également exécuter la commande bash suivante directement.


bash /usr/lib/hbase/bin/disable_all_tables.sh

Après avoir désactivé toutes les tables, videz hbase:meta à l'aide du shell HBase et de la commande suivante.


flush 'hbase:meta'

Vous pouvez ensuite exécuter un script shell fourni sur le cluster Amazon EMR pour vider le cache du MemStore. Vous pouvez l'ajouter soit comme une étape, soit en l'exécutant directement à l'aide d'AWS CLI sur le cluster. Le script désactive toutes les tables HBase, ce qui entraîne le vidage du MemStore de chaque serveur de région dans Amazon S3. Si le script se termine avec succès, les données persistent dans Amazon S3 et le cluster peut être arrêté.

Pour redémarrer un cluster avec les mêmes données HBase, spécifiez le même emplacement Amazon S3 que le cluster précédent ; soit dans l'AWS Management Console, soit en utilisant la propriété de configuration hbase.rootdir.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Création d'un cluster avec HBase

Utilisation du shell HBase