失败

在实际情况下，用户代码存在软件错误，进程会崩溃，机器会产生故障。使用 Hadoop最主要的好处之一是它能处理此类故障并完成作业。

任务失败

首先考虑子任务失败的情况。最常见的情况是map或reduce任务中的用户代码抛 出运行异常。如果发生这种情况，子任务JVM进程会在退出之前向其父tasktracker发送错误报告。错误报昔最后被记入用户日志。tasktracker会将此次 taskattempt标记为failed(失败)，释放一个任务槽运行另外一个任务。

对于Streaming任务，如果Streaming进程以非零退出代码退出，则被标记为 failed。这种行为由stream.non.zero.exit.is.failure属性(默认值为ture)来控制。

另一种错误情况是子进程JVM突然退出——可能由于JVM bug(软件缺陷)而导致 MapReduce用户代码造成的某些特殊原因造成JVM退出。在这种情况下，tasktracker化以会注意到进程已经退出，并将此次尝试标记为failed(失败)。

任务挂起的处理方式则有不同。一旦tasktracker注意到已经有一段时间没有收到进 度的更新，便会将任务标记为failed。在此之后，JVM子进程将被自动杀死。任务失败的超时间隔通常为10分钟，可以以作业为基础（或以集群为基础将 mapred.task.timeout属性设置为以毫秒为单位的值）。

如果超时(timeout)设置为0将关闭超时判定，所以长时间运行的任务永远不会被标 记为failed。在这种情况下，被挂起的任务永远不会释放它的任务槽，并随着时 间的推移最终降低整个集群的效率。因此，尽量避免这种设置，同时充分确保每个 任务能够定期汇报其进度。

jobtracker知一个task attempt失败后(通过tasktracker的“心跳”调用），它将重新 调度该任务的执行。jobtracker会尝试避免重新调度失败过的tasktracker上的任 务。此外，如果一个任务的失败次数超过4次，它将不会再被重试。这个值是可以 设置的：对于map任务，运行任务的最多尝试次数由mapred.map.max.attempts属性控制;而对于reduce任务，则由mapred.reduce.max.attempts属性控制。 在默认情况下，如果有任何任务失败次数大于4(或最多尝试次数被配置为4)，整 个作业都会失败。

对于一些应用程序，我们不希望一旦有少数几个任务失败就中止运行整个作业，因 为即使有任务失败，作业的一些结果可能还是可用的。在这种情况下，可以为作业 设置在不触发作业失败的情况下允许任务失败的最大百分比。map任务和reduce 任务可以独立控制，分别通过mapred.max.map.failures.percent和 mapred.max. reduce.failures. percent 属性来设置0

任务尝试(task attempt)也是可以中止的(killed)，这与失败不同。task attempt可以中 止是因为它是一个推测副本，或因 为它所处的tasktracker失败，导致jobtracker将它上面运行的所有 task attempt标 记为killed。被中止的task attempt不会被计入任务运行尝试次数（由 mapred.map.max.attempts 和 mapred.reduce.max.attempts 设置），因为尝试 中止并不是任务的错。

用户也可以使用Web UI或命令行方式(输入hadoop job来查看相应的选项)来中 止或取消taskattempt。作业也可以采用相同的机制来中止。

tasktracker 失败

tasktracker失败是另一种失败模式。如果一个tasktracker由于崩溃或运行过于缓慢 而失败，它将停止向jobtracker发送“心跳”（或很少发送“心跳”）D jobtracker 会注意到已经停止发送“心跳”的tasktracker (假设它有10分钟没有接收到一个 “心跳” ^ 这个值由 mapred.tasktracker.expiry.interval 属性来设置，以 毫秒为单位），并将它从等待任务调度的tasktracker池中移除。如果是未完成的作 业，jobtracker会安排此tasktracker上已经运行并成功完成的map任务重新运行， 因为reduce任务无法访问。它们的中间输出(都存放在失败的tasktracker的本地文 件系统上)。任何进行中的任务也都会被重新调度。

即使tasktracker没有失败，也可能被jobtracker列入黑名单。如果tasktracker上面 的失败任务数远远高于集群的平均失败任务数，它就会被列入黑名单。被列入黑名 单的tasktracker可以通过重启从jobtracker的黑名单中移出。

jobtracker 失败

btracker失败在所有失败中是最严重的一种。目前，Hadoop没有处理jobtracker 失败的机制——它是一个单点故障——因此在这种情况下，作业注定失败。然而， 这种失败发生的概率很小，因为具体某台机器失败的几率很小。未来版本的 Hadoop可能会通过运行多个jobtracker的方法来解决这个问题，任何时候，这些 jobtracker中都只有一个是主jobtracker。可以使用ZooKeeper作为jobtracker的协 调机制来决定哪一个是主jobtracker。