图.阿里巴巴全球数据中心MaxCompute上每天运行着数以千万计的作业，处理EB级别的数据。这些计算和数据分布在全球的数据中心，复杂的业务依赖关系产生了大量的跨中心依赖。相比于数据中心内的网络，跨数据中心网络（尤其是跨域的网络）是非常昂贵的，同时具有带宽小、延迟高、稳定性低的特点。比如网络延迟，数据中心内部网络的网络延迟一般在100微秒以下，而跨地域的网络延迟则高达数十毫秒，相差百倍以上。因此，如何高效地将跨中心依赖转化为数据中心内部的数据依赖，减少跨数据中心网络带宽消耗，从而降低成本、提高系统效率，对MaxCompute这样超大规模计算平台而言，具有极其重要的意义。
1.2.2以project为粒度的多集群业务排布算法随着上层业务的不断发展，业务的资源需求和数据需求也在不断变化。比如一个集群的跨中心依赖增长迅速，无法完全通过数据缓存来转化为本地读取，这就会造成大量的跨数据中心流量。因此我们需要定期对业务的排布进行分析，根据业务对计算资源、数据资源的需求情况，以及集群、机房的规划，通过业务的迁移来降低跨中心依赖以及均衡各集群压力。下图展示了某个时刻业务迁移的收益分析：左图横轴为迁移的project数量，纵轴为带宽减少比例，可以看出大约移动60个project就可以减少约30%的带宽消耗。右图统计了不同排布下（迁移0个、20个、50个project）的最优带宽消耗，横轴为冗余存储，纵轴为带宽。
1.2.3跨数据中心计算调度机制我们打破了计算资源按照数据中心进行规划的限制，理论上允许作业跑在任何一个数据中心。我们将调度粒度拆解到作业粒度，根据每个作业的数据需求、资源需求，为其找到一个最合适的数据中心。在对作业进行调度之前需要知道这个作业的输入和输出，目前我们有两种方式获得这一信息，对于周期性作业，通过对作业历史运行数据进行分析推测出作业的输入输出；对于偶发的作业，我们发现其产生较大跨域流量时，动态的将其调度到数据所在的数据中心上运行。另外，调度计算还要考虑作业对计算资源的需求，防止作业全部调度到热点数据所在的数据中心，造成任务堆积。1.3线上效果线上三种策略相辅相成，数据缓存主要解决周期类型作业、热数据的依赖；作业粒度调度主要解决临时作业、历史数据的依赖；并周期性地通过业务整体排布进行全局优化，用来降低跨中心依赖。整体来看，通过三种策略的共同作用，降低了约90%的跨地域数据依赖，通过约3%的冗余存储节省了超过80%的跨数据中心带宽消耗，将跨中心依赖转化为本地读取的比例提高至90%。下图以机房为单位展示了带宽的收益：
3.资源调度2.0-去中心化的多调度器架构2019年双十一，MaxCompute平台产生的数据量已接近EB级别，作业规模达到了千万，有几十亿的worker跑在几百万核的计算单元上，在超大规模（单集群超过万台），高并发的场景下，如何快速地给不同的计算任务分配资源，实现资源的高速流转，需要一个聪明的“大脑”，而这就是集群的资源管理与调度系统（简称资源调度系统）。资源调度系统负责连接成千上万的计算节点，将数据中心海量的异构资源抽象，并提供给上层的分布式应用，像使用一台电脑一样使用集群资源，它的核心能力包括规模、性能、稳定性、调度效果、多租户间的公平性等等。一个成熟的资源调度系统需要在以下五个方面进行权衡，做到“既要又要”，非常具有挑战性。
13年的5K项目初步证明了伏羲规模化能力，此后资源调度系统不断演进，并通过MaxCompute平台支撑了阿里集团的大数据计算资源需求，在核心调度指标上保持着对开源系统的领先性，比如1）万台规模集群，调度延时控制在了10微秒级别，worker启动延时控制在30毫秒；2）支持任意多级租户的资源动态调节能力（支持十万级别的租户）；3）极致稳定，调度服务全年99.99%的可靠性，并做到服务秒级故障恢复。2.1单调度器的局限性2.1.1线上的规模与压力大数据计算的场景与需求正在快速增长（下图是过去几年MaxComputer平台计算和数据的增长趋势）。单集群早已突破万台规模，急需提供十万台规模的能力。
图.MaxCompute2015~2018线上作业情况但规模的增长将带来复杂度的极速上升，机器规模扩大一倍，资源请求并发度也会翻一番。在保持既有性能、稳定性、调度效果等核心能力不下降的前提下，可以通过对调度器持续性能优化来扩展集群规模（这也是伏羲资源调度1.0方向），但受限于单机的物理限制，这种优化总会存在天花板，因此需要从架构上优化来彻底规模和性能的可扩展性问题。2.1.2调度需求的多样性伏羲支持了各种各样的大数据计算引擎，除了离线计算（SQL、MR)，还包括实时计算、图计算，以及近几年迅速发展面向人工智能领域的机器学习引擎。
图.资源调度的架构类型我们将系统中最核心的资源管理和资源调度逻辑进行了拆分解耦，使两者同时具备了多partition的可扩展能力（如下图所示），其中：资源调度器（Scheduler）：负责核心的机器资源和作业资源需求匹配的调度逻辑，可以横向扩展。资源管理和仲裁服务（ResourceManagerService，简称RMS）：负责机器资源和状态管理，对各个Scheduler的调度结果进行仲裁，可以横向扩展。调度协调服务（Coordinator）：管理资源调度系统的配置信息，Meta信息，以及对机器资源、Scheduler、RMS的可用性和服务角色间的可见性做仲裁。不可横向扩展，但有秒级多机主备切换能力。调度信息收集监控服务（FuxiEye）：统计集群中每台机的运行状态信息，给Scheduler提供调度决策支持，可以横向扩展。用户接口服务（ApiServer）：为资源调度系统提供外部调用的总入口，会根据Coordinator提供的Meta信息将用户请求路由到资源调度系统具体的某一个服务上，可以横向扩展。
图.伏羲多调度器新架构2.3上线数据以下是10w规模集群/10万作业并发场景调度器核心指标（5个Scheduler、5个RMS，单RMS负责2w台机器，单Scheduler并发处理2w个作业）。通过数据可以看到，集群10w台机器的调度利用率超过了99%，关键调度指标，单Scheduler向RMScommit的slot的平均数目达到了1wslot/s。在保持原有单调度器各项核心指标稳定不变的基础上，去中心化的多调度器框架实现了机器规模和应用并发度的双向扩展，彻底解决了集群的可扩展性问题。
在此统一离线作业与准实时作业的到一套架构的基础上，这种统一的描述方式，使得探索离线作业高资源利用率，以及准实时作业的高性能之间的tradeoff成为可能：当调度单位可以自由调整，就可以实现一种全新的混合的计算模式，我们称之为Bubble执行模式。
这种混合Bubble模式，使得DAG的用户，也就是上层计算引擎的开发者(比如MaxCompute的优化器)，能够结合执行计划的特点，以及引擎终端用户对资源使用和性能的敏感度，来灵活选择在执行计划中切出Bubble子图。在Bubble内部充分利用网络直连和计算节点预热等方式提升性能，没有切入Bubble的节点则依然通过传统离线作业模式运行。在统一的新模型之上，计算引擎和执行框架可以在两个极端之间，根据具体需要，选择不同的平衡点。4.1.3效果DAG2.0的动态性使得很多执行优化可以运行时决定，使得实际执行的效果更优。例如，在阿里内部的作业中，动态的conditionaljoin相比静态的执行计划，整体获得了将近3X的性能提升。
混合Bubble执行模式平衡了离线作业高资源利用率以及准实时作业的高性能，这在1TBTPCH测试集上有显著的体现，
【基于文件系统shuffle的示意图/一个20000*10000的MR作业的碎片读】分布式作业中并发度的提升往往是加速作业运行的最重要手段之一。但处理同样的数据量，并发度越高意味着上述碎片读现象越严重。通常情况下选择忍受一定的碎片IO现象而在集群规模允许的情况下提升并发度，还是更有利于作业的性能。所以碎片IO现象在线上普遍存在，磁盘也处于较高的压力水位。一个线上的例子是，某些主流集群单次读请求size为50-100KB,Diskutil指标长期维持在90%的警戒线上。这些限制了对作业规模的进一步追求。我们不禁考虑，作业并发度和磁盘效率真的不能兼得吗？4.2.2Fuxi的答案：FuxiShuffle2.0引入ShuffleService-高效管理shuffle资源为了针对性地解决上述碎片读问题及其引发的一连串负面效应，我们全新打造了基于shuffleservice的shuffle模式。Shuffleservice的最基本工作方式是，在集群每台机器部署一个shuffleagent节点，用来归集写给同一reducer的shuffle数据。如下图
5.2资源隔离分级管理单机的物理资源总是有限的，按照资源特性可以大体划分为可伸缩资源与不可伸缩资源两大类。CPU、Net、IO等属于可伸缩资源，Memory属于不可伸缩资源，不同类型的资源有不同层次的资源隔离方案。另一方面，通用集群中作业类型种类繁多，不同作业类型对资源的诉求是不同的。这里包括在线、离线两个大类的资源诉求，同时也包含了各自内部不同层次的优先级二次划分需求，十分复杂。基于此，Fuxi2.0提出了一套基于资源优先级的资源划分逻辑，在资源利用率、多层次资源保障复杂需求寻找到了解决方案。
隔离策略如下图所示
基于不同类型的资源对应不同的优先级作业
为此，我们提出了FuxiSensor的资源画像方案，架构如上图所示，同时利用SLS进行数据的收集和分析。在集群、Job作业、机器、worker等不同层次和粒度实现了资源信息的画像，实现了秒级的数据采集精度。在混部及MaxCompute的实践中，成为资源问题监控、报警、稳定性数据分析、作业异常诊断、资源监控状况的统一入口，成为混部成功的关键指标。5.4线上效果日常资源利用率由10%提升到40%以上
在线抖动小于5%
5.5单机调度小结为了解决三大挑战，通过完善的各维度优先级隔离策略，将在线提升到高优先级资源维度，我们保障了在线的服务质量稳定；通过离线内部优先级区分及各种管理策略，实现了离线质量的稳定性保障；通过细粒度资源画像信息，实现了资源使用的评估与分析，最终实现了混部在阿里的大规模推广与应用，从而大量提升了集群资源利用率，为离线计算节省了大量成本。6.展望从2009到2019年历经十年的锤炼，伏羲系统仍然在不断的演化，满足不断涌现的业务新需求，引领分布式调度技术的发展。接下来，我们会从以下几个方面继续创新：