记得从去年第一次在组会上讲论文时讲了Christina Delimitrou的HCloud论文后，陆陆续续的一直在读她的论文，并在今年4月份的ASPLOS和她有了一张合影（当时我心里的那个忐忑啊，想和她搭讪又不敢）。
这篇论文发表自2014年的ASPLOS（这些年她好像每年都会中一篇ASPLOS，膜拜），依旧是关于数据中心非常棘手的一个问题：现在数据中心的成本都非常高，各大厂商都在努力提高集群的性能和灵活度来达到很高的经济效益，但是现在大部分的集群资源利用率依旧非常的低（前段时间和阿里云的大佬们聊时了解到，阿里云现在的集群平均利用率能达到40%，目标是希望能达到60%），这样严重的影响到了公司的经济效益和以后集群的扩展性。
这篇文章提出了Quasar，它通过对负载需要的资源进行预测和自动分配来对集群进行管理，同时提高资源利用率并保证应用的性能不受影响。它整个框架分为三部分。
- Quasar提供了一个高层次的接口来让用户描述它们对负载的性能需求给调度器，不同的负载对性能的需求不同，当然接口也不相同。对于分布式框架如hadoop，其限制条件就是执行的时间；对于延迟敏感型应用，限制条件则为每秒钟的查询次数和延迟QoS的限制等。
- Quasar使用了快速分类技术对不同的负载进行评估，例如不同的资源和不同的资源调度对负载的性能会产生什么样的影响？分类的结果就是准确的估计了当我们考虑了不同数目的服务器、单个服务器上的资源数量和来自其他负载的干扰时该负载的性能，Quasar通过将分类评估的问题分解为几个小的部分来降低了分类的复杂度。
- Quasar使用第二部分的分类结果来进行资源的分配，它同时使用了监控系统，当机器有空闲资源的情况下，负载的性能没有得到满足（即使负载发生了变化，例如job内部阶段发生了变化）都说明这个分类是不正确的或者贪心算法导致了次优解，无论是是什么导致分类不正确，只要条件允许Quasar都会调整资源的分配或者重新对负载进行分类和调度。
Quasar的代码行数我是非常诧异的，只有6K代码，增加一个应用也只需要几百行代码，在这样的前提下能对应用性能带来那么大的提升真的很赞。
- Single batch job（纯粹hadoop）：平均提升29%到58%。
- Multiple Batch Frameworks performance(Hadoop,Storm, and Spark混合)：提升27%。
- Large-Scale Cloud Provider：从15%的cpu利用率提升到62%,提升47%。