分布式资源调度YARN

  • Post author:
  • Post category:其他


YARN产生背景

  • Hadoop1.x中的MapReduce构成图如下:

在Hadoop1.x中MapReduce是Master/Slave结构,在集群中的表现形式为:

1个JobTracker带多个TaskTracker;



JobTracker

:负责资源管理和作业调度;
只存在一个JT——–宕掉后,整个架构无法完成作业运行,即


单点故障






JT要接受来自每个TT的RPC请求和客户端的作业提交/查询请求,集群规模越来越大时


,JT节点存在压力过大的瓶颈仅支持MapReduce作业,不支持其他计算框架



TaskTracker

:定期向JobTracker汇报本节点的健康状况、资源使用情况以及任务的执行情况;
接收来自JobTracker的命令(启动/杀死任务等)并执行接收到的命令;


1、MapReduce1.0存在的问题:

1)

单点故障

:JobTracker只有一个,JobTracker挂了整个集群就没办法使用了;

2)JobTracker负责接收来自各个JobTracker节点的RPC请求,压力会很大

,限制了集群的扩展;随着节点规模增大之后,JobTracker就成为一个瓶颈



3)

仅支持MapReduce计算框架;


MapReduce计算框架是一个基于Map和Reduce两阶段、适合批处理的、基于磁盘的计算框架;

MapReduce计算框架优点:容错性好;

MapReduce计算框架缺点:性能差;


2、资源利用率

在没有YARN之前,是一个集群一个计算框架。比如:Hadoop一个集群、Spark一个集群、HBase一个集群……

造成各个集群管理复杂,资源的利用率很低

;比如:在某个时间段内Hadoop集群忙而Spark集群闲着,反之亦然,各个集群之间不能共享资源造成集群间资源并不能充分利用;

解决思路:

将所有的计算框架运行在一个集群中,

共享一个集群的资源

,按需分配;Hadoop需要资源就将资源分配给Hadoop,Spark需要资源就将资源分配给Spark,进而整个集群中的资源利用率就高于多个小集群的资源利用率;


3、运维成本

采用“一个框架一个集群”的模式,则需要多个管理员管理这些集群,进而增加运维成本;

而共享集群模式通常需要少数管理员即可完成多个框架的统一管理;


4、数据共享

随着数据量的暴增,跨集群间的数据移动不仅需要花费更长的时间,且硬件成本也会大大增加;

而共享集群模式可让多种框架共享数据和硬件资源,将大大减少数据移动带来的成本;


总结:

1) 源于MRv1的缺陷:

扩展性受限、单点故障、难以支持MR之外的计算框架;


2)

多计算框架各自为战,数据共享困难,资源利用率低;




MR: 离线计算框架

Storm:实时计算框架

Spark:内存计算框架


催生了YARN的产生。


YARN:不同计算框架可以共享同一个HDFS集群上的数据,享受整体的资源调度

XXX on YARN的好处:(

XXX: Spark/MapReduce/Storm/Flink





与其他计算框架共享集群资源,按资源需要分配,进而提高集群资源的利用率。




YARN基本构成



YARN架构:



1.ResourceManager:


整个集群只有一个,负责集群资源的统一管理和调度





1)处理来自客户端的请求(启动/杀死应用程序);

2)启动/监控ApplicationMaster;一旦某个AM挂了之后,RM将会在另外一个节点上启动该AM;

3)监控NodeManager,接收NodeManager的心跳汇报信息并分配任务到NodeManager去执行;一旦某个NM挂了,


标志下该NM上的任务,来告诉对应的AM如何处理;

4)负责整个集群的资源分配和调度;



2. NodeManager:


整个集群中有多个,负责单节点资源管理和使用





1)周期性向ResourceManager汇报本节点上的资源使用情况和各个Container的运行状态;



2)接收并处理来自ResourceManager的Container启动/停止的各种命令;



3)处理来自ApplicationMaster的命令;



4)负责单个节点上的资源管理和任务调度;



3. ApplicationMaster:


每个应用一个,负责应用程序的管理



1)数据切分;



2)为应用程序/作业向ResourceManager申请资源(Container),并分配给内部任务;



3)与NodeManager通信以启动/停止任务;



4)任务监控和容错(在任务执行失败时重新为该任务申请资源以重启任务);



5)处理ResourceManager发过来的命令:杀死Container、让NodeManager重启等;



4.Container:


对任务运行环境的抽象


1)封装了任务运行资源(节点、内存、CPU)的一个容器;

