mapreduce 的工作机制

本节将会从作业的角度来解释一个作业是如何在Hadoop的MapReduce计算框架下提交、运行等。

一个MapReduce作业运行过程如图

作业提交

用户的MapReduce作业运行时己经设置作业运行时的各种信息，如Mapper类、Reducer类等，并通过job.waitForCompletion方法提交作业，如下图所示。



    首先由JobClient的subJobInternal方法提交作业(步骤1 ),并且在waitForCompletion方法中会调用monitorAndPrintJob方法轮询作业的进度，并将进度信自、输出至控制台，我们在WordCount看到的作业进度信息就是由该方法输出的。在JobClient的submitJoblnternal方法中，通过调用JobTracker的getNewJobId方法向JobTracker清求一个作业 ID （步骤2
).接着检查作业输出目录和输入分片(InputSplit）是否符合要求，将运行作业所需要的资源(包括作业jar文件、第三方jar文件等)复制到 HDFS下特定日录下(步骤3 ),供作业运行时使用。当这些完成后，通过调用JobTracker的submitJob方法告知JobTracker作业准备执行(步骤4)。

作业初始化

    当JobTracker收到对其submitJob方法的调用后，会将此调用交由作业调度器进行调度，并对其初始化，创建一个表示正在运行作业的对象(步骤5)。为了给TaskTracke:分配任务，必须先从HDFS系统中获取已计算好的输入分片信息、(步骤6）。然后为每个输入分片创建一个Map任务，而创建的Reduce任务的个数由mapred-site.xml文件的mapred.reduce.tasks配置决定，默认是1，可通过setNumReduceTasks方法针对每个作业设置。此时，Map任务和Reduce任务的任务ID将被指定。

任务分配

    JobTracker和TaskTracker之间采用了push通信模型. 即 JobTracker不会主动与CaskTracker通信，而总是被动等待TaskTracker通过心跳告知JobTracker是否存活、节点资源使情况、各个任务的状态等。如果JobTracker觉得TaskTracker已经准备好运行新的任务，JobTracker:将会通过心跳的返回值为TaskTracker分配一个任务(步骤7）。

    由4.1节的MapReduce资源管理可知，一个TaskTracker可以运行的Map任务数址和Reduce任务数量是一定的。调度器在为TaskTracker分配任务时，会优先分配Map任务，也就是说如果该TaskTracker至少有一个空闲的Map槽，那么它将会被分配一个Map任务，否则会被分配一个Reduce任务。JobTracker同时也会遵循就近原则，选择一个距离InputSplit最近的节点，如果输入分片没有跨节点，那么任务就将运行在输入分片所在的节点，这样就减少了网络负载的压力，如果跨节点，JobTracke:会优先考虑同机架的节点。

任务执行

    TaskTracker在接到启动任务的命令后，会把作业的jar文件、第三方jar文件等作业所需文件复制到TaskTracker所在节点的本地目录(步骤8)，由mapred-site.xml文件的mapred.local.dir配置。

    接着TaskTracker会新建一个TaskRunner实例来运行任务，TaskRunner启动一个JVM(步骤9)运行侮个任务(步骤10)，以便在一个任务中，某些程序上的问题所引起的崩溃或是挂起不会影响其他任务的执行。

任务完成

    当JobTracker收到最后一个任务己完成的通知后(通常是Reduce任务)，便把作业的状态设置为成功。JobClient查询状态时，会将作业完成的消息在控制台打印。最后JobTracker会清空作业的工作状态，并且让TaskTracker也清空作业的工作状态，如删除中间结果。

推测执行

    MapReduce计算框架将一个作业分解成一个个Map任务和Reduce任务以便可以并行地运行任务，但是这样一来，作业完成的时间将取决于最慢的任务完成的时间，当作业的任务数到达一定址的时候，出现个别拖慢整个作业进度的任务是很常见的。

    为了避免这种情况的发生，MapReduce计算框架采取了推测执行的机制(speculativeexecution ) 。当一个任务运行进度比预期要慢的时候，MapReduce计算框架会启动一个相同的任务作为其备份。当一个作业的所有任务都启动之后，MapReduce计算框架会针对某些己经运行一段时问月比作业中其他任务平均进度慢的任务启动一个推测执行的任务。该推测执行的任务与原任务享有同样的地位，也就是说如果推测执行的任务先于原任务完成，则原任务会被关闭，如果原任务先于推测执行的任务完成，则推测执行的任务会被关闭。

    推测执行的机制有利有弊，它可以改善由于硬件老化等原因引起的作业时间延长，但是如果任务执行缓慢的原因是由于软件缺陷，推测执行对于这种情况是无能为力的，反而会因为大星的兀余任务抢占集群资源、增加网络带宽的负荷量。

MapReduce容错

               1.      任务出错

    当TaskTracker进程崩溃或者TaskTracker进程所在节点故障时，JobTracker将接收不到TaskTracker发来的心跳，那么JobTracker将会认为该TaskTracker失效并且在该TaskTracker运行过的任务都会被认为失败，这些任务将会被重新调度到别的TaskTracke:执行，而对于用户来说，在执行MapReduce作业时，只会感觉到该作业在执行的一段时间里变慢了。

              2.      TaskTracker出错

    当TaskTracker进程崩溃或者TaskTrackr:进程所在节点故障时，JobTracker将接收不到TaskTracker发来的心跳，那么JobTracker将会认为该TaskTracke:失效并且在该TaskTracker运行过的任务都会被认为失败，这些任务将会被重新调度到别的TaskTracke:执行，而对于用户来说，在执行ManReduce作业时，只会感觉到该作业在执行的一段时间里变慢了。

              3.      JobTracker出错

    在Hadoop中，JobTracker出错是}f=常严重的情况，因为在Hadoop 中JobTracker存在单点故障的可能性，所以如果JobTracker一旦出错，那么正在运行的所有作业的内部状态f言息将会丢失，即使JobTracker马上恢复了，作业的所有任务都将被认为是失败的，即所有作业都需要重新执行。

              4.      HDFS出错

    对于依赖底层存储HDFS的作业，一旦HDFS出错，那么对于整个作业来说，还是会执行失败。当DataNode出错时，MapReduce会从其他DataNode上读取所需数据，除非包含任务所需的数据块的节点都出错，否则都是可以恢复的。如果NameNode出错，任务将在下一次访问NameNode时报错，但是MapReduce计算框
4000
架还是会尝试执行4次(默认的最大尝试执行次数为4)，在这期间，如果NameNode依然处于故障状态，那么作业最终会执行失败。

本文参考书籍------Hadoop海量数据处理 技术详解与项目实战