Vidéo: Hadoop Processing Frameworks 2025
Une application MapReduce traite les données dans les divisions d'entrée sur une base enregistrement par enregistrement et chaque enregistrement est compris par MapReduce comme une valeur / clé paire. Une fois les divisions d'entrée calculées, les tâches de mappeur peuvent commencer à les traiter, c'est-à-dire juste après que la fonction de planification du gestionnaire de ressources leur a assigné leurs ressources de traitement. (Dans Hadoop 1, JobTracker affecte des tâches de mappage à des emplacements de traitement spécifiques.)
La tâche de mappeur elle-même traite son enregistrement d'entrée séparé à la fois - dans la figure, cet enregistrement isolé est représenté par la paire clé / valeur. Dans le cas de nos données de vol, lorsque les divisions d'entrée sont calculées (en utilisant la méthode de traitement de fichiers par défaut pour les fichiers texte), l'hypothèse est que chaque ligne du fichier texte est un enregistrement unique.
Pour chaque enregistrement, le texte de la ligne elle-même représente la valeur et le décalage d'octet de chaque ligne à partir du début de la division est considéré comme la clé.
Vous vous demandez peut-être pourquoi le numéro de ligne n'est pas utilisé à la place du décalage d'octet. Lorsque vous considérez qu'un fichier texte très volumineux est décomposé en plusieurs blocs de données individuels et qu'il est traité en autant de divisions, le numéro de ligne est un concept risqué.
Le nombre de lignes dans chaque division varie, il serait donc impossible de calculer le nombre de lignes précédant celui en cours de traitement. Cependant, avec le décalage d'octets, vous pouvez être précis, car chaque bloc a un nombre fixe d'octets.
Lorsqu'une tâche de mappage traite chaque enregistrement, elle génère une nouvelle paire clé / valeur: La clé et la valeur ici peuvent être complètement différentes de la paire d'entrées. La sortie de la tâche de mappage est la collection complète de toutes ces paires clé / valeur.
Avant d'écrire le fichier de sortie final pour chaque tâche de mappage, la sortie est partitionnée en fonction de la clé et triée. Ce partitionnement signifie que toutes les valeurs de chaque clé sont regroupées.
Dans le cas de l'exemple d'application relativement basique, il n'y a qu'un seul réducteur, de sorte que toute la sortie de la tâche de mappage est écrite dans un seul fichier. Mais dans les cas avec plusieurs réducteurs, chaque tâche de mappeur peut également générer plusieurs fichiers de sortie.
La décomposition de ces fichiers de sortie est basée sur la clé de partitionnement. Par exemple, s'il n'y a que trois clés de partitionnement distinctes pour les tâches du mappeur et que vous avez configuré trois réducteurs pour le travail, il y aura trois fichiers de sortie du mappeur. Dans cet exemple, si une tâche de mappeur particulière traite une division d'entrée et qu'elle génère une sortie avec deux des trois clés, il n'y aura que deux fichiers de sortie.
Toujours compresser les fichiers de sortie de vos tâches de mappeur. Le plus grand avantage ici est dans les gains de performance, car l'écriture de fichiers de sortie plus petits minimise le coût inévitable du transfert de la sortie du mappeur vers les nœuds où les réducteurs sont en cours d'exécution.
Le partitionneur par défaut est plus qu'adéquat dans la plupart des situations, mais parfois vous pouvez vouloir personnaliser la façon dont les données sont partitionnées avant qu'elles ne soient traitées par les réducteurs. Par exemple, vous souhaiterez peut-être trier les données de vos ensembles de résultats en fonction de la clé et de leurs valeurs, appelées tri secondaire .
Pour ce faire, vous pouvez remplacer le partitionneur par défaut et implémenter le vôtre. Cependant, ce processus nécessite quelques précautions, car vous devez vous assurer que le nombre d'enregistrements dans chaque partition est uniforme. (Si un réducteur doit traiter beaucoup plus de données que les autres réducteurs, vous attendez que votre travail MapReduce se termine alors que le réducteur surchargé surcharge son ensemble de données démesurément grand.)
En utilisant des fichiers intermédiaires de taille uniforme, vous peut mieux tirer parti du parallélisme disponible dans le traitement MapReduce.
