CR du Hadoop User Group Paris du 26 Février sur Impala

Le HUG s'est déroulé dans les locaux d'AF83, dans le 2ème arrondissement Parisien.

Il n'y a eu qu'une seule présentation, celle de Marcel Kornacker Lead Architect chez Cloudera sur le projet Impala.

La présentation était très dense et portait sur Impala aujourd'hui et dans un futur proche.

Voici ce que j'en ai retenu.

Impala

Qu'est ce qu'Impala ?

Impala est un projet OpenSource de Cloudera et non de la fondation Apache permettant de faire du requêtage SQL sur des jeux de données de type Big Data.

Impala est adapté aussi bien à des traitements OLAP qu'OLTP et garantie des temps de réponse très rapides.

Niveau de maturité

C'est aujourd'hui une bêta que Cloudera installe chez ses clients lorsque ces derniers veulent tester le produit et donner du feedback pour son amélioration.

Impala n'est pas, aujourd'hui, prêt pour la production comme pour du POC.

Cependant, un premier palier déstabilisé sera franchi avec la sortie d'une version GA en Avril 2013.

Architecture

Dans Impala, on distingue deux composants.

Le Statestore

C'est ici que se trouvent les schéma des tables et que les agents impalas (voir plus bas) s'enregistrent.

Le statestore exporte aussi une façade Thrift pour le contrôler à distance.

Au jour d'aujourd'hui, le statestore lit le contenu du NameNode et du Metastore de Hive.

Il ne s'agit pas d'une base de référence en ce sens qu'elle se construit sur la base à la fois du contenu du NameNode et des RegionServer HBase. Cloudera parle de soft-state.

Ainsi, il sera possible d'utiliser un statestore pour consolider les données se trouvant dans plusieurs clusters Hadoop et les requêtes SQL se répartiront entre les agents impalad des différents clusters en fonction du besoin.

Les agents Impalad

Installés sur chacun des noeuds Hadoop (HDFS ou HBase), ce composant assure à la fois le point d'entrée des requêtes SQL, le calcul du plan d'exécution et l'exécution des chunks.

Le résultat intermédiaire sur chaque agent est ensuite streamé sur le noeud à l'origine de la requête.

Le choix de l'agent qui peut traiter un bout de requête se fait en fonction de la localité de la donnée, comme pour Map Reduce donc.

Accès à Impala

Il y a deux modes d'accès à Impala :

 - ODBC/JDBC

 - impala-shell, qui se connecte à un agent impalad

Aujourd'hui, on doit se connecter à un noeud en particulier. Il est prévu d'ajouter un mécanisme de load balancing afin de ne plus avoir à se soucier de la charge des agents.

D'autre part, Kerberos est déjà supporté.

Stockage et formats supportés

Il n'y a pas de contrainte particulière de stockage ni de format, le produit se voulant le plus ouvert possible.

Ce qui est supporté aujourd'hui :

 - stockage RAW avec ou sans compression LZO

 - stockage SequenceFile ou RCFile avec Snappy ou GZip

La version GA apportera entre autres le support pour les fichiers binaires Avro.

Les performances

Les performances sont un élément fondamental pour eux. Impala est écrit en C++, ne repose pas sur MapReduce et les requêtes SQL soumises au moteur sont transformées en bytecode LLVM pour que ce dernier puisse générer au runtime le code exécutant l'opération SQL demandée.

Un autre point important est de réduire autant que possible l'empreinte mémoire des agents.

Un moteur SQL

Impala permet de requêter en SQL-92 avec globalement les même limitations que Hive plus le fait qu'aujourd'hui on ne peut pas faire d'opération de DDL.

Le support pour les opérations DDL arriveront courant 2013 de même que les opérations d'INSERT, de DELETE et d'UPDATE.

Limitations fonctionnelles actuelles

Aujourd'hui, Impala ne supporte pas d'UDF personnalisées, de Serdes, ni d'extension au delà de SQL tels que XPath, Json, …

De la même manière, une requête doit tenir en mémoire, les ORDER BY nécessitent une clause LIMIT, il n'y a pas de support les TOP-n et l'ordre des JOIN dépend de l'ordre dans la requête.

Ce sont là des points qui seront dépassés dans le courant de l'année 2013.

Quelques métriques de performances

Sans avoir fait des tests poussés, les métriques suivantes ont été constatées :

 - Sur une petite table avec des données facilement compressible,le ratio de compression de Parquet par rapport à Snappy est de 15:1

 - Impala est plus intensif en I/O que Hive. Sur certaines requêtes, les I/O peuvent être  saturées

 - Sur des requêtes simples tenant sur la mémoire d'un seul noeud, un gain jusqu'à x100 a été constaté par rapport à Hive

 - Sur des requêtes plus complexe, le gain constaté est d'environ x2 à x3 par rapport à Hive

Parquet

Parquet est le successeur de Trevni, un format de stockage orienté colonne.

Il sert pour la sérialisation de :

 - Avro

 - Thrift

 - ProtoBuf

Le projet est OpenSource et conjointement développé par Cloudera et Twitter.

Parmi les fonctionnalités attendues se trouvent :

 - un nombre de colonne différent pour chaque ligne

 - les types natifs

 - l'indexation de pages pour accélérer les opérations de lookup

 - l'ajout de nouveaux encodages de types

 - la compression dictionnaire pour les valeurs à faible cardinalité

D'autre part, Impala avec Parquet supportera les JOIN.

Conclusion

La vision que nous a exposé Marcel Kornacker pour Impala peut se résumer ainsi :

 Impala devra pouvoir être utilisé pour des requêtes exploratoires et de production sur le même cluster dans impact sur les jobs de production de ce cluster.