混部數(shù)據(jù)中心在線離線服務特征分析

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

1.杭州電子科技大學 計算機學院，杭州310018

2.阿里云計算有限公司，杭州311121

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

4.之江實驗室，杭州311121

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

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

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

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

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

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

1 背景介紹

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

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

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

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

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

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

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

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

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

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

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

圖2 離線任務上三級任務模式關系圖Fig.2 Three-level task mode relationship diagram on offline tasks

2 在線任務基本情況

2.1 服務器上容器基本分配情況

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

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

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

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

container_meta.csv 文件中記錄的容器有4 個狀態(tài)，分別是started、allocated、stopped 以及unknow，經(jīng)統(tǒng)計，有71 342 個容器在這8 天內(nèi)只出現(xiàn)過一種狀態(tài)，其中70 903 個容器在8 天里始終保持started 狀態(tài)，有133 個容器出現(xiàn)過兩種狀態(tài)，并且這些容器都出現(xiàn)過started 狀態(tài)，只有id 為c_13222 的容器出現(xiàn)過三種狀態(tài)。具體統(tǒng)計數(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 天，而且可能會在更長一段時間內(nèi)繼續(xù)存活。并且在這期間，新容器部署的頻率較低，說明新上線的服務和容器出現(xiàn)故障的幾率較低。8 天時間里只有5 臺服務器上出現(xiàn)過不明狀態(tài)的容器，而且不明狀態(tài)的容器數(shù)量均分布在不同服務器上而且數(shù)量都為1，這表明大多數(shù)容器在8 天時間里都是在穩(wěn)定狀態(tài)下運行的。

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

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

2.2 容器資源使用情況

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

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

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

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

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

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

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

具體信息統(tǒng)計顯示：最大的平均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%。同時，還對上述3 幅圖的分布進行曲線擬合，結(jié)果發(fā)現(xiàn)圖7（a）和圖7（b）的分布符合指數(shù)分布，且圖7（a）的分布其擬合度達到了97.7%，而圖7（c）的分布則是符合高斯分布，擬合度達到了99%，具體擬合函數(shù)及其參數(shù)如表5 所示。

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

3 離線任務基本情況

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

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

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

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

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

圖10 所有實例的運行時間Fig.10 Duration of instances

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

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

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

4 服務器、容器及實例特征聚類分析

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

4.1 服務器聚類分析

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

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

圖12 服務器在不同分類數(shù)下的評價分數(shù)Fig.12 Evaluation score of servers under different classification number

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

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

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

表6 所有服務器特征指標的邊界Table 6 Boundaries of feature vectors for servers

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

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

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

4.2 容器聚類分析

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

圖16 容器在不同分類數(shù)下的評價分數(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 個容器分為兩類，cGroup0 的容器數(shù)量為50 533，占了總?cè)萜鲾?shù)量的75.2%，cGroup1 的容器數(shù)量為16 699。

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

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

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

4.3 實例聚類分析

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

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

表8 抽樣實例特征指標的邊界Table 8 Boundaries of feature vectors for instance

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

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

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

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

4.4 各類容器和實例在每類服務器中的分布情況

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

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

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

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

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

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

（2）容器和實例進行混合部署的算法，在防止部分服務器（例如mGroup4 中的服務器）成為熱點方面，仍然有較大的改進空間。

5 相關工作

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

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

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

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

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

6 結(jié)論

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