集群资源管理与任务调度系统综述

0. 集群资源管理与任务调度系统出现的背景

（1）出现背景
信息技术快速发展，各行各业都慢慢于互联网进行深度融合，即所谓的“互联网+”。为了提供更好的服务以吸引更多的消费者进行更多维度的消费，各个互联网公司针对不同的场景进行深度拓展，而这些业务的进行全部需要对海量数据进行大规模处理。传统的单机模式已经很难满足公司和企业的发展需求，因此各个公司开始搭建自己的数据中心，但是独立搭建的数据中心往往存在一定的缺陷，例如：集群的资源利用率低导致资源闲置（业务往往是不均衡的，但是公司为了保证用户体验，不得不配置能够应对洪峰的物理资源），集群的维护和管理成本也越来越高。因此出现了云服务商，公司可以将自己的服务部署在云上，以实现按需付费和弹性调度，这样能够显著降低公司的运营成本，这就是云计算出现的本质原因。对于云计算来说涉及到多个方面的内容，例如：云存储系统、云资源管理和任务调度系统、网络等，下面仅关注集群资源管理和任务调度系统。

（2）目前的挑战

数据中心的负载种类越来越多，有批处理任务、实时查询任务、流式服务等；
异构负载的资源需求越来越多样化，资源约束和偏好越来越复杂，例如：一个任务运行需要考虑CPU、内存、网络、磁盘甚至内存带宽、网络带宽等，还需要考虑数据本地行，对物理机的偏好等；
不同类型任务在实际调度过程中不可避免会调度至相同的数据节点上，这就需要对不同种类的任务进行隔离以减少两者之间的干扰；
调度过程中的动态资源调整；
任务抢占模式下的重调度机制；
故障恢复；
集群中不可知原因的长尾问题；
集群资源利用率低，全球云服务器的平均物理资源利用率低于20%，并且通常在逻辑资源几乎全部分配的前提下实际的物理资源利用量不及资源申请总量的一半；

（3）抽象模型
其实集群资源管理和任务调度系统就是一个复杂的多维混合背包问题，背包问题应该是动态规划问题中最经典的问题。我们可以将集群中的每个数据节点比作一个背包，不同背包不同维度的容量是不同的，将任务比作是需要放置的物品，任务所需要的资源就是其花费，而任务运行产生的租赁费用即为效益。我们需要做的就是在满足任务需求的前提下将其放置在适合的背包中，保证集群利用率最高。但是实际的调度过程和该算法还有很多不同的地方，例如：

背包问题只是一个推演的过程，我们可以使用一些数据结构来保存一些中间结果来推导出最优的分配方式。但是实际的调度中来了一个任务我们要马上根据现有的资源情况进行分配，而不能暂时存留一个分配方案，等多有任务都提交完成之后再根据最优的方案进行任务放置；
不同的任务在实际运行过程中有一定的优先级，需要保证高优先级的任务最先被保证，这就增加了调度的难度；
任务在运行过程中的资源需求不是一成不变的，有时候会随着时间的变化增加资源需求，这就是弹性调度需要解决的问题。
任务之间还会产生干扰，并且不同资源敏感度的任务在不同资源维度上的干扰是不同的；
资源管理和调度系统相当于系统的大脑，其要处理所有数据节点和任务的各种请求，所以其核心的调度逻辑一定不能太过复杂，如果考虑所有的情况后再进行调度，势必会延长调度时间，这是任务执行所不能容忍的；
因此对于一个资源管理和任务调度系统来说，其的职能就表明其不可能是一个完美的系统，也不可能是一个通用的系统，需要针对不同的业务场景进行改造，因此就在工业界和学术界激起了广泛的研究和探索。

（4）系统演进

整体上来说分为：单层调度系统，两层调度系统，共享状态调度系统，分布式调度系统，混合式调度系统。
Google提出MR模型
批处理框架Hadoop的出现
内存计算框架Spark的出现
资源管理框架Mesos、YARN、borg的出现
基于状态共享的Omega
完全的分布式调度器Sparrow
中心式和分布式相结合的混合架构Mercury
支持快速故障恢复的Fuxi
支持在离线混合调度的阿里混布系统
基于容器的集群管理框架kubernetes的出现

