7
votes

Exécution d'une application de Hadoop autonome sur plusieurs cœurs CPU

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é".

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.

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.

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.

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)?

Je m'attends à ce que cela soit quelque chose de très stupide que j'ai négligé.


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.

Pour l'instant, j'ai également trouvé la solution décrite ici dans cette question .


0 commentaires

4 Réponses :


0
votes

Selon Ce fil sur La liste de courriels Hadoop.core-utilisateur , vous voudrez modifier le paramètre Mapred.TaskTracker.tasks.maximum sur le nombre maximal de tâches que vous souhaitez que votre appareil gère (qui serait le nombre de cœurs).

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 .


4 commentaires

Il n'y a pas d'option comme: mapred.tasktracker.tasks.maximum minimum , il existe des options séparées pour la carte et réduisez: Mapred.TaskTracker. {Carte | Réduire} .Tasks.maximum minimum , C'est sous le deuxième lien que vous avez affiché.


Mon interprétation de c'était que vous pouviez avoir mapper ou réduire ou aucun. Le thread e-mail est de 2007 mais l'auteur de Hadoop mentionné avec mapred.tasktracker.tasks.maximum


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.



5
votes

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.

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 mapred.tasktracker.map.tasktracker.map.tasks.maximze et mapred.tasktracker.reduce.tasks.maximum minimum Par défaut, ces options sont définies sur 2 , donc je pourrais avoir raison.

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


1 commentaires

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.



2
votes

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.

Tous ces

Mapred.TaskTracker. {Carte | Réduire} .Tasks.Maximum

Les propriétés ne s'appliquent qu'à l'Hadoop exécutée en mode distribué!

hth Joahnnes


1 commentaires

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.



0
votes

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.

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.

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.


1 commentaires

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é".