Stratégies d'optimisation de requêtes SQL dans un écosystème Hadoop

5.1.3 Agréger en amont

Nous avons vu que la phase de « Shuffle & Merge & Sort » est coûteuse, au regard de la nécessité de transmettre les données au travers du réseau mais aussi,parce que cette phase implique des fusions et des tris à répétition.

Afin d'alléger considérablement cette charge, les Mappers peuvent agréger partiellement les données ce qui réduira la quantité de données à transmettre. Les Reducers n'auront plus qu'à effectuer un « Group By Operator » dont le mode sera « mergepartial » au lieu de « complete », ce qui sera moins coûteux.

La directive suivante devra être utilisée pour activer l'agrégation au niveau « Map » :

set hive.map.aggr=true;

5.1.4 Réaliser un « benchmark » significatif

Terminons cette partie en abordant la problématique de la réalisation d'un « benchmark » d'une requête SQL sous Hive.

Il n'y a pas de déterminisme dans le temps qui sera nécessaire pour obtenir du NameNode et des DataNodes les informations permettant de lire les données et surtout pour obtenir des containers YARN.

Ainsi, une même requête pourra avoir des temps d'exécution drastiquement différents, suivant la disponibilité du cluster. Il conviendra donc de s'affranchir au maximum de ce temps préalable à l'exécution réelle de la requête, afin de mieux évaluer son coût d'exécution.

Les directives suivantes permettent de réserver à l'avance une quantité de containers.

set hive.prewarm.enabled=trueset hive.prewarm.numcontainers=10

Suite à ses directives, nous constatons sur l'interface graphique d'administration YARN la présence de 11 containers (1 ApplicationMaster et 10 containers), chacun reposant sur une JVM de 2GB.

Bien sûr, cette préemption ne dure que le temps de la session Tez qui est défini par la directive suivante (par défaut réglé à 30 secondes) :

set tez.client.timeout-ms=30000

Il devient ainsi possible de « jouer » plusieurs fois une requête et d'estimer son temps d'exécution sans qu'il soit parasité par la phase de réservation des ressources.

Enfin, il sera intéressant d'étudier les techniques du site http://www.tpc.org/tpcds/ qui propose plusieurs méthodes de benchmarking. Celles-ci n'ont pu être étudiées dans le cadre de ce mémoire du fait de la nécessité de disposer de droits « administrateur » sur l'infrastructure Hadoop.

Mais c'est un sujet important qui devra faire l'objet d'un approfondissement durant la réalisation des projets à venir.