混部數據中心負載特征及其任務調度優化分析*

王濟偉，葛浙奉，蔣從鋒，張紀林，俞 俊，林江彬，閆龍川，任祖杰，萬 健

(1.杭州電子科技大學計算機學院，浙江 杭州 310018；2.阿里云計算有限公司，浙江 杭州 311121； 3.國網電力信息通信有限公司，北京 100053；4.之江實驗室，浙江 杭州 311121； 5.浙江科技學院信息與電子工程學院，浙江 杭州 310023)

1 引言

隨著各類互聯網應用的快速增長，企業及個人用戶對云計算服務的需求與日俱增。互聯網數據中心IDCs(Internet Data Centers)作為承載云計算服務的基礎設施，發揮了越來越重要的作用。數據中心提供的服務可簡單分為在線(如瀏覽型請求、交易型業務和支付型業務等)和離線(如科學計算、統計報告和數據處理等)2類。在線類服務要求較低的延遲，而離線批處理類任務要求具有較高的吞吐量。另外，由于任務時延過長或任務失敗重試會影響用戶體驗，因此在線類服務往往不可降級。而批處理任務相對于在線任務，對時延不敏感，可以接受任務失敗重試。

用戶任務負載的動態性和多樣性，使得數據中心內服務器資源的使用也會動態變化，既具有一定的周期性，又具有一定的波動性。為提高數據中心資源利用率，降低數據中心運行成本，云計算服務提供商逐步將在線服務和離線批處理任務在數據中心進行混合部署(以下簡稱混部)[1,2]。因此，在混部場景下，如何同時滿足在線服務和離線批處理任務的不同要求，在提高資源利用率的同時，盡量降低2類任務之間的干擾，是目前互聯網數據中心任務調度面臨的關鍵挑戰。

目前，大型互聯網公司，如谷歌[3]、臉書[4]、微軟[5]和阿里巴巴[6,7]等，都采取了在線服務與離線任務混部的方式以提高數據中心的資源利用率。但是，由于在線服務和離線任務的資源需求和資源使用特性的差異，數據中心集群調度器將服務器資源在不同業務間復用和共享的同時，需要在資源競爭時優先保證高優先級業務的資源需求。以阿里巴巴的集群管理系統為例，阿里巴巴的多個數據中心于2015年逐步開始混部，通過逐年提高集群中機器的混部比例，以確保其在實際生產環境中的可靠性。

阿里巴巴混部集群調度管理系統主要由Sigma和Fuxi 2種調度器組成[8]。其中Sigma調度器負責Pouch容器[9](在線服務)的調度，Fuxi負責離線批處理作業的調度。由于同一集群上同時存在Sigma和Fuxi，機器上的CPU、內存、磁盤、網絡帶寬等資源會被這2種調度器爭搶。為了避免機器上的資源被一方過度占用導致另一方無法正常工作，或者資源被閑置，無法得到充分利用，集群管理系統中設置了Level0模塊來協調資源的分配。目前阿里巴巴采用混部的服務器已經達到數萬臺以上，將原來的單一在線原生集群的日均資源利用率從10%提高到了40%，并在“雙十一”等特殊促銷時期，將離線批處理任務進行業務降級處理，以滿足激增的在線任務的資源需求。通過混部，在確保數據中心服務質量的同時，節省了30%以上的成本[6]。如果能夠對數據中心負載特征進行更深入的分析，如負載的時間、空間特征及資源使用維度，則可以進一步挖掘集群的混部潛力，進而提高混部集群的資源利用率，降低數據中心運行成本。

本文根據阿里巴巴2018年12月公開的具有4 034個結點的混部集群的任務調度日志數據(cluster-trace-v2018)[8]，系統分析了典型混部數據中心的負載特征，并提出了相應的任務調度優化策略。本文工作如下所示：

(1)對離線批處理作業與在線應用的資源使用進行了分析，發現單個在線應用所包含的容器數量符合Zipf分布，表明混部集群中在線應用的規模都具有明顯的傾斜現象(Task Skew)。該發現有助于集群調度相關領域學者與研究人員建立更為合理的調度優化模型。

