Question

我有一个hadoop reduce任务尝试，除非我手动失败/杀死它，否则永远不会失败或完成。

当任务跟踪器节点（由于我正在调查的网络问题）失去与其他任务跟踪器/数据节点的连接而不是与作业跟踪器的连接时，问题浮出水面。

基本上，由于超时问题，reduce任务无法从其他数据节点获取必要的数据，并将其列入黑名单。到目前为止，如此好，黑名单是预期和需要的，问题是它将继续重试相同的黑名单主机几个小时（尊重它似乎是一个指数退避算法），直到我手动杀死它。最新的长时间运行任务已经> 9小时重试。

我在日志中看到了数百条这样的消息：

2013-09-09 22:34:47,251 WARN org.apache.hadoop.mapred.ReduceTask (MapOutputCopier attempt_201309091958_0004_r_000044_0.1): attempt_201309091958_0004_r_000044_0 copy failed: attempt_201309091958_0004_m_001100_0 from X.X.X.X
2013-09-09 22:34:47,252 WARN org.apache.hadoop.mapred.ReduceTask (MapOutputCopier attempt_201309091958_0004_r_000044_0.1): java.net.SocketTimeoutException: connect timed out

是否有任何方法或设置指定在 n 重试或秒后任务失败并在另一个任务跟踪器主机中自行重启？

这些是我在群集中设置的一些相关的减少/超时Hadoop群集参数：

<property><name>mapreduce.reduce.shuffle.connect.timeout</name><value>180000</value></property>
<property><name>mapreduce.reduce.shuffle.read.timeout</name><value>180000</value></property>
<property><name>mapreduce.reduce.shuffle.maxfetchfailures</name><value>10</value></property>

<property><name>mapred.task.timeout</name><value>600000</value></property>
<property><name>mapred.jobtracker.blacklist.fault-timeout-window</name><value>180</value></property>
<property><name>mapred.healthChecker.script.timeout</name><value>600000</value></property>

BTW，此作业在AWS EMR集群上运行（Hadoop版本：0.20.205）。

提前致谢。

Answer 1

虽然我不确定，但您对理解感兴趣的内容是在org.apache.hadoop.mapred.ReduceTask.ReduceCopier类中实现的，特别是如果您查看该类的构造函数的源代码：

this.abortFailureLimit = Math.max(30, numMaps / 10);

this.maxFetchFailuresBeforeReporting = conf.getInt(
      "mapreduce.reduce.shuffle.maxfetchfailures", REPORT_FAILURE_LIMIT);

this.maxFailedUniqueFetches = Math.min(numMaps, 
                                       this.maxFailedUniqueFetches);

您会注意到这是您已经列出的配置值之一 - mapreduce.reduce.shuffle.maxfetchfailures。您是否尝试将其设置为较小的值（1或0），这是否会产生所需的功能？

您还可以使用mapreduce.reduce.shuffle.connect.timeout降低连接超时（同样，您的问题也是如此）。尝试并降低该值以使连接超时更快地被抛出（180000是3分钟，而不是尝试30000）。

对不起，这不是确定的，但至少可以开始。

Answer 2

“太多的提取失败”实际上很常见，一旦你超过Hadoop 0.20（你已经完成）。该问题似乎与Jetty 6版本中的问题有关，该问题与后来的Hadoop发行版捆绑在一起。请参阅MAPREDUCE-2386，MAPREDUCE-2529，MAPREDUCE-3851，MARREDUCE-3184。

似乎有两件事让我不再看到这种失败模式：

从Cloudera中寻找Todd Lipcon的patched version of Jetty 6并使用引导操作将AWS中的默认值替换为已修补的二进制文件
使用bootstrap操作将somaxconns从默认值128增加到16384，并使用configure Hadoop bootstrap操作将ipc.server.listen.queue.size设置为相同的值。

我相信2.3.x范围内的AMI使用Jetty 7，所以如果你倾向于升级到更高版本的Hadoop（1.0.3），那也应该有所帮助。

在太多数据获取失败后，如何使hadoop任务尝试失败？

2 个答案: