HBasesur Amazon S3 (mode de stockage Amazon S3)

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

• Le répertoire HBase racine est stocké dans Amazon S3, y compris les fichiers de HBase stockage et les métadonnées des tables. Ces données sont persistantes en dehors du cluster, disponibles dans toutes les zones de EC2 disponibilité Amazon, et vous n'avez pas besoin de les récupérer à l'aide de snapshots ou d'autres méthodes.

• Avec les fichiers de stockage dans Amazon S3, vous pouvez dimensionner votre EMR cluster Amazon en fonction de vos besoins de calcul plutôt que de vos exigences en matière de données, avec une réplication multipliée par 3. HDFS

• À l'aide de EMR la version 5.7.0 ou ultérieure d'Amazon, vous pouvez configurer un cluster en lecture seule, qui vous permet de conserver des copies en lecture seule des 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 HFile suivi persistant utilise une table HBase système appelée hbase:storefile pour suivre directement les HFile chemins 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 montre les HBase composants pertinents pour HBase Amazon S3.

Activation HBase sur Amazon S3

Vous pouvez l'activer HBase sur Amazon S3 à l'aide de la EMR console Amazon AWS CLI, du ou d'Amazon EMRAPI. 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 le AWS CLI, utilisez l'--configurations option pour fournir un objet JSON de configuration. 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 se trouver dans la même région que votre EMR cluster Amazon. Un seul cluster actif à la fois peut utiliser le même répertoire HBase racine dans Amazon S3. Pour les étapes de console et un exemple détaillé de création de cluster à l'aide du AWS CLI, voir. Création d'un cluster avec HBase Un exemple d'objet de configuration est présenté dans l'JSONextrait 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 formulaire rootdirHBase, vous devez ajouter une barre oblique à la fin du compartiment Amazon S3URI. 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 configuré un cluster principal à l'aide d'HBaseAmazon S3, vous pouvez créer et configurer un cluster en lecture seule qui fournit un accès en lecture seule aux mêmes données que le 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 lecture et de réplication est disponible avec Amazon EMR version 5.7.0 et versions ultérieures.

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, compte tenu de la JSON classification du cluster principal présentée plus haut dans cette rubrique, la configuration d'un cluster en lecture et réplique est la suivante :

