Vidéo: Diffusion et osmose 2024
Après la phase Map et avant le début de la phase Reduce, un processus de transfert, appelé shuffle et trier . Ici, les données des tâches du mappeur sont préparées et déplacées vers les nœuds où les tâches du réducteur seront exécutées. Lorsque la tâche de mappeur est terminée, les résultats sont triés par clé, partitionnés s'il existe plusieurs réducteurs, puis écrits sur le disque.
Vous pouvez voir ce concept dans la figure suivante, qui montre le flux de traitement de données MapReduce et son interaction avec les composants physiques du cluster Hadoop. (Une note rapide: Les données en mémoire sont représentées par des carrés blancs, et les données stockées sur le disque sont représentées par des carrés gris.)
Pour accélérer le processus MapReduce global, les données sont immédiatement déplacées vers les nœuds des tâches du réducteur, afin d'éviter une inondation d'activité réseau lorsque la tâche finale du mappeur termine son travail. Ce transfert se produit pendant l'exécution de la tâche de mappage, car les sorties de chaque enregistrement (mémoriser) sont stockées dans la mémoire d'une tâche de réducteur en attente. (Vous pouvez configurer si cela se produit - ou ne se produit pas - et aussi le nombre de threads impliqués.)
Gardez à l'esprit que même si une tâche de réduction peut avoir la plus grande partie de la sortie de la tâche de mappeur, le traitement de la tâche de réduction ne peut pas commencer tant que toutes les tâches de mappeur ne sont pas terminées.
Pour éviter les scénarios où la performance d'un travail MapReduce est entravée par une tâche de mappage inégale qui s'exécute sur un nœud esclave médiocrement performant, l'infrastructure MapReduce utilise un concept appelé exécution spéculative .
Dans le cas où certaines tâches de mappeur sont exécutées plus lentement que ce qui est considéré comme raisonnable, le maître d'application engendrera des tâches en double (dans Hadoop 1, le JobTracker le fait). Quelle que soit la tâche qui se termine en premier - le duplicata ou l'original - ses résultats sont stockés sur le disque et l'autre tâche est supprimée. Si vous surveillez vos travaux de près et que vous vous demandez pourquoi il y a plus de tâches de mappeur en cours que vous ne le pensez, c'est une raison probable.
La sortie des tâches de mappeur n'est pas écrite dans HDFS, mais plutôt dans le disque local sur le nœud esclave où la tâche de mappeur a été exécutée. En tant que tel, il n'est pas répliqué sur le cluster Hadoop.
Outre la compression de la sortie, vous pouvez améliorer les performances en exécutant une tâche de combinaison. Cette tactique simple, illustrée ici, consiste à effectuer une réduction locale de la sortie pour des tâches de mappeur individuelles.
Dans la majorité des cas, aucune programmation supplémentaire n'est nécessaire, car vous pouvez demander au système d'utiliser la fonction de réduction. Si vous n'utilisez pas votre fonction de réduction, vous devez vous assurer que la sortie de la fonction de combinaison est identique à celle de la fonction de réduction.
C'est à MapReduce de décider si la fonction de combinateur doit être exécutée une fois, plusieurs fois ou jamais. Il est donc essentiel que le code du combinateur garantisse que les résultats finaux ne sont pas affectés par plusieurs exécutions. L'exécution du combineur peut générer des avantages en termes de performances en diminuant la quantité de données intermédiaires qui devraient sinon être transférées sur le réseau.
Cela réduit également la quantité de traitement que les tâches du réducteur doivent effectuer. Vous exécutez ici une tâche supplémentaire, il est donc possible que tout gain de performance soit négligeable ou puisse même entraîner des performances globales moins bonnes. Votre kilométrage peut varier, alors testez-le attentivement.
Une fois tous les résultats des tâches de mappage copiés dans les noeuds des tâches du réducteur, ces fichiers sont fusionnés et triés.
