Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

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 :

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 ou de AWS CLI 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 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 apparaît dans l'extrait JSON suivant.

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

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

Le cluster de répliques en lecture seule est conçu pour les opérations en lecture seule, et aucune action manuelle de compactage ou d'écriture ne doit être effectuée sur celui-ci. Pour les versions d'Amazon EMR antérieures à 7.4.0, il est recommandé de désactiver le compactage sur le cluster de lecture-réplication lorsque vous activez la fonctionnalité de lecture-réplique. Cette précaution est nécessaire car, lorsque la fonction de suivi HFile persistante est activée sur le cluster principal, il est possible que le cluster en lecture-réplique compresse les tables système, ce qui peut provoquer un FileNotFoundException dysfonctionnement du cluster principal. La désactivation du compactage sur le cluster en lecture permet d'éviter les incohérences de données entre le cluster principal et le cluster en lecture.

Par exemple, compte tenu de la classification JSON du cluster principal, comme indiqué précédemment dans cette rubrique, la configuration d'un cluster en lecture et en réplique pour les versions EMR antérieures à 7.4.0 est la suivante :

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

Pour les versions d'Amazon EMR ultérieures à 7.3.0, nous utilisons désormais Suivi des fichiers du magasin cette fonctionnalité. Il n'est donc pas nécessaire de désactiver les compactages.

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

Étant donné que la réplique en lecture utilise HBase StoreFiles et les métadonnées que le cluster principal écrit sur Amazon S3, la réplique en lecture est à jour uniquement au même titre 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.

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 les versions 6.2.0 à 7.3.0 d'Amazon EMR et ne nécessite aucune étape de migration manuelle.

Désactivation du suivi permanent des fichiers

Le suivi permanent des fichiers est activé par défaut à partir de la version 6.2.0 d'Amazon 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"
  }
}

Synchronisation manuelle de la table Storefile

La table Storefile est mise à jour au fur et à mesure que de nouvelles instances de HFile 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 :

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'

Suivi des fichiers du magasin

Par défaut, nous utilisons l'FileBasedStoreFileTrackerimplémentation. Cette implémentation crée de nouveaux fichiers directement dans le répertoire du magasin, évitant ainsi d'avoir à effectuer des opérations de renommage. Il conserve une liste des instances de hfile validées en mémoire, soutenue par des méta-fichiers dans chaque répertoire de magasin. Chaque fois qu'un nouveau hfile est validé, la liste des fichiers suivis dans le magasin concerné est mise à jour et un nouveau méta-fichier est écrit avec le contenu de la liste et en supprimant le méta-fichier précédent, qui contient une liste obsolète. Pour plus d'informations sur le suivi des fichiers de stockage, consultez la section Suivi des fichiers de magasin dans le guide de référence d'Apache HBase.

L'implémentation du FileBasedStoreFile tracker est activée par défaut, à partir de la version 7.4.0 d'Amazon EMR :

{
  "Classification": "hbase-site",
  "Properties": {
    hbase.store.file-tracker.impl: "org.apache.hadoop.hbase.regionserver.storefiletracker.FileBasedStoreFileTracker"
   }
}

Pour désactiver l' FileBasedStoreFileTracker implémentation, spécifiez la modification de configuration suivante lors du lancement d'un cluster :

{
  "Classification": "hbase-site",
  "Properties": {
    hbase.store.file-tracker.impl: "org.apache.hadoop.hbase.regionserver.storefiletracker.DefaultStoreFileTracker"
   }
}

Configuration de la politique de lecture S3A pour HBase

À partir de la version 7.10 d'Amazon EMR, HBase sur Amazon S3 utilise le client de système de fichiers S3A. Par défaut, la propriété fs.s3a.experimental.input.fadvise est définie sur normal. Dans ce mode, le S3A s'adapte automatiquement entre les politiques de lecture séquentielle et aléatoire en fonction du modèle d'accès observé du flux d'entrée.

HBase sur Amazon S3 s'appuie sur des lectures séquentielles pour les compactages, les scans et les chargements en masse. Dans certains cas, le mode normal peut passer à la politique de lecture aléatoire. Cela peut se produire même si les lectures suivantes restent séquentielles. Dans ce cas, les performances de lecture pour les compactages, les scans et les chargements en vrac peuvent se dégrader de manière significative.

Si vous présentez l'un des symptômes suivants, définissez la politique de lecture du S3A sur : sequential

Spécifiez la configuration suivante lorsque vous créez votre cluster :

[
  {
    "Classification": "hbase-site",
    "Properties": {
      "fs.s3a.experimental.input.fadvise": "sequential"
    }
  }
]

Appliquez cette propriété hbase-site.xml à tous les nœuds. La modification prend effet après le redémarrage des processus du serveur principal et régional HBase.

Configuration de la politique de lecture pour les opérations de chargement en vrac

Si vous souhaitez uniquement améliorer les performances de chargement groupé sans modifier la configuration à l'échelle du cluster, vous pouvez transmettre la propriété directement à la completebulkload commande.

Pour utiliser la politique de lecture séquentielle pour une seule opération de chargement en bloc :

sudo -u hbase hbase completebulkload \
  -Dfs.s3a.experimental.input.fadvise=sequential \
  s3://amzn-s3-demo-bucket/path/to/hfiles table_name

Vous pouvez également utiliser EMRFS pour l'opération de chargement en masse :

sudo -u hbase hbase completebulkload \
  -Dfs.s3.impl=com.amazon.ws.emr.hadoop.fs.EmrFileSystem \
  s3://amzn-s3-demo-bucket/path/to/hfiles table_name

Considérations opérationnelles

Les serveurs de région HBase 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 les écritures de données en mémoire et utilisent les journaux d'écriture anticipée pour stocker les écritures de données dans HDFS avant que les données ne soient écrites dans HBase dans StoreFiles Amazon S3. MemStore 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' StoreFile enregistrement depuis Amazon S3, ce qui présente une latence et un écart-type nettement supérieurs à ceux de la lecture depuis 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. Comme il BucketCache utilise le stockage d'instance EC2 du serveur régional, vous pouvez choisir un type d'instance EC2 avec un stockage d'instance suffisant et ajouter du stockage Amazon EBS pour répondre à la taille de cache requise. Vous pouvez également augmenter la BucketCache taille des magasins d'instances attachés et des volumes EBS à 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 multiplicateur de blocs MemStore flush et HRegion, 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 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 régionaux fonctionnent de manière optimale lorsqu'il est nécessaire de réduire le nombre de StoreFiles compactages nécessaires.

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.

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 :

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.

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

Pour arrêter un cluster Amazon EMR sans perdre de données qui n'ont pas été écrites sur Amazon S3, vous devez vider votre MemStore cache sur 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 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. 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 transfert MemStore 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 données HBase, 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.