0

ジョブFileInputFormatの入力としてGoogle Cloud Storage のファイルを使用しようとしています。MapReduceファイルはAvro形式です。

bdutil簡単なテストとして、マスター ノードとそれぞれ 2 つのスロットを持つ 2 つのワーカー ノードで構成される小さな Hadoop2 クラスターをツールと共にデプロイしました。

ジョブを実行すると、ファイルは複数の部分に分割されます。データのロードにオフセットが使用されているログを調べることで確認できる事実。その結果、複数のマップ タスクが作成されます。これまでのところ、何も異常はありません。

ただし、これらのマップ タスクはワーカー ノード間で分散されません。代わりに、1 つのノードで 2 つのノードが開始され、他のノードはそのままのScheduled状態になります。

各ワーカーで 2 つのマップ タスクが実行されることを期待していました。これは、データがワーカー ノード (クラウド ストレージ内) でローカルに利用できず、すべてのワーカーが同等の候補になるためです。

なぜこれが起こるのですか？

4

1 に答える 1

0

YARN の動作のアーティファクトの 1 つが表示されているようです。JobTracker が効果的に Hadoop 2 の AppMaster と ResourceManager の役割を同時に果たしていた Hadoop 1 とは異なり、Hadoop 2 では ResourceManager (マスター ノードで実行されている) が実際に真新しい AppMaster をオンデマンドで YARN コンテナーにパックします。 MapReduce ジョブ。

また、少し変わったもう 1 つの概念は、「スロット」がまったくないということです。YARN コンテナーは、実際にはメモリと CPU の両方の次元でスケジュールを設定します。これは、YARN にパックされた 1 つのタスクが大量のメモリを要求するが 1 つの CPU しか要求しない場合、そうでなければ複数の map または reduce タスクをパックした可能性のあるリソース フットプリントを占有する可能性があることを意味します。

たとえば、n1-standard-2 ごとに 2 つのワーカーをデプロイしたと仮定するとhttp://<master-ip>:8088/cluster/nodes、mapreduce を実行すると、ResourceManager ページの下に次のように表示される場合があります。

... Containers  Mem Used    Mem Avail   VCores Used VCores Avail    Version
...     1       5.50 GB     0 B         1           1               2.6.0
...     2       5 GB        512 MB      2           0               2.6.0

この場合、application_masterResourceManager からのリンクにアクセスすると、ResourceManager が実際に報告された VM にパックされていることがわかりました5.5GB Mem Used, 0B Mem Avail, 1 VCores Used。同様に、私のマップ タスクは、 を報告したワーカーでのみ実行されていることがわかりました2 VCores Used。

一般に、これは、ワーカーの数を増やしたときに確実にスケーリングすることに主に関心がある場合は、特別なことをする必要がないことを意味します。NUM_WORKERS - 1そのうちの 1 台がジョブの AppMaster を実行している間に、可能なマシンにパックされた map または reduce タスクが完成するだけです。

ただし、仕事によっては、これは無駄かもしれません。既定の設定は、多数の進行中のタスクを OOM で追跡しないようにするために非常に大きな AppMaster を使用することが理にかなっている、非常に大きなジョブに最適です。カスタムファイルでNODEMANAGER_MEMORY_FRACTION、CORES_PER_MAP_TASK、CORES_PER_REDUCE_TASK、およびをオーバーライドすることで、きめの細かい設定を調整できます (または でインライン化しますが、これは、 のようなファイルを維持する場合と比較して、アップグレードのために追跡するのが難しくなります)。bdutil のコメントは、これらの設定を説明しています。CORES_PER_APP_MASTER*_env.shhadoop2_env.shmy_overrides_env.shhadoop2_env.sh

# Fraction of worker memory to be used for YARN containers
NODEMANAGER_MEMORY_FRACTION=0.8

# Decimal number controlling the size of map containers in memory and virtual
# cores. Since by default Hadoop only supports memory based container
# allocation, each map task will be given a container with roughly
# (CORES_PER_MAP_TASK / <total-cores-on-node>) share of the memory available to
# the NodeManager for containers. Thus an n1-standard-4 with CORES_PER_MAP_TASK
# set to 2 would be able to host 4 / 2 = 2 map containers (and no other
# containers). For more details see the script 'libexec/configure-mrv2-mem.py'.
CORES_PER_MAP_TASK=1.0

# Decimal number controlling the size of reduce containers in memory and virtual
# cores. See CORES_PER_MAP_TASK for more details.
CORES_PER_REDUCE_TASK=2.0

# Decimal number controlling the size of application master containers in memory
# and virtual cores. See CORES_PER_MAP_TASK for more details.
CORES_PER_APP_MASTER=2.0

特に、n1-standard-4 のような大規模なマシンに移行する場合は、単純NODEMANAGER_MEMORY_FRACTIONに小さい値に変更することを検討してください。

于 2015-06-15T18:16:34.063 に答える