hadoop系列十三 ——MapReduce整体工作流程和YARN的架构及原理

概述

一个完整的 MapReduce 程序在分布式运行时有两类实例进程：

1、MRAppMaster：负责整个程序的过程调度及状态协调

2、Yarnchild（MapTask）：负责 map 阶段的整个数据处理流程

3、Yarnchild（ReduceTask）：负责 reduce 阶段的整个数据处理流程 以上两个阶段 MapTask 和 ReduceTask 的进程都是 YarnChild，并不是说这 MapTask 和 ReduceTask 就跑在同一个 YarnChild 进行里

MapReduce的Shuffle过程介绍

MapReduce里的Shuffle：描述着数据从map task输出到reduce task输入的这段过程。

Shuffle的本义是洗牌、混洗，把一组有一定规则的数据尽量转换成一组无规则的数据，越随机越好。MapReduce中的Shuffle更像是洗牌的逆过程，把一组无规则的数据尽量转换成一组具有一定规则的数据。

为什么MapReduce计算模型需要Shuffle过程？我们都知道MapReduce计算模型一般包括两个重要的阶段：Map是映射，负责数据的过滤分发；Reduce是规约，负责数据的计算归并。Reduce的数据来源于Map，Map的输出即是Reduce的输入，Reduce需要通过Shuffle来获取数据。

从Map输出到Reduce输入的整个过程可以广义地称为Shuffle。Shuffle横跨Map端和Reduce端，在Map端包括Spill过程，在Reduce端包括copy和sort过程，如图所示：

MapReduce 程序的运行

整体的maptask的工作机制

1、划分输入切片：JOb客户端负责划分，扫描所有输入的分件，遍历每一个文件，按128M划分范围，标记数据偏移量和文件名，例如有 a.txt 200m, b.txt 180m,c.txt 100m 三个文件，则按这样划分：
FileSplit0：/wordcount/input/a.txt 0-128m
FileSplit1：/wordcount/input/a.txt 128-200m
FileSplit2：/wordcount/input/b.txt 0-128m
FileSplit3：/wordcount/input/b.txt 128-180m
然后将这些文件序列化到ArrayList中，再把ArrayList序列化成一个文件，这个文件叫做job.split

2、MRAppMaster启动 maptask 进程：一个 mr 程序启动的时候，最先启动的是 MRAppMaster，MRAppMaster 启动后根据本次 job 的描述信息(job.split文件)，计算出需要的 maptask 实例数量，然后 MRAppMaster向集群申请机器启动相应数量的 maptask 进程，然后向根据切片信息（文件名和数据偏移量），向maptask分配文件处理的范围。

一个maptask内部工作机制

1、调用的 TextInputFormat类 再调 LIneRecordReader中的方法next(),将这一行的启始偏移量作为key，那一行的数据作为value， 从而产生数据key-value数据，传给下一个方法map()。

2、将输入 KV 对传递给客户定义的 map()方法，做根据自己的需求逻辑运算，并将 map()方法输出的 KV 对收 集到缓存 （自己写）。每行调用一次。

3、（这时候数据还在内存中）MapOutPutCollector接受map方法传输出来的数据进行缓存，然后放在一个环形内存缓冲区中（每个map task都有一个内存缓冲区，该缓冲区的大小默认为100M，由io.sort.mb属性控制），当该缓冲区快要溢出时（默认为缓冲区大小的80%，即80M，由io.sort.spill.percent属性控制），另外一个线程会执行逻辑，这个逻辑叫spiller。

Map端shuffle的过程从这开始：

spill过程

4，spiller（溢出）

从内存—>硬盘

对环形内存缓存区的数据溢出的数据进行分区，排序
分区：根据Partitionner的getPartitionner进行分区
排序：按key的compareTo 去排序
完成分区排序后，会在本地磁盘创建临时的一些文件，将排序，分组完毕的数据存入改文件中。（分组且排好序，区号小的在前，同区按key排序）。
每次溢写会在磁盘上生成一个溢写文件，如果map的输出结果真的很大，有多次这样的溢写发生，磁盘上相应的就会有多个溢写文件存在，所以会在本地硬盘中生成许多溢出文件

5，Merge（合并）