{
  "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

Étant donné que le réplica en lecture utilise HBase StoreFiles les métadonnées que le cluster principal écrit dans Amazon S3, le réplica en lecture est uniquement aussi actuel que le magasin 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 plus d'informations, consultez la section Chargement groupé dans la HBase documentation d'Apache.

• 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 lecture et de réplication, lorsque des métadonnées ont changé, par exemple en cas de division de HBase région ou de compactage, 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.

HFileSuivi permanent

HFileLe suivi permanent utilise une table HBase système appelée hbase:storefile pour suivre directement les HFile chemins utilisés pour les opérations de lecture. De nouveaux HFile chemins sont ajoutés à la table au fur et à mesure que des données supplémentaires sont ajoutéesHBase. Cela supprime les opérations de renommage en tant que mécanisme de validation dans les HBase opérations de chemin d'écriture critiques et améliore le temps de restauration lors de l'ouverture d'une HBase région en lisant dans la table hbase:storefile système 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 versions ultérieures, et ne nécessite aucune étape de migration manuelle.

Note

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

Désactiver le suivi permanent HFile

HFileLe suivi permanent est activé par défaut à partir de la EMR version 6.2.0 d'Amazon. Pour désactiver le HFile suivi permanent, 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 EMR cluster Amazon, tous les groupes d'instances doivent être mis à jour.

Synchronisation manuelle de la table Storefile

La table Storefile est mise à jour au fur et à mesure que de nouvelles tables HFiles sont créées. 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

HBaseles serveurs régionaux sont utilisés BlockCache pour stocker les lectures de données en mémoire et BucketCache pour stocker les lectures de données sur le disque local. En outre, les serveurs régionaux stockent MemStore les écritures de données en mémoire et utilisent des journaux d'écriture anticipée pour stocker les écritures de données HDFS avant qu'elles ne soient écrites dans HBase StoreFiles 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. Une erreur de cache entraîne la lecture de l'enregistrement StoreFile dans Amazon S3, ce qui présente une latence et un écart-type nettement supérieurs à ceux de la lecture depuisHDFS. 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 améliorer les performances, nous vous recommandons de mettre en cache la plus grande partie possible de votre ensemble de données dans le stockage d'EC2instance. Comme il BucketCache utilise le stockage d'EC2instance du serveur régional, vous pouvez choisir un type d'EC2instance avec un stockage d'instance suffisant et ajouter du EBS stockage Amazon pour répondre à la taille de cache requise. Vous pouvez également augmenter la BucketCache taille des magasins et EBS volumes d'instances attachés à l'aide de cette hbase.bucketcache.size propriété. Le paramètre par défaut est 8 192 MB.

En ce qui concerne les écritures, la fréquence des MemStore purges d'eau et le nombre de personnes StoreFiles présentes lors de compactages mineurs ou majeurs peuvent contribuer de manière significative à l'augmentation des temps de réponse des serveurs régionaux. Pour des performances optimales, pensez à augmenter la taille du MemStore purgeur et du multiplicateur de HRegion blocs, ce qui augmente le temps écoulé entre les compactages majeurs, mais augmente également le retard de cohérence si vous utilisez une réplique en lecture. Dans certains cas, vous pouvez obtenir de meilleures performances en utilisant des blocs de fichiers de plus grande taille (mais inférieurs à 5 Go) pour activer la fonctionnalité de téléchargement partitionné d'Amazon S3 dansEMRFS. La taille EMR de bloc par défaut d'Amazon est de 128 Mo. Pour de plus amples informations, veuillez consulter HDFSconfiguration. 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, HBase les compactages et les serveurs régionaux fonctionnent de manière optimale lorsqu'il est StoreFiles nécessaire de compacter moins de serveurs.

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 HBase processus de nettoyage qui nettoie les anciens WAL fichiers et stocke les fichiers. Avec les EMR versions 5.17.0 et ultérieures d'Amazon, le nettoyeur est activé globalement et les propriétés de configuration suivantes peuvent être utilisées pour contrôler le comportement du nettoyeur.

Propriété de configuration	Valeur par défaut	Description
hbase.regionserver.hfilecleaner.large.thread.count	1	Le nombre de threads alloués au nettoyage a expiré en grande quantitéHFiles.
hbase.regionserver.hfilecleaner.small.thread.count	1	Le nombre de threads alloués au nettoyage a expiré petitHFiles.
hbase.cleaner.scan.dir.concurrent.size	Défini sur un quart de tous les noyaux disponibles.	Le nombre de threads à analyser dans les oldWALs répertoires.
hbase.oldwals.cleaner.thread.size	2	Le nombre de threads à nettoyer WALs sous le oldWALs répertoire.

Avec Amazon EMR 5.17.0 et versions antérieures, le fonctionnement du nettoyeur peut affecter les performances des requêtes lors de l'exécution de charges de travail importantes. Nous vous recommandons donc d'activer le nettoyeur uniquement pendant les heures creuses. Le nettoyeur possède les commandes HBase shell 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 pour HBase le réglage des performances sur Amazon S3

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

Propriété de configuration	Valeur par défaut	Description
hbase.bucketcache.size	8 192	La quantité d'espace disque, en Mo, réservée sur les stockages d'EC2instances Amazon sur le serveur régional et les EBS volumes de BucketCache stockage. Le paramètre s'applique à toutes les instances de serveur de la région. Des BucketCache tailles plus grandes correspondent généralement à de meilleures performances
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 MemStore supérieure à laquelle les mises à jour sont bloquées. Si les MemStore dépassements hbase.hregion.memstore.flush.size sont multipliés par cette valeur, les mises à jour sont bloquées. MemStore des bouffées d'eau et du compactage peuvent survenir pour débloquer les mises à jour.
hbase.hstore.blockingStoreFiles	10	Le nombre maximum de celles-ci peut exister dans un magasin avant StoreFiles que les 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 EMR cluster Amazon sans perdre de données qui n'ont pas été écrites sur Amazon S3, vous devez vider votre MemStore cache d'Amazon S3 pour y écrire de nouveaux fichiers de boutique. 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 la section Travailler avec les étapes à l'aide de la console AWS CLI et dans le guide EMR de gestion Amazon.

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-les à l'hbase:metaaide du HBase shell et de la commande suivante.

flush 'hbase:meta'

Vous pouvez ensuite exécuter un script shell fourni sur le EMR cluster Amazon pour vider le MemStore cache. 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 HBase tables, ce qui MemStore entraîne le transfert du serveur de chaque région vers 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 HBase données, spécifiez le même emplacement Amazon S3 que le cluster précédent dans AWS Management Console ou à l'aide de la propriété hbase.rootdir de configuration.