(2)計算并繪制了離線批處理作業的DAG(Directed Acyclic Graph)關系圖和每個作業的關鍵路徑，計算了任務等待時間、作業通信時間等指標，并指出了可能的任務調度優化空間。

2 數據集概述

2018年12月，阿里巴巴面向公眾開放了一個具有4 034個結點的混部集群運行日志數據cluster-trace-v2018(以下簡稱trace-2018)，圖1是阿里巴巴混部集群調度管理系統示意圖。與阿里巴巴2017年首次公開的混部集群數據集cluster-trace-v2017(以下簡稱trace-2017)相比，trace-2018的數據更豐富，具體體現在：(1)時間跨度更長，服務器數量更多。trace-2018中記錄了混部集群中4 034臺機器連續8天的運行狀況，而trace-2017數據集僅包含1 300臺機器在1天內的運行日志；(2)trace-2018包含了以DAG形式表示的離線批處理作業中任務間的依賴信息。

Figure 1 Architecture of the Alibaba co-located cluster management system圖1 阿里巴巴混部集群管理系統架構示意圖

trace-2018數據包含6個csv表格數據，涵蓋機器、離線批處理作業、在線容器3類主體。每個主體包含1份靜態信息表與1份運行信息表，如表1所示。接下來分別對機器、離線批處理作業、在線容器這3類主體的數據進行分析。

Table 1 Data tables in trace-2018表1 trace-2018數據構成

2.1 機器

trace-2018中的機器指混部集群中的物理服務器，這些機器既運行離線批處理作業，也作為容器宿主機，運行在線服務。machine_meta.csv表記錄了機器靜態配置信息，主要包括機器編號(machine_id)、容錯等級(disaster_level_1和disaster_level_2)、CPU核心數量(cpu_num)、內存容量(mem_size)和狀態(status)。該表包含每臺機器1個或多個時間戳上的配置信息，記錄了不同時間點機器的配置情況(但全表中未出現機器配置變化)。

machine_usage.csv記錄了機器的實時運行信息數據，包括時間戳、CPU利用率(cpu_util_percent)、內存利用率(mem_util_percent)和硬盤帶寬利用率(disk_io_percent)等。

2.2 離線批處理作業

離線批處理作業具有作業-任務-實例3層結構，即job-task-instance(為方便和數據集中字段參照，下文中將作業和job，任務和task，實例和instance交叉使用)。1個作業包含1個或多個任務，同一個作業的任務可能會有先后執行順序的約束。1個任務包含1個或多個實例，同一個任務的實例沒有先后執行順序，每個實例可以被分配到不同的機器上以并行執行。圖2給出了ID為j_87的作業的“job-task-instance”3層結構。

Figure 2 Internal structure of batch job j_87圖2 批處理作業j_87的內部結構

2.3 在線服務容器

容器用于承載在線任務，常用于用戶端內容搜索、電商平臺交易等業務。在線任務具有很強的時延敏感性，其服務質量將直接影響在線服務的用戶體驗。因此，在線任務具有很高的優先級。1臺機器上通常部署多個容器且不間斷地運行。

container_meta.csv記錄了容器的靜態配置信息，包括容器編號(container_id)、容器所在機器編號(machine_id)、容器所屬的應用組(app_du)、容器狀態(status)、請求CPU核心數量(cpu_request)、CPU核心使用數量限制(cpu_limit)和容器請求的內存使用量(mem_size)。container_usage.csv表記錄了容器的實時運行信息，包括CPU資源使用率(cpu_util_percent)、每指令時鐘周期(cpi)、每千條指令緩存缺失次數(mpki)、內存使用率(mem_util_percent)、內存帶寬使用率(mem_gps)、磁盤IO使用率(disk_io_percent)、接收網絡數據包數量(net_in)和發送網絡數據包數量(net_out)。

