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

Question

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

当任务跟踪器节点

（由于我仍在调查的网络问题）失去与其他任务跟踪器/数据节点的连接时，问题就会出现，但与作业跟踪器的连接却没有。

基本上，由于超时问题，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>

顺便说一句，此作业在 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。

似乎帮助我停止看到这种失败模式的两件事：

1. 查找来自 Cloudera 的 Todd Lipcon 的 Jetty 6 修补版本，并使用引导操作将 AWS 中的默认版本替换为修补的二进制文件
2. 使用引导操作将 somaxconns 从默认值 128 增加到类似 16384 的值，并使用配置 Hadoop 引导操作将 ipc.server.listen.queue.size 设置为相同的值。

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