（5）一些分配策略演进

FIFO方式，先来先分配后来后分配；该方式虽然不能保证调度最优但是因为简单在目前的资源调度系统中也广泛使用；
公平调度，将资源分配为多个不同的资源池，每个资源池中分配一定比例的资源，任务在资源池中按照最大最小策略（例如有三个任务分别需要的资源是2 ，4， 4 个单位，而现在总共有9个单位资源，首先每个任务平均得到3个单位资源，因为第一个任务多了一个单位资源，其将多出的一个单位资源再平均分配给任务二和三，所以最终任务一得到2个单位资源，任务二得到3.5个单位资源，任务三得到3.5个单位资源）或者加权的最大最小策略（不同任务具有不同的优先级，所以在平均分配的时候还需要考虑权重）进行资源分配。
DRF主资源优先调度。对于一个任务来说其主资源是其各维度资源申请中占比最大的资源，例如一个任务需要<2CPU,4G>，现在有<4CPU, 10G>,比例为1/2,4/10，那么CPU就是该任务的主资源。在分配时候选择主资源占比最小的任务进行优先分配，目前该方式被广泛的应用在各种调度系统中。有兴趣的可以搜索相关论文查看其详细的论证过程。
最短作业优先调度。有研究表明采用最短作业优先调度的方式可以提高系统资源利用率，其实也比较容易理解，短作业需要的资源少所以在分配的时候可以尽快被满足，另外短作业的执行时间少，所以可以尽快的释放资源，这对于提高集群吞吐量和利用率都有好处。但是这种方式也存在缺点就是长作业会出现长时间得不到资源而饿死的情况；另外任务的执行时间预先是不可预知的；
能力调度器，被默认应用在YARN中。其原理是为不同的用户组构建不同层级的任务队列。在进行分配时，优先选择min{use/分配}的队列进行分配，在队列内部按照FIFO的策略进行选择。所以选择的过程可以总结为下面步骤：（1）根据最小满足比选择一个任务队列；（2）在任务队列中选择一个具体的任务；（3）从该任务中选择一个资源申请请求，因为一个任务可能会对应多个资源申请请求；得到这个请求之后与目前的剩余资源情况进行匹配，然后进行调度；
Tetris算法。考虑到任务的资源申请需求越来越多样，需要考虑不同维度资源的权重问题，其核心思想是将资源申请表示为多维向量，进行归一化处理并与集群剩余资源进行点积运算，优先响应权重最大的资源请求。该方法从算法论证的角度来看能够在一定程度提高调度的准确度和效率，但是其在资源分配过程中需要进行较为复杂的运算，采用的并不多。并且目前主流的资源调度系统中在资源申请方面仅考虑了CPU和内存两个维度的资源。
延迟调度策略。如果当前分配的资源不能够满足诸如数据本地行等需求，可以暂时放弃该轮分配，等待下一轮分配，通过设定一个放弃次数阈值来进行。

1. 研究点与研究团队

目前关于集群资源管理和任务调度的研究点很多，例如：资源分配策略的优化、支持调度器的热插拔、支持资源超售、支持任务的混合部署、支持对多维度资源的高效隔离、避免任务之间的干扰、长尾问题的处理、任务资源需求和运行时画像、多任务优先级抢占、针对特定场景的调度系统设计、大数据系统基准测试等。
主要研究团队：

