陳圣蕾，裘翼滔，蔣從鋒+，張紀(jì)林，俞 俊，林江彬，閆龍川，任祖杰，萬 健

1.杭州電子科技大學(xué) 計(jì)算機(jī)學(xué)院，杭州310018

2.阿里云計(jì)算有限公司，杭州311121

3.國網(wǎng)電力信息通信有限公司，北京100053

4.之江實(shí)驗(yàn)室，杭州311121

5.浙江科技學(xué)院 信息與電子工程學(xué)院，杭州310023

隨著云計(jì)算技術(shù)的日益發(fā)展和云服務(wù)能力的進(jìn)一步提升，越來越多的企業(yè)傾向于將自已的業(yè)務(wù)部署到云平臺(tái)上。然而，最近的一些研究顯示大多數(shù)商業(yè)化集群的資源利用率都較低。根據(jù)蓋特納和麥肯錫的研究數(shù)據(jù)，從全球范圍來看，服務(wù)器利用率僅達(dá)到6%～12%。即使通過服務(wù)聚合技術(shù)進(jìn)行優(yōu)化，服務(wù)器的利用率仍然只有7%～17%。因此如何有效地對(duì)各類資源進(jìn)行管理，保證資源的高利用率和服務(wù)的高可用性成為了云平臺(tái)管理者的一大挑戰(zhàn)。

為了進(jìn)一步提高資源利用率，可以通過更加細(xì)粒度的資源調(diào)度以及借助虛擬機(jī)和容器等虛擬化技術(shù)將不同的服務(wù)實(shí)例整合在一起（比如將在線服務(wù)和離線任務(wù)進(jìn)行混合部署），使得工作負(fù)載分布的密度更高。但是這種模式可能會(huì)對(duì)在線服務(wù)產(chǎn)生重大影響，例如由于在線服務(wù)和離線任務(wù)之間共享資源，高密度部署會(huì)引起嚴(yán)重的資源競(jìng)爭(zhēng)，從而增加在線服務(wù)的延遲，尤其是長尾請(qǐng)求的延遲。因此分析數(shù)據(jù)中心中服務(wù)器真實(shí)的資源利用率和各類工作負(fù)載實(shí)際的運(yùn)行狀況有助于更好地了解各類資源的分配情況，還可以對(duì)目前的調(diào)度算法提供有效的改進(jìn)建議。

本文深入分析了阿里巴巴數(shù)據(jù)中心中某一個(gè)含有4 034 臺(tái)服務(wù)器的集群在8 天時(shí)間內(nèi)所有服務(wù)器的資源利用情況以及在線服務(wù)和離線任務(wù)的運(yùn)行狀況。通過對(duì)該數(shù)據(jù)集的分析，主要貢獻(xiàn)有：

（1）通過對(duì)整個(gè)集群中所有在線任務(wù)以及離線任務(wù)資源使用情況的分析，總結(jié)了工作負(fù)載資源使用的一些特點(diǎn)，包括：①從在線服務(wù)的運(yùn)行情況來看，所有容器的平均CPU 利用率存在周期性變化，從每天的早8 點(diǎn)到晚9 點(diǎn)維持在一個(gè)較高水平，并且在每天凌晨4 點(diǎn)回落到最低點(diǎn)；②對(duì)離線任務(wù)來說，發(fā)現(xiàn)除去第一天和第八天，剩下6 天中任務(wù)提交峰值都集中在每天的同一時(shí)刻。其次95%實(shí)例的運(yùn)行時(shí)間都在199 s以內(nèi)，但是有0.052%的實(shí)例運(yùn)行時(shí)間在1 h以上甚至?xí)掷m(xù)幾天。

（2）對(duì)集群中的批處理作業(yè)和在線服務(wù)進(jìn)行了聚類分析，并確定工作負(fù)載模式，發(fā)現(xiàn)相對(duì)高資源利用率的容器占了所有容器的絕大部分，而低資源利用率、短執(zhí)行時(shí)間的實(shí)例則占了總實(shí)例的絕大部分。首先選擇有效的特征指標(biāo)作為聚類的維度，然后使用-means 算法識(shí)別每個(gè)維度的聚類邊界，并對(duì)其進(jìn)行聚類分析。

1 背景介紹

1.1 阿里巴巴任務(wù)調(diào)度體系

如圖1所示，阿里巴巴通過兩個(gè)調(diào)度器Sigma和Fuxi來調(diào)度集群中的在線服務(wù)和離線任務(wù)，其中Sigma負(fù)責(zé)在線服務(wù)的調(diào)度，F(xiàn)uxi負(fù)責(zé)離線任務(wù)的調(diào)度。

圖1 混部集群架構(gòu)Fig.1 Mixed cluster architecture

阿里巴巴的在線服務(wù)都由其自建的Pouch容器進(jìn)行托管并由Sigma 負(fù)責(zé)Pouch 容器的部署決策。這些在線服務(wù)都是面向用戶的，因此要求滿足低延遲和高性能的需求。通過阿里巴巴內(nèi)部幾年的實(shí)踐以及多次雙十一流量高峰的考驗(yàn)，Sigma 已經(jīng)證明了其大規(guī)模容器調(diào)度的能力。

