经典的MapReduce1中的失败

经典的MapReduce1中的失败
在MapReduce1运行时，主要考虑三种失败的模式，运行任务失败、tasktracker失败以及jobtracker失败
1. 任务运行失败
首先考虑子任务失败的情况。最常见的情况是map任务或reduce任务中的用户代码抛出运行异常。如果发生这种情况，子任务JVM进程会在退出之前向其父tasktracker发送错误报告。错误报告最后被记入用户日志。Tasktracker将此次任务尝试标记为failed(失败),释放任务槽运行另外一个任务。
对于streaming任务，如果streaming进程以非零退出代码退出，则被标记为failed。这种行为由stream.non.zero.exit.is.failure属性(默认值为true)来控制
另一种错误情况是子进程JVM突然退出，可能由于JVM软件缺陷而导致MapReduce用户代码由于某些特殊原因造成JVM退出。在这种情况下，tasktracker会注意到进程已经退出并将此次任务尝试标记failed(失败)。
任务挂起的处理方式则有不同。一旦tasktracker注意到已经有一段时间没有收到进度的更新，便会将任务标记为failed。在此之后，JVM子进程将被杀死。任务失败的超时间隔通常为10分钟，可以以作业为基础(或以集群为基础)将mapred.task.timeout属性设置为以毫秒为单位的值。
超时(timeout)设置为0将关闭超时判定，所以长时间运行的任务永远不会被标记为failed。在这种情况下，被挂起的任务永远不会释放它的任务槽并随着时间的推移最终降低整个集群的效率。因此，尽量避免这种设置，同时充分确保每个任务能够定期汇报其进度。
Jobtracker被告知一个任务尝试失败后(通过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属性来设置。
任务尝试(task attempt)也是可以终止的(killed)，这与失败不同。任务尝试可以被中止是因为它是一个推测副本，或因为它所处的tasktracker失败，导致jobtracker将它上面运行的所有任务尝试标记为killed。被中止的任务尝试不会被计入任务运行尝试次数(由mapred.map.max.attempts和mapred.reduce.max.attempts设置)，因为尝试中止并不是任务的过错。
2. tasktracker失败
tasktracker失败是另一种失败模式。如果一个tasktracker由于崩溃或运行过于缓慢而失败，会停止向jobtracker发送心跳（或很少发送心跳）。Jobtracker会注意到已经停止发送心跳的tasktracker(假设它有10分钟没有接收到一个心跳。这个值由mapred.tasktracker.expiry.interval属性设置，以毫秒为单位)并将它从等待任务调度的tasktracker池中移除。如果是未完成的作业，jobtracker会安排此tasktracker上已经运行并成功完成的map任务重新运行，因为reduce任务无法访问它们的中间输出结果(都存放在失败的tasktracker的本地文件系统上)。任何正在运行的任务也都会被重新调度。
即使tasktracker没有失败，也可能被jobtracker列入黑名单。如果在一个特定的tasktracker上超过4个（通过mapred.max.tracker.failures设置）来自同一个作业的任务失败了，jobtracker就会将此记录为出错。如果tasktracker上面的失败任务数超过最小阈值(默认值是4，由mapred.max.tracker.blacklists设置)并远远高于集群中tasktracker的平均失败任务数，就会被列入黑名单。
列入黑名单的tasktracker不再被分配任务，但会继续和jobtracker通信。随着错误期满（每天一次的比率），tasktracker有机会再次运行作业。另外，如果🈶可修复的潜在错误(比如替换硬件)，在tasktracker重启并重新加入集群后，它将从jobtracker的黑名单中移出。
3. jobtracker失败
在所有失败中，jobtracker失败是最严重额。目前Hadoop没有处理jobtracker失败的机制--它是一个单点故障--因此在这种情况下，作业的执行注定是失败的。然而，这种失败发生的概率很小，因为具体某台机器失败的几率很小。YARN进一步改善了这种情况，它的设计目标之一就是消除MapReduce中单点失败的可能性。
Jobtracker重启后，在它停止时运行的所有作业都需要再次提交。配置选项mapred.jobtracker.restart.recover（默认为关闭）可尝试恢复所有运行作业，但它还不太可靠，因此建议不要用。