Skip to main content

Optimiser les accès en lecture sur HBase

Increase HBase read performance checklist

Accès en parallèle, client "multihtread"
Dans HBase les données sont découpées en Régions et ces Régions peuvent être servies par des Region Servers différents. La charge de lecture doit donc être dans la mesure du possible distribuée sur l'ensemble des serveurs. 

Privilégier les lectures en mode "batch"
L'API HBase permet de lotir des appels à la base dans des "Batch Operations". L’intérêt est d'éviter de trop nombreux aller/retour sur le réseau.
Ainsi les opérations PUT, GET, DELETE peuvent être regroupées dans un seul appel à la base de donnée.


HTable hTable = new HTable("cachetestdb");
List listOfget = new ArrayList();
for (int i = 0; i < 10; i++) {
String keyAsString = "17#" + i;
Get get = new Get(Bytes.toBytes(keyAsString));
listOfget.add(get);
}

Object[] batch = hTable.batch(listOfget);

for (Object object : batch) {
Result result = (Result) object; 
/* TODO : process data */
}



Le cache joue t-il correctement son rôle ?
Il est important de vérifier si le cache joue efficacement son rôle. HBase dispose en effet d'un cache de type LRU pour accélérer l'accès aux données récemment accédées.
Si ce n'est pas le cas car les accès se font sur des données non contiguës alors il peut être envisageable de diminuer la taille des blocs de données qui par défaut est de 64Ko Attention à ne pas confondre les blocs de données gérés par HBase avec les blocs de données du système de fichiers HDFS qui par défaut sont de 64Mo.
Au contraire si le cache est souvent atteint (lecture de plages de données contiguës) on peut augmenter la taille de ses blocs (e.g. 640Ko)




Paramètre IN_MEMORY sur les Column Family
Lors de la déclaration d'une Column Family il est possible de positionner le paramètre IN_MEMORY à true (par défaut il est à false). Dans ce cas HBase va faire son maximum pour garder les données en mémoire en les rendant plus prioritaire lors du nettoyage du cache.
Par défaut seules les 2 tables "systèmes" -ROOT- et .META. possèdent cette propriété afin de garantir un accès rapide aux données qu'elles contiennent. L'activation de cette propriété place donc vos données dans le cache avec le même niveau de priorité.

Utilisation des "Bloom filters"
Les Bloom filters permettent d'accélérer la recherche d'une ligne en excluant certains fichiers de données HFile de la recherche.
L'activation des Bloom filters peut se faire sur des données existantes, ils seront simplement générés et activés lors de la création de nouveau fichiers de données HFile lors de flush ou de (major/minor) compact.
De plus depuis l'arrivée du format HFile V2 avec la version 0.92 de HBase (en release candidate  à l'heure où j'écris ces lignes) la pression sur la mémoire engendrée par leur activation s'est considérablement amoindrie. A l'ouverture d'un fichier HFile V1 il fallait charger l'intégralité des données des bloom filters en mémoire : cela ralentissait l'ouverture du fichier et donc la disponibilité des données de la Region. Ce n'est plus le cas avec le nouveau format.
Depuis la version 0.92 HBase lit les HFile V1 et les convertis en V2 lors des opérations de flush ou de (major/minor) compact

Compression des données
HBase permet de compresser les données, le gain en terme de rapidité de lecture des données est en règle générale supérieur à l'augmentation de la consommation CPU induite par les algorithmes de compression. L'intégration de l'algorithme Google Snappy dans la version 0.92 vient compléter la liste des algorithmes déjà intégrés dans les versions antérieures : Gzip et LZO (attention cependant aux dépendances sur les bibliothèques natives pour LZO et Snappy)
Si il est en règle générale toujours une bonne chose d'activer la compression des données il faudra noter que cela n'apportera rien sur des données ayant déjà une trop grande entropie (archives .zip, images jpeg ...)
La compression des données se définie au niveau des Column Family.
Quel algorithme choisir ?
  • GZip : très bon taux de compression mais aussi très gourmand en CPU, ce qui diminue les débit de lectures et d'écritures
  • LZO : bon compromis entre taux de compression et débit
  • Snappy : taux de compression en retrait par rapport aux autres algorithme mais le débit qu'il assure est excellent
