6.2　错误处理机制

众所周知，Hadoop有很强的容错性。这主要是针对由成千上万台普通机器组成的集群中常态化的硬件故障，Hadoop能够利用冗余数据方式来解决硬件故障，以保证数据安全和任务执行。那么MapReduce在具体执行作业过程中遇到硬件故障会如何处理呢？对于用户代码的缺陷或进程崩溃引起的错误又会如何处理呢？本节将从硬件故障和任务失败两个方面说明MapReduce的错误处理机制。

6.2.1　硬件故障

从MapReduce任务的执行角度出发，所涉及的硬件主要是JobTracker和TaskTracker（对应从HDFS出发就是NameNode和DataNode）。显然硬件故障就是JobTracker机器故障和TaskTracker机器故障。

在Hadoop集群中，任何时候都只有唯一一个JobTracker。所以JobTracker故障就是单点故障，这是所有错误中最严重的。到目前为止，在Hadoop中还没有相应的解决办法。能够想到的是通过创建多个备用JobTracker节点，在主JobTracker失败之后采用领导选举算法（Hadoop中常用的一种确定Master的算法）来重新确定JobTracker节点。一些企业使用Hadoop提供服务时，就采用了这样的方法来避免JobTracker错误。

机器故障除了JobTracker错误就是TaskTracker错误。TaskTracker故障相对较为常见，并且MapReduce也有相应的解决办法，主要是重新执行任务。下面将详细介绍当作业遇到TaskTracker错误时，MapReduce所采取的解决步骤。

在Hadoop中，正常情况下，TaskTracker会不断地与系统JobTracker通过心跳机制进行通信。如果某TaskTracker出现故障或运行缓慢，它会停止或者很少向JobTracker发送心跳。如果一个TaskTracker在一定时间内（默认是1分钟）没有与JobTracker通信，那么JobTracker会将此TaskTracker从等待任务调度的TaskTracker集合中移除。同时JobTracker会要求此TaskTracker上的任务立刻返回，如果此TaskTracker任务是仍然在mapping阶段的Map任务，那么JobTracker会要求其他的TaskTracker重新执行所有原本由故障TaskTracker执行的Map任务。如果任务是在Reduce阶段的Reduce任务，那么JobTracker会要求其他TashTracker重新执行故障TaskTracker未完成的Reduce任务。比如，一个TaskTracker已经完成被分配的三个Reduce任务中的两个，因为Reduce任务一旦完成就会将数据写到HDFS上，所以只有第三个未完成的Reduce需要重新执行。但是对于Map任务来说，即使TashTracker完成了部分Map, Reduce仍可能无法获取此节点上所有Map的所有输出。所以无论Map任务完成与否，故障TashTracker上的Map任务都必须重新执行。