我正在测试Google Compute Engine的Hadoop集群上某些MapReduce作业的扩展,并找到一些意想不到的结果。简而言之,我被告知这种行为可能是因为Hadoop集群中每个工作节点都有多个reducer插槽。
有人可以确认GCE Hadoop集群上MapReduce作业的每个工作节点(工作虚拟机)的减速器插槽数量吗?我正在使用hadoop2_env.sh部署。
https://groups.google.com/a/cloudera.org/forum/#!topic/oryx-user/AFIU2PE2g8o提供了有关我遇到的行为的背景讨论的链接,如果需要,可提供其他详细信息。
谢谢!
答案 0 :(得分: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
设置为大约等于您拥有的减少插槽数。如果您使用的是默认设置,只需将您拥有的机器数量乘以每台机器的核心数除以2即可知道插槽的数量。如果您希望每台计算机减少1个插槽,请将CORES_PER_REDUCE_TASK
设置为等于每台计算机的核心数。
我说大概是因为在工作中设置减少任务的数量还有其他高级设置,包括&#34;投机执行&#34;设置;一个典型的建议是将您的reduce并行度设置为更低,可能是reduce槽数的0.95倍;这可以为失败或卡住的减少任务留出一点空间。
此外,您可能已经看到了一些性能更快的情况,当您将并行度提高到超过减少时隙数量时,尽管由于需要执行多个&#34; wave&#34;而导致预期的减速,不同减少任务的速度。在某些具有高差异的工作负载中,第二个&#34; wave&#34;可以有效地与第一波#34;的最慢任务同时运行;以前Hadoop wiki给出了一个经验法则,即将并行度设置为可用减少时隙数的0.95或1.75倍。这是关于该主题的一些further discussion;正确的海报指出这些只适用于单租户群。
如果您确实希望与大量用户同时共享大型群集,那么这些经验法则不适用,因为您应该完全根据工作负载的大小和特征来分配并行性,因为您不会&# 39; t想要占用100%的集群资源。但是,云环境中的推荐方法确实是拥有多个较小的单租户群集,因为您可以根据所需的工作负载调整每个群集,而不必担心多个群集之间的资源打包问题。不同的用例。