Hadoop-MapReduce调度原理，Yarn原理

一、MapReduce中的角色

上一节中，我们介绍了MapReduce的一些理论概念。那么mapReduce的框架是如何实现的呢？框架中都分别包含哪些角色呢？

mapReduce框架实现有个目标，就是实现计算向数据移动；其中hdfs集群中已经为我们暴露出了数据块的位置，一个文件块可能会存在多个副本，散列在不同的Datanode中，此时如果客户端要用mapReduce框架计算其中一部分数据，那就有个问题，如何将mapReduce的计算程序“扔”到对应的合适的datanode节点中运行计算呢？在解决这个问题之前，我们先了解下mapReduce的角色JobTracker与TaskTracker

1、MapReduce的JobTracker与TaskTracker介绍

Hadoop MapReduce采用Master/Slave结构。

• Master：是整个集群的唯一的全局管理者，功能包括**：作业管理、状态监控和任务调度等**，即MapReduce中的JobTracker。

• Slave：负责任务的执行和任务状态的汇报，即MapReduce中的TaskTracker。

mapReduce的角色包括两种：JobTracker 、TaskTracker

与hdfs中的角色相比，其对应关系如下：

• JobTracker 对应于 NameNode
• TaskTracker 对应于 DataNode
• DataNode 和NameNode 是针对数据存放来而言的
• JobTracker和TaskTracker是对于MapReduce执行而言的

除此之外，还有调用mapReduce提供接口的客户端jobclient

1.1、JobTracker剖析

(1)概述：JobTracker是一个后台服务进程，启动之后，会一直监听并接收来自各个TaskTracker发送的心跳信息，包括资源使用情况和任务运行情况等信息。

(2)JobTracker的主要功能：

• 作业控制：在hadoop中每个应用程序被表示成一个作业，每个作业又被分成多个任务，JobTracker的作业控制模块则负责作业的分解和状态监控。 最重要的是状态监控：主要包括TaskTracker状态监控、作业状态监控和任务状态监控。主要作用：容错和为任务调度提供决策依据。
• 资源管理

1.2、TaskTracker剖析：

(1)TaskTracker概述：TaskTracker是JobTracker和Task之间的桥梁：

• 一方面，从JobTracker接收并执行各种命令：运行任务、提交任务、杀死任务等；

• 另一方面，将本地节点上各个任务的状态通过心跳周期性汇报给JobTracker。TaskTracker与JobTracker和Task之间采用了RPC协议进行通信。

(2)TaskTracker的功能：

• 汇报心跳：Tracker周期性将所有节点上各种信息通过心跳机制汇报给JobTracker。这些信息包括两部分：
  • 机器级别信息：节点健康情况、资源使用情况（比如节点还剩多少内存）等。
  • 任务级别信息：任务执行进度、任务运行状态等。
• 执行命令：JobTracker会给TaskTracker下达各种命令，主要包括：启动任务(LaunchTaskAction)、提交任务(CommitTaskAction)、杀死任务(KillTaskAction)、杀死作业(KillJobAction)和重新初始化(TaskTrackerReinitAction)。

2、mapreduce的主要执行过程

mapreduce中几个主要概念，mapreduce整体上可以分为这么几条执行线索：

jobclient，JobTracker与TaskTracker。

1、JobClient会在用户端通过JobClient类将应用已经配置参数打包成jar文件存储到hdfs，

并把路径提交到Jobtracker,然后由JobTracker创建每一个Task（即MapTask和ReduceTask）

并将它们分发到各个TaskTracker服务中去执行

2、JobTracker是一个master服务，软件启动之后JobTracker接收Job，负责调度Job的每一个子任务task运行于TaskTracker上，

并监控它们，如果发现有失败的task就重新运行它。一般情况应该把JobTracker部署在单独的机器上。

3、TaskTracker是运行在多个节点上的slaver服务。TaskTracker主动与JobTracker通信，接收作业，并负责直接执行每一个任务。

TaskTracker都需要运行在HDFS的DataNode上

二、MapReduce如何实现计算向数据移动？

要实现这个目标，mapReduce中的客户端Client就非常重要了。

1、客户端的作用

1.1、支持计算向数据移动
我们未来开发程序的时候，最终会生成一个可执行的jar包，里面包含了Map和Reduce的处理逻辑。客户端会根据每次的计算数据，咨询NN元数据，目的是因为元数据包含了文件的block块信息，客户端会根据获取的block块信息计算切片split （默认等于块大小），默认情况下，文件有多少块，对应的就有多少切片。客户端可以通过计算是IO密集型还是cpu密集型，来划分切片的大小。不管怎么样，最终得到一个切片的”清单“，也就是这次计算的这批数据，总共有多少个切片，只要客户端一算出切片的数量，就间接得到map的数量（split:map = 1:1）。最终split上包含了偏移量，以及split对应的map任务应该移动到哪些节点（根据block块的locations位置得到）。只要拿到split”清单“，就可以支持计算向数据移动了。

切片是逻辑概念，block是物理概念。block身上有offset和locations（副本都在哪些机器上），split和block是有映射关系的

1.2、生成计算程序未来运行时的相关配置文件