Sigma由Alikenel、SigmaSlave、SigmaMaster三層大腦聯(lián)動(dòng)協(xié)作。其中，Alikenel 部署在每一臺(tái)物理機(jī)上，它能夠增強(qiáng)內(nèi)核，在資源分配和時(shí)間片分配上按優(yōu)先級(jí)以及分配策略進(jìn)行靈活調(diào)整。SigmaSlave 可以在本機(jī)對(duì)容器進(jìn)行CPU 分配、應(yīng)急場(chǎng)景處理等。本機(jī)Slave會(huì)對(duì)時(shí)延敏感型任務(wù)的干擾快速做出決策和響應(yīng)，從而避免因全局決策處理時(shí)間延長帶來的業(yè)務(wù)損失。SigmaMaster 是一個(gè)中心大腦，負(fù)責(zé)統(tǒng)攬全局，能夠?yàn)榇罅课锢頇C(jī)上容器部署進(jìn)行資源的調(diào)度和分配以及算法的優(yōu)化決策。

Fuxi 負(fù)責(zé)管理非容器化的離線任務(wù)，而離線任務(wù)主要是復(fù)雜的大規(guī)模計(jì)算類應(yīng)用程序，因此Fuxi采用數(shù)據(jù)驅(qū)動(dòng)的多級(jí)流水線并行計(jì)算框架，與Map-Reduce、Map-Reduce-Merge等批處理編程模型兼容。

最終，整個(gè)系統(tǒng)通過Level-0 策略機(jī)制來協(xié)調(diào)和管理兩種類型的工作負(fù)載，使其能夠盡可能合理地部署在同一集群中。

1.2 數(shù)據(jù)集基本介紹

cluster-trace-v2018 數(shù)據(jù)集記錄了4 034 臺(tái)服務(wù)器在8 天時(shí)間內(nèi)的運(yùn)行狀況。在后續(xù)計(jì)算中假設(shè)該數(shù)據(jù)采集時(shí)間從每一天的0 點(diǎn)開始。該數(shù)據(jù)集一共由6個(gè)文件組成（大約270 GB），具體信息如表1所示。

表1 阿里巴巴數(shù)據(jù)集記錄行數(shù)Table 1 Alibaba dataset record line number

該數(shù)據(jù)集主要記錄了服務(wù)器、在線服務(wù)和離線任務(wù)的資源配置以及資源使用情況，每個(gè)計(jì)算節(jié)點(diǎn)都配置了一定的資源，監(jiān)控程序每過60 s 就會(huì)采樣一次實(shí)際的資源使用情況，最后將300 s 內(nèi)采樣值的平均值作為實(shí)際值記錄到數(shù)據(jù)文件中。從這些文件介紹中可以得知，對(duì)離線任務(wù)而言，一個(gè)批處理作業(yè)就代表一個(gè)離線任務(wù)，每個(gè)批處理作業(yè)都運(yùn)行在物理機(jī)上，離線任務(wù)上的三級(jí)任務(wù)模式關(guān)系圖如圖2 所示，每個(gè)批處理作業(yè)（job）由多個(gè)任務(wù)（task）構(gòu)成，而每個(gè)任務(wù)由多個(gè)實(shí)例（instance）構(gòu)成，每個(gè)實(shí)例都配有一定數(shù)量的資源（例如CPU、內(nèi)存等）。實(shí)例是批處理作業(yè)的最小調(diào)度單位并在某一個(gè)特定節(jié)點(diǎn)上運(yùn)行。每個(gè)實(shí)例的資源配置和實(shí)際運(yùn)行情況都會(huì)在數(shù)據(jù)文件中有相應(yīng)的記錄，例如開始時(shí)間、結(jié)束時(shí)間、運(yùn)行狀態(tài)（成功或者失?。?、平均CPU 使用核數(shù)和最大CPU 使用核數(shù)等。對(duì)在線服務(wù)而言，其應(yīng)用程序都是運(yùn)行在容器中，因此可以通過容器的資源使用情況來分析應(yīng)用程序的性能。容器的數(shù)據(jù)包括請(qǐng)求的資源量、實(shí)際的資源使用率、cpi 和mpki 等。分析這份數(shù)據(jù)將有助于解決大型IDC 所面臨的在線服務(wù)和離線任務(wù)混合部署的問題，同時(shí)還可以對(duì)在線服務(wù)和離線任務(wù)之間的協(xié)同調(diào)度提供合理的建議。

圖2 離線任務(wù)上三級(jí)任務(wù)模式關(guān)系圖Fig.2 Three-level task mode relationship diagram on offline tasks

2 在線任務(wù)基本情況

2.1 服務(wù)器上容器基本分配情況

首先根據(jù)container_meta.csv 文件統(tǒng)計(jì)了每臺(tái)服務(wù)器上容器數(shù)量的分布情況。container_meta.csv 中顯示有4 005 臺(tái)服務(wù)器部署了容器，整個(gè)集群中所有服務(wù)器一共部署了71 476 個(gè)容器。具體統(tǒng)計(jì)信息如圖3、圖4 所示，在一臺(tái)服務(wù)器上最多部署35 個(gè)容器，最少只部署1 個(gè)容器，80%的服務(wù)器部署的容器數(shù)量在23 個(gè)以內(nèi)，大部分服務(wù)器部署的容器數(shù)量集中在8～25。