2)任务启动命令;

3)任务运行环境;

任务是运行在Container中,一个Container中既可以运行ApplicationMaster也可以运行具体的Map/Reduce/MPI/Spark Task;


5. Client





提交作业





查询作业的运行进度





杀死作业



流程:Task submit —–> 先到ResourceManage —–> 从RM在到任意一个NodeManage上去启动ApplicationMaster——-> AM再到RM申请资源——->RM通知对应的NM,启动Container运行Task





YARN工作原理








1)用户向YARN中提交应用程序/作业,其中包括ApplicaitonMaster程序、启动ApplicationMaster的命令、用户程序等;


2)ResourceManager为作业分配第一个Container,并与对应的NodeManager通信,要求它在这个Containter中启动该作业的ApplicationMaster;


3)ApplicationMaster首先向ResourceManager注册,这样用户可以直接通过ResourceManager查询作业的运行状态;然后它将为各个任务申请资源并监控任务的运行状态,直到运行结束。即重复步骤4-7;


4)ApplicationMaster采用轮询的方式通过RPC请求向ResourceManager申请和领取资源;


5)一旦ApplicationMaster申请到资源后,便与对应的NodeManager通信,要求它启动任务;


6)NodeManager启动任务;


7)各个任务通过RPC协议向ApplicationMaster汇报自己的状态和进度,以让ApplicaitonMaster随时掌握各个任务的运行状态,从而可以在任务失败时重新启动任务;

在作业运行过程中,用户可随时通过RPC向ApplicationMaster查询作业当前运行状态;

8)作业完成后,ApplicationMaster向ResourceManager注销并关闭自己;


流程:

①Client submit task —–> RM

②,③RM 与 NM 通信,在这个NM上启动一个Container(用来启动应用程序ApplicationMaster)

④AM到RM上注册,注册完成后Client即可查询Task运行情况,AM向RM上申请Core,Memory

⑤,⑥AM在对应的NM上启动Task(在Container中启动)






YARN容错性



1、ResourceMananger

基于ZooKeeper实现HA避免单点故障;

2、NodeManager

执行失败后,ResourceManager将失败任务告诉对应的ApplicationMaster;

由ApplicationMaster决定如何处理失败的任务;

3、ApplicationMaster

执行失败后,由ResourceManager负责重启;

ApplicationMaster需处理内部任务的容错问题;

RMAppMaster会保存已经运行完成的Task,重启后无需重新运行。



YARN调度框架



1、双层调度框架

1)ResourceManager将资源分配给ApplicationMaster;

2)ApplicationMaster将资源进一步分配给各个TASK;


2、



基于资源预留的调度策略




1)资源不够时,会为Task预留,直到资源充足;



描述:当一个Task需要10G资源时,各个节点都不足10G,那么就选择一个节点,但是某个NodeManager上只有2G,那么就在这个NodeManager上预留,当这个NodeManager上释放其他资源后,会将资源预留给10G的作业,直到攒够10G时,启动Task;





缺点:资源利用率不高,要先攒着,等到10G才利用,造成集群的资源利用率低;



2)与“all or nothing”策略不同(Apache Mesos)



描述:当一个作业需要10G资源时,节点都不足10G,


那就慢慢等


,等到某个节点上有10G空闲资源时再运行,


很可能会导致该Task饿死。



YARN设计目标



通用的统一的资源管理系统:

1)同时运行


长应用程序


(永不停止的程序:Service、HTTP Server);

2)


短应用程序


(秒、分、小时级内运行结束的程序:MR job、Spark job等);




MapReduce2.0与YARN


1、一个MapReduce应用程序需要如下模块:

1)任务管理和资源调度;

2)任务驱动模块(MapTask、ReduceTask);

3)用户代码(Mapper、Reducer);

2、MapReduce2.0的组成:

1)YARN(整个集群只有一个);

2)MRAppMasster(一个应用程序一个);

3)用户代码(Mapper、Reducer);

3、MapReducer1.0和MapReduce2.0的区别:

1)MapReduce1.0是一个独立的系统,直接运行在Linux上;

2)MapReduce2.0则是运行在YARN上的框架,且可与多种框架一起运行在YARN之上;

4、MapReduce2.0和YARN的区别:

1)YARN是一个资源管理系统,负责资源管理和调度;

2)MapReduce只是运行在YARN上的一个应用程序;如果把YARN看成是android,那么MapReduce就是运行在android上个一个app;



版权声明:本文为qq_22027637原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。