快手超大规模集群调度优化实践

1. 离线ETL场景

离线场景下如何保障核心作业的SLA是比较核心的问题。在快手，核心作业和普通作业在同一个队列中，通过完善作业分级保障能力和异常节点规避能力，保障核心作业的SLA。

离线ETL场景中经常会遇到以下情况以及相应的优化方案：

① 其他队列作业大量占据资源不释放

通过优化队列间资源抢占来解决这个问题。为防止抢占影响过大，默认情况下只有高优先级核心作业触发抢占，并且会限制每轮抢占的最大资源量。抢占过程中根据作业优先级，饥饿等待时间等条件动态计算每个队列可以抢占的资源量，从而把资源倾斜给优先级更高，饥饿等待时间更长的作业。

② 队列内低优先级作业占据大量资源不释放

在生产场景下如果低优先级作业占用大量资源不释放，导致优先级比较高的任务无法获取到足够资源，从而导致产出延迟。为解决这个问题提出基于虚拟队列来保障高优先级作业产出。所谓虚拟队列，是在物理队列下，按照一定逻辑规则（比如优先级）抽象出的逻辑队列。每个虚拟队列有一定的资源配额，并且会触发物理队列内部的抢占，从而解决上面的问题。

③ 低优先级作业占据app solt不释放

为方便AppSlot资源的管理，抽象出minApp概念，如果App启动时，队列running App小于minApp，将会立刻启动App，不会受限于父队列的maxRunningApp，这样在队列层面保障有可预期的app slot。但同样存在一个问题，队列内部低优先级作业占据大量AppSlot不释放，导致高优先级作业启动延迟。为此提出了App Slot抢占功能。如下图所示，如果发现高优先级作业（P0）长时间pending不能启动，扫描队列内runningApp，选择低优先级作业进入睡眠模式（不再调度新task，极端情况下回收task）从而释放出slot资源，保障高优先级作业能及时启动。

④ 回溯作业影响生产作业

回溯作业的特点在于大量提交多个作业，如果不加控制可能会影响生产作业的产出。主要方案是限制回溯作业最大资源量和最大运行APP数目，将影响控制在一定的范围以内。但是限制最大资源量和运行数目导致大量回溯作业在yarn处于pending状态，对yarn有比较大的压力，通过与上游调度系统打通，反压上层工作流调度系统，阻止新提交的回溯作业，从而减轻了YARN负载。对于已经提交到yarn上的作业，会限制每个队列最大pending app个数，从而保障总体pending app数目可控。

⑤ 高优先级作业大块资源请求不能及时满足

原有的Reserve机制中，调度器可以reserve一批节点，不再调度新task，等待节点上自然释放资源。如果被reserve节点资源长时间不释放，如何处理？针对这个场景开发了reserve抢占功能，用于抢占reserve节点上的低优先级的container，从而保障节点上有足够的空闲资源启动高优先级作业。

⑥ 规避异常节点，避免核心作业长尾

通过采集节点物理指标，task失败率，task运行速度，以及shuffle失败率等，将此节点标记为异常节点，不再调度新Task。从而尽量减少异常节点的影响范围，规避其导致的Task长尾，失败问题。

2. Adhoc即时查询场景

AdHoc场景主要着力于提升每个用户的查询体验。

通过虚拟队列技术，从user维度来划分虚拟队列，实现基于user公平的资源的分配，配合基于user的资源抢占，从而避免大量资源被某一个用户占用，导致其他用户长时间得不到资源。

3. 机器学习训练场景

机器学习训练场景下，资源需求呈现all or nothing特点，在队列资源紧张时，如果基于yarn原生的公平调度方式，为每个app分配部分资源，容易产生资源分配死锁问题。为此我们采用APP轮转调度策略，采用类似FIFO策略，保障头部APP（头部会动态变化，轮转策略名称的由来）的资源需求，避免死锁问题。

4. Flink实时作业场景

FLink实时场景下，主要介绍故障发生时，如何尽量减少故障的影响范围，以及如何快速恢复故障作业：

• 通过cpu均衡调度，避免机器cpu热点。

• 通过AM失败节点规避机制，避免调度到AM失败机器。

• NM挂起（不调度新Task，介于RUNNING和LOST状态）机制，防止NM异常退出导致Task失败。

• 基于Hawk秒级发现节点宕机，快速进行作业恢复。

虽然可以基于Hawk秒级发现节点宕机，但作业恢复过程可能需要几分钟（申请资源，下载jar包，job recover等）。我们通过资源冗余分配策略，优化掉其中资源申请和下载jar包过程，最终实现秒级作业恢复。