圖3 每臺(tái)服務(wù)器包含的容器數(shù)量Fig.3 Container amount of server

圖4 不同的容器數(shù)量對(duì)應(yīng)的服務(wù)器數(shù)量Fig.4 The number of servers corresponding to different container number

實(shí)際上像Sigma 這樣的在線任務(wù)調(diào)度系統(tǒng)在為長時(shí)間運(yùn)行的容器執(zhí)行調(diào)度時(shí)需要考慮多種因素，包括應(yīng)用程序的優(yōu)先級(jí)，應(yīng)用程序是否能容忍資源超額分配等，這種多約束多目標(biāo)優(yōu)化會(huì)導(dǎo)致容器數(shù)量在整個(gè)集群中不均勻分布。

container_meta.csv 文件中記錄的容器有4 個(gè)狀態(tài)，分別是started、allocated、stopped 以及unknow，經(jīng)統(tǒng)計(jì)，有71 342 個(gè)容器在這8 天內(nèi)只出現(xiàn)過一種狀態(tài)，其中70 903 個(gè)容器在8 天里始終保持started 狀態(tài)，有133 個(gè)容器出現(xiàn)過兩種狀態(tài)，并且這些容器都出現(xiàn)過started 狀態(tài)，只有id 為c_13222 的容器出現(xiàn)過三種狀態(tài)。具體統(tǒng)計(jì)數(shù)據(jù)如表2～表4 所示。

表2 只出現(xiàn)一種狀態(tài)的容器數(shù)量Table 2 Container amount with only one state

表3 出現(xiàn)過兩種狀態(tài)的容器數(shù)量Table 3 Container amount with two states

表4 出現(xiàn)過三種狀態(tài)的容器數(shù)量Table 4 Container amount with three states

總體來看，數(shù)據(jù)集中絕大多數(shù)容器在8 天內(nèi)始終處于started 狀態(tài)，可以得出：絕大多數(shù)容器的生命周期大于8 天，而且可能會(huì)在更長一段時(shí)間內(nèi)繼續(xù)存活。并且在這期間，新容器部署的頻率較低，說明新上線的服務(wù)和容器出現(xiàn)故障的幾率較低。8 天時(shí)間里只有5 臺(tái)服務(wù)器上出現(xiàn)過不明狀態(tài)的容器，而且不明狀態(tài)的容器數(shù)量均分布在不同服務(wù)器上而且數(shù)量都為1，這表明大多數(shù)容器在8 天時(shí)間里都是在穩(wěn)定狀態(tài)下運(yùn)行的。

還統(tǒng)計(jì)了容器的內(nèi)存請(qǐng)求量的分布情況，如圖5所示，容器的內(nèi)存請(qǐng)求量共有23 種情況，且內(nèi)存請(qǐng)求量的值都已經(jīng)過歸一化處理，其中容器的最大內(nèi)存請(qǐng)求量為25，最小為0；內(nèi)存請(qǐng)求量為1.56 的容器數(shù)量最多，有54 397 個(gè)，其次是內(nèi)存請(qǐng)求量為3.13，容器數(shù)量有13 022 個(gè)，這兩個(gè)內(nèi)存值對(duì)應(yīng)的容器數(shù)量共占總?cè)萜鲾?shù)量的94.3%，說明大部分容器請(qǐng)求的內(nèi)存為1.56 和3.13。

圖5 不同內(nèi)存請(qǐng)求量對(duì)應(yīng)的容器數(shù)量Fig.5 Container amount corresponding to different memory requests

2.2 容器資源使用情況

根據(jù)container_usage.csv 文件統(tǒng)計(jì)顯示，在第一天中并沒有容器資源使用情況的數(shù)據(jù)，故統(tǒng)計(jì)的是第2 天到第9 天這8 天內(nèi)容器資源利用率的分布情況，結(jié)果如圖6 所示。

根據(jù)統(tǒng)計(jì)分析得到以下結(jié)論：（1）8 天時(shí)間里在每天凌晨4 點(diǎn)，在線任務(wù)的平均CPU 利用率都達(dá)到一天內(nèi)的最小值，說明這個(gè)時(shí)間對(duì)在線任務(wù)的訪問量較低；（2）大部分在線任務(wù)的內(nèi)存利用率較高而CPU利用率和磁盤利用率較低。

以小時(shí)為單位統(tǒng)計(jì)了所有容器的資源利用率的最大值、平均值、最小值隨時(shí)間的分布情況，圖6 清楚地反映了在第2 天至第9 天時(shí)間內(nèi)容器運(yùn)行時(shí)的資源特征。從圖6 中可以看出在線任務(wù)的平均CPU 利用率隨時(shí)間呈現(xiàn)周期性變化，并且根據(jù)統(tǒng)計(jì)數(shù)據(jù)，平均CPU 利用率在5%～13%，在時(shí)間戳為28、52、76、100、124、148、172、196 時(shí)，平均CPU 利用率都處在波谷的位置，即在每天凌晨4 點(diǎn)，在線任務(wù)的平均CPU利用率都達(dá)到一天中的最小值。而在每天的早上9點(diǎn)至晚上9 點(diǎn)，容器的平均CPU 利用率都處在一個(gè)較高的階段。平均內(nèi)存利用率隨時(shí)間變化的趨勢(shì)比較平緩，在79%～83%上下波動(dòng)，而平均磁盤利用率則波動(dòng)幅度相對(duì)較大，在5%～19%變化，且沒有明顯的規(guī)律性。對(duì)于資源利用率的最大值、最小值分布，發(fā)現(xiàn)CPU、內(nèi)存和磁盤利用率的最大值、最小值都是一個(gè)極端值，分別是100%和0%。

