Travail en continu Hadoop utilisant Mxnet défaillant dans AWS Emr

J'ai configuré une étape emr dans AWS datapipeline. La commande étape ressemble à ceci:Travail en continu Hadoop utilisant Mxnet défaillant dans AWS Emr

/usr/lib/hadoop-mapreduce/hadoop-streaming.jar,-input,s3n://input-bucket/input-file,-output,s3://output/output-dir,-mapper,/bin/cat,-reducer,reducer.py,-file,/scripts/reducer.py,-file,/params/parameters.bin

Je reçois l'erreur suivante

Error: java.lang.RuntimeException: PipeMapRed.waitOutputThreads(): subprocess failed with code 1 
    at org.apache.hadoop.streaming.PipeMapRed.waitOutputThreads(PipeMapRed.java:322) 
    at org.apache.hadoop.streaming.PipeMapRed.mapRedFinished(PipeMapRed.java:535) 
    at org.apache.hadoop.streaming.PipeReducer.close(PipeReducer.java:134) 
    at org.apache.hadoop.io.IOUtils.cleanup(IOUtils.java:244) 
    at org.apache.hadoop.mapred.ReduceTask.runOldReducer(ReduceTask.java:467) 
    at org.apache.hadoop.mapred.ReduceTask.run(ReduceTask.java:393) 
    at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:164) 
    at java.security.AccessController.doPrivileged(Native Method) 
    at javax.security.auth.Subject.doAs(Subject.java:422) 
    at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1698) 
    at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:158) 

Container killed by the ApplicationMaster. 
Container killed on request. Exit code is 143 
Container exited with a non-zero exit code 143 

Error: java.lang.RuntimeException: PipeMapRed.waitOutputThreads(): subprocess failed with code 1 
    at org.apache.hadoop.streaming.PipeMapRed.waitOutputThreads(PipeMapRed.java:322) 
    at org.apache.hadoop.streaming.PipeMapRed.mapRedFinished(PipeMapRed.java:535) 
    at org.apache.hadoop.streaming.PipeReducer.close(PipeReducer.java:134) 
    at org.apache.hadoop.io.IOUtils.cleanup(IOUtils.java:244) 
    at org.apache.hadoop.mapred.ReduceTask.runOldReducer(ReduceTask.java:467) 
    at org.apache.hadoop.mapred.ReduceTask.run(ReduceTask.java:393) 
    at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:164) 
    at java.security.AccessController.doPrivileged(Native Method) 
    at javax.security.auth.Subject.doAs(Subject.java:422) 
    at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1698) 
    at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:158) 

Container killed by the ApplicationMaster. 
Container killed on request. Exit code is 143 
Container exited with a non-zero exit code 143

J'ai essayé de courir pas réducteur séparément sur mon bureau (sur un seul noeud configuration Hadoop) et son fonctionnement. J'ai déjà inclus le #!/usr/bin/env python dans le script réducteur. ~~Je suppose que je n'écris pas l'étape EMR correctement.~~

EMR version: 5.5.0

EDIT: Après une enquête plus approfondie, j'ai trouvé la ligne exacte du code où le code réducteur manque à RME. Je fais des prédictions d'apprentissage automatique en utilisant la bibliothèque mxnet dans le réducteur. Lorsque je charge les paramètres du modèle, le réducteur échoue. Référence API doc est here

module.load_params('parameters.bin')

J'ai vérifié le répertoire courant du noeud DME [en utilisant os.listdir(os.getcwd())] et il contient le fichier parameters.bin (j'ai même imprimé le contenu du fichier avec succès). Je tiens à souligner à nouveau que le travail de diffusion fonctionne correctement sur mon installation locale à nœud unique.

EDIT2: Je mets le nombre de tâches de réducteur à 2. Je joint mon code réducteur dans un try-except bloc et je vois l'erreur suivante dans l'une des tâches (l'autre fonctionne très bien)

[10:27:25] src/ndarray/ndarray.cc:299: Check failed: from.shape() == to->shape() operands shape mismatchfrom.shape = (119,) to.shape=(111,) 

Stack trace returned 10 entries:  
[bt] (0) /usr/local/lib/python2.7/site-packages/mxnet/libmxnet.so(+0xc72fc) [0x7f81443842fc]  
[bt] (1) /usr/local/lib/python2.7/site-packages/mxnet/libmxnet.so(+0xc166f4) [0x7f8144ed36f4] 
[bt] (2) /usr/local/lib/python2.7/site-packages/mxnet/libmxnet.so(+0xc74c24) [0x7f8144f31c24] 
[bt] (3) /usr/local/lib/python2.7/site-packages/mxnet/libmxnet.so(MXImperativeInvoke+0x2cd) [0x7f8144db935d]  
[bt] (4) /usr/lib64/libffi.so.6(ffi_call_unix64+0x4c) [0x7f8150b8acec] 
[bt] (5) /usr/lib64/libffi.so.6(ffi_call+0x1f5) [0x7f8150b8a615]  
[bt] (6) /usr/lib64/python2.7/lib-dynload/_ctypes.so(_ctypes_callproc+0x30b) [0x7f8150d9d97b] 
[bt] (7) /usr/lib64/python2.7/lib-dynload/_ctypes.so(+0xa915) [0x7f8150d97915] 
[bt] (8) /usr/lib64/libpython2.7.so.1.0(PyObject_Call+0x43) [0x7f815a69e183]  
[bt] (9) /usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x337d) [0x7f815a73107d]

Source

2017-05-17 ishan3243

Veuillez mettre à jour la question avec votre code car le code de sortie 1 peut être dû à un mauvais code. –

@RameshMaharjan Comme je l'ai déjà souligné, j'ai essayé d'exécuter le code avec un seul cluster de nœuds sur mon bureau et cela fonctionne très bien. – ishan3243

Est-il possible de: * fournir la version du MXNet installé; * fournir le fichier 'parameters.bin'; Il semble qu'à un moment donné, MXNet s'attend à ce que la forme d'un tenseur diffère de ce qu'il obtient réellement. –

J'ai trouvé le problème. En fait, les formes attendues par mxnet dépendaient de l'ensemble de données (cela dépendait en fait de la valeur maximale dans l'ensemble de données). La formation se passe sur une seule boîte de gpu et contient l'ensemble des données. La prédiction cependant, fonctionne bien avec la configuration de nœud unique car elle a toutes les données utilisées dans la formation. Mais lorsque le cluster multi-nœuds est utilisé, l'ensemble de données est divisé, ce qui rend la valeur max différente pour chaque nœud. Cela causait l'erreur.

J'ai maintenant rendu les formes attendues indépendantes de l'ensemble de données et cette erreur ne se produit plus. J'espère que cela clarifie les choses.

Source

2017-08-01 07:10:08 ishan3243

Travail en continu Hadoop utilisant Mxnet défaillant dans AWS Emr

Répondre

Questions connexes