UC Berkeley的AMP实验室。开创性的提出多框架资源共享调度框架Mesos，对后续工业界和学术界有很大的启发和推动作用；完全分布式的高吞吐分布式调度系统Sparrow；内存计算框架Spark；DRF调度策略；其多项成果被Apache收录；
Stanford大学。通过对任务的建模分类来进行高效的调度和提高资源利用率，保证服务质量，减少任务间的性能干扰，研究基于私有云和公有云的高效集群。代表系统有Quasar，Tarcil，Hcloud，Paragon。
Google。其实大规模分布式调度系统的先导者，分布式系统的三驾马车：MR,BigTable,GFS。其研究涉及高效的任务调度、资源管理和任务隔离。代表系统有：MR，Borg,Omega。
微软。其研究主要与其内部的业务紧密相关，涉及数据和查询密集型的分布式系统和针对Bing搜索任务单额资源管理和任务调度系统，代表：Apollo，JetScope，Mercury，Reserved。
澳大利亚墨尔本大学。其主要进行调度系统优化相关工作，包括云负载的弹性调度、基于经济学的资源调度模型、绿色节能计算机制等。代表：GridSim，CloudSim。
华中科技大学的金海教授团队。主要进行资源的虚拟化研究，利用虚拟化技术来提高负载均衡、平台的可用性等。
中科院计算所詹剑锋团队。主要进行大数据系统基准测试相关研究，包括数据集的生成、负载的特征分析和分类、负载集的构建、测试指标的选择等方面，代表：BigDataBench，BDGS。

虽然目前针对资源管理和任务调度的研究已经有很多，但是任然面临着一些挑战，这些挑战主要包括：负载异质性程度越来越高；资源请求的高并发越来越高；物理资源的利用率得不到显著的提升。

2. 集群资源管理与任务调度系统架构

集群资源管理和任务调度设计两个方面：（1）集群管理，主要负载集群中资源的管理和调度，给定一个任务需求，其能够在目前情况下给出较优的调度方案；（2）任务调度，来了很多的任务我们应该选择哪个任务来进行分配；这两个方面是相辅相成的关系，任何一个方面的优化都会带来集群整体性能的提升。因为任务调度主要涉及调度策略部分，在上面一节中有一些论述，并且任务调度本身带有一些随机性，所以对其的研究相对较少，下面主要针对资源管理系统进行简要总结。

总的来说目前的调度系统可以分为：单层调度系统、两层调度系统、共享状态调度系统、分布式调度系统和混合式调度系统。每种调度系统的存在都有其背景，下面主要从产生的背景、实现的原理、存在的缺点、典型的系统等方面进行阐述。需要注意的是，虽然有这么多种调度系统，但是目前工业界使用的大部分还是单层或者两层的调度系统，原因是这些架构设计方案成熟，已经经历了多年的线上实践，可以平稳运行；另外就是这些调度系统拥有比较好的生态和社区，能够兼容现有的生态，节省研究的成本。所以一些小型公司大多还是采用Hadoop相关的系统，只有专门针对云计算市场的公司，例如阿里云、腾讯云、华为云等会专门研发自己的调度系统。

2.1 单层调度系统

产生背景：该调度系统是大规模数据分析和云计算出现的雏形，其产生主要就是进行大规模的集群管理以提高数据处理能力。
基本原理：单层调度系统融合了资源管理和任务调度，有一个中心式的JobTracker负责进行集群资源的合理分配、任务的统一调度、集群计算节点信息的统计维护、任务执行过程中的状态管理等。
优点：（1）JobTracker能够感知集群中所有资源和任务的执行状态，能够进行全局最优的资源分配和调度，避免任务间的干扰，适当进行任务抢占，保证任务计算效率和服务质量；（2）架构模型简单，只有一个全局的管理者负责进行所有管理。
缺点：（1）JobTracker作为集群的中心，存在单点瓶颈问题，不能支持大规模集群；（2）内部实现异常复杂，因为一个调度器中需要实现所有的功能模块；（3）负载种类的增加会导致系统需要进行不断的迭代，这将增加系统的复杂性，不利于后期的维护和扩展；（4）只支持单类型的任务，MR类型的批处理任务；
典型的调度系统：Hadoop1.*版本；K8S中的kube-scheduler，Paragon,Quasar。

2.2 双层调度器

