阿里巴巴伏羲调度系统在双 11 场景下面临的挑战以及技术如何实现

随着阿里经济体和阿里云业务需求（尤其是双十一）的不断丰富，伏羲的内涵也不断扩大，从单一的资源调度器（对标开源系统的 YARN）扩展成大数据的核心调度服务，覆盖数据调度（Data Placement）、资源调度（Resouce Management）、计算调度（Application Manager）、和本地微（自治）调度等多个领域，并在每一个细分领域致力于打造超越业界主流的差异化能力。

过去十年来，伏羲在技术能力上每年都有新的进展和突破，2013 年 5K，2015 年 Sortbenchmark 世界冠军，2017 年超大规模离在/在离线混部能力，2019 年的 Yugong 发布并且论文被 VLDB2019 接受等。随着 Fuxi 2.0 首次亮相 2019 双 11，今年飞天大数据平台在混部侧支持和基线保障 2 个方面均顺利完成了目标。其中，混部支持了双十一 60%在线交易洪峰的流量，超大规模混部调度符合预期。在基线保障方面，单日数据处理 970PB，较去年增长超过 60%。在千万级别的作业上，不需要用户额外调优，基本做到了无人工干预的系统自动化。

新的挑战

随着业务和数据的持续高速增长，MaxCompute 双十一的作业量和计算数据量每年的增速都保持在 60%以上 。

2019 双十一，MaxCompute 日计算数据量规模已接近 EB 级，作业量也到了千万量级，在如此大规模和资源紧张的情况下，要确保双十一稳定运行，所有重要基线作业按时产出压力相当之大。

在双十一独特的大促场景下，2019 双 11 的挑战主要来自以下几个方面：

1、超大规模计算场景下，以及资源紧张的情况下，如何进一步提升平台的整体性能，来应对业务的持续高速增长。

2、双十一会给 MaxCompute 带来全方面超压力的极端场景，如几亿条的热点 key、上千倍的数据膨胀等，这对集群磁盘 IO 的稳定性、数据文件读写性能、长尾作业重跑等各方面都是挑战。

3、近千万量级作业的规模下，如何做到敏捷、可靠、高效的分布式作业调度执行。

4、以及对高优先级作业（如重要业务基线）的资源保障手段。

5、今年也是云上集群首次参与双十一，并且开始支持混部。

如何应对挑战

为了应对上述挑战，与往年相比，除了常规的 HBO 等调整之外，飞天大数据平台加速了过去 1-2 年中技术积累成果的上线，尤其是 Fuxi 2.0 首次亮相双十一，最终在单日任务量近千万、单日计算量近千 PB 的压力下，保障了基线全部按时产出。

• 在平台性能优化方面，对于挑战 #1 和 #2，StreamlineX + Shuffle Service 根据实时数据特征自动智能化匹配高效的处理模式和算法，挖掘硬件特性深度优化 IO，内存，CPU 等处理效率，在减少资源使用的同时，让全量 SQL 平均处理速度提升将近 20%，出错重试率下降至原来的几十分之一，大大提了升 MaxCompute 平台整体效能。

• 在分布式作业调度执行方面，对于挑战 #3，DAG 2.0 提供了更敏捷的调度执行能力,和全面去阻塞能力，能为大规模的 MR 作业带来近 50%的性能提升。同时 DAG 动态框架的升级，也为分布式作业的调度执行带来了更灵活的动态能力，能根据数据的特点进行作业执行过程中的动态调整。

• 在资源保障方面，为应对挑战 #4，Fuxi 对高优先级作业 （主要是高优先级作业）采取了更严格、更细粒度的资源保障措施，如资源调度的交互式抢占功能，和作业优先级保障管控等。目前线上最高优先级的作业基本能在 90s 内抢占到资源。

• 其他如业务调优支持等：如业务数据压测配合，与作业调优等。

StreamlineX + Shuffle Service

挑战

