GCE Hadoop 工作节点上的 reducer 插槽数量是多少？

Question

我正在 Google Compute Engine 的 Hadoop 集群上测试一些 MapReduce 作业的扩展，并发现了一些意想不到的结果。简而言之，有人告诉我这种行为可能是由于 Hadoop 集群中每个工作节点都有多个 reducer 槽。

有人可以确认 GCE 的 Hadoop 集群上 MapReduce 作业的每个工作节点（工作虚拟机）的 reducer 槽数吗？我正在使用 hadoop2_env.sh 部署。

https://groups.google.com/a/cloudera.org/forum/#!topic/oryx-user/AFIU2PE2g8o 提供 link 背景讨论，以讨论我遇到的行为，如果需要，可提供更多详细信息。

谢谢！

Answer 1

在bdutil中，reduce槽的数量是机器上核心总数和环境变量CORES_PER_REDUCE_TASK的函数，在configure_hadoop.sh中应用：

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 设置为大约等于您拥有的 reduce 插槽数。如果您使用的是默认设置，只需将您拥有的机器数量乘以每台机器的核心数，除以 2 即可知道插槽数。如果您希望每台机器有 1 个 reduce 插槽，请将 CORES_PER_REDUCE_TASK 设置为每台机器的核心数。

我之所以说大约是因为在设置工作中的 reduce 任务数量方面还有其他高级设置，包括 "speculative execution" 设置；一个典型的建议是将你的 reduce parallelism 设置得少一点，可能是 reduce slots 数量的 0.95 倍；这为失败或卡住的 reduce 任务留出了一些空间。

此外，您可能已经看到一些情况下，当您将并行度增加到超过 reduce 插槽的数量时，性能会更快，尽管由于速度差异很大，需要执行多个 "waves"，预计速度会降低不同的减少任务。在某些存在高差异的工作负载中，第二个 "wave" 可以有效地运行与第一个 "wave" 中最慢的任务并发；之前关于该主题的 Hadoop wiki gave a rule of thumb of setting reduce parallelism to either 0.95 or 1.75 times the number of available reduce slots. Here's some further discussion；那里的海报正确地指出这些仅适用于单租户集群。

如果您真的想与大量用户并发共享一个大型集群，则这些经验法则不适用，因为您应该完全根据工作负载的大小和特征来分配并行度，因为您不会不想占用 100% 的集群资源。但是，在云环境中推荐的方法确实是拥有多个较小的单租户集群，因为您可以随后专门针对所需的工作负载调整每个集群，而无需担心大量不同用途之间的资源打包问题案例。

GCE Hadoop 工作节点上的 reducer 插槽数量是多少？

What is the number of reducer slots on GCE Hadoop worker nodes?

hadoop

mapreduce

google-compute-engine

google-hadoop