Le test de performances est un élément incontournable des mises en production.

De bons tests de performances permettent en effet :

• de s'assurer que la solution déployée répond aux attentes en termes de performances
• que le service rendu aux utilisateurs sera rapide sans mettre les serveurs à genoux
• de tester les limites de l'architecture déployée

Hadoop n'est pas une application web, une base de données ou encore un webservice. Avec Hadoop, on ne teste pas les performances d'un job sous une haute charge d'utilisation. Au lieu de cela, il est plus pertinent d'effectuer un benchmark, c'est à dire de tester l'ensemble des composants du cluster Hadoop pour différents profils d'utilisation.

Intel a sorti, il y a quelques temps, un outil permettant de faire des benchmarks d'un cluster Hadoop. C'est de ce dernier, HiBench, dont nous faisons un retour d'expérience ici.

HiBench, de quoi s'agit il ?

HiBench est un ensemble de scripts shells publiés sous Apache Licence 2 disponible sur GitHub : https://github.com/intel-hadoop/HiBench

Il permet de tester un cluster Hadoop selon plusieurs profils d'utilisation.

Micro Benchmarks

WordCount

Ce test distribue un comptage des mots d'une source de données.

Cette source est générée par un script de préparation de HiBench utilisant le randomtextwriter d'Hadoop.

Il représente une classe de jobs qui extrait un petit sous ensemble de données d'une source plus conséquente.

Ce test est de type CPU bound.

Sort

Ce test distribue le tri d'une source de données.

Cette source est générée par un script de préparation de HiBench utilisant le randomtextwriter d'Hadoop.

Le test en lui même est le plus simple que l'on puisse imaginer. En effet, les phases de Map et de Reduce sont des fonctions identités, la capacité de tri des données sources étant induite lors de la phase de Shuffle & Merge de MapReduce.

Ce test est de type I/O bound.

TeraSort

Ce test distribue aussi le tri d'une source de données.

Cette source est générée par le job Teragen qui génère par défaut  1 milliard de lignes de 100 octets chacune.

Ces lignes sont ensuite triées par le Terasort. Contrairement au Sort, le Terasort défini ses propres formats d'entrée, de sortie et le Partitioner lequel s'assure que les clés sont réparties le plus uniformément possible entre les partitions, assurant in fine une répartition plus équitable du travail entre tous les mappers.

C'est donc un Sort amélioré visant à garantir une utilisation uniforme du cluster lors du test.

De part cette spécificité, ce test est de type :

• CPU bound en map
• I/O bound en reduce

Enhanced DFSIO

Ce test est dédié à HDFS. Il a pour objectif de mesurer l'I/O et la bande passante agrégée lors de l'utilisation d'HDFS.

Dans sa phase préparatoire, il génère de la donnée et dépose des fichiers sur HDFS.

Ensuite, deux tests sont exécutés :

• Une lecture du jeu de données précédemment généré
• Une écriture d'un jeu de données

Le test d'écriture est globalement la même chose que la phase préparatoire de lecture.

Ce test est de type I/O bound.

Web Search

Nutch indexing

Ce test permet de mesurer les performances du cluster pour des tâches d'indexation.

Pour ce faire, une phase préparatoire génère des données à indexer.

Ensuite, l'indexation est effectuée au moyen d'Apache Nutch.

Ce test est de type I/O bound avec une forte utilisation du CPU en map.

Page Rank

Ce test permet de mesurer les performances du cluster pour des tâches de PageRanking.

Là encore, une phase préparatoire génère le graphe de données à traiter au moyen de l'algorithme du PageRank.

Ensuite, le traitement a proprement parler est effectué par une suite  de 6 jobs MapReduce.

Ce test est de type CPU bound.

Machine Learning

Classification naïve bayésienne

Ce test effectue une classification probabilistique sur un jeu de données.

Il a été expliqué en détails dans cet article.

La phase préparatoire génère ce jeu de données.

Ensuite, le test lance deux jobs MapReduce au travers de Mahout:

• seq2sparse qui transforme le jeu de données textuel en vecteurs
• trainnb qui calcule le modèle à partir de ces vecteurs

Ce test est de type I/O bound mais présente toutefois une très forte utilisation du CPU durant le map du seq2sparse.