产生背景：为了解决单层调度系统的扩展性问题，系统实现负责，需要不断迭代，不能支持不同类型任务等缺点
实现原理：将资源管理和任务调度解耦。集群资源管理器负责维护集群中的资源信息并将资源分配给具体的任务，任务管理器负责申请资源并将申请到的资源根据用户逻辑进行细分和具体的任务调度，节点管理器负责维护节点上的所有信息，包括：任务的运行状况，节点资源剩余情况等。通过三者之间的协调来进行资源资源管理和任务调度。
优点：（1）资源管理器只负责资源分配，任务调度由应用完成，提高了系统的扩展性和模块化设计；（2）任务调度逻辑由具体的任务完成，能够提供对不同类型任务的支持；（3）内部实现模块化，利于维护和扩展；
缺点：（1）任务无法感知全局的资源情况，只能基于request/offer来进行资源获取，无法有效避免异构负载之间的性能干扰问题；（2）任务调度和资源管理解耦不利于实现多任务间的优先级抢占；（3）所有任务的资源请求都需要资源管理器进行处理，此外其还需要与节点管理器之间维持通信，导致资源管理器存在单点问题；
典型系统：
- Mesos：最先将资源管理和任务调度解耦的offer-based（基于资源供应）方案，其有一个中心的资源管理器，通过采用一些分配策略将资源分配给不同的计算框架，每个计算框架依据自身的逻辑、资源偏好等采取增量或者All-or-Nothing的方式决定接受还是拒绝分配的资源，计算框架根据分配到的资源进行下一步的资源分配和任务执行。优点：实现逻辑简单，两层调度；缺点：（1）调度结果不是全局最优的；（2）存在单点瓶颈，因为中央资源管理器需要逐个询问计算框架是否需要资源；（3）无法支持抢占，资源一旦分配不能够抢占回收；（4）DRF策略过于理想化；（5）并发度不高，因为对于某个slave的资源剩余信息，需要逐个询问计算框架是否需要资源,，基于串行轮询方式；
- YARN：基本思想与Mesos相同，但其采用requese-based方式进行资源申请，但是在YARN中有三个模块，RM负责资源管理，AM负责任务资源申请和运行；优点：（1）支持不同的调度策略可以保证任务优先级、多租户容量管理、资源公平共享、弹性伸缩（当某个租户需要资源时会抢占共享出去的资源）等；（2）应用扩展方便，只要根据提供的AM 相关API就可以实现用户的任务执行逻辑；缺点：存在单点瓶颈问题；故障处理和容错方面不够完善；对于隔离的支持不够友好；
- borg：最早融合资源隔离、资源超售、机器打分、多任务优先级于一体的资源管理系统。采用二层调度框架，节点管理器Borglet定期将自己节点的资源和任务执行情况汇报给BorgMaster，每个应用内的调度器根据自身保存的集群信息做调度决策，然后由Master决定是否允许其资源申请。在此基础上其做了一些优化，例如：用户控制访问、节点打分、多任务派遣、多维度资源隔离和进程隔离、可插拔的调度策略等，支持数千种不同的应用和服务，支持数万台规模的集群。但是目前其为闭源系统，这些思想仅能通过论文中获取，具体的实现细节并不清楚。
- Fuxi。其是阿里云针对离线作业的调度系统，与其相对的是针对在线服务端额调度系统Sigma。伏羲的设计思想与YARN非常相似，具体的资源分配也相似。但是伏羲针对故障恢复和可用性方面记性了优化扩展，能够基于已有的信息进行快速的故障恢复，并提供多级黑名单机制。

2.3 共享状态调度器

产生背景：前面的调度器存在一个问题就是应用在进行资源申请的时候无法获知到集群的全局资源信息，这就导致无法进行全局最优的调度，共享状态调度器就是为了解决这个问题。
基本原理：是一个半分布式的架构，通过共享集群状态为应用提供全局的资源视图，并采用乐观并发机制进行资源申请和释放，来提高系统的并发度。
优点：（1）支持全局最优调度；（2）能够一定程度的提高并发度；
缺点：（1）高并发资源请求下会造成频繁的资源竞争；（2）不利于实现任务的优先级抢占；（3）资源全局副本维护模块存在单点瓶颈；
典型系统：
- Omega:Omega系统中存在多个调度器，每个调度器中都保存集群资源的副本信息，每个调度器可以按照副本信息进行任务调度，在进行资源申请和调度时采用乐观锁的并发方式进行。目前其只是在模拟环境下进行实验，并没有真正在线上进行测试。
- Apollo：综合考虑了微软生产平台Scope的扩展性、用户群间的公平调度、提高资源利用率、缩短工作时间（数据本地行、任务特性、任务预测）的解决方案。核心包括两个方面：（1）利用实时系统维护和更新每个任务的等待时间矩阵作为调度的基础和参考，需要考虑子任务调度到哪个计算节点上更合适；（2）在计算节点设置独立的任务等待队列，采集其上的任务执行情况，依次根据相关成本模型进行较优的调度决策。其主要针对海量短作业进行设计。
- JetScope：在Apollo的基础上对交互式数据分析任务进行了特殊的优化处理，通过Gang调度策略对低延迟交互式作业进行调度优化。
- Nomad