比如配置这个计算程序，可以使用多大的堆栈内存等。

1.3、保证未来数据移动应该相对可靠

为了保证支持计算向数据移动中的移动可靠性，客户端不能直接将数据抛给jobTracker，因为jobTracker可能随时宕机。可靠的做法是，客户端会将jar、split清单、配置文件xml等信息，上传到hdfs的目录中，这些客户端上传的东西在hdfs中的默认副本数是10。然后客户端回调用JobTracker，通知JobTrakcer将要要启动一个计算程序了，并且告知这些文件都放在hdfs的哪些地方。当所有的TaskTracker运行完了之后，再将客户端上传的jar等这些东西删除。

为什么客户端上传的jar、配置文件等信息，在hdfs中副本数默认为10，而一般上传文件的副本数在hdfs中默认为3？

因为你的map将来可能就会存在几十个几百个，并且未来可能有很多个TaskTracker去Datanode找客户端上传的jar包和配置文件，试想如果存在100个TaskTracker要计算需要用到客户端上传的jar、配置文件等信息，而此时这些信息的副本数只有3个，也就是只存放在3台Datanode上。此时这3台datanode就要同时承受这100个TaskTracker的访问拉取，消耗网卡IO。 而将副本数调大，分布在更多的datanode上，就可以将压力分摊，提高负载。

虽然客户端根据split切片可以确定map可以访问哪些dn节点获取切片数据。但是客户端并不知道让map去到哪个dn节点获取数据最合适。

一个集群有很多节点，客户端并没有和这其中的节点保持心跳获取他们的资源信息，所以无法确定最适合的dn节点获取数据。这个时候JobTracker就派上用场了！

JobTracker和集群中的TaskTracker保持着心跳，并可以清楚知道Task的运行信息，及每台节点上的资源信息等。
所以客户端相当于一个任务的发起者，但是最终调度这个任务的是通过JobTracker。

2、JobTracker接收到请求后的处理流程

• 从hdfs中取回【split清单】
• 根据自己收到的TT（TaskTracker）汇报的资源，最终确定每一个split对应的map应该去到哪个节点。【确定清单】
• 未来，TaskTracker在和JobTracker心跳的时候会取回分配给自己的任务信息，来确定自己需要跑哪些map

3、TaskTracker的处理流程

• 在和JobTracker维持心跳取回任务之后，从hdfs中下载jar包，xml等资源到本机
• 最终启动任务描述中的MapTask/ReduceTask（最终，代码在某一个节点被启动，是通过客户端上传jar包，TaskTracker下载jar来实现计算向数据移动的过程）

三、JobTracker的问题

1. JobTracker是主从的，所以是单点的，会出现单点故障
2. JobTracker会收到本机资源的限制，导致压力过大
3. 集成了【资源管理和任务调度】，两种耦合。带来的弊端就是未来的计算框架不能够复用资源管理，这又会带来两个问题
   • 重复造轮子，也就是另一套计算框架还得要重写资源管理这一块。
   • 因为各自实现资源管理，但是它们部署在同一批硬件上，因为双方的资源管理隔离（互相不能知道对方资源管理中TT汇报的正在运行的任务数，使用内存等情况），所以不能够感知对方的使用情况。所以最终会导致资源争抢！

因为上面的问题，hadoop2.x就已经发生变化和调整了，为此引出了yarn的概念。

四、Yarn初始

在hadoop2.x中yarn的出现，解决了上面我们说的JobTracker引发的一些资源争抢、资源管理的问题。

1、yarn的概念：
Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一
种新的 Hadoop 资源管理器，它是一个通用资源管理系统和调度平台，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。可以把 yarn 理解为相当于一个分布式的操作系统平台，而 mapreduce 等运算程序则相当于运行于操作系统之上的应用程序，Yarn 为这些程序提供运算所需的资源（内存、cpu）。

2、yarn的优势与特点

• yarn 并不清楚用户提交的程序的运行机制
• yarn 只提供运算资源的调度（用户程序向 yarn 申请资源，yarn 就负责分配资源）
• yarn 中的主管角色叫 ResourceManager
• yarn 中具体提供运算资源的角色叫 NodeManager
• yarn与运行的用户程序完全解耦，意味着yarn上可以运行各种类型的分布式运算程序，比如 mapreduce、storm，spark，tez ……
• spark、storm 等运算框架都可以整合在 yarn 上运行，只要他们各自的框架中有符合yarn 规范的资源请求机制即可
• yarn 成为一个通用的资源调度平台.企业中以前存在的各种运算集群都可以整合在一个物理集群上，提高资源利用率，方便数据共享。

3、mapReduce On yarn的运行机制

mapReduce在hadoop2.x就可以依赖在资源管理层yarn上面了。
yarn架构图：

YARN 是一个资源管理、任务调度的框架，主要包含三大模块：ResourceManager（RM）、 NodeManager（NM）、ApplicationMaster（AM）。

• ResourceManager 负责所有资源的监控、分配和管理；
• ApplicationMaster负责每一个具体应用程序的调度和协调；
• NodeManager负责每一个节点的维护。
  对于所有的 applications，RM 拥有绝对的控制权和对资源的分配权。而每个 AM 则会和 RM 协商资源，同时和 NodeManager 通信来执行和监控 task。