3 作業調度特征

離線批處理作業擁有“job-task-instance”3層結構，我們將job、task和instance的數量進行統計，如表2所示。

Table 2 Number of elements in “job-task-instance” hierarchy表2 “job-task-instance”層次結構中的元素數量

根據同一個job的task之間的依賴關系，可以將所有task分為3種類型，如表3所示。

Table 3 Example of DAG task names表3 DAG任務命名示例

(1)無DAG關系：該類task所屬的job無DAG結構，其執行可以完全并行化。該類task的名稱有2種形式：①以“task_”加上一段隨機數字與字母組成的字符串，并以“==”結尾，本文稱之為task_xxxx型；②“MergeTask”，本文稱之為MergeTask型。

(2)有DAG關系、有依賴：該類task有1個或多個前驅依賴。其名稱是單個大寫字母與該task在job內序號的組合，加上“_”，后跟其依賴的task的job內序號構成。1個task可以有多個依賴。如表3中的示例J3_1_2表示job內序號為3的task“J3_1_2”依賴于job內序號為1和2的task。

(3)有DAG關系、無依賴：該類task所屬的job有DAG結構，但是該任務本身不依賴于任何其它task。此類task可能成為其所屬job包含的其余task的依賴。另外，存在task名稱中包含“_Stg”的特殊情況。如名為“M9_Stg4”的task，此處的“_Stg4”不指代任何task。

表4給出了3類任務的占比。在所有的task中，只有少部分不具有DAG關系(15.98%)，且具有前驅依賴的task的數量幾乎占總數的一半(47.07%)。

Table 4 Classification and statistics of tasks according to DAG dependencies表4 任務分類(有無DAG依賴)

圖3展示了作業j_2041的任務依賴示意圖。為了計算上的便利，我們添加了start和end節點；每個節點表示job中的1個task，節點中的數字表示的是task在job內的編號；圖3中帶箭頭的有向邊(x→y)表示2個task之間的依賴關系，如圖3中task 1、2、3、5都依賴于task 4，而task 6依賴于task 1、2、3、5，有向邊上的數字表示的是所依賴的task的實際執行時間，如有向邊4→1上的值為5，表示task 4的執行時間為5 s，即task 1需要等待5 s(task 4執行完)才能開始執行。由于數據集中缺乏相關數據，我們沒有考慮task間數據傳輸、任務調度等帶來的其他時間開銷，即僅考慮理想情況下的DAG圖；圖3中用灰色顯示的節點及虛線有向邊代表此DAG圖中的關鍵路徑，在該路徑上的task執行時間之和最大。

Figure 3 DAG example of job j_2041圖3 作業j_2041的DAG圖

instance是離線作業中最細粒度的調度單位，我們根據其所屬的task是否含有DAG關系，將所有instance劃分為2類，如表5所示。在表5中，含DAG關系的task的instance調度次數占總調度次數的96.91%，這與前述的含DAG關系的task占總task數量的84.02%有一定差別。說明包含DAG關系的任務的規模大小不同，導致其中instance的調度次數不同。

Table 5 Scheduling numbers of DAG and noDAG instances表5 DAG型與noDAG型實例的調度數量

如表6所示，通過計算DAG型task與noDAG型task包含instance數量的均值，發現上述現象是由包含DAG關系的task平均包含更多數量的instance引起的。從表6可以直觀地看出，noDAG型的task不僅沒有依賴關系，在體積上也更為輕量，其包含的平均instance數量只有DAG型task的0.16倍，全體task均值的0.19倍。

Table 6 Number of instances in each type of task表6 各類型任務包含的實例數量