上面提到今年双十一数据量翻倍接近 EB 级，作业量接近千万，整体资源使用也比较紧张，通过以往经验分析，双十一影响最关键的模块就是 Streamline (在其他数据处理引擎也被称为 Shuffle 或 Exchange)，各种极端场景层出不穷，并发度超过 5 万以上的 Task，多达几亿条的热点 Key，单 Worker 数据膨胀上千倍等全方位覆盖的超压力数据场景，都将极大影响 Streamline 模块的稳定运行，从而对集群磁盘 IO 的稳定性，数据文件读写性能，机器资源竞抢性能，长尾 Worker PVC（Pipe Version Control，提供了某些特定情况下作业失败重跑的机制）重跑等各方面产生影响，任何一个状况没有得到及时的自动化解决，都有可能导致基线作业破线引发故障。

Streamline 与 Shuffle Service 概述

• Streamline

在其他 OLAP 或 MPP 系统中，也有类似组件被称为 Shuffle 或 Exchange，在 MaxCompute SQL 中该组件涉及的功能更加完善，性能更优，主要包含但不限于分布式运行的 Task 之间数据序列化，压缩，读写传输，分组合并，排序等操作。SQL 中一些耗时算子的分布式实现基本都需要用到这个模块，比如 join，groupby，window 等等，因此它绝对是 CPU，memory，IO 等资源的消耗大户，在大部分作业中运行时间占比整个 sql 运行时间 30%以上，一些大规模作业甚至可以达到 60%以上，这对于 MaxCompute SQL 日均近千万任务量，日均处理数据接近 EB 级的服务来说，性能每提升 1 个多百分点，节省的机器资源都是以上千台计，因此对该组件的持续重构优化一直是 MaxCompute SQL 团队性能提升指标的重中之重。今年双十一应用的 SLX 就是完全重写的高性能 Streamline 架构。

• Shuffle Service

在 MaxCompute SQL 中，它主要用于管理全集群所有作业 Streamline 数据的底层传输方式和物理分布。调度到不同机器上成千上万的 Worker 需要通过精准的数据传递，才能协作完成整体的任务。在服务 MaxCompute 这样的数据大户时，能否高效、稳定地完成每天 10 万台机器上千万量级 worker 间传输几百 PB 数据量的数据 shuffle 工作，很大意义上决定了集群整体的性能和资源利用效率。 Shuffle Service 放弃了以磁盘文件为基础的主流 shuffle 文件存储方式，突破了机械硬盘上文件随机读的性能和稳定性短板；基于 shuffle 数据动态调度的思想，令 shuffle 流程成为了作业运行时实时优化的数据流向、排布和读取的动态决策。对准实时作业，通过解构 DAG 上下游调度相比 network shuffle 性能相当，资源消耗降低 50%+。

StreamlineX + Shuffle Service 关键技术

StreamlineX (SLX) 架构与优化设计

• SLX 逻辑功能架构如图所示，主要包含了 SQL runtime 层面的数据处理逻辑重构优化，包括优化数据处理模式，算法性能提升，内存分配管理优化，挖掘硬件性能等各方面来提升计算性能，而且底座结合了全新设计的负责数据传输的 Fuxi ShuffleService 服务来优化 IO 读写以及 Worker 容错性等方面，让 SLX 在各种数据模式以及数据规模下都能够有很好的性能提升和高效稳定的运行。

SQL Runtime SLX 主要包含 Writer 和 Reader 两部分，下面简要介绍其中部分优化设计：

1、框架结构合理划分: Runtime Streamline 和 fuxi sdk 解耦，Runtime 负责数据处理逻辑，Fuxi SDK 负责底层数据流传输。代码可维护性，功能可扩张性，性能调优空间都显著增强。

2、支持 GraySort 模式: Streamline Writer 端只分组不排序，逻辑简单，省去数据内存拷贝开销以及相关耗时操作，Reader 端对全量数据排序。整体数据处理流程 Pipeline 更加高效，性能显著提升。

