资源调度框架YARN的前世今生

一、产生的背景

　　1、MapReduce1.0存在的问题 ，架构如图所示:

　     　　　　　　   　

1)单点故障:JobTracker只有一个,JobTracker挂了整个集群就没办法使用了;

2)一个人干的活太多：JobTracker负责接收来自各个JobTracker节点的RPC请求,压力会很大,限制了集群的扩展;随着节点规模增大之后,JobTracker就成为一个瓶颈;

　　2、资源利用率和运维成本

　　　　1)在没有YARN之前,是一个集群一个计算框架。比如:Hadoop一个集群、Spark一个集群、HBase一个集群......造成各个集群管理复杂,资源的利用率很低;比如:在某个时间段内Hadoop集群忙而Spark集群闲着,反之亦然,各个集群之间不能共享资源造成集群间资源并不能充分利用;

              解决思路:将所有的计算框架运行在一个集群中,共享一个集群的资源,按需分配;Hadoop需要资源就将资源分配给Hadoop,Spark需要资源就将资源分配给Spark,进而整个集群中的资源利用率就高于多个小集群的资源利用率;

　　　　2)采用“一个框架一个集群”的模式,则需要多个管理员管理这些集群,进而增加运维成本;而共享集群模式通常需要少数管理员即可完成多个框架的统一管理;

                  

二、YARN架构

　　　RM(ResourceManag