4.3 Discussion
Notre approche « par l'EXPLAIN », nous a
permis de découvrir comment Hive transforme une requête SQL en
application MapReduce. Elle doit permettre de mieux appréhender toute
requête demandant un travail d'optimisation.
4.3.1 Requête avec une
restriction
Elle montre qu'un« Map-Only Job » permet
de parcourir et traiter très efficacement l'intégralité
d'une tablesans déclencher de phase « Reduce » qui
impliqueraitles phases intermédiaires« Partition &
Sort » et « Shuffle & Merge & Sort ».
ð Il serait donc intéressant d'utiliser ce mode de
traitement le plus souvent possible.
4.3.2 Requête avec une
agrégation
Ellemontre un « Map Reduce » et permet de
mieux appréhender la puissance de ce paradigme. En effet, il ne semble
plus aussi problématique que sur un SGBDR de réaliser un
« full scan » d'une table, puisque plusieurs Mappers se
répartissent le travail.
En revanche, le « Shuffle & Merge &
Sort » est coûteux du fait de la nécessité de
transmettre des données au travers du réseau, de fusionner puis
d'appliquer un tri sur les données, ce qui est particulièrement
vrai lorsque le volume de données à traiter est volumineux.
ð Il serait intéressant de transférer
uniquement les données qui seront utiles pour la suite de la
requête.
4.3.3 Requête avec une jointure et
une agrégation
Elle montre un enchaînement de deux « Map
Reduce » qui implique de lire et d'écrire plusieurs fois sur
HDFS, sollicitant donc le cluster davantage. Ainsi, les données issues
du premier « Map Reduce » seront écrites sur HDFS,
et le second « Map Reduce » commencera par les charger.
Intuitivement, ilaurait été plus immédiat que le premier
« Reduce » (de jointure) enchaîne
immédiatement sur le second « Reduce »
(d'agrégation), puisque les données auraient déjà
toutes été chargées.
ð Il faudrait pouvoir éviter d'une part des
lectures/écritures superflues sur HDFS et d'autre part, une phase
« Map » redondante qui ne ferait que lire une
deuxième fois les mêmes données.
En outre, nous remarquons que la problématique des
« petits fichiers » s'applique également dans le
contexte de Hive. La figure 13 montre que la table temporaire
générée sera composée de plusieurs fichiers et
potentiellement, de petits fichiers. Dans ce cas de figure, la
génération de petits fichiersserait liéeaux faibles
occurrences des clés dans chaque partition.
ð Fusionner en fin de traitement les petits fichiers entre
eux, permettrait d'alléger la pression exercée sur le NameNode et
ses DataNodes. De même, cela optimiserait les traitementsfuturs sur ces
données.
A l'inverse, un déséquilibre pourrait être
provoqué par une partition qui contiendrait beaucoup plus de
données que la moyenne des autres partitions. Cela pourrait provenir
d'une clé représentée bien plus fréquemment par
rapport aux autres. La charge imputée au Reducer responsable de cette
partition serait alors bien supérieure à celle des autres.
ð Il serait intéressant d'être en mesure
d'influencer Hive à l'exécution en lui indiquant comment sont
réparties les données,si elles sont
déséquilibrées.
A la lumière de toutes ces observations, nous disposons
maintenant de nombreuses pistes à explorer afin d'optimiser les
traitements de nos requêtes SQL. C'est ce que nous allons tenter de faire
dans notre prochaine partie.
| 