為了研究DAG型和noDAG型任務在調度instance到機器的過程中是否存在偏好，本文對所有機器上運行的DAG型和noDAG型實例進行了統計，發現在運行較多實例的機器上，接受的DAG型實例調度次數處于同一數量級，而noDAG型實例的調度情況則有所不同。由表7可見，在數據集所記錄的時間范圍內，machine_id為m_1455的機器曾接受過133 522次noDAG型實例的調度，是所有機器中最多的。machine_id為m_3761的機器所接受的noDAG型實例調度次數位列第二，然而其數量為14 313次，僅占機器m_1455的10.72%。可見，在阿里巴巴混部集群中調度器會設置特殊分工的機器，該類機器相較于集群中的其他機器，會接受更多的來自于noDAG型task的instance調度。

Table 7 Number of scheduled instances on machine m_1455 and m_3761表7 機器m_1455與m_3761上運行的instance數量

為了對比DAG型與noDAG型2種task的調度特征，本文將二者包含的instance在機器上的調度次數的分布按照DAG型task包含的instance調度次數升序排序，如圖4所示。由于noDAG型task包含的instance總數較少，本文將其分布進行歸一化處理，分別以2種instance在機器上的最大調度次數為基準(noDAG型不含前述的m_1455機器)。從圖4中可以看出，DAG型task包含的instance調度數量與noDAG型在機器上的分布較為相似。為了進一步確認，計算得出兩者的相關系數為0.75，表明調度器對有無DAG關系沒有明顯偏好(除m_1455機器)。另外，在圖4放大部分中，無論DAG型還是noDAG型task，其中instance的調度次數在機器上的分布都有較為明顯的區間分布。

Figure 4 Distribution of scheduled tasks of DAG and noDAG (normalized to the maximum value of each type)圖4 DAG型與noDAG型task包含的 instance的調度分布(以各自類型的最大值歸一化)

圖5中圖例data表示原數據的散點，其縱軸為單個應用組上容器的數量出現的頻次，橫軸坐標為該頻次的排名。在圖5a中，從排名第1的數據點開始擬合，得到分布參數α為0.579，C為9.49E2，決定系數R2為0.858。從第10位的數據點開始擬合，得到分布參數α為0.729，C為2.270E3，決定系數R2為0.941。圖5表明，不論是否去除排名前10的重量型在線應用，混部集群中所有在線應用的容器規模都具有明顯的傾斜現象，其分布符合Zipf分布。

Figure 5 Zipf distribution on container number in a single online application group圖5 在線應用組的容器規模的Zipf分布

混部集群中在線應用任務規模(應用中容器數量)的傾斜現象的定量分析，可以為集群調度相關領域研究人員建立合理的在線任務調度模型提供參考。混部集群中的這一傾斜現象，同本文作者之前發現的未混部的淘寶生產集群中的數據傾斜現象相類似[10]。

4 調度優化

本文使用多種衡量集群調度效率的指標，用以評價混部集群管理系統的可優化潛力。本文選擇的評價指標將任務的生命周期劃分為多個階段，通過分析各個階段的開銷，可以推斷相應的性能影響因素，有助于確定混部集群的優化方向。

4.1 實例開始延遲

實例開始延時SD(Start Delay)是指某instance開始時間與其所屬task中的第1個開始的instance的開始時間之間的差值。1個task的平均SD(meanSD)指的是該task中所有instance的SD平均值，最大SD(maxSD)指的是該task中所有instance的SD的最大值，1個task的第i個instance的開始延時tSD_i如式(1)所示：

tSD_i=Tinst_i_start-Tinst_first_start

(1)

其中，Tinst_i_start表示第i個instance的開始時間,Tinst_first_start表示此task的第1個instance的開始時間。

圖6將具有相同instance數量的task的平均SD和最大SD通過取平均值來聚合，研究trace-2018中1個task的instance的數量對instance的調度效率的影響。其中橫軸是1個task的instance數量(取數量大于或等于2的task)，縱軸是以秒為單位的開始延時。

Figure 6 Relationship between instance start delay and number of instances圖6 實例開始延時與其數量之間的關系

因為包含大量instance的task數量占比較少，所以在圖6中，平均SD和最大SD在橫軸103～105的區域發生了較大的波動。但是，整體趨勢仍然可以看出，隨著task的instance數量的增長，task的平均SD與最大SD都有所上升(在橫軸為2時，平均SD與最大SD相交。因為除去最早開始的instance外，只會剩下1個instance用于求SD，此時平均SD等于最大SD)。

