互聯網普及的20年來，尤其是近10年移動互聯網、互聯網+的浪潮，使互聯網技術滲透到各行各業，滲透到人們生活的方方面面，這帶來了互聯網服務規模和數據規模的大幅增長。日益增長的服務規模和數據規模帶來數據中心的急劇膨脹。在大規模的數據中心中，傳統的運維方式已經不能滿足規模化的需求，于是基于自動化調度的集群管理系統紛紛涌現。

 這些系統往往有一個共同的目標，就是提高數據中心的機器利用率。在龐大的數據中心服務器規模下，平均利用率每提高一點，就會帶來非常可觀的成本節約。這一點我們可以通過一個簡單的計算來感受一下。假設數據中心有N臺服務器，利用率從R1提高到R2，能節約多少臺機器？ 不考慮其他實際制約因素的情況下，假設能節約X臺，那么我們有理想的公式：

      N*R1 = (N-X)*R2  

=>  X*R2 = N*R2 – N*R1

=>         X = N*(R2-R1)/R2

如果我們有10萬臺服務器，利用率從28%提升到40%，那么代入上述公式有：

N = 100000(臺),  R1 = 28%, R2 = 40% 

X= 100000* (40-28)/40 = 30000(臺)

也就是說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