我们观察yarn的架构图，其中hadoop1.x的时候的JobTracker和TaskTracker角色在hadoop2.x被淘汰了，换成了上面这些新角色。

不过上图的yarn架构图也是个主从模型，hadoop2.x支持yarn为HA架构，也是通过Zk进行主备切换的。

客户端提交mapReduce的运行程序流程还是和hadoop1.x差不多，拿上面的yarn架构图为例说下客户端提交任务的流程：

• step1: 客户端划分split清单后（同hadoop1.x的流程），将运行程序的jar、配置文件xml、split清单等提交到hdfs中。在hadoop1.x中客户端将会通知JobTracker去执行任务调度，而hadoop2.x的时候，客户端将会通知yarn的ResourceManager，告知有个任务要执行。

• step2: 此时ResourceManager就会去挑一台不忙的NodeManager，因为ResourceManager可以清楚的知道NodeManager所在机器的资源使用情况。此时RM就会通知NM启动一个Application master角色（图中AppMstr）。

实际上NM启动AppMstr进程的时候，也是先启动一个container，然后再由这个container反射映射出AppMstr这个对象跑起来的。

• step3: AppMstr就会根据客户端上传的文件在hdfs的路径，获取对应运行的split清单信息。
  AppMstr这个角色就相当于阉割版的JobTracker，也就相当于去除了资源管理的JobTracker，因为AppMstr并不知道每台节点的资源使用情况，所以AppMstr又回过头来依赖ResourceManager，并且根据split清单信息告知ResourceManger：“现在我有x个split，对应x个map要运行，这些map可以运行在xxDataNode节点上，请你根据每台节点的资源使用情况，帮我决定哪些节点可以跑这里的哪些map”。

• step4: 当RM收到AppMstr的这个信息后，就会根据NodeManager汇报的节点资源信息，将适量的map提交到不同NM所在的机器上，并通知NM，告知它要运行map的数量。

• step5: 然后RM会在对应的NM的机器上创建对应map数量的container进程，实际上container就相当于容器，里面规定了这个map未来运行需要多少内存，占用哪些资源等（container是逻辑的也是物理的）。

• step6: 当container启动了之后，会反向注册到ApplicationMaster中，这时候AppMstr就知道哪台机器上运行了多少个container，也就知道这个集群中有多少个槽位可供AppMstr做任务调度的。然后container会去hdfs中拉取客户端上传jar，并运行，最终mapTask将会运行在container中（这里就实现了container从逻辑的概念变现成物理的概念，也就是最终会启动一个container进程，并按照之前定义container所需的内存大小等划分这个jvm进程）。

• step7: 最终，AppMstr就会将MapTask/ReduceTask调度给注册到它上面的container。注意这里并不是AppMstr直接将MapTask/ReduceTask计算程序直接发给container的，而是让container自己去hdfs中拉取对应的jar包、配置文件xml等信息，然后通过反射机制得到对象及运行方法。

4、yarn总结

1、yarn模型中的container容器

yarn中的container并不是docker中的container喔

• container容器是虚拟的： 因为container在没运行成为一个JVM进程前，包含了客户端所定义的属性，比如cpu，内存，io量等。所以此时只是概念层次，并没有变现跑起来，是虚拟的。
• container容器是物理的： container最终会被NM所创建，变成一个JVM进程，使用之前container定义的一些内存资源。 与此同时，NodeManager也会启动个线程监控container资源使用情况，如果发现存在资源使用超额现象，NodeManger就立刻kill调这个container，此时container里做的操作就表示失败了。当container在这个NM节点上失败后，会被传递到其他节点运行，当然如果是因为资源使用超额后被kill导致任务失败的话，在其他节点也可能会被kill掉。当失败次数达到3次左右，将会告知整个mapTask/ReduceTask失败。

出现资源使用超额的原因，一般是用户分配运行mapTask/ReduceTask的资源不够，比如内存大小你分配1GB运行container，而在实际跑的时候，mapTask里突然分配了2GB的byte数组，当然会超额。

当然上面的方式直接kill掉container进程可能太不安全，还有种方式是使用cgroup内核级技术：在启动jvm进程，由内核约束死，这个container运行的任务未来只能使用多少内存空间，就可以省去启动监控线程的步骤。

2、yarn实现：架构/框架

• ResourceManager（主） 负责整体资源的管理

• NodeManager（从） 向RM汇报心跳，提交自己的资源情况

MapReduce在Yarn运行的流程：

yarn种一切皆是资源，一切皆是container，在container里运行对应的角色，比如AppMaster、map/reduce Task,container容器的目的用于解耦

3、感悟

从hadoop1.x到2.x

• 1.x中JobTracker和TaskTracker是MapReduce的长服务。
• 在2.x的时候就没有JobTracker和TaskTracker这些服务了，相对的，MapReduce的cli，任务调度，任务执行等这些都成为了临时服务，而且任务调度从JobTracker变成了AppMstr，AppMstr和其他的AppMstr相隔离，互不相干。