圖6 在線任務(wù)的資源利用率隨時(shí)間變化情況（第2 天至第9 天）Fig.6 Resource usage of online tasks changes over time(Day 2—9)

為了進(jìn)一步展現(xiàn)在線任務(wù)資源利用的差異性，統(tǒng)計(jì)分析了容器在不同資源利用率下的數(shù)量分布情況，結(jié)果如圖7 所示。發(fā)現(xiàn)絕大部分容器都有內(nèi)存利用率較高而CPU 以及磁盤利用率較低的特性。并且CPU 和內(nèi)存利用率分布圖符合指數(shù)分布，磁盤利用率分布圖符合高斯分布。

圖7（a）～（c）分別是在線任務(wù)不同平均CPU 利用率、平均內(nèi)存利用率和平均磁盤利用率對(duì)應(yīng)的容器數(shù)量分布以及擬合曲線，橫坐標(biāo)為平均資源利用率，縱坐標(biāo)為對(duì)應(yīng)的容器數(shù)量。

圖7 不同平均資源利用率的容器數(shù)量分布Fig.7 Distribution of the number of containers with different average resource usage

具體信息統(tǒng)計(jì)顯示：最大的平均CPU 利用率為100%，最小的平均CPU 利用率為0，平均CPU 利用率的中位值是6.787%，80%容器的平均CPU 利用率在0%～16%。最大的平均內(nèi)存利用率為100%，最小的平均內(nèi)存利用率是1%，內(nèi)存平均利用率的中位值是91.89%，有54%容器的平均內(nèi)存利用率在90%以上。最大的平均磁盤利用率是99%，最小平均磁盤利用率是0%，磁盤平均利用率的中位值是8.203%，有88%容器的平均磁盤利用率在6%～12%。同時(shí)，還對(duì)上述3 幅圖的分布進(jìn)行曲線擬合，結(jié)果發(fā)現(xiàn)圖7（a）和圖7（b）的分布符合指數(shù)分布，且圖7（a）的分布其擬合度達(dá)到了97.7%，而圖7（c）的分布則是符合高斯分布，擬合度達(dá)到了99%，具體擬合函數(shù)及其參數(shù)如表5 所示。

表5 容器資源利用率分布擬合函數(shù)以及參數(shù)Table 5 Fitting function and parameter value of container resource usage distribution

3 離線任務(wù)基本情況

根據(jù)batch_task.csv 和batch_instance.csv 這兩份文件的記錄，總共有4 201 014 個(gè)批處理作業(yè)被提交，這些批處理作業(yè)被劃分為14 295 731 個(gè)批處理任務(wù)，而這些任務(wù)最終由1 350 473 907 個(gè)實(shí)例負(fù)責(zé)執(zhí)行。每一個(gè)批處理任務(wù)至少含有一個(gè)實(shí)例，并且有一部分大型批處理任務(wù)含有的實(shí)例數(shù)目達(dá)到了上億個(gè)。95%的服務(wù)器在8 天時(shí)間里運(yùn)行的實(shí)例數(shù)量在400 000 以內(nèi)，其中服務(wù)器m_2335 運(yùn)行的實(shí)例數(shù)量達(dá)到了483 998，為所有服務(wù)器之最。對(duì)集群中所有批處理實(shí)例的資源使用情況以及實(shí)例的運(yùn)行時(shí)間進(jìn)行了統(tǒng)計(jì)分析，結(jié)果如圖8～圖10 所示。

圖8 描述了所有實(shí)例在執(zhí)行過程中所使用的CPU 核數(shù)情況，其中橫坐標(biāo)每100 代表一個(gè)CPU核。由結(jié)果可知95%的實(shí)例使用的CPU 核數(shù)都在1.1 以內(nèi)，然而少數(shù)實(shí)例占用的平均CPU 核數(shù)達(dá)到了6 以上。由于分配給同一任務(wù)中的每個(gè)實(shí)例的CPU資源是固定的，導(dǎo)致每個(gè)實(shí)例的CPU 利用率很低。

圖8 實(shí)例的平均CPU 核數(shù)使用個(gè)數(shù)分布圖Fig.8 Distribution of average number of CPU cores used by instance

圖9 是所有實(shí)例的平均內(nèi)存利用率分布圖以及CDF（cumulative distribution function）圖，其中橫坐標(biāo)代表的平均內(nèi)存利用率是經(jīng)過歸一化后的值，縱坐標(biāo)是對(duì)應(yīng)的實(shí)例數(shù)量。從圖中可以看出，99%實(shí)例的平均內(nèi)存利用率在30%以下，值得注意的是有少部分實(shí)例的內(nèi)存利用率超過100%，說明預(yù)分配給該部分實(shí)例的內(nèi)存資源是不合理的。綜合圖8 和圖9 來看，為了提高實(shí)例的CPU 利用率以及減少內(nèi)存搶占情況的發(fā)生，調(diào)度系統(tǒng)可以在給實(shí)例分配資源前使用一些資源預(yù)測(cè)算法來提高資源分配的精確度。

