原 Hadoop学习笔记(8)--MapReduce工作机制

任务执行流程

代码编写→作业配置→作业提交→Map任务的分配和执行→处理中间结果→Reduce任务的分配和执行→作业完成，
每个任务的执行过程中，又包含输入准备→任务执行→输出结果。

各角色分工

1.客户端（Client）：编写MapReduce代码，配置作业，提交作业。

Map接口的输出key-value类型和Reduce接口的输入key-value类型要对应，因为Map输出组合value之后，它们会成为Reduce的输入内容。

保证输出路径不存在，如果存在程序会报错。

2.JobTracker：初始化作业，分配作业，与TaskTracker通信，协调整个作业的执行。

TaskTracker和JobTracker之间的通信和任务的分配是通过心跳机制完成的。心跳信息里面包含任务的分配信息。

3.TaskTracker：保持与JobTracker的通信，在分配的数据片段上执行Map或Reduce任务。

TaskTracker申请到新的任务之后，就要在本地运行任务了。（将任务运行所必需的数据、配置信息、程序代码从HDFS复制到TaskTracker本地）

4.HDFS：保存作业的数据、配置信息等，保存作业结果。

容灾机制

• JobTracker故障

在Hadoop集群中，任何时候都只有唯一一个JobTracker。JobTracker故障就是单点故障，这是所有错误中最严重的。唯一能避免的就是使用领导选举算法的备用JobTracker。

• TaskTracker故障

Hadoop通过心跳信息判断TaskTracker是否故障(执行缓慢，或者无心跳)。
如果是Map阶段故障，则重新执行所有故障TaskTracker下的Map任务。
如果是Reduce故障，只需重新执行故障TaskTracker下的未完成Reduce任务。

如果此任务尝试了默认配置的失败次数(默认为4次)仍没有完成，此时整个作业也就失败了。

作业调度机制

0.19.0版本采用FIFO的作业调度机制。

• 默认调度机制，FIFO调度器。
• 支持多用户同时服务和集群资源公平共享的调度器，即公平调度器和容量调度器。

当集群上只有一个作业在运行时，它将使用整个集群；当有其他作业提交时，系统会将TaskTracker节点空闲时间片分配给这些新的作业，并保证每一个作业都得到大概等量的CPU时间。

Shuffle和排序

为了让Reduce可以并行处理Map结果，必须对Map的输出进行一定的排序和分割，然后再交给对应的Reduce，而这个将Map输出进行进一步整理并交给Reduce的过程就成为了shuffle。

• Map端Shuffle

Map端的shuffle过程是对Map的结果进行划分（partition）、排序（sort）和分割（spill），然后将属于同一个划分的输出合并在一起（merge）并写在磁盘上，同时按照不同的划分将结果发送给对应的Reduce

• Reduce端Shuffle

Reduce端又会将各个Map送来的属于同一个划分的输出进行合并（merge），然后对merge的结果进行排序，最后交给Reduce处理。

任务执行

• 推测式执行

JobTracker会统计所有任务的平均进度，如果某个任务节点由于配置低或CPU负载高，导致任务速度比总体平均速度要慢，此时JobTracker就会启动一个新的备份任务，原有任务和新任务哪个先执行完就把另外一个kill掉。

对于由于代码缺陷导致的任务执行速度过慢，该机制并不会解决问题。

• JVM重用

一个非常短的任务结束之后让后续的任务重用此Java虚拟机的机制。

原文链接：Hadoop学习笔记(8)--MapReduce工作机制，转载请注明来源！