3、支持 Adaptive 模式: StreamlineReader 支持不排序和排序模式切换，来支持一些 AdaptiveOperator 的需求，并且不会产生额外的 IO 开销，回退代价小，Adaptive 场景优化效果显著。

4、CPU 计算效率优化: 对耗时计算模块重新设计 CPU 缓存优化的数据结构和算法，通过减少 cache miss，减少函数调用开销，减少 cpu cache thrashing，提升 cache 的有效利用率等手段，来提升运算效率。

5、IO 优化：支持多种压缩算法和 Adaptive 压缩方式，并重新设计 Shuffle 传输数据的存储格式，有效减少传输的 IO 量。

6、内存优化: 对于 Streamline Writer 和 Reader 内存分配更加合理，会根据实际数据量来按需分配内存，尽可能减少可能产生的 Dump 操作。

根据以往双十一的经验，11 月 12 日凌晨基线任务数据量大幅增加，shuffle 过程会受到巨大的挑战，这通常也是造成当天基线延迟的主要原因，下面列出了传统磁盘 shuffle 的主要问题：

• 碎片读：一个典型的 2k*1k shuffle pipe 在上游每个 mapper 处理 256MB 数据时，一个 mapper 写给一个 reducer 的数据量平均为 256KB，而从 HDD 磁盘上一次读小于 256KB 这个级别的数据量是很不经济的，高 iops 低 throughput 严重影响作业性能。

• 稳定性：由于 HDD 上严重的碎片读现象，造成 reduce input 阶段较高的出错比率，触发上游重跑生成 shuffle 数据更是让作业的执行时间成倍拉长。

Shuffle Service 彻底解决了以上问题。经过此次双 11 的考验，结果显示线上集群的压力瓶颈已经从之前的磁盘，转移到 CPU 资源上。双十一当天基线作业执行顺畅，集群整体运行持续保持稳定。

Shuffle Service 主要功能有：

• agent merge：彻底解决传统磁盘 shuffle 模式中的碎片读问题；

• 灵活的异常处理机制：相较于传统磁盘 shuffle 模式，在应对坏境异常时更加稳定高效；

• 数据动态调度：运行时为任务选择最合适的 shuffle 数据来源

• 内存 &PreLaunch 对准实时的支持：性能与 network shuffle 相当的情况下，资源消耗更少

StreamlineX + Shuffle Service 双十一线上成果

为了应对上面挑战，突破现有资源瓶颈，一年多前 MaxCompute SQL 就启动性能持续极限优化项目，其中最关键之一就是 StreamlineX (SLX)项目，它完全重构了现有的 Streamline 框架，从合理设计高扩展性架构，数据处理模式智能化匹配，内存动态分配和性能优化，Adaptive 算法匹配，CPU Cache 访问友好结构设计，基于 Fuxi Shuffle Service 服务优化数据读写 IO 和传输等各方面进行重构优化升级后的高性能框架。至双十一前，日均 95%以上弹内 SQL 作业全部采用 SLX，90%以上的 Shuffle 流量来自 SLX，0 故障，0 回退的完成了用户透明无感知的热升级，在保证平稳上线的基础上，SLX 在性能和稳定性上超预期提升效果在双十一当天得到充分体现，基于线上全量高优先级基线作业进行统计分析：

• 在性能方面，全量准实时 SQL 作业 e2e 运行速度提升 15%+，全量离线作业的 Streamline 模块 Throughput(GB/h)提升 100%

• 在 IO 读写稳定性方面，基于 FuxiShuffleService 服务，整体集群规模平均有效 IO 读写 Size 提升 100%+，磁盘压力下降 20%+；

• 在作业长尾和容错上，作业 Worker 发生 PVC 的概率下降到仅之前的几十分之一；

• 在资源优先级抢占方面，ShuffleService 保障高优先级作业 shuffle 数据传输比低优先级作业降低 25%+；

