MapReduce的作业失败主要分三个层次，即jobtracker失败,tasktracker,子任务实例
1，jobtracker失败
jobtracker失败应该说是最严重的一种失败方式了，而且在hadoop中存在单点故障的情况下是相当严重的，因为在这种情况下作业最终失败，尽管这种故障的概率极小但是还是应该避免，可以通过启动多个jobtracker，在这种情况只运行一个主的jobtracker.通过一种机制来确定那个是主的jobtracker.
2，tasktacker失败
作业运行期间，tasktracker会通过心跳机制不断与系统jobtracker通信，如果某个tasktracker运行缓慢或者失败，出现故障。tasktracker就会停止或者很少想jobtracker发送心跳，jobtracker会注意到此tasktracker发送心跳的情况，从而将此tasktracker从等待任务调度的tasktracker池中移除，jobtracker会安排此tasktracker上一成功运行的map任务返回，
①，如果他们属于为完成的作业的化，reduce阶段无法获取改tasktracker上的本地map输出文件，任何任务都需要重新调度---即只要是mapping阶段必然是重新执行
②，如果是reduce阶段呢，如果是reduce阶段自然就是执行为完成的reduce任务了，因为reduce只要执行完了的就会把输出写到Hdfs上
3，子任务失败，这个是不是可以理解为JVM级别的
①，当map或者reduce子任务中的代码抛出异常，JVM进程会在退出之前向服进程tasktracker进程发送错误报告，，tasktracker会将此（任务尝试）task attempt标记为failed状态，释放一个槽以便运行另外一个任务
②，对于流任务，如果流进程以非零退出代码退出运行则会标记为failed。
③，子JVM突然退出，即JVM错误，这时tasktracker会注意到进程已经退出，标记为failed
tasktracker将子任务标记为失败后会将自身计数器减一，以便想jobtracker申请新的任务，也是通过心跳告知jobtracker本地的一个任务尝试失败。jobtracker接到任务失败的通知后，会将其重新加入到调度队列重新分配给其他的tasktracker执行（避免将失败的任务分配给执行失败的tasktracker），但是这个尝试也是有次数限制的，默认情况下任务尝试4次后仍然没有完成，就不会再重试（jobtracker会将其标记为killed），此时整个作业就执行失败了。
4，jobcleanup,recoverymanager,taskcleanup,expiretrackers,expirelaunchingtasks,监测失效，清除恢复，还有好多后台线程。。。。