在理想情況下，1個task中的所有instance是同時開始執行的，所以SD可以衡量1個task中instance的并行效率。我們發現，隨著task中包含的instance數量增加，調度器對于instance的調度效率不斷下降。

4.2 任務間隙時間

當前驅依賴的task執行完畢，后繼task并不會立即執行，需要等待前驅task數據傳輸、系統調度等，本文將這段時間記為task的間隙時間。間隙時間可以反映有前后依賴的task之間實際上未執行計算任務的時間。間隙時間越長，則表明調度器的效率越低，所以該指標可以用于探究集群調度有依賴task開始執行的效率。2個有依賴關系的task的間隙時間為當前task的開始執行時間與其所依賴的task的結束時間之間的差值。2個有依賴關系的task的間隙時間tinterval的計算如式(2)所示：

tinterval=Tstart-Tdep_end

(2)

其中，Tstart表示當前task的實際開始執行時間，Tdep_end表示當前task所依賴的task的實際結束時間。

本文將間隙時間分為2種情況：

(1)情況1：當job的所有task只有1個前驅依賴的時候，則任意2個有依賴關系的task的間隙時間是由數據傳輸、調度引起的，如圖7a所示；

(2)情況2：當1個task有多個前驅依賴的時候，且其中1個前驅依賴的task的執行時間又特別長時，則另外的前驅task與當前task之間的間隙時間會變長，如圖7b所示。

Figure 7 Interval time of two cases圖7 2種情況間隙時間示意

為了對2種情況的間隙時間作說明，對DAG圖進行擴展，在有向邊上增添了2個task的間隙時間，有向邊上括號外的數值表示task的執行時間，括號內的數值表示2個task的間隙時間，如圖7a有向邊1→2的標簽為“69(3)”，表示task 1的執行時間為69 s，task 1與task 2的間隙時間為3 s。圖7a中job(j_1084)的任意2個task的間隙時間完全是由數據傳輸、調度等所造成的；而圖7b中job(j_2959)的task 4同時依賴于task 1和task 3，task 4需要等待task 1和task 3執行完才能執行，而task 1的執行時間為233 s，task 3的執行時間為2 s，所以task 3很快就執行完，而task 1仍需執行相當一段時間，造成task 3與task 4的間隙時間為239 s，此間隙時間不僅由數據傳輸、調度等造成，還與等待task 1執行完有關。

4.3 任務等待時間

batch_task.csv表中字段start_time記錄的是每個task在job master的注冊時間，而task實際開始執行的時間為該task中首個instance開始執行的時間，將task實際開始時間與注冊時間之間的差值定義為task的等待時間twaiting：

twaiting=Tfirst_inst_start-Tregister

(3)

其中，Tfirst_inst_start表示該task中最早開始的instance的時間，即task的實際開始時間，Tregister表示task的注冊時間。

Task的等待時間是由于此task的前驅task的執行所耗費的時間、task間的數據通信及調度等帶來的時間開銷所造成的，所以task的等待時間可以視為衡量task調度效率的指標，task的等待時間越長則說明調度效率越低。

4.4 作業通信時間

由于job的task間含有DAG關系，有前驅依賴的task需要等待其所依賴的task完成后才能執行，而前驅依賴的task執行完之后，并不會立即執行當前task，當前task需要等待前驅task數據傳輸、系統調度等，才能開始執行。所以，完整執行1個job的時間由2部分組成：(1)job中task的執行時間(關鍵路徑長度)；(2)task間通信、調度等帶來的時間開銷。為此我們定義job的通信時間為關鍵路徑上task之間的數據通信、調度等時間開銷。該指標可以反映job執行效率，縮短作業通信時間可在很大程度上縮短job的持續時間。

作業通信時間tcomm通過計算job的總耗時與關鍵路徑上的所有task的執行時間之間的差值得到：