正是这些超预期优化效果，MaxCompaute 双十一当天近千万作业，涉及到近 10 万台服务器节省了近 20%左右的算力，而且针对各种极端场景也能智能化匹配最优处理模式，做到完全掌控未来数据量不断增长的超大规模作业的稳定产出。上面性能数据统计是基于全量高优先级作业的一个平均结果，实际上 SLX 在很多大规模数据场景下效果更加显著，比如在线下 tpch 和 tpcds 10TB 测试集资源非常紧张的场景下，SQL e2e 运行速度提升近一倍，Shuffle 模块提升达 2 倍。

StreamlineX+Shuffle Service 展望

高性能 SLX 框架经过今年双十一大考觉不是一个结束，而是一个开始，后续我们还会不断的完善功能，打磨性能。比如持续引入高效的排序，编码，压缩等算法来 Adaptive 匹配各种数据 Parttern，根据不同数据规模结合 ShuffleService 智能选择高效数据读写和传输模式，RangePartition 优化，内存精准控制，热点模块深度挖掘硬件性能等各方向持续发力，不断节省公司成本，技术上保持大幅领先业界产品。

DAG 2.0

挑战

双十一大促场景下，除了数据洪峰和超过日常作业的规模，数据的分布与特点也与平常大不相同。这种特殊的场景对分布式作业的调度执行框架提出了多重挑战，包括：

• 处理双十一规模的数据，单个作业规模超过数十万计算节点，并有超过百亿的物理边连接。在这种规模的作业上要保证调度的敏捷性，需要实现全调度链路 overhead 的降低以及无阻塞的调度。

• 在基线时段集群异常繁忙，各个机器的网络/磁盘/CPU/内存等等各个方面均会收到比往常更大的压力，从而造成的大量的计算节点异常。而分布式调度计算框架在这个时候，不仅需要能够及时监测到逻辑计算节点的异常进行最有效的重试，还需要能够智能化的及时判断/隔离/预测可能出现问题的物理机器，确保作业在大的集群压力下依然能够正确完成。

• 面对与平常特点不同的数据，许多平时的执行计划在双十一场景上可能都不再适用。这个时候调度执行框架需要有足够的智能性，来选择合理的物理执行计划；以及足够的动态性，来根据实时数据特点对作业的方方面面做出及时的必要调整。这样才能避免大量的人工干预和临时人肉运维。

今年双十一，适逢计算平台的核心调度执行框架全新架构升级- DAG 2.0 正在全面推进上线，DAG 2.0 很好的解决了上述几个挑战。

DAG 2.0 概述

现代分布式系统作业执行流程，通常通过一个有向无环图(DAG)来描述。DAG 调度引擎，是分布式系统中唯一需要和几乎所有上下游(资源管理，机器管理，计算引擎, shuffle 组件等等)交互的组件，在分布式系统中起了重要的协调管理，承上启下作用。作为计算平台各种上层计算引擎(MaxCompute, PAI 等)的底座，伏羲的 DAG 组件在过去十年支撑了上层业务每天数百万的分布式作业运行，以及数百 PB 的数据处理。而在计算引擎本身能力不断增强，作业种类多样化的背景下，对 DAG 架构的动态性，灵活性，稳定性等多个方面都提出了更高的需求。在这个背景下，伏羲团队启动了 DAG 2.0 架构升级。引入了一个，在代码和功能层面，均是全新的 DAG 引擎，来更好的支持计算平台下个十年的发展。

这一全新的架构，赋予了 DAG 更敏捷的调度执行能力，并在分布式作业执行的动态性，灵活性等方面带来了质的提升，在与上层计算引擎紧密结合后，能提供更准确的动态执行计划调整能力，从而为支持各种大规模作业提供了更好的保障。例如在最简单的 MR 作业测试中，DAG 2.0 调度系统本身的敏捷度和整个处理流程中的全面去阻塞能力, 能为大规模的 MR 作业(10 万并发)带来将近 50%的性能提升。而在更接近线上 SQL workload 特点的中型（1TB TPCDS）作业中，调度能力的提升能带来 20%+的 e2e 时间缩短。