当map task真正完成时，内存缓冲区中的数据也全部溢写到磁盘中形成一个溢写文件。最终磁盘中会至少有一个这样的溢写文件存在（如果map的输出结果很少，当map执行完成时，只会产生一个溢写文件），因为最终的文件只有一个，所以需要将这些溢写文件归并到一起，这个过程就叫Merge。并且Merge生成的文件中的数据，同样按照之前的规则进行分区，排序。

在这里，如果有设置combiner的话，便执行combiner，即combiner的意义就是对每一个maptask的输出进行局部汇总，以减小网络传输量，或者解决数据倾斜问题。
6 maptask关闭，不占资源，将数据信息存在NodeManager的web程序document目录中

整体的ReduceTask的工作机制

reduce端Shuffle

1 copy过程，简单地拉取数据 。reduce会接收到不同mapTask传来的数据，并且每个map传来的数据都是有序的。。reduce会接收到不同mapTask传来的数据，并且每个map传来的数据都是有序的。，Reduce进程启动一些数据copy线程（Fetcher），通过http方式请求map task所在的TaskTracker获取map task的输出文件。因为map task早已结束，这些文件就归TaskTracker管理在本地磁盘中。

2 Merge阶段。这里的merge和map端的merge动作相同，只是数组中存放的是不同map端copy来的数值，是来自不同map task的数据。 同样这里也会根据key（按key的compareTo 去排序）进行排序。最后一次合并的结果并没有写入磁盘，而是直接输入到reduce函数。

3reduce方法，reduce() 函数以 key 及对应的 value 列表作为输入。根据key的不同，每一个key及其对应的value调用一次reduce（）。根据分组比较器groupingcomparter来判断key是否相同。然后输出结果。

4输出到hdfs，reduce()完成后，将数据输出到TextOutPutFormat类，通过该类的RecordWriter()对象，中的write方法，将你的key和value写出去，输出HDFS。

整体流程超详细图解

Hadoop1.0和Hadoop2.0的区别

原框架中核心的 JobTracker和 TaskTracker不见了,取而代之的是ResourceManager, ApplicationMaster与 NodeManager三个部分.

• JobTracker–> ResourceManager（所有应用的共同点） 财务
  –> ApplicationMaster （不同应用单独自己管理） 不同部门不同组的leader
• TaskTracker–》NodeManager
• Hadoop1.0 + spark storm cpu，内存，io

Hadoop2.0的设计

• ResourceManager（RM） 代替集群资源管理器
• ApplicationMaster（AM） 代替一个专用且短暂的 JobTracker（任务管• NodeManager（NM） 代替 TaskTracker
• 一个分布式应用程序代替一个 MapReduce 作业

重构的根本思想：将 JobTracker 两个主要的功能分离成单独的组件，这两功能是资源管理和任务调度 / 监控

YARN的优点

特点：
– 良好的扩展性、高可用（2AM，2个用户，提交两个job）
– 对多种类型、多版本1.5，1.6，2.0 应用进行统一管理和调度
– 自带了多种用户调度器 FIFO，Faire公平调度，适合共享集群环境
– 相比传统模式，提高了资源利用率、降低运维成本和数据共享成本

YARN的架构及原理

什么是YARN

YARN是Hadoop2.0版本新引入的资源管理系统，直接从MR1演化而来。

核心思想：将MP1中JobTracker的资源管理和作业调度两个功能分开，分别由ResourceManager和ApplicationMaster进程来实现。

1）ResourceManager：负责整个集群的资源管理和调度。

2）ApplicationMaster：负责应用程序相关的事务，比如任务调度、任务监控和容错等。

YARN的出现，使得多个计算框架可以运行在一个集群当中。

1）每个应用程序对应一个ApplicationMaster。

2）目前可以支持多种计算框架运行在YARN上面比如MapReduce、Storm、Spark、Flink等。
3. YARN的基本架构
从YARN的架构图来看，它主要由ResourceManager和ApplicationMaster、NodeManager、ApplicationMaster和Container等组件组成。

ResourceManager（RM）