圖9 實(shí)例的平均內(nèi)存利用率Fig.9 Average memory usage of instance

圖10 所有實(shí)例的運(yùn)行時(shí)間Fig.10 Duration of instances

圖10是所有實(shí)例的運(yùn)行時(shí)間分布圖以及CDF圖。統(tǒng)計(jì)結(jié)果顯示所有實(shí)例中最長運(yùn)行時(shí)間為479 737 s（133.26 h），最短運(yùn)行時(shí)間不到1 s，95%實(shí)例的運(yùn)行時(shí)間在199 s以內(nèi)，99%實(shí)例的運(yùn)行時(shí)間在628 s以內(nèi)，因此大多數(shù)批處理作業(yè)都是短期作業(yè)，但是還有0.052%實(shí)例運(yùn)行時(shí)間超過1 h，這部分實(shí)例可能會(huì)成為整個(gè)批處理作業(yè)最終完成時(shí)間的瓶頸，即整個(gè)批處理作業(yè)會(huì)出現(xiàn)長尾延遲。

圖11 顯示了整個(gè)集群中每小時(shí)到達(dá)的批處理作業(yè)數(shù)量分布情況，從圖中可以直觀看到每小時(shí)到達(dá)的批處理作業(yè)數(shù)量存在較大的差異。除了第一天和第四天運(yùn)行的批處理作業(yè)數(shù)量較少外，其他6 天每天執(zhí)行的最大批處理作業(yè)數(shù)量都保持在68 000 左右，并且在每天凌晨3 點(diǎn)達(dá)到該波峰值，而在這個(gè)時(shí)間戳在線任務(wù)的平均CPU 利用率則是接近一天中的波谷值，說明離線任務(wù)的急劇增加會(huì)影響在線任務(wù)的運(yùn)作。更值得注意的是，在時(shí)間戳為116 h 時(shí)，批處理作業(yè)數(shù)目出現(xiàn)了異常的增加，可能是由于該時(shí)間段的負(fù)載壓力測(cè)試導(dǎo)致的。因此從批處理作業(yè)數(shù)量的峰值來看，阿里巴巴的分布式離線任務(wù)調(diào)度系統(tǒng)Fuxi應(yīng)當(dāng)具備相當(dāng)大的吞吐量，從而能夠應(yīng)對(duì)平常時(shí)期處于萬級(jí)的批處理作業(yè)數(shù)量以及異常時(shí)期十萬級(jí)以上的批處理作業(yè)數(shù)量。

圖11 每小時(shí)內(nèi)到達(dá)的批處理作業(yè)數(shù)量Fig.11 Number of jobs arriving in an hour

4 服務(wù)器、容器及實(shí)例特征聚類分析

-means 聚類算法是機(jī)器學(xué)習(xí)中常用的聚類算法之一，通常用于工作負(fù)載聚類，有如下優(yōu)點(diǎn)：（1）-means 算法是解決聚類問題的經(jīng)典算法，算法簡(jiǎn)單，實(shí)現(xiàn)容易，收斂速度快；（2）對(duì)于處理大型數(shù)據(jù)集，該算法保持可伸縮性和高效性，復(fù)雜度為()，其中是所有對(duì)象的數(shù)量，是聚類數(shù)量，是迭代次數(shù)（通常?）；（3）-means 算法的可解釋度比較強(qiáng)。因此采用此算法分別對(duì)整個(gè)集群中所有服務(wù)器、在線任務(wù)以及離線任務(wù)進(jìn)行聚類分析。

4.1 服務(wù)器聚類分析

根據(jù)跟蹤數(shù)據(jù)集，在整個(gè)集群中一共有4 034 臺(tái)服務(wù)器，服務(wù)器的資源利用率在0～100%，-1 和101 是一些無效的值。因此需要對(duì)原始數(shù)據(jù)進(jìn)行處理，剔除掉無效的數(shù)據(jù)，最終采用-means 聚類算法對(duì)4 021臺(tái)服務(wù)器進(jìn)行聚類。首先確定以CPU 利用率、內(nèi)存利用率和磁盤利用率這三種資源利用率作為聚類的特征指標(biāo)，并采用Calinski-Harabasz Index作為評(píng)估標(biāo)準(zhǔn)，Calinski-Harabasz分?jǐn)?shù)值的數(shù)學(xué)計(jì)算公式如下：

其中，為訓(xùn)練集樣本數(shù)，為類別數(shù)，B為類別之間的協(xié)方差矩陣，W為類別內(nèi)部數(shù)據(jù)的協(xié)方差矩陣，tr 為矩陣的跡。評(píng)價(jià)分?jǐn)?shù)越高，聚類效果越好，服務(wù)器在不同聚類數(shù)下的評(píng)價(jià)分?jǐn)?shù)分布情況如圖12所示。由圖12 可以看出，當(dāng)評(píng)估CPU 利用率、內(nèi)存利用率和磁盤利用率這3 個(gè)特征指標(biāo)的聚類效果時(shí)，值為6 對(duì)應(yīng)的評(píng)價(jià)分?jǐn)?shù)最高，即將服務(wù)器分為6 類效果最好。三維聚類效果圖如圖13 所示。

