1.MapReduce工作流程
1.MapReduce核心思想 (图6)：
采用“分而治之”思想，将大数据集拆分到多个小数据块，再转到多台机器上并行处理。总的来说Map任务独立执行被分割的数据，Reduce将Map任务的中间结果进行并行整合，最后得到整个数据集输出结果。
图6 MapReduce整体流程
2.MapReduce各阶段流程 (图7)：
(1)Map预处理：MapReduce框架使用InputFormat模块做Map任务前的预处理（从HDFS中加载数据)，比如验证输入格式是否符合输入规则。然后，将输入文件切分为逻辑上多个InputSplit单位（逻辑定义分片长度、起始位置）。
(2)加载Map数据：由于InputFormat非物理上切分，所以还需要RecordReader（RR）转换为多个适合Map任务的数据格式，再输入给Map任务。
(3)执行Map任务：Map任务由用户自定义规则，然后映射输出一系列<key，value>作为中间结果。
(4)Reduce预处理：为了让Reduce并行处理Map结果，需要对Map输出结果Shuffle操作，包括但不限于：分区(Portition)、排序(Sort)、合并(Combine)、归并(Merge)等。接下来，将得到的<key，value-list>中间结果交给Reduce。
(5)执行Reduce任务：根据4中<key，value-list>中间结果输入，再执行用户用户定义的逻辑，输出结果给OutputFormat模块。
(6)保存结果：OutputFormat模块验证输出目录是否存在以及结果类型是否符合预期，若满足则将Reduce结果保存到分布式文件系统。
图7 MapReduce各阶段流程
3.Shuffle整体流程 (图8)：
所谓Shuffle是指对Map输出结果进行进行分区、排序、合并等处理并提交给Reduce，它相当于一个中间过程。其又可分为Map端和Reduce端的Shuffle操作。
图8 Shuffle流程
①Map端Shuffle流程 (图9)：
Map的输出结果首先被写入缓存，当缓存满时，启动溢写操作，将缓存中数据写入磁盘文件并清空缓存。当启动溢写操作时，首先需要把缓存中的数据进行分区，然后对每个分区的数据进行排序（Sort）和合并(Combine)，之后再写入磁盘文件。但是每次溢写操作都会生成新的磁盘文件。在Map任务结束之前，所有溢出文件会被归并（Merge）为大的磁盘文件，然后通知相应的Reduce任务来领取属于自己处理的数据。
图9 Map端的Shuffle过程
②Reduce端Shuffle流程 (图10)：
该任务从Map端的不同Map机器节点中领取属于自己处理的专属数据，然后对数据进行归并（Merge）后，最后交给对应Reduce处理。
2.Job执行流程（MapReduceV1.0）
1.架构两大部分：MapReduce1.0采用的是主/从架构,其中主节点是JobTracker(作业服务器),从节点是TaskTracker(任务服务器)。二者之间通过定时心跳进行通信。
2.Job执行流程 (图11)：
①提交作业：一个MapReduce作业提交到Hadoop之后,会进入完全地自动化执行过程。在这个过程中，用户除了监控作业的执行情况和强制终止作业之外，不能对作业的执行过程进行干扰，所以在作业提交之前，用户需要将作业所有的需要的参数配置完备。
②初始化作业：在客户端中,当用户作业调用JobTracker对象的submitJob()方法之后，JobTracker会把这个作业放在一个作业队列中去,进行调度，默认的调度方式是FIFO。当作业被调度执行时，JobTracker会对此作业进行初始化，根据处理数据的情况为其创建Map和Reduce任务。
③分配任务：TaskTracker是一个单独循环运行的软件,每间隔一段时间向JobTracker发送心跳信息(heartbeat)，包括告知JobTracker此TaskTracker是否存活，是否准备好执行新的任务。在JobTracker接收到心跳信息后,如果任务队列中有待分配的任务时，它就会给一个准备好的TaskTracker分配一个任务，并将分配信息(包括要执行的任务信息和分配的资源信息)封装在心跳信息返回值返回给TaskTracker,TaskTracker根据此返回信息来执行任务。在JobTracker为TaskTracker分配任务时，为了减少数据移动I/O开销大的问题，会考虑将任务分配到数据所在的TaskTracker上。
④执行任务：TaskTracker根据心跳返回值的信息来执行任务,并跟踪任务执行的状态,并定时向JobTracker报告任务的状态,直到任务执行完成。
3.主要缺陷：
- 可靠性差。在Hadoop集群中,任何时候都只有唯一的一个JobTracker。一旦主节点出现问题整个集群就无法工作，所以JobTracker的单点故障是所有故障中最严重的。
- 可扩展性差。JobTracker同时作为资源管理器和作业调度器两个角色，当集群逐渐扩大时，JobTracker的压力会越来越大，成为了Hadoop系统的瓶颈，制约了Hadoop集群的可扩展性。
图11 MapReduceV1架构图
3.MapReduceV2.0主要变化内容
1.V 2.0版本思想：将JobTracker的资源管理和任务调度这两个主要功能进行分离,由两个单独的组件完成。新的资源管理器全局管理整个集群上所有计算资源的分配；YARN为每一个应用分配一个ApplicationMaster,由它负责相应作业的调度和资源的协调。
2.RsourceManager和NodeManager (图12)：RsourceManager是一个主节点，它负责管理集群中所有资源的统一管理和分配,它接受来自各个节点上NodeManager的资源汇报信息。
主节点ResourceManager只是负责简单的任务调度和资源分配，不在监控和记录每个任务的执行状态,也不再负责执行失败任务的重启等,只负责监控和重启ApplicationMaster；极大的减少了本身的资源开销,而且单点故障对整个集群的影响变得很小,恢复也因此变得更加容易。
从节点NodeManager是单个节点上的任务和资源管理器，部署在集群的每台机器上，它管理这集群中的单个节点中的资源，监控Container的生命周期和资源使用情况，还负责与ResourceManger进行通信,报告节点计算资源的使用情况、节点的健康状况等。
3.相比与V1改进优势：
- 资源利用率高,一个框架一个集群会造成资源占用的不均衡,某个框架因应用多而造成集群资源紧张,而某个框架因应用少而造成集群资源浪费。而YARN通过多种计算框架共享一个集群,使得集群利用率更高。
- 数据共享,随着数据量的增加,移动数据的代价越来越大,YARN模式可以有效的降低这种代价。
- 运维成本低。从运维多个集群到一个集群,大大降低了运维成本。
图12 MapReduceV2架构图
