互联网普及的20年来，尤其是近10年移动互联网、互联网+的浪潮，使互联网技术渗透到各行各业，渗透到人们生活的方方面面，这带来了互联网服务规模和数据规模的大幅增长。日益增长的服务规模和数据规模带来数据中心的急剧膨胀。在大规模的数据中心中，传统的运维方式已经不能满足规模化的需求，于是基于自动化调度的集群管理系统纷纷涌现。
这些系统往往有一个共同的目标，就是提高数据中心的机器利用率。在庞大的数据中心服务器规模下，平均利用率每提高一点，就会带来非常可观的成本节约。这一点我们可以通过一个简单的计算来感受一下。假设数据中心有N台服务器，利用率从R1提高到R2，能节约多少台机器？不考虑其他实际制约因素的情况下，假设能节约X台，那么我们有理想的公式：
N*R1 = (N-X)*R2 => X*R2 = N*R2 – N*R1 => X = N*(R2-R1)/R2AI 代码解读
如果我们有10万台服务器，利用率从28%提升到40%，那么代入上述公式有：
N= 100000(台),
R1 = 28%,
R2 = 40%
X=100000* (40-28)/40 = 30000(台)
AI 代码解读
也就是说10万台服务器，利用率从28%提升到40%，就能节省出3万台机器。假设一台机器的成本为2万元，那么节约的成本就有6个亿。
但是遗憾的是，根据盖特纳和麦肯锡前几年的调研数据，全球的服务器利用率并不高，只有6%到12%。即使通过虚拟化技术优化，利用率还是只有7%－17%；这正是传统运维和粗放的资源使用模式带来的最大问题。调度系统的主要目标就是解决这个问题。
通过资源的精细化调度，以及虚拟化的手段，比如Virtual Machine或容器技术，让不同服务共享资源，堆叠高密部署，可以有效的提升资源利用率。但是这种模式对在线业务的应用上存在瓶颈。因为在线业务间的资源共享，高密部署会带来各个层面的资源使用竞争，从而增加在线服务的延迟，尤其是长尾请求的延迟。
对于在线业务来说，延迟的增加往往立刻反应到用户的流失和收入的下降，这是在线业务无法接受的。而近年来随着大数据的普及，对实时性要求并不高的批量离线作业规模越来越大，在资源使用上，逐渐和在线业务的体量相当，甚至超过了在线业务。于是很自然想到，将离线业务和在线业务混合部署在一起运行会怎样？能否在牺牲一些离线作业延迟的情况下，充分利用机器资源，又不影响在线的响应时间？
阿里巴巴从15年开始做了这个尝试。在这之前，阿里内部针对离线和在线场景，分别各有一套调度系统： 从10年开始建设的基于进程的离线资源调度系统Fuxi（伏羲），和从11年开始建设的基于Pouch容器的在线资源调度系统Sigma。 从15年开始，我们尝试将延迟不敏感的批量离线计算任务和延迟敏感的在线服务部署到同一批机器上运行，让在线服务用不完的资源充分被离线使用以提高机器的整体利用率。
这个方案经过2年多的试验论证、架构调整和资源隔离优化，目前已经走向大规模生产，并已服务于电商核心应用和大数据计算服务ODPS业务。混布之后在线机器的平均资源利用率从之前的10%左右提高到了现在的40%以上，并且同时保证了在线服务的SLO目标。
我们了解到，近年来解决资源调度和集群管理领域特定问题的学术研究也在蓬勃发展。但是考虑到学术研究和实际真实的生产环境还是存在很大差异。首先是用于学术研究的机器规模都相对较小，可能无法暴露出实际生产规模的问题；其次是学术研究中所用的数据往往不是实际生产环境产生的，可能会对研究的准确性和全面性产生影响。
因此我们希望将这个阿里内部核心混布集群的数据开放出来，供学术界研究。希望学术界能在有一定规模的真实生产环境数据中，寻找到资源调度和集群管理更好的模式和方法，能够指导优化实际生产场景，将机器利用率和服务质量提高到一个更高的水平。我们一期先开放1000台服务器12个小时的数据。
数据格式描述和数据下载链接放在了github工程中，欢迎查阅：https://github.com/alibaba/clusterdata
有任何问题和建议可以通过邮件反馈给我们：
alibaba-clusterdata@list.alibaba-inc.com
来源：阿里技术
原文链接