圖12 服務(wù)器在不同分類數(shù)下的評(píng)價(jià)分?jǐn)?shù)Fig.12 Evaluation score of servers under different classification number

圖13 服務(wù)器三維聚類效果圖Fig.13 3D clustering rendering of servers

分類邊界數(shù)據(jù)如表6 所示。采用-means 聚類算法根據(jù)服務(wù)器的資源利用情況將4 021 臺(tái)服務(wù)器分為6 類，每一類對(duì)應(yīng)的服務(wù)器數(shù)量如圖14 所示。mGroup0 的服務(wù)器數(shù)量最多，有1 711 臺(tái)，mGroup0、mGroup3 和mGroup5 這3 組的服務(wù)器數(shù)量占總數(shù)量的90%以上，mGroup4的服務(wù)器數(shù)量最少，只有32臺(tái)。

圖14 每個(gè)分類中服務(wù)器的數(shù)量Fig.14 Servers amount in each group

表6 所有服務(wù)器特征指標(biāo)的邊界Table 6 Boundaries of feature vectors for servers

使用了CDF 圖來描述所有服務(wù)器的資源利用率的變化，一種顏色的曲線代表一組服務(wù)器的資源使用情況，如圖15 所示，橫坐標(biāo)是平均資源利用率，縱坐標(biāo)是對(duì)應(yīng)服務(wù)器數(shù)量的比例。由圖15（a）可以看出，這6個(gè)組在CPU利用分布上都有一定的差異，其中mGroup1和mGroup2相對(duì)來說比較近似。由圖15（b）可以看出，除了mGroup1，其他組在內(nèi)存分布上都比較相似，其中mGroup0、mGroup3、mGroup4 這3 個(gè)組的內(nèi)存分布幾乎是重合的，而mGroup1 的內(nèi)存利用率則普遍較低。由圖15（c）可以看出，mGroup4 的磁盤利用率特別高，大多數(shù)的利用率都在50%～60%，而其他組的磁盤利用率與mGroup4 相差甚大，且這些組的分布比較相近，都集中在15%以內(nèi)。由圖15 可以得到mGroup4 的資源利用率相比較其他組來說較高，而mGroup1 的資源利用率相較其他組較低。

圖15 服務(wù)器每個(gè)分類的平均資源利用率Fig.15 Average resource usage for server groups

通過數(shù)據(jù)分析可以得到：只有部分服務(wù)器存在比較明顯的資源使用特征，如mGroup1 中的116 臺(tái)服務(wù)器資源利用率普遍偏低，而mGroup4 中的32 臺(tái)服務(wù)器資源利用率則是較高的。

4.2 容器聚類分析

根據(jù)跟蹤數(shù)據(jù)集，整個(gè)集群中一共有71 476 個(gè)容器，通過對(duì)數(shù)據(jù)的處理，除去資源利用率無效的數(shù)據(jù)，最終對(duì)67 232 個(gè)容器進(jìn)行聚類分析。同樣，將平均CPU 利用率、平均內(nèi)存利用率和平均磁盤利用率作為聚類的3 個(gè)特征指標(biāo)，評(píng)估這3 個(gè)特征向量在不同值下的評(píng)價(jià)分?jǐn)?shù)，評(píng)價(jià)分?jǐn)?shù)分布圖如圖16 所示。由圖16 可以看出，在值為2 時(shí)評(píng)價(jià)分?jǐn)?shù)最高，說明將容器聚類為2 類時(shí)聚類效果最好。三維聚類效果圖如圖17 所示。

圖16 容器在不同分類數(shù)下的評(píng)價(jià)分?jǐn)?shù)Fig.16 Evaluation scores of containers under different classification number

圖17 容器三維聚類效果圖Fig.17 3D clustering rendering of containers

分類邊界數(shù)據(jù)如表7 所示。采用-means 聚類算法根據(jù)容器的資源利用情況將67 232 個(gè)容器分為兩類，cGroup0 的容器數(shù)量為50 533，占了總?cè)萜鲾?shù)量的75.2%，cGroup1 的容器數(shù)量為16 699。

表7 所有容器特征指標(biāo)的邊界Table 7 Boundaries of feature vectors for containers

圖18 是容器每個(gè)分類的CPU、內(nèi)存、磁盤使用情況的CDF 圖。此圖具體數(shù)據(jù)顯示cGroup0、cGroup1這兩組在內(nèi)存利用率上相差較大，cGroup1 內(nèi)存利用率主要在20%～60%，而cGroup0 則有70%以上的容器內(nèi)存利用率在90%以上。然而，這兩組的磁盤分布卻及其相似，曲線分布幾乎是重合的。由圖18 可以得出，cGroup0 中容器資源利用率相對(duì)較高，而cGroup1 中容器的資源利用率相對(duì)較低。

圖18 在線服務(wù)的平均資源利用率CDF 圖Fig.18 CDF of average resource usage for online service groups

4.3 實(shí)例聚類分析

