Représenter la phase de reduce d’un job MapReduce comme une instance MASTA permet de
bénéficier des propriétés de convergence et de monotonie démontrées dans le chapitre 4. En
attribuant un agent à chaque nœud reducer et en faisant négocier ces agents, il est possible de diminuer l’impact des biais de la phase de reduce et réduire le makespan de l’ensemble du job. Dans un premier temps, cette section illustre comment la phase de reduce d’un job MapReduce peut être décrite par une instance MASTA. Ensuite, elle présente comment l’amélioration d’une instance MASTA permet de corriger les biais susceptibles d’apparaître lors d’une phase de reduce.
8.2.1 Description de la phase de reduce par une instance MASTA
Comme expliqué dans la section 3.2, la distribution d’un job MapReduce sur plusieurs nœuds
de calcul (ou une grappe de PCs) réclame (a) de désigner des nœuds mappers qui appliquent la fonction de map pour filtrer les données et les regrouper par clé et (b) de désigner des nœuds
reducers qui vont appliquer la fonction de reduce sur les données agrégées d’une même clé pour
produire le résultat lié à cette clé. Les deux phases étant consécutives, les rôles de mapper et de
reducer ne sont pas mutuellement exclusifs. Autrement dit, un nœud peut être successivement mapper et reducer .
Lors de la phase de map, un sous-ensemble des données est attribué à chaque mapper . Lorsqu’un
mapper applique la fonction de map sur ses données, il produit des couples (clé, valeur). Les
couples qui se réfèrent à la même clé sont regroupés en chunks. Les chunks sont des fichiers de taille limitée, c’est le nombre de valeurs que produit un mapper pour une clé qui détermine le nombre de chunks associés à cette clé. Ainsi, à la fin de la phase de map, chaque mapper a produit un ou plusieurs chunks pour chaque clé qu’il a rencontrée. Plusieurs mappers sont susceptibles d’avoir produit des chunks pour la même clé. Pour s’assurer de la cohérence du résultat, il est essentiel que tous les chunks d’une même clé soient traités par le même reducer . Pour satisfaire cette contrainte, une fonction de partition détermine quelles clés sont affiliées à quel reducer . Pour rappel, ce mécanisme est statique et déterminé avant la phase de map. En effet, l’utilisateur ne connaît pas à l’avance les clés produites par les mappers, ni quels mappers produisent quelles clés, ni la fréquence à laquelle chaque clé sera générée. Cette répartition statique des clés est la
cause du biais de partitionnement (cf. section 3.3.1).
Un reducer connaît donc l’ensemble des chunks associés aux clés qu’il doit traiter. L’exécution d’une tâche de reduce, c’est-à-dire la production du résultat lié à une clé, consiste à traiter
8.2. Liens entre un job MapReduce et une instance MASTA 119
l’ensemble des valeurs qui lui sont associées1. Les chunks représentent donc les ressources qu’un
reducer doit rassembler pour l’exécution d’une tâche de reduce.
Une fois qu’il a reconstitué l’ensemble des tâches de reduce qu’il doit exécuter, un reducer les consomment une à une. En lisant l’ensemble des chunks d’une clé, le reducer possède toutes les données sur lesquelles appliquer la fonction de reduce. Une fois que le résultat d’une tâche est produit, il est écrit sur le disque local du reducer et la tâche est considérée comme terminée. Le job MapReduce est achevé une fois que toutes les tâches de reduce ont été consommées. De ce fait, le makespan de l’allocation des tâches de reduce a un impact direct sur le temps nécessaire pour achever le job : améliorer l’allocation des tâches permet de faire décroître le temps d’exécution de l’ensemble du job.
Le tableau 8.1 décrit les correspondances entre les différents éléments d’une instance MASTA
et les composants essentiels à la distribution d’une exécution MapReduce. Comme on peut le constater, la fonction de coût est un élément essentiel à la résolution d’une instance MASTA mais ne possède pas d’équivalent explicite pour MapReduce. Une méthode simple pour déterminer le coût d’une tâche peut consister à utiliser les informations disponibles et qui reflètent son volume, par exemple le nombre de chunks ou le nombre de valeurs qui lui sont associées.
MASTA MapReduce
S
N Grappe de PCs / nœuds de calcul
A Reducers
E Possibilités de communication / d’échange de données entre les nœuds de calcul
R Chunks produits par les mappers
l Déploiement d’un reducer par nœud de calcul
d Chaque chunk se trouve sur le nœud du mapper qui l’a produit
T Tâches de reduce
P Allocation des tâches de reduce par la fonction de partitionnement
c NP
Tableau 8.1 : Équivalence entre les termes d’une instance MASTA et les composants d’une exécution MapReduce distribuée. Une exécution MapReduce distribuée ne demande pas d’estimer le coût d’une tâche : la fonction de coût c est un élément non pertinent (NP) dans le cadre applicatif habituel de MapReduce.
8.2.2 Correction des biais de la phase de reduce
Considérer la phase de reduce comme un problème MASTA permet de réallouer dynamiquement les tâches de reduce alors que celles-ci sont exécutées. Ainsi, les agents reducers utilisent le pro-
tocole décrit dans le chapitre 5pour effectuer des délégations de tâche socialement rationnelles.
Ces délégations, concurrentes aux exécutions des tâches, permettent de corriger le biais de par- titionnement en équilibrant la charge de travail parmi les nœuds reducers et par conséquent de réduire le temps d’exécution de l’ensemble du job MapReduce.
Même dans le cas d’une allocation stable, le risque qu’un des nœuds de calcul ralentisse en cours
d’exécution existe. Comme présenté dans la section4.4, le fait que les délégations de tâches soient
120 Chapitre 8. MAS4Data
réalisées pendant l’exécution des tâches permet d’affiner l’allocation de tâches tout au long de la phase de reduce. En cas de ralentissement, les agents corrigent dynamiquement l’allocation de tâches grâce aux ajustements continus permis par les délégations socialement rationnelles. Le second biais de la phase de reduce est le biais des clés coûteuses. Ce biais apparaît notamment lorsque le traitement d’un sous-ensemble de clés demande excessivement plus de temps de calcul que les autres clés. Cette disparité provoque une différence de charge de travail qui ne peut être
compensée par une meilleure allocation des tâches (cf. chapitre 3). Le biais des clés coûteuses
ne peut donc pas être résolu ni par une fonction de partition classique ni par un processus de négociation uniquement. Cependant ce biais peut être corrigé grâce à un mécanisme de découpe
de tâches basée sur l’heuristique présentée dans le chapitre 6. Une tâche de reduce peut être
découpée en répartissant ses chunks de sorte à créer plusieurs sous-tâches. La section8.3discute
des contraintes spécifiquement liées à la découpe des tâches reduce.
Comme cette section l’expose, les mécanismes et stratégies de résolution d’une instance MASTA présentés dans l’ensemble de ce manuscrit permettent de corriger les biais de la phase de reduce. En déléguant et découpant les tâches de reduce, les agents reducers sont en mesure de diminuer le makespan de l’allocation courante et ainsi de faire décroître le temps d’exécution du job
MapReduce. Cette amélioration du temps d’exécution sera mesurée dans le chapitre 9.