分布式调度系统的比较

分布式系统有两个重要的部分：1.任务调度 2.资源调度
现有的分布式调度系统有：

• hadoop MR
• YARN
• Mesos
• Aliyun-Fuxi
• Borg
• Torca
• Corona

不同类型的作业和服务有：

• 内存作业(spark)
• 离线作业
• 流式作业(storm)
• 迭代式作业(iMapReduce)
• crawler server
• web server等，不同任务对资源有不同需求。

1)hadoop MR是hadoop2之前的调度框架，它通过JobTracker对client发来的请求进行资源调度和任务调度。将相应的资源和任务分配给TaskTracker后，TaskTracker进行任务的执行，并将执行结果反馈给JobTracker。

该系统是一个典型的主从架构，单管理节点也导致一些问题：

1. 受内存限制，管理节点的注册内存限定了扩展上限（据说在yahoo公司hadoop被调优到可支持4000台）
2. 容错性差,JobTracker进程挂掉后之前的所有正在运行的app的调度信息就没了。
3. 扩展性差，无法在一个进程中实现在不停止当前任务的情况下根据进来的任务需求改变调度策略。

2)YARN是2011年hadoop2中的调度框架。将JobTracker的任务细分为ResourceManager和NodeManager，client的任务被封装成一个AppMaster,它向ResourceManager请求任务资源,ResourceManager把资源分配结果给NodeManager上的AppMaster，AppMaster会进行task的分配调度和进度跟踪。AppMaster是可变更的部分，用户可以对不同的编程模型写自己的AppMaster让更多类型的编程模型跑在Hadoop集群中。(Hadoop YARN大数据计算框架及其资源调度机制研究)当AppMaster出问题后，ResourceManager中有个叫AppMasters的用于检测AppMaster的模块，它会在其它Node上重启这个App。其它的App不受影响。

但是也有不足：

1. ResourceManager只支持内存的分配，不会根据任务对cpu,网络,磁盘的不同需求来进行更多维度的资源划分。当引入更多维度的参数时，系统的资源与调度分配就成了一个背包问题，即NP完全问题。YARN仅支持按内存分配的资源调度问题。
2. 资源复用问题，当NodeManager上任务运行结束后需要将资源归还给ResourceManager，有时一个用户请求里有多个reduce,当一个reduce执行完后,AppMstr去归还然后再去拿一块资源运行下一个reduce。

3)Mesos,每个Agent向Master报告自己的资源剩余情况，Master告诉Scheduler自己有的资源，Scheduler选好自己要的资源向Master发过去,Master再把资源和task发给agent让它去执行。

问题：
1.Scheduler与Mesos master之间资源的描述不一定是完全匹配的。
2.除了Master向Scheduler发自己有的资源，Scheduler还要返回给Master自己接收了哪些资源，所以一次资源分配有两次通信。
3.不支持资源抢占，mesos一个一个来满足framework的要求，当有新的资源被释放时会先被用来满足当前还没被满足的framework。当资源并不匹配时其它的framework可能恰好只需要这些资源但并不会被满足。
YARN与Mesos区别
YARN资源调度器
4)Aliyun-Fuxi和YARN的调度系统很像，支持了多维度的资源调度考仲裁和资源抢占。

伏羲介绍
5)Borg这玩意和Mesos很像很像

Google Borg