tcomm=tjob-tcritical

(4)

其中，tjob表示1個job的總執行時間，tcritical表示DAG圖中關鍵路徑上的task的執行時間之和。

4.5 作業執行時間

1個作業的總執行時間為其關鍵路徑上所有任務的總執行時間(關鍵路徑長度)與作業的通信時間之和。為了分析job的總執行時間與上述二者之間的關系，給出了如圖8所示的job執行時間、關鍵路徑長度和job通信時間的累積分布函數CDF(Cumulative Distribution Function)圖，并對三者進行比較,結果如表8所示。

Figure 8 CDF of job execution time,critical path length,and job communication time圖8 job執行時間、關鍵路徑長度和job通信時間CDF圖

表8 關鍵路徑長度、job通信時間和job執行時間對比 s

圖8給出了作業執行時間、關鍵路徑長度和作業通信時間的CDF圖，其中縱軸為累積分布，實線為job執行時間，點劃線為關鍵路徑長度，虛線為job通信時間。從圖8可以看出，橫坐標在0～500左右處，job執行時間和關鍵路徑長度的CDF曲線近似直線，說明在該時間段內job執行時間和關鍵路徑長度分布得較為均勻，而job通信時間主要分布在0～25 s左右區間內。

從表8可以發現，關鍵路徑的最大值(175 453)與job執行時間的最大值(175 460)較為接近，它們都出自j_2724077，而j_2724077的通信時間僅為7 s；job通信時間的最大值為4 691 s，與關鍵路徑和job執行時間最大值相差較大。可以推測job通信時間與job中關鍵路徑上的task執行的總時間長短并沒有直接關系。關鍵路徑長度平均值為134.97 s(占job平均執行時間71.20%)，而job通信時間平均值為54.59 s(占job平均執行時間28.80%)，表明大多數job的通信時間較短，job執行時間的增長主要是由于關鍵路徑長度增長導致的，但仍有一部分job的通信時間相當長，有潛在的優化空間以減少job的總執行時間。

4.6 任務執行優化

為了研究task等待時間與其前驅task的執行時間與間隙時間之間的關系，給出了如圖9所示的task等待時間、執行時間和間隙時間的CDF圖。

Figure 9 CDF of task interval time圖9 間隙時間的CDF圖

上文介紹間隙時間時，提出了2種間隙時間情況：(1)情況1：job中所有task只依賴一個task；(2)情況2：job中存在task依賴多個task。圖9a為間隙時間為情況1的CDF圖，圖9b為間隙時間為情況2的CDF圖。根據圖9a發現，當task等待時間較小時(約3 s)，task等待時間與間隙時間CDF曲線非常接近，而當等待時間逐漸增大時，間隙時間的CDF曲線高于等待時間的CDF曲線，即此時task間隙時間對等待時間影響逐漸減小；而圖9b中等待時間和間隙時間的曲線保持高度一致，但需注意的是情況2的間隙時間受所依賴task的執行時間影響，即task間的間隙時間會由于其中一個依賴task的執行時間過長而變長，從而導致task等待時間變長。因此可以得出結論，task等待時間受task執行時間和間隙時間共同影響，但task執行時間受task規模或者處理邏輯的極大影響，很難直接減少task的執行時間。所以，有必要重視對task間隙時間的優化，以減少整體task的等待時間。且由于離線批處理作業對時效不敏感，我們可以調整其執行順序，通過將多個job聯合考慮以提升整體完成效率。

5 相關工作

對數據中心運行日志的分析一直都是研究服務器性能瓶頸和優化潛力的重要環節。針對阿里巴巴2017年發布的數據集trace-2017，多位學者給出了相應的混部集群特征分析結果[11 - 15]。本文根據2018年發布的數據集trace-2018，針對出現的新特性，進一步豐富了混部集群的相關研究。

