YARN统一资源（内存、cpu核数）管理和调度平台1、MR1的缺点可靠性差显然，每一个MR程序的主控任务都启动在Jobtracke中，即r
educetask，和maptask都由jobtasker来管理，一旦jobtracker宕机，整个系统都瘫痪了。扩展性差MRv1
的主节点JobTracker承担资源管理和作业调度的功能，一旦同时提交的作业过多，JobTracker的任务过重，成为整个集群的性
能瓶颈，制约集群的线性扩展。（必须知道mr的扩展性包括：数据扩展，节点扩展）资源利用低Map槽只能运行map任务，而Reduce槽
只能运行reduce任务，两者不能混用，因此在运行mr作业时，就一定会存在资源浪费的情况，（例如Map槽非常紧张，而Reduce槽
还很充裕）无法支持异构的计算框架Mr支持的是离线批处理，但在一个组织中可能并不只有离线批处理的需求，也许还有流处理的需求，大规模并
行处理的需求等，相应的新的计算框架有strom,spark,Impala等，目前MRv1并不能支持多种计算框架共存MR2的相关
改进YARN接管了所有资源管理的功能，兼容了异构的计算框架，采用无差别的资源隔离方案；整个hadoop其实是以Yarn为中心的，计
算框架都是可插拔的，而mapreduce失去了所有资源管理的功能，进而退化为单一的计算框架，并且所有计算框架都可以共享底层的数据。
3种调度器集中调度器特点：全局只运行一个中央调度器。全部计算资源都提交给中央调度器，所有的调度逻辑都由中央调度器来实现。因此在高
并发作业的情况下容易出现性能瓶颈。在分配资源时，是完全顺序执行的，相应的调度框架有MRv1的JobTracker注：调度资源不是并
发的，但计算是分布式的。双层调度器将整个调度工作划分为两层：中央调度器和框架调度器中央调度器：管理集群中所有资源的状态，它拥有集群
所有的资源信息，它按照一定策略（如FIFO、Fair、Capacity、Delay、DominantResourceFair）
将资源粗粒度地分配给框架调度器。框架调度器：各个框架收到资源后再根据作业特性细粒度地将资源分配给容器执行具体的计算任务。每个计
算框架看不到整个集群的资源，只能看到中央调度器给自己的资源。注：二级调度器的存储大大减轻了中央调度器的负载，这对并发来说有很大的
提升，资源利用率也得到了提升，但由于中央调度器的存在，这种并发还是一种悲观并发（这里的并发指的是资源分配的并行执行，不是计算的并行
执行）。当中央调度器做出将某些资源分配给哪个计算框架的决策的时候，还是必须顺序执行，属于悲观锁。注意，中央调度器还是保存有整个集群
的资源信息。状态共享调度器状态共享式调度大大弱化了中央调度器，它只需保存一份集群使用信息，取而代之的是各个框架调度器，每个调度
器都能获取集群的全部信息，并采用了乐观锁控制并发。在状态共享调度器中每个框架内部会不断从主调度器更新集群信息并保存一份，一旦框架作
出决策，就会将该信息同步到主调度，资源竞争过程是通过事务进行的，从而保证了操作的原子性。yarn的架构YARN的架构还是传统的主
从（master/slave）架构。YARN服务由resourceManager和NodeManager两类进程组成。任何类型的计
算类型的作业都可以运行在Container中。ResourceManager是中央调度器ApplicationMaster是二级
调度器（注意区分ApplicationMaster与ApplicationManager）ResourceManager是集群中所
有资源的管理者，在双层调度器范型中，属于中央调度器。它定期会接受各个NodeManager的资源汇报信息，并进行汇总并根据资源使用
情况，将资源分配给各个应用的二级调度器（ApplicationMaster）.在YARN中ResoureceManager主要的职
责是资源调度，当多个作业同时提交时，ResourceManager在多个竞争的作业之间权衡优先级并进行仲裁资源，当资源分配完成后，
RescourceManager就不关心应用内部的资源分配，也不关注每个应用的状态，ResourceManager针对每个应用来说
，只进行一次资源分配，大大减轻了ResourceManager负荷，使得其扩展性大大增强。上述的意思就是在一个yarn集群中，假设
有一个ResourceMananger节点，有多个nodemanager节点。这些nodemanager都需要向ResourceM
anager发送请求，但是虽然能够同时向resourcemanger发起请求，但在同一时间内resourcemanager只能接受
一个nodemanager的请求。这恰好说明了双层调度器模型中的中央调度器是按照顺序线性的调度集群资源以及双层调度器的调度是悲观式
的并发执行。在资源调度方面区分MR1和MR2MR1属于集中调度器模式，MR2属于双层调度器模式。jobTracker与Resou
rceManager一样都是负责资源管理和作业调度的。不同的调度资源的程度不同。jobTracker会关心应用内部的资源分配，并且
关注每个应用的状态。而yarn系统中将这个过程分成了两个阶段，分别有中央处理器和二级处理器来完成。因此我们说减轻了中央调度器的工作
负担。对于并行主要包括两个方面：一个是调度任务时的并发，一个是mr计算时的并行。Mr1：任务调度是非并发的Mr2:任务调度第一阶段
是非并发的，第二阶段是并发的。我们说集中调度器模式不是并行的，指的是在jobtracker调度资源是，由于是按照顺序（调度策略）进
行资源调度的，因此其在调度资源时不是并发的。但在mr计算时仍然可以并发执行。在双层调度器模式中，我们说它属于悲观试并发。这里的并发
指的是二级调度器给执行容器进行细粒度调度资源的过程。在中央调度器给各个二级调度器进行粗粒度分配资源时，这个过程与集中式调度器一样也
不是并行。同时mr的计算过程仍然是并行的。ResoureManager的内部结构ResourceManager的内部结构可以分成四
大部分：与namenode交互与ApplicationMaster交互与客户端交互调度器模块注：一定要区分1和21与namenod
e交互ResourceTrackerService：负责和NodeManager进行交互，NodeManager会周期性地发送
心跳到resourceManager的resourcetrackerService。该组件负责响应来自所有节点的RPC请
求，包括：注册新节点、接受前面注册节点的心跳、确保只有合法的节点可以和resourceManager通信，拒绝其他不合法的节点。
注意：对于任务调度也涉及到主从节点之间的交互，但这个交互并不是通过心跳完成的，也就是说与namenode交互并不是一回事。2与Ap
plicationMaster交互（1）ApplicationManager(应用程序管理器):ApplcationManag
er负责管理已提交的应用的集合。在应用提交后，首先检查ApplicationMaster资源请求的合法性，然后确定没有其他已提交的
应用已经使用了相同的id。ApplicationMasterservice：该组件响应来自所有ApplicationMaster
的请求，它可以注册新的ApplicationMaster、接受来自任意正在结束的ApplicationMaster的终止或取消注册
请求、认证来自不同ApplicationMaster的所有请求。与客户端交互ClientService：负责处理来自客户端到R
esourceManager的RPC通信。调度器模块YarnScaheduler（主调度器）:负责给正在运行的应用程序分配资源，
目前能够调度的资源为内存和cpu核。目前支持调度器有FIFO调度器，Capacity调度器、自适应调度器、自学习调度器、动态优先级
调度器等。小结：Nodemanager的内部结构YARN的资源表示模型ContainerMRv1的资源模型：是由两个槽（slot
）构成，其中Map槽只能运行map程序，reduce槽只能运行reduce程序。这两个槽即不能增加也不能减少，对于MR这种计算框架
，对Map槽和Reduce槽的需求会根据作业执行过程的变换而变化，这就必定会造成资源浪费。Yarn模型Container：对不同计
算框架都是无差别对待的，container中完全没有计算框架的逻辑，非常简洁和干净。Container将按照二级调度器Applic
ationMaster申请的大小来按需分配资源，从而大大减少了资源浪费。yarn的工作流程客户端向resourceManager提
交自己的应用。ApplicationManager向NodeManager发送指令，为该应用启动一个Container，并在Con
tainer中启动ApplicationMaster。ApplicationMaster向ApplicationManager注册
，目的是让ApplicationManager先检测ApplicationMaster请求资源是否合法。合法则执行下一步。当合法后
，AppcationMaster采用轮训的方式向ResourceManager的YarnScheduler申领资源。当Applic
ationMaster申请到资源后，便会与对应的nodemanager进行通信，请求启动计算任务。NodeManager根据资源量
的大小，所需的运行环境，在Container中启动map和reduce任务。各个任务向applicationMaster汇报自己的
状态和进度，以便applicationMaster掌握各个任务的执行状况。应用程序运行完成后，ApplicationMaster向
ResourceManager注销并关闭自己。注：上述为典型的双层调度器的实现：上述主调度器是：YarnScheduler二级调
度器是：ApplicationMasteryarn的调度器YarnScheduler是yarn的主调度器，其有多种实现，每一种
对应了不同的调度策略。如FIFOScheduler,FairScheduler,CapacityScheduler等。资源调
度器是YARN中最核心的组件之一，并且是可插拔的。用户可以根据它的一整套接口，编写自己的Scheduler，实现自己所需的调度逻辑
（这里的调度逻辑指的是第一次调度逻辑，而不关注第二层调度策略）Yarn的资源管理机制（1）YARN的资源是以资源池的形式组织的。每
个资源池对应一个队列（queue）,用户在提交作业的时候以-queue参数指定要提交的队列，就可以使用队列背后对应的资源池。基于队
列的资源池在实际场景中非常有用，每一个队列可以对应到某个部门或者项目组，这样在一个集群中，就可以支持多个业务同时运行而互不干涉。（
2）YARN中最大的资源池就是整个集群的资源，对应队列为root根队列，如果用户不指定队列，那么默认提交的就是该队列。（3）用户只
能将自己的作业提交给子队列，每个队列都可继续向其中添加子队列。子队列的资源使用的都是父队列的资源。几种常见的调度机制作业调度机
制需要考虑客户端提交作业，以及作业的执行等方面。FIFO先进先出队列特点：先提交的任务先执行，占用整个集群的资源，所有的任务都是串行执行；（默认一个job作业的task最多只能在一个节点中同时被启动2个）缺点：作业的并发度不高，造成资源浪费适用场景：作业数量少的FairScheduler:公平机制假如当前只有2个task，那么它们各占自愿的50%，现在又增加2个task，则此时它们各占25%。适合：任务批次提交，并且任务的计算复杂度基本一致不适合：同时提交很多任务自定义各任务所占资源可以自己决定。适合：主要是一些作业的计算所需资源很不均衡的场景。不适合：成千上万个任务 |
|
