开发者学堂课程【分布式系统开发调度技术：分布式调度系统现状】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/367/detail/4367
分布式调度系统现状
内容介绍：
一、 分布式调度的两大任务
二、分布式调度系统的比较
一、分布式调度的两大任务
分布式调度主要作用是使像使用台式机一样来使用云计算，台式机最重要的部件是处理器 CPU，对云计算而言，分布式调度就是它的处理器，它能够将成千上万台硬件的运算能力汇合起来，提供可靠的云计算服务。
分布式调度最重要的两个任务是任务调度和资源调度。
1.任务调度
在任务调度方面，不同的业务部门在共享集群时，有大量的计算任务，这些任务如何进行切分？
如何将海量的数据进行分割，在不同的节点上进行运算，同时还有监控各个节点的运算状态。
2.资源调度
资源调度则是回到供应双方的供给方，分布式调度系统需要在不同的业务部门之间平衡资源的使用，从而使得每个部门之间的资源相对比较平衡，同时又需要支持优先级抢占。
二、分布式调度系统的比较
熟悉的分布式调度系统有 Hadoop MR、YARN、Mesos以及Aliyun-Fuxi 等等。
1. Hadoop MR
下图是经典的 Hadoop MR 架构图，当集群部署完后，集群中有一个单点系统称为Job Tracker，负责资源调度和任务调度，当用户通过客户端提交作业到 Hadoop 系统之后，Job Tracker 进行资源的调度，然后将任务下发给相关的节点，每个节点上部署了一个 task tracker，进行任务的调度和执行，这个架构是经典的主从架构，但也存在着一些缺陷：
1>单点问题所引入的规模扩展,最大 4000台机器，往更大的规模扩展存在瓶颈，因为每增加一台节点的时候，task tracker 注册到 Job Tracke r需要的内存中加载一段内存，那当节点数变更多 Job Tracker 会受到所在物理机器的内存的上限限制。
2>容错性差 ，Job Tracker 是单节点进程，若该节点发生 crash，或者整个机器发生宕机，此时所有进行中之前运行的作业情况以及资源分配结果是无法恢复的。
不利于功能扩展，如当不同的业务部门使用 Hadoop 集群时，每个业务部门对资源的调度有不同的策略要求，如何在一个进程里做到支持不同的调度策略，同时还支持热拔插（热拔插：不停止进程的情况下，能够改变系统的调度行为。）在这一点Job Tracker 难以符合业务要求。
2.YARN
YARN 是一个简称，它的全称是 yet another resource 里 go theater，本质上也是一个资源调度器。
如下架构图，它与 Hadoop1.0 最大的区别在于将资源调度和任务调度进行区分，当用户将作业提交到 resource manager后，resource manager 只进行一次资源的调度将资源调度结果会发送给一个 application 对应的 app master，
当 app master 接受资源分配的结果之后会进行任务的调度，决定在哪些节点上运行作业，该架构相比 Hadoop1.0而言，有很大的改进，能支撑起更大的计算规模。但是另外一方面，YARN 系统本身
还存在缺陷：
1.resource manager 目前仅支持 memory 调度，不能支持其他维度（如CPU，磁盘，网络等维度），但这些维度在实际的生产业务系统中是非常重要的，如有两个作业a和b如果只是靠内存维度，可能会将这两个进程分配在同一个物理节点上，在这两个节点如果是跑，譬如 thought，是非常耗CPU的，所以在这个节点上会出现严重的CPU争抢，
如果考虑到CPU的维度，调度系统可以将它们区分开的但实际上，当增加更多的资源维度时，调度的复杂性却不是一个线性增长的过程，从本质上讲，调度是一个背包问题，当只考虑内存时，是一个很简单的一维线性规划，而如果增加更多的资源维度，如CPU，磁盘，网络，将变成一个高维的背包问题，复杂度会是一个指数级增长，目前YARN对资源调度的性能达不到这个要求，目前仅支持内存维度的调度。
2.资源交互性能，当每个节点上的 node manager 跑完一个用户的作业，就是其中的 container,跑完作业之后，node manager会自主的将这个资源归还给resource manager,而有的作业，要复用这个资源，
如下图中作业用户提交后，可能有四个 instance 、map 两个 reduce 两个，但实际 resource manager 只分配了三个 container，当这个作业运行完map和一个reduce 之后，完全可以复用其中的资源，跑最后一个instance，但是node manager 会立即将这个资源归还给 resource manager， app master 需要再发起新的一轮资源请求之后才可以拿到资源跑最后一个 instance，整个资源的交互过程会增加链路，导致性能不高。
3.Mesos
Mesos 宣传的力度小，在业界中使用不普遍，下图是经典的Mesos架构图。
它的架构和YARN的架构类似，也有一个中心化的资源调度系统，称为Mesos master。它的好处也是将任务调度从资源调度中隔离开，上层可以支持更多种的计算框架如 Hadoop scheduler 及 MPI 类型的作业，当用户提交一个作业之后，首先 schedule 会发起相应的资源请求给 Mesos master，Mesos master 经过调度之后将资源的结果下发给 scheduler，scheduler 进行 instance 调度。
对于这个系统的缺陷：
1>scheduler 与 Mesos master 之间不能描述精确的资源请求。 scheduler 与Mesos master 之间的资源描述协议表现力并不够丰富，从而使当resource manager 提出请求之后，Mesos master 将资源下发后，还存在scheduler 挑选的过程，所以会发出一个 accep 的消息，返回给 Mesos master,讲明刚才分配给了资源里哪些不满足需求，其原因在于资源的请求协议里不够具体相对笼统的描述需要哪些资源。
2>一次资源分配需两次通信交互（offer&accept）调度效率低。
3>不支持资源的抢占
4.Aliyun-Fuxi
下图就是阿里云飞天 Fuxi 系统的典型架构图。当集群部署完之后，集群中会有一个 Fuxi Master 的角色，类似于 resource manager 负责资源的调度，每一个节点上会部署一个 Tubo 进程。
Tubo 这个名字来自于古代的一个神土地神，主要负责每一片土地上的万物生长。
当集群部署完之后，除了 Fuxi Maste 和 Tubo 进程之外，还有一个package manager 系统，当不同的用户使用飞天的sdk，编写了自己的作业之后，这个可执行程序会被编译并打包传到 package manager 系统，当用户运行后期作业时，Tubo 会知道这个包存在什么地方，并从 package manager 下载解压，拉起用户的进程。典型的用户流程，当用户通过客户端提交一个任务到 Fuxi Master后，Fuxi Master 首先会在一个比较空闲的节点上启动一个 app master，也就是用户的 application master， app master 启动之后，会发起资源请求给Fuxi Master，这个资源请求描述，表现力是丰富的，笼统的讲，在集群中随便十台机器就可以，也可以具体到每一台机器需要多少资源。
可以避免 Master 系统中资源交互链路较长，准确描述所需资源的要求。Fuxi Master 通常在毫秒级别可以完成调度，并将调动结果在消息的回复里返回给app master ，app master有了资源之后，会知道哪些节点上可以启动 app walker,于是会通知相应的节点上的 Tubo 进程，拉起相应的 app worker, app worker 进程被拉起之后会到 app master 注册，开始执行任务。
app master 会将相应的计算任务下发给 app walker，其中包括每一个 app worker所处理的数据分片、存储的位置，以及每一个数据分片的处理结果该存货的地方，这个过程称之为 instance 的下发，每一个 app worker 所执行的任务称之为一个instance。这里也是典型的将资源的调度和任务调度进行了切分，所以 Fuxi Master 能够支撑起更大的规模。在2013年时已可支持单集群5000节点，现在并发运行10000级别作业。
以上是比较了业界比较流行的几个系统，以及阿里云自研发的飞天系统在分布式调度方面的一些技术实践。在阿里的应用，VLDB 2014 Fuxi论文
（http://www..vldb.org/pvldb/vol7/p1393-zhang.pdf），可以找到更多的技术细节，同时在CSDN文章
（http://www.csdn.net/article/a/2014-09-27/15820219）,这篇文章上可以找到关于做5k项目时面临的更多的技术挑战。
Aliyun-Fuxi 在最近10月份的世界排序大赛中取得了不错的一个成绩。