除了阿里巴巴公開的混部集群數據集，目前還有大量利用自有數據中心運行日志分析結果進一步優化調度性能的案例。Jiang等[16,17]使用模擬的混合負載測試多種虛擬化平臺，利用運行日志充分比較各平臺之間的優勢與劣勢，為數據中心調度系統設計者提供了重要參考。Qiu等[18]設計了一種結合了日志采集的簡化虛擬機調度框架，節省了37.07%～49.98%的服務器功耗。

為了促進業界與學術界對于集群調度的研究，Google于2012年公開了其異構集群的跟蹤數據集(clusterdata-2011-2)[19]，包含了集群內12 500臺服務器在29天內的負載數據[20]。作為Google目前正在使用的大規模集群管理系統，Borg采用了類似于Alibaba集群管理系統的混部機制。該調度器隱藏了2種負載間資源分配與錯誤處理的細節，讓開發者能夠專注于業務的開發[21]。Borg是少數幾個在萬臺服務器以上規模集群獲得較高彈性與可靠性的系統。Google部署Borg至今已經超過10年，混部比例高達98%。Google曾經統計過，如果不使用這樣的機制，應對相同的工作負載，機器的數量需要額外增加20%～30%[3]。

由于大規模集群跟蹤數據集的稀缺性，該數據集成為了許多相關領域科研人員的研究對象。據統計，已經有超過450篇發表的論文在實驗過程中使用到了Google的跟蹤數據集[22]。許多研究工作通過分析該數據集，對大型集群的負載特征、故障處理、調度機制等進行了深入探究[23,24]。

除此之外，由于Google數據集在權威性、數據量方面的優勢，眾多的研究工作利用Google跟蹤數據集來評估算法或系統的性能。其中，Islam等[25]提出了一種基于循環神經網絡RNN(Recurrent Neural Network)的集群故障預測算法，利用Google數據集進行實驗測試，預測準確率達到了87%。Han等[26]將Google跟蹤數據集作為參考，設計出了可以產生不同類型負載的基準工具，用以研究云服務的性能瓶頸。Xu等[27]利用真實電價與Google跟蹤數據集等數據，測試提出的基于區塊鏈的去中心化資源管理系統在降低電力成本方面的效果。Dabbagh等[28]針對過度承諾資源的云服務，設計出一套高效能的虛擬機預測與遷移框架，并在Google數據集的測試下證明該框架能夠顯著降低電力消耗。此外，還有很多資源分配方面的研究利用Google數據集，提出了有價值的資源調度算法[29 - 33]。

大型集群的運行日志數據對于推動相關領域的研究是大有裨益的。然而，Google跟蹤數據集已經公開將近7年，整個互聯網環境都發生了較大的變化，使用該數據集得出的結論對于當今的環境是否適用有待考證。并且，大量的集群調度研究工作集中在單一的數據集上，容易使研究結論陷入過擬合的誤區。如果要進一步得出有價值的研究成果，選擇更為多樣、更為新穎的數據集是很有必要的。因此，本文的分析工作對于研究目前的混部集群的任務負載特征和調度優化具有較高的參考價值。

6 結束語

作為開放集群跟蹤項目(Open Cluster Trace Program)的一部分，阿里巴巴繼2017年開放實際生產中的混部集群日志cluster-trace-v2017后，于2018年末開放了時間跨度更長、機器數量更多、包含離線批處理任務間依賴關系的cluster-trace-v2018。

在本文中，我們分析了cluster-trace-v2018的新特性，詳細介紹了在“job-task-instance”3層結構下DAG形式的task間依賴的表達方式。對數據集中靜態、動態運行情況下的調度情況進行了統計分析。基于混部集群運行時特征，使用了開始延時、間隙時間、等待時間等多種指標來評價含有DAG形式依賴關系的批處理作業調度效率，并分析對其進一步優化的方向與可能性。最后，在未來的工作中，希望可以根據本文中分析的混部集群特性與可優化潛力，提出DAG形式離線任務在混部場景下的優化方案，可以在不同混部搭配條件下有效提升機器硬件資源使用率。