【Hadoop】MapReduce笔记（二）：MapReduce容错，任务失败处理

典型问题：Hadoop如何判断一个任务失败？失败了怎么做？

分析：实际情况下，用户代码存在软件错误、进程崩溃、机器故障等都会导致失败。Hadoop判断的失败有不同级别类型，针对不同级别的失败有不同的处理对策，这就是MapReduce的容错机制。下面是几个不同级别失败的分类：

一、任务失败

分为3种情况：Task失败、子进程JVM退出、超时检测被关闭。

1.任务失败。最常见的是Map或Reduce任务的失败，即写的本身MR代码导致失败。发生Map或Reduce失败的时候，子任务JVM进程会在退出之前向上一级TaskTracker发送错误报告。错误报告最后悔记录在用户的错误日志里面，TaskTracker会将此次task attempt标记为failed，释放一个任务槽slot用来运行另一个任务。

2. 子进程JVM突然退出。可能由于JVM的bug导致，从而导致MapReduce用户代码执行失败。在这种情况下，TaskTracker会监控到进程以便退出，并将此次尝试标记为“failed”失败。

3. 关闭了超时连接（把超时timeout设置成0）。所以长时间运行的任务永不会被标记failed。在这种情况下，被挂起的任务永远不会释放其所占用的任务槽slot，并随时间推移会降低整个集群的性能。

二、TaskTracker失败

        正常情况下，TaskTracker 会通过心跳向 JobTracker 通信，如果发生故障，心跳减少， JobTracker 会将TaskTracker 从等待任务调度的池中移除，安排上一个成功运行的 Map 任务返回。

主要有两种情况：

1.Map 阶段的情况。如果属于未完成的作业，Reduce 阶段无法获取本地 Map 输出的文件结果，任务都需要重新调度和执行，只要是Map阶段失败必然是重新执行这个任务。

2.Reduce 阶段的情况。自然是执行未完成的 Reduce 任务。因为 Reduce 只要执行完了就会把输出写到 HDFS 上。

 

三、JobTracker失败

    最严重的情况就是 JobTracker 失败，并且这情况在单点故障时是最严重的，因为此情况下作业最终失败。

    解决方案是启动多个 JobTracker ，只运行主 JobTracker ，其可以通过 ZooKeeper 来协调。

 

四、任务失败重试

        当 MapTask 执行失败后会重试，超过重试次数（默认为4），整个Job会失败。

        Hadoop 提供配置参数 mapred.max.ap.failures.percent 解决这个问题。如果一个 Job 有 200 个 MapTask ，参数设置为5，则单个 Job 最多允许 10 个 MapTask 失败（200×5%=10），其可以在配置文件 mapred-site.xml 里修改。