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

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

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

（2）目前的挑战

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

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

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

（4）系统演进

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

（5）一些分配策略演进

• FIFO方式，先来先分配后来后