十大主流集群调度系统大盘点

众所周知，集群调度系统是现代数据中心举足轻重的组件，一个好的调度器，能提高集群资源利用率，实现自动化部署和高可用，节约用户投资，“让开发者最大可能地把精力集中到上层业务逻辑上”。考虑到时下各路调度系统眼花缭乱，小编打算从Google的三代集群调度架构演进切入，对十个主流集群调度系统进行分门别类大盘点。

开始盘点前，让我们先快速回顾一下Google的三代集群调度架构——中央式（Monolithic）、双层式（Two-level）、共享状态式（Shared-state）都有哪些特征？

快速回顾：Google三代集群资源调度架构

早在十多年前，Google就开始使用第一代集群管理Borg技术管理数据中心。2013年，Google发表的Omega论文（Omega，a scalable scheduler for large compute clusters）详细介绍了Google的三代集群资源调度架构：中央式（Monolithic）、双层式（Two-level）、共享状态式（Shared-state）。（见下图）

http://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/41684.pdf

（1） 中央式调度器（Monolithic scheduler）

中央式调度器实质上就是一个单一的调度agent来负责所有请求，通常用在HPC（高性能计算）中。由于将资源的调度和作业的管理功能全部放到一个进程中完成，扩展性较差：首先，集群规模受限。其次，很难引入新的调度策略，比如之前仅支持MapReduce作业，现在要支持流式作业，而将流式作业的调度策略嵌入到中央式调度器中是一项很难的工作。

（2） 双层调度器（Two-level scheduler）

双层调度器采用“分层”思想，上层是一个非常轻量级的的中央式调度器，下层是具体某个应用程序的调度器，如Hadoop、Storm、Spark、MPI等。这样就可以减小“中心节点”的压力，由原来的一个“中心”，变成二层“中心”；而且同一个集群中多种应用接入，多种框架混部，有效提高分布式集群的利用率。但是，这种“二级调度”也有缺陷：各应用无法感知集群整体的使用状况，只能等待上层调度推送信息；再加上资源分配采用轮询，在分配过程使用“悲观锁”（即PCC，Pessimistic Concurrency Control，悲观并发访问控制方式），并发粒度小，响应稍慢，缺乏一种有效的竞争机制。

（3）共享状态调度器（Shared-state scheduler）

为克服双层调度器的不足，Google提出了共享状态调度。这种调度器将双层调度器中的集中式资源调度模块简化为持久化的“共享数据”（状态）和针对这些数据的验证代码——这里的“共享数据”实际上就是整个集群的实时资源使用信息。共享状态调度器最典型的代表就是Google的Omega系统，它也可理解为改进版的“双层调度器”。通过将双层调度器中的“共享数据”进行全局持久化，任何应用都可以看到集群资源信息。而且资源申请采用“乐观锁”（即MVCC，Multi-V