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

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

3.4 Discussion

Cette première partie nous a permis de mieux comprendre le Paradigme MapReduce et au travers d'un premier exemple, d'entrevoir les premiers enjeux et problématiques.

3.4.1 Du point de vue HDFS

Le NameNode répond seul aux sollicitations de toutes les applications, pour leurs besoins de lecture et d'écriture. Nous avons considéré dans notre exemple « WordCount », 3 fichiers de quelques octets. La conséquence immédiate est le besoin de solliciter 3 fois le NameNode au lieu d'une seulesi les données avaient été regroupées dans un seul fichier.

Dans ce contexte de « petits fichiers » :

Ø Le NameNode peut porter atteinte aux performances du cluster. D'une part, parce que la table d'allocation qu'il stocke en mémoire peut se saturer rapidement (au regard des 150B nécessaires pour référencer un fichier, un répertoire, un bloc). D'autre part, parce qu'il devra gérer seul un grand nombre d'opérations sur ces métadonnées (plus il y a de fichiers, plus il y a d'opérations).

Ø Les performances pourront aussi être affectées par la nécessité d'accéder simultanément à beaucoup de fichiers stockés sur les DataNodes. Prenons le cas théorique, d'un ensemble de données faisant 1GB. Selon la répartition de ces données, pouvant aller d'un seul fichier jusqu'à 10 000 fichiers, lestemps d'accès cumulés (à mettre en relation avec la taille totale à traiter) peuvent provoquer le ralentissement du cluster dans son ensemble.

nombre de fichiers

taille en bytes

nombre de blocs

par fichier

temps

d'accès total (sec)

1

1000000000

8,0

0,08

1000

1000000

1,0

10

10000

100000

1,0

100

100000

10000

1,0

1000

Tableau 1 : temps d'accès cumulés sur 1GB de données suivant le nombre de fichiers

3.4.2 Du point de vue YARN

Dans ce même contexte de « petits fichiers » :

Ø L'ApplicationMaster réalise les demandes de création de containersauprès du ResourceManager, pour exécuter des tâches Map ou Reduce sur les NodeManagers. Chaquebloc étant associé à une tâche Map (exécuté par un container), il faudra donc impliquer un plus grand nombre de containers lors de traitement sur des petits fichiers.De plus, les ressources sont négociées au travers d'une file d'attente et elles ne seront pas systématiquement disponibles en même temps.

Ø L'ApplicationMaster réalise également la gestion des tâches entre elles (notamment, leur synchronisation), et ce coût est fixe quel que soit le volume de données manipulées.Ainsi, les performances de traitement d'un grand nombre de tâches ne manipulant que peu de données seront fortement impactées.

A la lumière de ces observations, nous constatons qu'il faudra être vigilant et bien maîtriser la quantité de petits fichiers afin d'éviter de ralentir les performances du cluster et donc du traitement.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Là où il n'y a pas d'espoir, nous devons l'inventer"   Albert Camus