DAG 2.0 的架构设计中结合了过去 10 年支持集团内外各种计算任务的经验，系统的对实时机器管理框架，backup instance 策略以及容错机制等方面进行了考虑和设计，为支持线上多种多样的实际集群环境打下了重要基础。而另一挑战是，2.0 架构要在日常数百万分布式作业的体量上做到完全的上线，在飞行中换引擎。从 FY20 财年初开始，DAG2.0 推进线上升级，至今已经实现了在 MaxCompute 离线作业，PAI 平台 Tensorflow CPU/GPU 作业等每天数百万作业的完全覆盖。并经过项目组所有成员的共同努力，在双十一当天交出了一份满意的答卷。

DAG 2.0 关键技术

能取得上述线上结果，和 DAG2.0 众多的技术创新密不可分，受篇幅限制，这里主要选取和双 11 运行稳定性相关的两个方面做重点介绍。

• 完善的错误处理能力

在分布式环境中由于机器数量巨大，单机发生故障的概率非常高，因此容错能力是调度系统的一个重要能力。为了更好的管理机器状态，提前发现故障机器并进行主动归并，DAG2 通过完整的机器状态管理，完善了机器错误的处理能力：

如上图所示，DAG2 将机器分为多个状态。并根据一系列不同的指标来触发在不同状态之间的转换。对于不同状态的机器，根据其健康程度，进行主动规避，计算任务迁移，以及计算任务主动重跑等操作。将机器问题造成的作业运行时间拉长，甚至作业失败的可能性降到最低。

另一方面，在一个 DAG 上，当下游读取数据失败时，需要触发上游的重跑，而在发生严重机器问题时，多个任务的链式重跑，会造成作业的长时间延迟，对于基线作业的及时产出造成严重影响。DAG2.0 上实现了一套基于血缘回溯的主动容错策略（如下图），这样的智能血缘回溯，能够避免了层层试探，层层重跑，在集群压力较大时，能够有效的节约运行时间，避免资源浪费。

• 灵活的动态逻辑图执行策略–Conditional join

分布式 SQL 中，map join 是一个比较常见的优化，其实现原理对小表避免 shuffle，而是直接将其全量数据 broadcast 到每个处理大表的分布式计算节点上，通过在内存中直接建立 hash 表，完成 join 操作。map join 优化能大量减少额外 shuffle 和排序开销并避免 shuffle 过程中可能出现的数据倾斜，提升作业运行性能。但是其局限性也同样显著：如果小表无法 fit 进单机内存，那么在试图建立内存中的 hash 表时就会因为 OOM 而导致整个分布式作业的失败。所以虽然 map join 在正确使用时，可以带来较大的性能提升，但实际上优化器在产生 map join 的 plan 时需要偏保守，导致错失了很多优化机会。而即便是如此，依然没有办法完全避免 map join OOM 的问题。

基于 DAG 2.0 的动态逻辑图执行能力，MaxCompute 支持了开发的 conditional join 功能：在对于 join 使用的算法无法被事先确定时，允许优化器提供一个 conditional DAG，这样的 DAG 同时包括使用两种不同 join 的方式对应的不同执行计划支路。在实际执行时，AM 根据上游产出数据量，动态选择一条支路执行(plan A or plan B)。这样子的动态逻辑图执行流程，能够保证每次作业运行时都能根据实际作业数据特性，选择最优的执行计划，详见下图：

出于对上线节奏把控的考虑，双十一期间 conditional join 尚未覆盖高优先级作业。双十一期间，我们也看到了重要基线上由于数据膨胀导致 Mapjoin hint 失效，作业 OOM 需要临时调参；以及因为 Mapjoin 未能被正确选中，而导致作业未能选中优化执行计划而延迟完成的情况。在 conditional join 在重要基线上线后，能够有效的避免这一情况，让基线的产出更加流畅。

