condaを使用してHadoop-streamでカスタムpython解釈器を使用する

hadoop-streamツールを使用してpythonタスクをパブリッシュすると、「subprocess failed with code 1」エラーが発生しやすくなります.一般的に、このエラーは、pythonスクリプトの実行中にDatanodeが例外を起こしたためです.比較的一般的なのはpythonスクリプトの実行中にいくつかのエラーが発生したことです.これはtry文を増やすことで解決できます.また、最も一般的なのはサードパーティ製ライブラリが欠けていることです.
サードパーティ製ライブラリを欠落させる最も簡単な解決策は、もちろん、すべてのDatanodeに同じpython解釈器を導入することです.この方法は、小さなクラスタで実行できますが、クラスタノードの数が増えるたびに、新しいライブラリを追加したり、pythonバージョンを更新したりするたびに、煩雑で時間のかかる作業になります.また,ノードのpython解釈器に問題が発生した場合の並べ替えもかなり悩ましい.
以前の作業では、ネット上で説明したvirtualenvを使用してpython解釈器をパッケージングし、hadoop-streamの-archivesオプションを使用してパッケージングしたpython解釈器を各実行ノードに配布し、この解釈器を使用してpythonスクリプトを実行すると、ノードがこれらのパケットを自動的に解凍し、対応するスクリプトを実行することを指定しました.
実際の使用では、パッケージ化されたpython解釈器はテスト環境で問題なく、実際のクラスタでエラーが報告され、データとスクリプトの原因が排除された後、python解釈器の動作に問題があるのではないかと疑われます.パッケージ化されたpython解釈器をサーバに転送して実行すると、libフォルダの下にvirtualenvが作成した環境でソフトリンク形式で保存されているベースpythonライブラリがいくつか欠けていることがわかりました.したがって、パッケージされたpython解釈器が他のサーバで実行されると(サーバのpythonバージョンが異なるか、python解釈器がないか、パスが異なるなど)、これらのソフトリンクが無効になり、python解釈器の実行エラーが発生します.解決策は2つあります.
一、condaを利用してpython解釈器を作成する環境も、本稿で推奨する方法である.
この方法の利点は、virtualenvのように元の環境でpython解釈器をコピーしてpipでサードパーティ製ライブラリをインストールし、パッケージング後に移植するより良い点ではなく、任意のpythonバージョンとサードパーティ製ライブラリをインストールすることを指定できることです.
例を挙げます.
1.新規環境:

conda create -n test python=2.7.12 numpy pandas 

        2.パッケージ化され、環境ファイルは一般的にcondaディレクトリのenvsフォルダにあり、conda env listで表示できます.

tar cf test.tar test

3.hadoop-streamでタスクをコミットする:

hadoop jar /usr/lib/hadoop/hadoop-streaming.jar \
-archives test.tar \
-input /user/testfiles \
-output /user/result \ 
-mapper "test.tar/test/bin/python mapper.py" \
-file mapper.py \
-reducer"test.tar/test/bin/python reducer.py" \
-file reducer.py

二、virtualenvで環境を新規作成する際にソフトリンクを使わない
公式ドキュメントによると、virtualenvコマンドの後に--always-copyオプションを追加するとソフトリンクを使用しないことを示しているようですが、実際に使用するとエラーが発生し、私のテスト環境と関係があるかどうか分かりません(CentOS Linux release 7.2.1511、python 2.7.5)、必ず--no-setuptools--no-pip--no-wheelを追加して環境を作成することができます.しかし、これらのツールがなければサードパーティのライブラリをインストールするのは不便で、この問題を解決することができることを望んでいます.