Il est à noter qu'à l'utilisation, nous n'avons pas pu observer de réelle charge sur ce test. Il semblerai en effet qu'il soit nécéssaire soit d'apporter son propre jeu de données soit d'augmenter considérablement la taille du jeu de données généré pour que cela charge réellement un cluster.

Algorithme des k-moyennes

Ce test classifie un jeu de données et permet de visualiser le niveau de représentation des classes ainsi que leur distances les unes aux autres.

La phase préparatoire génère le jeu de données.

Ensuite, l'algorithme est lancé sur ce jeu de données au travers de Mahout.

L'algorithme des k-moyennes est composé de deux phases distinctes :

• les itérations
• le clustering

A chacune de ces deux phases correspondent des jobs MapReduce et un profil d'utilisation des ressources différents.

• CPU bound pendant la phase itérations
• I/O bound pendant la phase clustering

Analytical Query

Cette catégorie de tests correspond au requêtage que font traditionnellement les analystes métier.

Les données d'entrées sont là encore générées par une phase préparatoire.

Deux tables sont créées :

• Une table rankings contenant un classement
• Une table uservisits contenant un historique de visites d'utilisateurs

Un shéma que l'on pourrait retrouver sur un site web pour de l'analyse de traffic donc.

Une fois les données sources générées, deux requêtes Hive sont lancées :

• Une jointure
• Un agrégat

Ces tests sont de type I/O bound.

Utilisation

Effectuer un tir

Lancer HiBench n'est pas particulièrement compliqué, il suffit de :

• récupérer les sources sur github
• s'assurer que personne n'utilise le cluster
• s'assurer que les variables d'environnement sont bien positionnées

A partir de là, le fichier bin/hibench-config.sh contient les options utiles à changer tel que le répertoire HDFS où écrire les résultats, le fichier de rapport à écrire (sur le FS local), ...

Une fois que tout cela est configuré et que le répertoire d'entrée sur HDFS existe, il suffit de lancer bin/run-all.sh et d'aller prendre un café... ou deux.

Interpréter les résultats

Les résultats sont écrits dans le fichier hibench.report dans le format CSV suivant :

_test_name end_date <jobstart_timestamp,jobend__timestamp> size_in_bytes duration_ms throughput

Attention, le fichier ne contient pas les entêtes décrit au dessus.

Le test DFSIO écrit en plus un CSV et une interprétation des résultats dans son sous répertoire dfsioe.

Limitations

Support des dernières évolutions d'Hadoop

Actuellement, HiBench fonctionne sur Hadoop 1.0. Cela signifie que les dernières versions des distributions de Cloudera ou HortonWorks par exemple ne fonctionneront pas forcément avec.

Ces dernières reposent en effet sur Hadoop 2.

Cependant, l'effort de port pour supporter Hadoop 2 est mineur pour la majorité des tests puisqu'il s'agit surtout de mettre à jour des noms de paramètres de configuration.

D'autre part, HiBench ne se suffit pas à lui même. Il est nécessaire de récupérer aussi les informations du JobTracker / ResourceManager concernant les temps moyen d'execution des Map, des Reduces, des Shuffle et des Merge de chaque job afin d'obtenir des informations plus précises.

Un référentiel de benchmarks, gros manque actuel

Un manque que HiBench a essayé de combler sans succès pour le moment est la construction d'un référentiel des benchmarks sur les clusters Hadoop.

L'intention est très claire lorsque l'on regarde le wiki du projet qui ne contient qu'une page invitant à déposer les résultats de tests de perfs.

Il serait intéressant qu'elle soit suivie ou qu'émerge un référentiel permettant de valider que les performances de son cluster sont dans les normes.

Des alternatives ?

Une autre solution existe mais est plus focalisée sur un profil d'utilisation particulier.

GridMix

GridMix est inclus dans Hadoop aux côtés des jobs d'exemple TeraSort, Sort, ...

Cependant ce dernier génère des jobs MapReduce orientés tri de large volumes de données et n'adresse donc pas par exemple l'aspect Machine Learning.

Conclusion

Malgré ces quelques défauts de jeunesse, HiBench simplifie grandement la conduite de benchmarks pertinents sur un cluster Hadoop.

Gageons que le domaine va se structurer sous peu avec de nouvelles solutions plus faciles à prendre en main et contenant plus de profils d'utilisation.