Divise dans MapReduce de Hadoop - des nuls

La façon dont HDFS a été configuré, il décompose de très gros fichiers en gros blocs (par exemple, 128 Mo), et stocke trois copies de ces blocs sur différents nœuds du cluster HDFS n'a pas conscience du contenu de ces fichiers

Dans YARN, lorsqu'un travail MapReduce est démarré, le Gestionnaire de ressources (la gestion des ressources de cluster et la planification des jobs) crée un démon Application Master pour prendre en charge le cycle de vie du travail (dans Hadoop 1, le JobTracker surveillait des tâches individuelles et gérait la planification des tâches et la gestion des ressources de cluster.)

> L'une des premières choses que fait le maître d'application est de déterminer quels blocs de fichiers sont nécessaires pour le traitement.Le maître d'application demande des détails au NameNode où sont stockées les répliques des blocs de données nécessaires. Le maître d'application envoie des requêtes à la ressource Le gestionnaire doit avoir des tâches de carte qui traitent des blocs spécifiques sur les nœuds esclaves où ils sont stockés.

La clé du traitement efficace de MapReduce est que, dans la mesure du possible, les données sont traitées

localement - sur le nœud esclave où il est stocké. Avant de voir comment les blocs de données sont traités, vous devez examiner de plus près comment Hadoop stocke les données. Dans Hadoop, les fichiers sont composés d'enregistrements individuels, qui sont finalement traités un par un par des tâches de mappage.

Par exemple, l'échantillon de données contient des informations sur les vols terminés aux États-Unis entre 1987 et 2008.

Pour télécharger l'exemple de fichier, ouvrez le navigateur Firefox à partir de la machine virtuelle et accédez à la page dataexpo.

Vous avez un fichier volumineux pour chaque année, et dans chaque fichier, chaque ligne individuelle représente un seul vol. En d'autres termes, une ligne représente un enregistrement. Maintenant, souvenez-vous que la taille de bloc pour le cluster Hadoop est de 64 Mo, ce qui signifie que les fichiers de données de lumière sont divisés en blocs de 64 Mo exactement.

Voyez-vous le problème? Si chaque tâche de carte traite tous les enregistrements d'un bloc de données spécifique, qu'advient-il de ces enregistrements qui s'étendent sur des limites de blocs? Les blocs de fichiers font exactement 64 Mo (ou ce que vous définissez comme taille de bloc), et parce que HDFS n'a aucune idée de ce qu'il y a dans les blocs de fichiers, il ne peut pas déterminer si un enregistrement peut déborder dans un autre bloc.

Pour résoudre ce problème, Hadoop utilise une représentation logique des données stockées dans les blocs de fichiers, appelées

splits d'entrée . Lorsqu'un client de travail MapReduce calcule les divisions d'entrée, il détermine où commence le premier enregistrement complet dans un bloc et où se termine le dernier enregistrement dans le bloc. Dans les cas où le dernier enregistrement d'un bloc est incomplet, le partage d'entrée inclut les informations d'emplacement pour le bloc suivant et le décalage d'octet des données nécessaires pour compléter l'enregistrement.

La figure montre cette relation entre les blocs de données et les divisions d'entrée.

Vous pouvez configurer le démon Application Master (ou JobTracker, si vous êtes dans Hadoop 1) pour calculer les divisions d'entrée au lieu du client de travail, ce qui serait plus rapide pour les travaux traitant un grand nombre de blocs de données.

Le traitement des données MapReduce est guidé par ce concept de partage d'entrée. Le nombre de divisions d'entrée calculées pour une application spécifique détermine le nombre de tâches de mappeur. Chacune de ces tâches de mappage est affectée, si possible, à un nœud esclave où la division d'entrée est stockée. Le gestionnaire de ressources (ou JobTracker, si vous êtes dans Hadoop 1) fait de son mieux pour s'assurer que les divisions d'entrée sont traitées localement.