DAG 2.0 双十一线上成果

双十一作为阿里集团所有技术线的大考，对于 DAG2.0 这一全新的组件，同样是一个重要的考验，也是 DAG2 线上升级的一个重要的里程碑：

• 双 11 当天，DAG2.0 覆盖支持线上 80%+project。截至目前已完成全面上线，日均支持几百万的离线作业执行。对于 signature 相同的基线作业，DAG 2.0 下 instance 运行的 overhead 开销有 1 到 2 倍的降低。

• 双 11 当天，使用 DAG 2.0 的高优先级基线在双十一数据洪峰下，没有任何人工干预的前提下，未发生任何作业失败重跑。其中，DAG2.0 提供的实时机器管理，backup instance 策略等智能容错机制发挥了重要作用。

• 支持开发环境中近百万量级作业，在作业平均规模更大的前提下，双 11 期间毫秒级(执行时间小于 1s 的作业)分布作业占比相比 1.0 提升 20%+。新框架上更高效的资源流转率也带来了资源利用率的明显提升：等待在线资源超时而回退的在线作业比例降低了将近 50%。

• DAG 2.0 还支持了 PAI 引擎，为双十一期间的搜索、推荐等业务的模型提前训练提供了有力的支持。双十一前 PAI 平台的所有 TensorFlow CPU/GPU 作业，就已经全量迁移到 DAG 2.0 上，其更有效的容错和资源使用的提升，保证了各条业务线上模型的及时产出。

除了基础提升调度能力提升带来的性能红利外，DAG2 在动态图亮点功能上也完成了新的突破。包括增强 Dynamic Parrellism， LIMIT 优化， Conditional Join 等动态图功能完成上线或者正在上线推动中。其中 Conditional Join 一方面保证了优化的执行计划能尽可能的被选用，同时也保证了不会因为错误选择而带来 OOM 导致作业失败，通过运行时数据统计来动态决定是否使用 Mapjoin，保证更加准确决策。双十一前在集团内部做了灰度上线，线上日均生效的 conditionl 节点 10 万+，其中应用 Map join 的节点占比超过了 90%，0 OOM 发生。推广的过程中我们也收到了各个 BU 多个用户的真实反馈，使用 conditional join 后，因为能选择最优的执行计划，多个场景上作业的运行时间，都从几个小时降低到了 30 分钟以下。

DAG 2.0 展望

在双十一值班的过程中，我们依然看到了大促场景下因为不同的数据分布特点，数据的倾斜/膨胀对于分布式作业整体的完成时间影响非常大。而这些问题在 DAG 2.0 完备的动态图调度和运行能力上，都能得到较好的解决，相关功能正在排期上线中。

一个典型的例子是 dynamic partition insert 的场景，在某个高优先级作业的场景上，一张重要的业务表直接采用动态分区的方式导入数据导致表文件数过多，后续基线频繁访问该表读取数据导致 pangu master 持续被打爆，集群处于不可用状态。采用 DAG2.0 的 Adaptive Shuffle 功能之后，线下验证作业运行时间由 30+小时降低到小于 30 分钟，而产生的文件数相比于关闭 reshuffle 的方式降低了一个数量级，在保障业务数据及时产出的前提下，能极大缓解 pangu master 的压力。动态分区场景在弹内生产和公共云生产都有广阔的应用场景，随着 Adaptive Shuffle 的上线，dynamic insert 将是第一个解决的比较彻底的数据倾斜场景。此外，DAG2.0 也持续探索其他数据倾斜(data skew)的处理，例如 join skew 等，相信随着在 2.0 上更多优化功能的开发，我们的执行引擎能做到更动态，更智能化，包括数据倾斜问题在内的一众线上痛点问题，将可以得到更好的解决。今天最好的表现，是明天最低的要求。我们相信明年的双十一，在面对更大的数据处理量时，计算平台的双十一保障能够更加的自动化，通过分布式作业运行中的动态化调整，在更少人工干预的前提下完成。

