WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

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

( Télécharger le fichier original )
par Sébastien Frackowiak
Université de Technologie de COmpiègne - Master 2 2017
  

précédent sommaire suivant

Aidez l'hopital de Montfermeil

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.

précédent sommaire suivant






Aidez l'hopital de Montfermeil

Appel aux couturier(e)s volontaires

Hack the pandemiuc !

Moins de 5 interactions sociales par jour