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.
| 