RM处理客户端请求，接收JobSubmitter提交的作业，（按照作业的上下文
(Context) 信息run.sh提交的参数，以及从 NodeManager（NM） 收集来的状
态信息），启动调度过程，分配一个 Container 作为 App Master。
RM拥有为系统中所有应用资源分配的决定权，是中心服务，做的事情就是调度
、启动每一个Job所属的Application、另外只监控Application的存在情况
与运行在每个节点上的NM进程交互，通过心跳通信，达到监控NM的目的RM有一个可插拔的调度器组件Scheduler
– Scheduler是一个纯粹的调度器：
• 不负责应用程序的监控和状态跟踪（AM）
• 不保证应用程序失败或者硬件失败的情况下对Task的重启（AM）

YARN分层结构的本质是ResourceManager。这个实体控制整个集群并管理应用程序向基础计算资源的分配。ResourceManager 将各个资源部分（计算、内存、带宽等）精心安排给基础NodeManager（YARN 的每节点代理）

1）处理客户端请求；

2）启动或监控ApplicationMaster；

3）监控NodeManager；

4）资源的分配与调度。

NodeManager（NM）

NodeManager管理一个YARN集群中的每个节点。NodeManager提供针对集群中每个节点的服务，从监督对一个容器的终生管理到监视资源和跟踪节点健康。根据请求，开辟运算资源（一定cpu和内存），创建app容器。MRv1通过插槽管理Map和Reduce任务的执行，而NodeManager 管理抽象容器，这些容器代表着可供一个特定应用程序使用的针对每个节点的资源。YARN继续使用HDFS层。它的主要 NameNode用于元数据服务，而DataNode用于分散在一个集群中的复制存储服务。

• 是slave进程，类似TaskTracker的角色，是每个机器框架代理
• 处理来自RM的任务请求
• 接收并处理来自ApplicationMaster的Container启动、停止等各种请求
• 负责启动应用程序的Container（执行应用程序的容器），并监控他们的资源
  用情况（CPU、内存、磁盘和网络），并报告给RM

总的来说，在单节点上进行资源管理和任务管理

ApplicationMaster（AM）

应用程序的Master，每一个应用对应一个AM，在用户提交一个应用程序时
个AM的轻量型进程实例会启动，AM协调应用程序内的所有任务的执行
• 负责一个Job生命周期内的所有工作，类似旧的JobTracker
• 每一个Job都有一个AM，运行在RM以外的机器上
• 与RM协商资源
– 与Scheduler协商合适的Container
• 与NM协同工作与Scheduler协商合适的Container进行Container的监控• 是一个普通Container的身份运行

ApplicationMaster管理一个在YARN内运行的应用程序的每个实例。ApplicationMaster 负责协调来自 ResourceManager 的资源，并通过 NodeManager 监视容器的执行和资源使用（CPU、内存等的资源分配）。

• 负责数据的切分；

• 为应用程序申请资源并分配给内部的任务；

• 任务的监控与容错。

• 负责一个Job生命周期内的所有工作，类似旧的JobTracker

• 每一个Job都有一个AM，运行在RM以外的机器上

• 与NM协同工作与Scheduler协商合适的Container进行Container的监控• 是一个普通Container的身份运行

Container

对任务运行环境进行抽象，封装CPU、内存等多维度的资源以及环境变量、启动命令等任务运行相关的信息。比如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。

要使用一个YARN集群，首先需要来自包含一个应用程序的客户的请求。ResourceManager 协商一个容器的必要资源，启动一个ApplicationMaster 来表示已提交的应用程序。通过使用一个资源请求协议，ApplicationMaster协商每个节点上供应用程序使用的资源容器。执行应用程序时，ApplicationMaster 监视容器直到完成。当应用程序完成时，ApplicationMaster 从 ResourceManager 注销其容器，执行周期就完成了。

Y a r n 框 架 的 运 行 过 程

1. 用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。
2. ResourceManager为该应用程序分配第一个Container，并与对应的Node-Manager通信，要求它在这个Container中启动应用程序的ApplicationMaster。
3. ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4~7。
4. ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。（就是排队）
5. 一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务
6. NodeManager为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。
7. 各个任务通过RPC协议向ApplicationMaster汇报自己的状态和进度，以便让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过RPC向ApplicationMaster查询应用程序的当前运行状态。
8. 应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。