2.4 分布式调度器

产生背景：提供系统吞吐率和并发度
基本原理：完全分布式的调度系统之间没有通讯协作，每个分布式调度器根据自己最少的先验知识进行最快的决策，每个调度器单独响应任务，总体的执行计划于资源分配服从统计意义。目前还处于学术研究阶段，尚未真正运用至生产环境中。
优点：提高吞吐量和并发度
缺点：（1）调度质量得不到保障；（2）资源非公平分配；（3）不能支持多租户管理；（4）不能避免不同任务之间的性能干扰；
典型系统：Sparrow：是一个完全的去中心化的分布式调度系统，通常用于满足低延迟高吞吐的短任务场景。系统包含多个调度器，这些调度器分布在集群的节点上，作业可以提交给任何一个分布式调度器。其核心是采用随机调度模型，利用二次幂采样原理针对每个任务随机采样出两个服务节点，选择任务等待队列最短的一个作为调度结果，也可以采用异步预定的方式进行资源调度。实验证明近似最优解能够有效的满足大规模毫秒调度性能的需求。

2.5 混合式调度器

出现背景：针对一些特定的混合任务调度场景，某些任务需要比较快的调度响应，而其他任务不需要很快的调度响应，但是需要保证调度质量。
基本原理:设计两条资源请求和任务调度路径，保留两层调度的优点，同时兼顾分布式调度器的优势。对于没有资源偏好且响应要求高的任务采用分布式调度器，对于资源调度质量要求较高的采用中央资源管理器进行资源分配。
优点：（1）能够针对不同类型的任务进行不同方式的调度；（2）为应用层提供灵活的接口和性能保障；
缺点：复杂化了计算框架层的业务逻辑；调度系统内部也需要针对两种不同的调度器进行协同处理；
典型调度系统：
- Mercury:微软的混合调度机制，中心式调度器对调度质量要求较高的作业进行公平的资源分配，分布式调度器对时间敏感和吞吐率要求高的作业进行调度。
- Tracil在Sparrow基础上增加了访问控制模型，结合QoS感知对负载进行建模和性能评估指定访问控制策略，确保任务可以快速获取到资源并执行，提升系统并发度和响应时间提高集群资源利用率。

2.6 总结

目前主流的开源调度系统比较（结构，资源维度，多调度器，支持可插拔，优先级抢占，重调度，资源超售，资源评估，避免干扰）：

Kubernetes：单层，支持多维资源，可插拔，资源超售
Swarm：单层，支持多维资源
YARN：单层/两层，CPU和内存，多调度器，可插拔
Mesos:两层，多维，多调度器，可插拔，资源超售
Nomad：共享状态，多维，可插拔
Sparrow：完全分布式，固定槽位
Borg:优先级抢占，重调度，资源超售，资源评估
Omega：支持除了避免干扰的所有特征
Apollo：多调度器，可插拔，优先级抢占，重调度
选用何种调度架构需要根据具体的应用场景结合不同调度框架的特点进行判断。目前调度系统存在的问题主要包括：功能缺失、资源利用率不佳、任务特征不可预测、性能干扰降低执行效率、调度器性能较弱。

3. 工业界相关系统

公司+市场份额+其调度系统
阿里云45.5%，Fuxi，Sigma，混布系统，Zeus（宙斯）系统
腾讯云10.3%， VStation
中国电信7.6%，天翼云
金山云6.5%
AWS5.4%
UCloud 5.3%
微软 5.0%
中国联通 5.0%
IBM 3.0%
华为云 0.9%
国云
百度云
京东云，京东阿基米德