| 
                        副标题[/!--empirenews.page--]
                         背景 
YARN作为Hadoop的资源管理系统,负责Hadoop集群上计算资源的管理和作业调度。 
美团的YARN以社区2.7.1版本为基础构建分支。目前在YARN上支撑离线业务、实时业务以及机器学习业务。 
    - 离线业务主要运行的是Hive on MapReduce, Spark SQL为主的数据仓库作业。
 
    - 实时业务主要运行Spark Streaming,Flink为主的实时流计算作业。
 
    - 机器学习业务主要运行TensorFlow,MXNet,MLX(美团点评自研的大规模机器学习系统)等计算作业。
 
 
YARN面临高可用、扩展性、稳定性的问题很多。其中扩展性上遇到的最严重的,是集群和业务规模增长带来的调度器性能问题。从业务角度来看,假设集群1000台节点,每个节点提供100个CPU的计算能力。每个任务使用1个CPU,平均执行时间1分钟。集群在高峰期始终有超过10万CPU的资源需求。集群的调度器平均每分钟只能调度5万的任务。从分钟级别观察,集群资源使用率是50000/(100*1000)=0.5,那么集群就有50%的计算资源因为调度能力的问题而无法使用。 
随着集群规模扩大以及业务量的增长,集群调度能力会随着压力增加而逐渐下降。假设调度能力依然保持不变,每分钟调度5万个任务,按照5000台节点的规模计算,如果不做任何优化改进,那么集群资源使用率为:50000/(100*5000)  = 10%,剩余的90%的机器资源无法被利用起来。 
这个问题解决后,集群在有空余资源的情况下,作业资源需求可以快速得到满足,集群的计算资源得到充分地利用。 
下文会逐步将Hadoop YARN调度系统的核心模块展开说明,揭开上述性能问题的根本原因,提出系统化的解决方案,最终Hadoop  YARN达到支撑单集群万级别节点,支持并发运行数万作业的调度能力。 
整体架构 
YARN架构 
YARN负责作业资源调度,在集群中找到满足业务的资源,帮助作业启动任务,管理作业的生命周期。 
资源抽象 
YARN在cpu,memory这两个资源维度对集群资源做了抽象。 
- class Resource{ 
 -   int cpu;   //cpu核心个数 
 -   int memory-mb; //内存的MB数 
 - } 
 
  
作业向YARN申请资源的请求是:List[ResourceRequest] 
- class ResourceRequest{ 
 -   int numContainers; //需要的container个数 
 -   Resource capability;//每个container的资源 
 - } 
 
  
YARN对作业响应是:List[Container] 
- class Container{ 
 -   ContainerId containerId; //YARN全局唯一的container标示 
 -   Resource capability;  //该container的资源信息 
 -   String nodeHttpAddress; //该container可以启动的NodeManager的hostname 
 - } 
 
  
YARN调度架构 
  
YARN调度器
名词解释 
    - ResourceScheduler是YARN的调度器,负责Container的分配。
 
    - AsyncDispatcher是单线程的事件分发器,负责向调度器发送调度事件。
 
    - ResourceTrackerService是资源跟踪服务,主要负责接收处理NodeManager的心跳信息。
 
    - ApplicationMasterService是作业的RPC服务,主要负责接收处理作业的心跳信息。
 
    - AppMaster是作业的程序控制器,负责跟YARN交互获取/释放资源。
 
 
调度流程 
    - 作业资源申请过程:AppMaster通过心跳告知YARN资源需求(List[ResourceRequest]),并取回上次心跳之后,调度器已经分配好的资源(List[Container])。
 
    - 调度器分配资源流程是:Nodemanager心跳触发调度器为该NodeManager分配Container。
 
 
资源申请和分配是异步进行的。ResourceScheduler是抽象类,需要自行实现。社区实现了公平调度器(FairScheduler)和容量调度器(CapacityScheduler)。美团点评根据自身的业务模式的特点,采用的是公平调度器。 
公平调度器 
作业的组织方式 
在公平调度器中,作业(App)是挂载如下图的树形队列的叶子。 
 队列结构 
核心调度流程 
  
核心调度流程
    - 调度器锁住FairScheduler对象,避免核心数据结构冲突。
 
    - 调度器选取集群的一个节点(node),从树形队列的根节点ROOT开始出发,每层队列都会按照公平策略选择一个子队列,最后在叶子队列按照公平策略选择一个App,为这个App在node上找一块适配的资源。
 
 
对于每层队列进行如下流程: 
    - 队列预先检查:检查队列的资源使用量是否已经超过了队列的Quota
 
    - 排序子队列/App:按照公平调度策略,对子队列/App进行排序
 
    - 递归调度子队列/App
 
 
例如,某次调度的路径是ROOT -> ParentQueueA -> LeafQueueA1 ->  App11,这次调度会从node上给App11分配Container。 
伪代码 
- class FairScheduler{ 
 -   /* input:NodeId 
 -    *  output:Resource 表示分配出来的某个app的一个container的资源量 
 -    *  root 是树形队列Queue的根 
 -    */ 
 -   synchronized Resource attemptScheduling(NodeId node){ 
 -     root.assignContainer(NodeId); 
 -   } 
 - } 
 -  
 - class Queue{ 
 -   Resource assignContainer(NodeId node){ 
 -     if(! preCheck(node) ) return;  //预先检查 
 -       sort(this.children);  //排序 
 -     if(this.isParent){ 
 -       for(Queue q: this.children) 
 -         q.assignContainer(node);  //递归调用 
 -     }else{ 
 -       for(App app: this.runnableApps) 
 -         app.assignContainer(node); 
 -     } 
 -   } 
 - } 
 -  
 - class App{ 
 -   Resource assignContainer(NodeId node){ 
 -     ...... 
 -   } 
 - } 
 
  
公平调度器架构 
                                                (编辑:91站长网) 
【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! 
                     |