资源调度的交互式抢占

挑战

FuxiMaster 是 fuxi 的资源调度器，负责将计算资源分配给不同的计算任务。针对 MaxComput 超大规模计算场景下，不同应用间多样的资源需求，过去几年资源调度团队对的核心调度逻辑做了极致的性能优化，调度延时控制在了 10 微秒级别，集群资源的高效流转为 MaxComputer 历年双十一大促的稳定运行提供了强有力的保障。

而其中高先级基线作业的按时完成是双十一大促成功的重要标志，也是资源保障中的重中之重。除了空闲资源的优先分配，还需要对低优先级作业占用的资源进行腾挪，在不影响集群整体利用率的前提下，快速地将资源分配给高优先级基线作业。

交互式抢占概述

在高负载的集群，若高优先级作业无法及时拿到资源，传统的做法是通过抢占，直接杀掉低优先级作业，然后将资源分配给高优先级作业，这种“暴力”抢占有资源快速腾挪的特点，但抢占“杀人”也会导致用户作业中途被杀，计算资源浪费的缺点。交互式抢占是指在明确资源从低优先级流向高优先级的前提下，不立即杀掉低优先级作业，而是通过协议，让低优先级作业尽快在可接受的时间内（目前是 90s）快速跑完，既不浪费集群的计算资源，同时也保障了高优先级作业的资源供给。

目前弹内线上针对高优先级 SU（schedule unit，是资源管理的基本单位）开启组内交互式抢占，在大多情况下可以保障基线作业的资源供给。然而，目前即使通过交互式抢占也还会存在一些作业无法及时获得资源的情况。例如，高优先级交互式抢占每隔 30s 的触发处理高优先的 SU 数量受全局配置约束，而该段时间还存在大量其他早已经提交进来的高优先级 SU，会导致该作业的 SU 被轮空。另外，交互式抢占指令发出后，需要对应 instance 结束后定向还这份资源，而对应的 instance 的运行时间都非常长，导致交互式无法及时拿回对应的资源。 基于上述问题，我们进一步优化了交互式抢占策略。

交互式抢占关键技术

针对前文提到的几个问题，交互式抢占做了如下优化：

• 通过性能优化，放宽了高优先级每轮处理的 SU 限制个数

• 交互式抢占超时后强制回收预留的低优先级资源，对于优先启动的、占据大量资源、instance 运行时间较长的低优先级作业，需要强制回收资源。

• 采用预留外的资源供给高优先级资源，可以通过预留外的其他资源为交互式抢占的 SU 继续分配资源，同时抵消对应的交互式抢占部分。

双十一线上成果

2019 双十一期间，面对远超以往的数据量，所有的高优先级作业顺利按期产出，资源调度方面顺利保障了基线资源供给，其丝般顺滑程度让整个基线保障的过程几乎感受不到资源调度的存在。其中基线作业交互式抢占以及加速功能提供了有效的资源保障能力，及时、有效的抢占到所需资源。下文给出了某个云上集群的资源供给情况。

• 交互式抢占加速为基线作业快速提供可用资源

从下面几张图中可以看到，在基线时间段(00:00 ~ 09:00), 基线作业超时拿不到资源发起交互式抢占 revoke 的频率明显高于其他时段， 这意味着通过交互式抢占加速的手段基线作业可以顺利拿到所需资源。双十一期间的线上运行情况，也证明了 在资源压力大的情况下，高优先级基线作业明显通过了交互式抢占 revoke 获得了资源。

• 基线作业的 SU 拿资源时间比例分布

下边为主要几个集群 SU 拿资源的时间分布 (fuxi 基本调度单元)， 可以发现这几个集群 90%分位拿资源的时间基本都在 1 分钟左右（符合线上基线作业等待资源达到 90s 进行抢占配置预期）。