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

【问题标题】：What is the number of reducer slots on GCE Hadoop worker nodes?GCE Hadoop 工作节点上的 reducer 插槽数是多少？
【发布时间】：2015-06-06 13:34:31
【问题描述】：

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

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

https://groups.google.com/a/cloudera.org/forum/#!topic/oryx-user/AFIU2PE2g8o 提供了一个关于我正在经历的行为的背景讨论的链接，如果需要，可以提供更多详细信息。

谢谢！

【问题讨论】：

标签： hadoop mapreduce google-compute-engine google-hadoop

【解决方案1】：

在bdutil中，reduce slot的数量是机器上内核总数和环境变量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 slot 2 个核心：

CORES_PER_REDUCE_TASK=2.0

最佳设置可能因工作负载而异，但在大多数情况下，这些默认设置应该没问题。如您链接的线程中所述，您可以遵循的一般方法是在您的实际工作负载中，将computation-layer.parallelism 设置为大约等于您拥有的减少插槽数。如果您使用默认设置，只需将您拥有的机器数量乘以每台机器的核心数除以 2 即可知道插槽数。如果您希望每台机器有 1 个减少插槽，请将 CORES_PER_REDUCE_TASK 设置为等于每台机器的核心数。

我说大概是因为在设置作业中减少任务的数量还有其他高级设置，包括“推测执行”设置；一个典型的建议是将你的 reduce 并行度设置为少一点，也许是 reduce 槽数的 0.95 倍；这为失败或卡住的减少任务留出了一点余地。

此外，尽管由于不同 reduce 任务的速度差异很大，由于需要执行多个“波”而预期会减慢，但当您将并行度增加到超过 reduce 槽数时，您可能已经看到了一些性能更快的情况.在某些差异很大的工作负载中，第二个“wave”可以有效地与第一个“wave”中最慢的任务同时运行；以前Hadoop wiki 给出了一个经验法则，将reduce 并行度设置为可用reduce 槽数的0.95 或1.75 倍。这里有一些关于这个话题的further discussion；那里的海报正确地指出这些仅适用于单租户集群。

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

【讨论】：