N.B : il s'agit de comportements généralement observés, si vous parcourez la mailing list vous trouverez des avis divergents concernant l'efficacité des algorithmes de compression



Comments

  1. Bonjour

    Cette il y a récemment (en Décembre) un débat portant sur une compression encore meilleure que Snappy.

    https://issues.apache.org/jira/browse/HADOOP-7657

    Cet algorithme est-il vraiment meilleur ? N'est-il activé que dans MapReduce, ou est-il aussi disponible pour HBase ?

    Merci

    ReplyDelete
    Replies
    1. Bonjour,

      Je ne connais pas cet algorithme donc je ne peux pas me prononcer. Il faut aussi définir ce que l'on appelle "meilleur". Est ce le ratio obtenu ? celui qui a le meilleur débit ? Par rapport à la conso CPU/mémoire ? Ou bien celui qui obtient le meilleur compromis entre tous ces paramètres ?

      Je pense qu'avant d'arrêter son choix il faut évaluer un algorithme sur un jeux de test avec des cas d'utilisations précis tout en surveillant le comportement des machines.

      Pour répondre à votre dernière question à ma connaissance LZ4 n'est pas disponible dans HBase. Le sujet avait été effleuré l'année dernière sans donner suite à une demande d'évolution.

      Delete

Post a Comment

Popular posts from this blog

Row Count : HBase Aggregation example

With the coprocessors HBase 0.92 introduces a new way to process data directly on a region server. As a user this is definitively a very exciting feature : now you can easily define your own distributed data services.

This post is not intended to help you how to define them (i highly recommend you to watch this presentation if you want to do so) but to quickly presents the new aggregation service shipped with HBase 0.92 that is built upon the endpoint coprocessor framework.

1. Enable AggregationClient coprocessor

You have two choices :

You can enable aggregation coprocessor on all your tables by adding the following lines to hbase-site.xml :
<property> <name>hbase.coprocessor.user.region.classes</name> <value>org.apache.hadoop.hbase.coprocessor.AggregateImplementation</value> </property> or ...you can enable coprocessor only on a table throught the HBase shell :

1. disable the table
hbase> disable 'mytable'

2. add the coprocessor
hbase…

Analyse d'un "thread dump" d'une JVM IBM sous AIX

Dans quels cas le thread dump est utile ?
Le thread dump est un instantané de l'activité des threads de la JVM. Leur analyse est intéressante dans les cas où l'activité de la JVM ne semble pas normale :
Activité suspendue (deadlock/interblocage) ou partiellement suspendue (starvation/famine)Activité existante mais le "débit" est en deçà de ce qui est attendu (Goulot d'étranglement / Bottleneck)Activité existante mais le "débit" reste nul (Boucle infinie / Infinite Loop)Comment avoir un thread dump ?
Nous nous limitons ici à la machine virtuel IBM sous AIX. Dans ce cas là il est extrêmement simple de déclencher la création d'un thread dump : il suffit de faire un kill -3 sur le processus Java.

Un fichier dont le nom est javacore.[date].[numero_processus].[compteur].txt est produit. Sur la sortie standard du processus vous devriez voir la ligne suivante s'afficher :
JVMDUMP010I Java Dump written to .....
En général le dump est produit dans le réper…

Zookeeper, Netflix Curator and ACLs

If you have one or more Zookeeper "multi-tenant" clusters you may want to protect znodes against unwanted modifications.
Here is a very simple and short introduction to the ACL and custom authentication features.
This post is not intended to give you best practices about security and Zookeeper, the only goal is to give you a complete example of a custom authentication handler.
Complete source code with JUnit test is available here :
https://github.com/barkbay/zookeeper-acl-sample/ Use case Let say that your Zookeeper cluster is used by several users. In order to restrict user actions you have decided that each user must prefix all paths with the first letter of his name.
User foo is only allowed to create, read, delete and update znodes under the /f znode. User bar is only allowed to create, read, delete and update znodes under the /b znode.
Get client authentication data on the server side Zookeeper client authentication can be easily customized , all you have to do is to…