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

Appel aux couturier(e)s volontaires

5.1.2 Contrôler la taille des fichiers manipulés

Comme nous l'avons vu dans le chapitre précédent, la phase « Reduce » est génératrice de fichiers et selon la qualité du partitionnement (homogénéité de la représentation d'une clé), leur quantité pourra varier. Lorsque ces fichiers sont de petite taille, toutes les couches composant Hadoop sont impactées.

Montrons comment il est possible d'optimiser la taille des fichiers manipulés, soit en phase de lecture (Map), soit en phase d'écriture (Reduce).

5.1.2.1 durant la phase de lecture (Map)

Une étape « Map » ayant à traiter de nombreux petits fichiers, engendrera beaucoup de Mappers (et donc de containers YARN)qui devront solliciter massivement le HDFS au travers du NameNode et de ses DataNodes pourlire leurs données.

Tez permet de consommer moins de Mappers en créant des groupes de splits (Bikas Saha, 2016 + annexe).

Pour rappel, un split est un pointeur sur un blocHDFS et indique à un Mapper l'emplacement des données à traiter.

Les options suivantes permettent de définir la taille d'un groupe :

settez.grouping.min-size=16777216; -- 16 MB min splitset tez.grouping.max-size=1073741824; -- 1 GB max split

Il est également possible de procéder de la façon suivante, en définissant le nombre de splits que contiendra un groupe (ce paramétrage est prioritaire par rapport au précédent) :

set tez.grouping.split-count=50;

Cette approche est très pratique mais n'empêche pas la sollicitationde HDFS, car il faudra bien que le NameNode soit interrogé pour indiquer l'emplacement des blocs de données. Il est donc nécessaire d'agir en amont (c'est-à-dire durant le processus de création des fichiers) afin d'éviter cela. Or, les données traitées par les Mappers pourront être issues de phases Reduce de traitements antérieurs. Il faudra donc agir au niveau de la phase Reduce.

5.1.2.2 durant la phase d'écriture (Reduce)

Le problème provient des étapes« Reduce » utilisant de nombreuses partitions et qui devront également solliciter massivement le HDFS.En effet, elles devront générer un fichier par partition.

Il est possible d'indiquer à Hive de réaliser une étape « Map » supplémentaire consistant à fusionner ces fichiers et ainsi permettre pour un prochain traitement d'alléger la pression exercée sur le HDFS (Hao Zhu, 2014). Nous aurons ainsi obtenu un traitement du type Map Reduce HDFS Map.

Pour ce faire, les directives à utiliser sont les suivantes :

Pour Tez :

set hive.merge.tezfiles=true;set hive.merge.smallfiles.avgsize=16000000;set hive.merge.size.per.task=128000000;

Pour MapReduce :

set hive.merge.mapredfiles=true;set hive.merge.mapfiles=true;set hive.merge.smallfiles.avgsize=16000000;set hive.merge.size.per.task=128000000;

- Les directives en rouge activent le mécanisme de fusion

- Les deux autres directives définissent respectivement

o la taille moyenne d'un petit fichier (16MB).

o la taille des fichiers générés (128MB).

Il est important de désactiver la compression des données, sinon la fusion des petits fichiers ne fonctionnera pas(Hao Zhu, 2015) une fusion de deux fichiers compressés n'étant pas réalisable.

set hive.exec.compress.output=false;

Il d'autant plus important de le savoir qu'aucune erreur ne sera signalée en cas d'échec de la fusion durant la phase de Map réalisant l'opération.

précédent sommaire suivant






Aidez l'hopital de Montfermeil




Moins de 5 interactions sociales par jour