根據(jù)第3 章統(tǒng)計(jì)，batch_instance.csv 文件中一共記錄了1 242 094 500 個(gè)實(shí)例的運(yùn)行狀況，由于實(shí)例數(shù)量比較龐大，為了方便分析，使用蓄水池抽樣算法從所有實(shí)例中抽取了10 000 000 個(gè)樣本進(jìn)行聚類。蓄水池抽樣算法是對(duì)一個(gè)長度很大（一般內(nèi)存中放不下）的數(shù)據(jù)流進(jìn)行數(shù)據(jù)采樣的常用算法，它對(duì)數(shù)據(jù)流中每個(gè)數(shù)據(jù)只訪問一次，并且保證所有數(shù)據(jù)被選中的概率相同。

與容器的聚類方法類似，將每個(gè)實(shí)例的平均CPU 使用核數(shù)、平均內(nèi)存利用率和執(zhí)行時(shí)間這3 個(gè)維度作為特征指標(biāo)，并采用-means 算法對(duì)抽樣的實(shí)例進(jìn)行了聚類分析。如圖19 所示，對(duì)抽樣實(shí)例在不同聚類數(shù)下的聚類效果進(jìn)行了評(píng)價(jià)，可以看到把所有實(shí)例分成兩類后得到的評(píng)價(jià)結(jié)果最好，因此決定將采樣實(shí)例分成兩類。表8 展示了聚類后每個(gè)類中特征向量的邊界。

表8 抽樣實(shí)例特征指標(biāo)的邊界Table 8 Boundaries of feature vectors for instance

圖19 抽樣實(shí)例在不同聚類數(shù)下的評(píng)價(jià)Fig.19 Evaluation of sampling instances under different number of clusters

通過聚類，將抽樣實(shí)例分為兩類，其中iGroup0中實(shí)例數(shù)量為321 752 個(gè)，只占總數(shù)的3.2%，而iGroup1 中實(shí)例數(shù)量則占了總數(shù)的絕大部分。

圖20 展示了兩類實(shí)例在CPU 和內(nèi)存資源使用以及執(zhí)行時(shí)間上的差異。從圖中可以看出，總體而言，iGroup0 中的實(shí)例無論在CPU 還是內(nèi)存資源上的需求都要略大于iGroup1，并且iGroup0 中的實(shí)例的執(zhí)行時(shí)間也要普遍大于iGroup1，iGroup1 中90%的實(shí)例運(yùn)行時(shí)間都在101 s之內(nèi)，而iGroup0 組中實(shí)例最短運(yùn)行時(shí)間為271 s。

圖20 兩類實(shí)例的平均資源利用率CDF 圖Fig.20 CDF of average resource usage for batch instance groups

4.4 各類容器和實(shí)例在每類服務(wù)器中的分布情況

根據(jù)本章前3 節(jié)，利用-means 聚類算法將所有服務(wù)器分為6 類，所有容器分為2 類，所有實(shí)例分為2 類。在本節(jié)中，統(tǒng)計(jì)了每類服務(wù)器中各類容器和實(shí)例的數(shù)量占比，并得出一些結(jié)論。結(jié)果如表9所示。

表9 每類服務(wù)器中兩類容器及兩類實(shí)例的數(shù)量占比Table 9 Proportion of two types of containers and instances in each type of server

具體統(tǒng)計(jì)數(shù)據(jù)顯示：mGroup0 和mGroup1 中兩類容器的分布占比接近1∶3，mGroup2、mGroup3 和mGroup4 中兩類容器的分布占比接近1∶4，mGroup5中兩類容器的分布占比近似于1∶2。從總體來看，容器對(duì)服務(wù)器沒有明顯的偏好性，每一類服務(wù)器上都有兩類容器的存在，但是兩類容器并沒有均勻分布在所有服務(wù)器上，這將會(huì)增加各類資源管理的復(fù)雜度。

此外，可以看到兩類實(shí)例在各類服務(wù)器上的分布較為均勻，每類服務(wù)器上兩類實(shí)例的比值都在1∶24左右，由此推測(cè)Fuxi 在進(jìn)行調(diào)度時(shí)會(huì)把每臺(tái)服務(wù)器上已部署的實(shí)例數(shù)量納入考慮范圍之內(nèi)。

綜合容器和實(shí)例的聚類情況，得出以下結(jié)論：

（1）相對(duì)高資源利用率的容器占了所有容器的絕大部分，而低資源利用率、短執(zhí)行時(shí)間的實(shí)例則占了總實(shí)例的絕大部分；

（2）容器和實(shí)例進(jìn)行混合部署的算法，在防止部分服務(wù)器（例如mGroup4 中的服務(wù)器）成為熱點(diǎn)方面，仍然有較大的改進(jìn)空間。

5 相關(guān)工作

對(duì)于包括基礎(chǔ)設(shè)施的設(shè)計(jì)、容量規(guī)劃以及成本優(yōu)化等多個(gè)目的的性能工程研究，了解工作負(fù)載的特性和行為是必不可少的，過去的許多工作已經(jīng)對(duì)工作負(fù)載特性進(jìn)行了多方面的研究。Shishira 等人對(duì)當(dāng)前工作負(fù)載特性的研究方法進(jìn)行了調(diào)查，他們根據(jù)處理模型、計(jì)算環(huán)境、資源利用率和應(yīng)用程序等對(duì)單個(gè)工作負(fù)載進(jìn)行分類繼而分析工作負(fù)載的關(guān)鍵特征。

