1

Google Compute Engine の Hadoop クラスタでいくつかの MapReduce ジョブのスケーリングをテストしており、予期しない結果がいくつか見つかりました。要するに、この動作は、Hadoop クラスター内の各ワーカー ノードごとに複数のレデューサー スロットがあることで説明できると言われています。

GCE の Hadoop クラスターでの MapReduce ジョブのワーカー ノード (ワーカー VM) あたりのレデューサー スロットの数を確認できますか? hadoop2_env.sh デプロイメントを使用しています。

https://groups.google.com/a/cloudera.org/forum/#!topic/oryx-user/AFIU2PE2g8oは、必要に応じて追加の詳細について、私が経験している動作に関する背景説明へのリンクを提供します。

ありがとう！

4

1 に答える 1

1

ではbdutil、reduce スロットの数は、マシン上のコアの総数と環境変数の関数であり、configure_hadoop.shCORES_PER_REDUCE_TASK内で適用されます。

export NUM_CORES="$(grep -c processor /proc/cpuinfo)"
export MAP_SLOTS=$(python -c "print int(${NUM_CORES} // \
    ${CORES_PER_MAP_TASK})")
export REDUCE_SLOTS=$(python -c "print int(${NUM_CORES} // \
    ${CORES_PER_REDUCE_TASK})")

<...>

# MapReduce v2 (and YARN) Configuration
if [[ -x configure_mrv2_mem.py ]]; then
  TEMP_ENV_FILE=$(mktemp /tmp/mrv2_XXX_tmp_env.sh)
  ./configure_mrv2_mem.py \
      --output_file ${TEMP_ENV_FILE} \
      --total_memory ${TOTAL_MEM} \
      --available_memory_ratio ${NODEMANAGER_MEMORY_FRACTION} \
      --total_cores ${NUM_CORES} \
      --cores_per_map ${CORES_PER_MAP_TASK} \
      --cores_per_reduce ${CORES_PER_REDUCE_TASK} \
      --cores_per_app_master ${CORES_PER_APP_MASTER}
  source ${TEMP_ENV_FILE}
  # Leave TMP_ENV_FILE around for debugging purposes.
fi

hadoop2_env.shデフォルトでは、reduce スロットあたり 2 コアであることがわかります。

CORES_PER_REDUCE_TASK=2.0

最適な設定はワークロードによって異なる場合がありますが、ほとんどの場合、これらのデフォルト設定で問題ありません。リンクしたスレッドで述べたように、従うことができる一般的なアプローチは、実際のワークロードであり、computation-layer.parallelism持っている削減スロットの数とほぼ同じに設定します。デフォルト設定を使用している場合は、所有しているマシンの数にマシンあたりのコア数を掛けて、スロットの数を知るために 2 で割ります。マシンごとに 1 つの削減スロットが必要な場合はCORES_PER_REDUCE_TASK、cores-per-machine に等しく設定します。

「投機的実行」設定を含む、ジョブの削減タスクの数を設定するための追加の詳細設定があるため、おおよそのことを言います。典型的な推奨事項は、reduce 並列処理を少し少なく設定することです。おそらく、reduce スロット数の 0.95 倍です。これにより、reduce タスクが失敗したりスタックしたりするための余裕が少しできます。

さらに、reduce スロットの数を超えて並列処理を増やした場合、複数の「ウェーブ」を実行する必要があるために予想される速度低下にもかかわらず、さまざまな reduce タスクの速度に大きなばらつきがあるため、パフォーマンスが向上する場合が見られる場合があります。変動が大きい特定のワークロードでは、2 番目の「ウェーブ」は、最初の「ウェーブ」の最も遅いタスクと同時に効果的に実行できます。以前、Hadoop wikiでは、reduce 並列処理を使用可能な reduce スロットの数の 0.95 倍または 1.75 倍に設定する経験則が示されていました。このトピックに関する詳細な議論は次のとおりです。そこのポスターは、これらが単一テナント クラスタにのみ適用されることを正しく指摘しています。

大規模なクラスターを実際に多数のユーザーと同時に共有したい場合、これらの経験則は適用されません。100 を独り占めしたくないため、ワークロードのサイズと特性に基づいて並列処理を割り当てる必要があるためです。クラスタ リソースの %。ただし、クラウド環境で推奨されるアプローチは、複数の小さなシングルテナント クラスターを使用することです。これは、必要なワークロードに合わせて各クラスターを調整でき、さまざまな用途でのリソース パッキングについて心配する必要がないためです。ケース。

于 2015-04-03T17:17:46.693 に答える