Mon équipe a construit une application Java à l'aide des bibliothèques Hadoop pour transformer un tas de fichiers d'entrée en sortie utile. Compte tenu de la charge actuelle, un seul serveur multicore fera bien pour l'année à venir. Nous n'avons pas (encore) la nécessité de choisir un cluster Hadoop multisserver, mais nous avons choisi de démarrer ce projet "préparé". P>
Quand j'exécute cette application sur la ligne de commande (ou dans Eclipse ou Netbeans), je n'ai pas encore été en mesure de la convaincre d'utiliser plus qu'une carte et / ou réduire le fil à la fois. Compte tenu du fait que l'outil est très important de la CPU cette "filetage unique" est mon goulot d'étranglement actuel. P>
Lorsque vous l'utilisez dans le profileur NetBeans, je vois que l'application démarre plusieurs threads à diverses fins, mais seule une seule carte / réduction est en cours d'exécution au même moment. P>
Les données d'entrée consistent en plusieurs fichiers d'entrée afin que Hadoop devrait au moins pouvoir exécuter 1 thread par fichier d'entrée en même temps pour la phase de carte. P>
Que dois-je faire au moins 2 ou même 4 threads actifs fonctionnant (ce qui devrait être possible pour la plupart du temps de traitement de cette application)? P>
Je m'attends à ce que cela soit quelque chose de très stupide que j'ai négligé. P>
Je viens de trouver ceci: https://issues.apache.org/jira/ Parcourir / Mapreduce-1367 Cela implémente la fonctionnalité que je cherchais dans Hadoop 0.21 Il introduit le drapeau mapreduce.local.map.tasks.maximum minimum pour le contrôler. P>
Pour l'instant, j'ai également trouvé la solution décrite ici dans cette question . p>
4 Réponses :
Selon Ce fil sur La liste de courriels Hadoop.core-utilisateur , vous voudrez modifier le paramètre Ceci (et d'autres propriétés que vous souhaiterez peut-être configurer) est également documentée dans la documentation principale sur la configuration de votre cluster / Daemons . P> Mapred.TaskTracker.tasks.maximum code> sur le nombre maximal de tâches que vous souhaitez que votre appareil gère (qui serait le nombre de cœurs). p>
Il n'y a pas d'option comme: mapred.tasktracker.tasks.maximum minimum code>, il existe des options séparées pour la carte et réduisez:
Mapred.TaskTracker. {Carte | Réduire} .Tasks.maximum minimum code>, C'est sous le deuxième lien que vous avez affiché.
Mon interprétation de c'était que vous pouviez avoir mapper code> ou
réduire code> ou aucun. Le thread e-mail est de 2007 mais l'auteur de Hadoop mentionné avec
mapred.tasktracker.tasks.maximum code>
Eh bien, cet email est à partir de 2007, il s'agit probablement de la version avant 0,16 de Hadoop, car des options distinctes pour les mappeurs et les réducteurs ont été introduites dans 0,16 (et 0,16 ont été introduites quelque part vers 2008) Jetez un oeil à: hadoop.apache.org/common/docs/r0.15.2/... et hadoop.apache .Org / Common / Docs / R0.16.0 / ...
Je viens de trouver que mapred.tasktracker.tasks.maximumizimum a été obsolète dans Hadoop 0.16 ( Problèmes.APache .org / jira / parcourir / hadoop-1274 ) et est maintenant mapred.tasktracker. {Carte | Réduire} .Tasks.maximum.
Je ne sais pas si je suis correct, mais lorsque vous exécutez des tâches en mode local, vous ne pouvez pas avoir plusieurs mappeurs / réducteurs. P>
Quoi qu'il en soit, pour définir le nombre maximal de mappeurs d'exécution et de réducteurs utilisez des options de configuration Enfin, si vous souhaitez être préparé pour le cluster multinode, allez-le en exécutant ceci à une manière entièrement distribuée, mais que tous les serveurs (Namenode, Datanode, Tasktracker, Jobtracker, ...) s'exécutent sur une seule machine P > mapred.tasktracker.map.tasktracker.map.tasks.maximze code> et
mapred.tasktracker.reduce.tasks.maximum minimum code> Par défaut, ces options sont définies sur
2 code>, donc je pourrais avoir raison. P>
Merci, à cause de votre observation, j'ai téléchargé la source et creusé à travers cela. J'ai trouvé que lors de la course en mode local, l'org.apache.hadoop.mapred.localjobrunner est utilisé pour exécuter le travail. La méthode Run () fait simplement tout ce que séquentiellement. Pas de filetage du tout. J'ai trouvé org.apache.hadoop.mapreduce.lib.map.multhreadedMapper Une fonctionnalité très étrange: une implémentation de mapper qui enfilait en dehors du cadre de Hadoop. Selon la documentation uniquement utile si vous n'êtes pas obligé de CPU. Notre outil est cpu lié afin que nous ne puissions pas l'utiliser.
juste pour clarification ... Si Hadoop fonctionne en mode local, vous n'avez pas d'exécution parallèle sur un niveau de tâche (sauf que vous exécutez> = Hadoop 0.21 ( Mapreduce-1367 )). Bien que vous puissiez soumettre plusieurs travaux à la fois et que ceux-ci sont exécutés en parallèle, alors. P>
Tous ces p>
Mapred.TaskTracker. {Carte | Réduire} .Tasks.Maximum P> blockQuote>
Les propriétés ne s'appliquent qu'à l'Hadoop exécutée en mode distribué! p>
hth Joahnnes P>
Correct. La façon dont je l'ai couru il y a deux ans ( Stackoverflow.com/questions/3546025 ) n'allait en exécutant qu'un emploi et une tâche. Ce n'est donc pas local et seulement à mi-chemin de pseudo-distribué. Cela facilite l'utilisation de plusieurs cœurs CPU sans la fonctionnalité de 0,21 que vous avez mentionnée.
Ce que vous voulez faire, c'est exécuter Hadoop en mode "pseudo-distribué". Une machine, mais, exécutant des trackers de tâches et des nœuds de nom comme s'il s'agissait d'un vrai groupe. Ensuite, il va (potentiellement) plusieurs travailleurs. P>
Notez que si votre contribution est petite Hadoop décidera qu'il ne vaut pas la peine de paralléliser. Vous devrez peut-être le coaxer en modifiant sa taille de division par défaut. P>
Dans mon expérience, "Typique" Les emplois Hadoop sont des I / O liés, parfois liés à la mémoire, avant qu'ils ne soient liés à la CPU. Vous trouverez peut-être impossible d'utiliser pleinement tous les noyaux sur une machine pour cette raison. P>
Pour le travail lié à la CPU, cette question était à peu près (il y a presque 2 ans), c'était bien de le faire courir sur plusieurs cœurs CPU sans HDFS. D'où une forme dépouillée de mode "pseudo-distribué".