2011 年隨著谷歌集群數(shù)據(jù)集的發(fā)布，許多研究人員對(duì)其進(jìn)行了工作負(fù)載分析，尋求資源調(diào)度優(yōu)化的方法。Reiss 等人研究了谷歌集群中工作負(fù)載的異構(gòu)性和動(dòng)態(tài)性。Fan 等人基于谷歌的數(shù)據(jù)集提出了一種基于功能的通用特征生成方法，可以從原始數(shù)據(jù)中生成新的特征以用于數(shù)據(jù)挖掘領(lǐng)域。Reiss 等人在分析了谷歌集群中工作負(fù)載多方面的特征后，揭示了谷歌集群在資源調(diào)度方面的一些不足之處。

2017 年阿里巴巴發(fā)布了他們的集群數(shù)據(jù)集，與Google 數(shù)據(jù)集不同之處在于阿里的數(shù)據(jù)集包含位于同一臺(tái)服務(wù)器的多個(gè)容器信息和批處理作業(yè)工作負(fù)載信息，使得可以對(duì)混合部署的工作負(fù)載進(jìn)行分析，了解它們之間的交互性和干擾性，從而提高云數(shù)據(jù)中心的資源利用率。許多研究人員已經(jīng)對(duì)2017 年阿里巴巴發(fā)布的數(shù)據(jù)集進(jìn)行了研究，提出了許多獨(dú)特的見解。Lu 等人通過對(duì)阿里巴巴在2017 年年底發(fā)布的集群數(shù)據(jù)集的統(tǒng)計(jì)分析，揭示了云數(shù)據(jù)中心中資源利用率存在的多個(gè)不平衡性。Cheng 等人詳細(xì)描述了阿里巴巴集群中存在的資源過度配置和過度承諾的情況。Deng 等人揭示了阿里巴巴數(shù)據(jù)集資源利用的一些重要特征。Liu 等人通過彈性和塑性角度揭示了阿里巴巴集群中工作負(fù)載有別于谷歌集群工作負(fù)載的運(yùn)行特征。這些特征將有助于為云平臺(tái)設(shè)計(jì)有效的資源管理方法，提高工作負(fù)載的資源利用率。

還有許多通過機(jī)器學(xué)習(xí)的方法對(duì)集群數(shù)據(jù)進(jìn)行的研究。Chen 等人對(duì)Google 集群數(shù)據(jù)集進(jìn)行了分析，根據(jù)數(shù)據(jù)集的時(shí)間行為提供了數(shù)據(jù)集的統(tǒng)計(jì)概要，研究發(fā)現(xiàn)每個(gè)作業(yè)具有不同的行為，并利用-means聚類方法對(duì)常見作業(yè)進(jìn)行聚類分析，確定常見作業(yè)組。Alam 等人對(duì)Google 集群跟蹤中的工作負(fù)載進(jìn)行聚類和分析。Chen 等人基于阿里巴巴集群跟蹤中工作負(fù)載的幾個(gè)典型特征采用-means 聚類算法對(duì)在線作業(yè)和批處理作業(yè)進(jìn)行聚類分析，典型特征包括CPU 利用率、內(nèi)存利用率、磁盤利用率以及批處理作業(yè)運(yùn)行持續(xù)時(shí)間。

本文的工作是阿里巴巴在2018 年年底發(fā)布的集群數(shù)據(jù)集的首批分析之一。從資源利用率、容器部署情況和常見作業(yè)聚類分析等多方面分析這個(gè)數(shù)據(jù)集，發(fā)現(xiàn)了阿里巴巴集群運(yùn)行情況的一些規(guī)律。

6 結(jié)論

本文詳細(xì)分析了阿里巴巴在2018 年發(fā)布的集群的云資源使用情況，并從整個(gè)集群服務(wù)器的資源使用情況、在線服務(wù)的資源使用情況、批處理實(shí)例的運(yùn)行時(shí)間以及批處理作業(yè)與在線服務(wù)的區(qū)別等方面得出了一些重要結(jié)論。首先，對(duì)硬件資源使用情況進(jìn)行分析，發(fā)現(xiàn)該集群中不同的硬件設(shè)備在資源利用率上存在顯著的空間不平衡和時(shí)間不平衡，大部分服務(wù)器以及容器都有內(nèi)存利用率較高而CPU 利用率和磁盤利用率較低的特性。由此，推測(cè)Sigma 在分配新的容器時(shí)會(huì)優(yōu)先考慮服務(wù)器上的內(nèi)存使用情況而非CPU 分配情況。其次，通過-means 機(jī)器學(xué)習(xí)算法分別對(duì)集群中所有服務(wù)器、在線任務(wù)以及批處理作業(yè)進(jìn)行聚類分析，確定了常見的作業(yè)組，發(fā)現(xiàn)相對(duì)高資源利用率的容器占了所有容器的絕大部分，而低資源利用率、短執(zhí)行時(shí)間的實(shí)例則占了總實(shí)例的絕大部分。本文提出的發(fā)現(xiàn)和見解可以幫助數(shù)據(jù)中心操作員更好地理解工作負(fù)載特性，從而通過優(yōu)化調(diào)度算法提高資源利用率。