B站调度优化实践

B站的YARN以社区的2.8.4分支构建，采用CapacityScheduler作为调度器， 期间进行过多次核心功能改造，目前支撑了B站的离线业务、实时业务以及部分AI训练任务。2020年以来，随着B站业务规模的迅速增长，集群总规模达到8k左右，其中单集群规模已经达到4k+ ，日均Application（下文简称App）数量在20w到30w左右。当前最大单集群整体cpu使用率，峰值通常会达到80%：

2021年，在原有的AZ1机房无法扩容的背景下，启用了AZ2机房。在每个机房中同时存在离线集群、实时集群、与在线业务混部集群，这些集群分别支持一定的业务场景。为了支撑跨机房场景，所有Client接入Federation，通过RMProxy路由到不同机房的不同集群。具体架构如下图所示：

定义单个App的分配时间是其下所有Container分配时间的总和，而单个Container的分配时间可以理解为从发出申请该Container，到App实际拿到该Container之间的时间差。举个例子，假如某一App的资源获取过程如下图所示：

假设一开始(t0)申请 8 个Container，一段时间后(t1)返回 5 个Container，那么一共有5个Container在等待了 t1 – t0 时间后，拿到了自己的资源。如此我们便获得了5个Container的分配时间。随后(t2)又申请了2 个Container，又一段时间后(t3)返回了5 个Container。至此，该App再也不需要其它Container了。那么，按照上文所说：一共有5个Container的等待时间为 t1 – t0，有3个Container的等待时间为 t3 – t0。这就是上回没分配到的那3个Container。有2个Container的等待时间为 t3 – t2。那么该App的Container等待时间就如上图蓝色面积所示，即 5 * (t1 – t0) + 3 * (t3 – t0) + 2 * (t3 – t2)。

整个集群情况如上图所示，红色代表高优先级的App, 灰色则是低优先级，我们的优化目标是App分配时长占运行时长的比例越小越好。

从业务层面如何判断调度系统是否成为系统的瓶颈，是平台层需要思考的问题。在YARN的资源设计中，通常每个业务会对应一个队列，我们从队列资源等待情况（pending），集群资源使用率（clusterUsedR），队列资源使用率（queueUsedR）这三个变量入手，定义了有效调度指标（validSchedule）的含义：当资源存在等待的情况下，若此时集群资源使用率低于一定阈值（比如90%），队列资源使用率也低于一定阈值（如95%），认为此时调度性能已无法满足该队列的资源需求。

返回1即认为是当前调度满足需求，相反返回0则认为当前调度无法满足需要。如下图所示，选取某个作业量较多的队列，发现在夜间高峰时段，有效调度指标会高频次掉0，也就说高峰时段调度上还存在一些瓶颈。

利用有效调度指标作为判断依据，当每个队列提交任务请求过多时，可以通过反压服务让Client提交等待，防止无效请求在集群中无意义的堆积。

反压服务毕竟压制了用户的请求，而我们的目标是尽力满足用户的资源需求。为了达到这一目标，我们需要对YARN调度的核心流程重新进行梳理：

上述的调度核心流程至少存在两个问题。一是Scheduler 锁从选取节点，选取队列以及App直到分配结束，这个过程的前半部分是可以剥离出来的，而调度写锁只需要锁住核心资源的变动即可；二是整个调度流程涉及多个对象的排序，这方面业界也有很多优化点。故针对这两点作出相应改进。

从上述调度流程可知，关注的核心排序逻辑主要存在于队列和App两个层级。

在队列层面，目前我们根据不同的业务需求设置了相应的队列优先级，同时部分无法按照业务划分的作业通过在队列内部设置App优先级的方式来区别对待。对于每次分配流程而言，调度器并不是每次分配都需要感知队列资源的使用情况并触发排序的。调度器的主要精力还是聚焦于分配，故而我们在每次队列排序后，进行一段时冷却。

在App层面，目前使用的策略类似SP算法（严格优先级调度，Strict Priority)，按照优先级从高到低选取，等到高优轮询结束才轮到低优，这样会存在部分低优App始终无法得到分配。经过调研发现WRR(加权轮询，Weighted Round Robin) 能够很好的解决这一问题，据此我们设计出了WRR Ordering Policy作为App层面的排序策略。

如上图所示，WRR在每个层级享受的调度机会和该层级的权重成比例。该策略首先判断是否为优先级5，若为5则执行严格的优先调度SP，先将优先级5的App全部执行完毕，之后再执行4到0优先级的App。这样设计能够确保在特殊情况下强保的App能够最快速完成。

具体来说，优先级5的App一定都是当前最重要的App，不应在其内部对App调度次序再进行比较，遵循先来后到的原则对于用户来说较有说服力，故在优先级5的内部采用FIFO作为Comparator。在一般情况下，App优先级为0（最低优）至4（次高优），此时加权轮询WRR作为App分配策略。WRR能够通过简单的计算，达到最细粒度区分不同优先级App获取资源速度的目的。而每个相同优先级内部采用DRF作为Comparator，这是由于相较于FairComparator，DRFComparator能够将VCore也纳入了比较范围，综合考虑多种资源。对DRFComparator，还引入了App分配等待因子，如果一个App等待分配时间过长，则需要把提高该App分配优先级，避免App长时间饿死。

为了观察WRR Ordering Policy的效果，我们利用压测工具SLS压测2400个节点、5000个Job，App分0～3四个优先级。压测结果如下图所示，任务完成时间按照优先级分布，且每个时段也同时存在低优任务完成，符合预期。

单集群内节点的增长对YARN的调度性能提出了更高的要求。当RM管控的节点数量超过4000后，原先默认的心跳驱动调度（Heartbeat-Driven Scheduler）已经无法将集群的利用率持续打满。为了保证RM的调度能力与NM的增长速度匹配，我们评估了Hadoop开源社区对RM性能提升的解决方案，最终决定采用Global Scheduling的思路对当前RM调度逻辑进行改造。

Global Scheduling：全局调度

Proposal ：一次分配的提议，比如某个App要求在队列A分配资源

AsyncScheduleThread: 负责提出Proposal的线程，可并发

resourceCommitterService: 负责接受或拒绝Proposal 的线程，单线程

Global Schedusling的主要目标可以分为两个，第一是赋予YARN多线程调度的能力，从而提升单集群的调度性能；第二是将App的可选范围从单一Node的转变为批量Nodes（PlacementSet），从而能够支持较优节点调度、满足更复杂的资源请求。基于此，我们将Global Scheduling分为两个版本进行迭代升级，其中v1版本聚焦于YARN多线程改造，v2版本聚焦于批量节点及其选取策略改造。

YARN调度的逻辑能够分为“提出Proposal”、“消费Proposal”两个部分，目前的单线程调度逻辑将两部分在一个线程中完成，而Global Scheduling v1的主要目标是对上述两部分进行解耦，之后将“提出Proposal”的逻辑改为多线程并发，再单独生成一个线程运行“消费Proposal”的逻辑，具体框架如下图所示：

在Global Scheduling 灰度上线离线集群时，发现ERROR Log的数量在启动后陡增，检查日志后发现大量报错信息为：

6. 展望