皮艾迪，喻 劍，周笑波

(1.同濟(jì)大學(xué) 計算機(jī)科學(xué)與技術(shù)系，上海 201804； 2.嵌入式系統(tǒng)與服務(wù)計算教育部重點實驗室(同濟(jì)大學(xué))，上海 201804)

基于學(xué)習(xí)的容器環(huán)境Spark性能監(jiān)控與分析

皮艾迪1,2，喻 劍1,2，周笑波1,2*

(1.同濟(jì)大學(xué) 計算機(jī)科學(xué)與技術(shù)系，上海 201804； 2.嵌入式系統(tǒng)與服務(wù)計算教育部重點實驗室(同濟(jì)大學(xué))，上海 201804)

Spark計算框架被越來越多的企業(yè)用作大數(shù)據(jù)分析的框架，由于通常部署在分布式和云環(huán)境中因此增加了該系統(tǒng)的復(fù)雜性，對Spark框架的性能進(jìn)行監(jiān)控并查找導(dǎo)致性能下降的作業(yè)向來是非常困難的問題。針對此問題，提出并編寫了一種針對分布式容器環(huán)境中Spark性能的實時監(jiān)控與分析方法。首先，通過在Spark中植入代碼和監(jiān)控Docker容器中的API文件獲取并整合了作業(yè)運(yùn)行時資源消耗信息；然后，基于Spark作業(yè)歷史信息，訓(xùn)練了高斯混合模型(GMM)；最后，使用訓(xùn)練后的模型對Spark作業(yè)的運(yùn)行時資源消耗信息進(jìn)行分類并找出導(dǎo)致性能下降的作業(yè)。實驗結(jié)果表明，所提方法能檢測出90.2%的異常作業(yè)，且其對Spark作業(yè)性能的影響僅有4.7%。該方法能減輕查錯的工作量，幫助用戶更快地發(fā)現(xiàn)Spark的異常作業(yè)。

Spark；容器；分布式監(jiān)控系統(tǒng)；高斯混合模型；機(jī)器學(xué)習(xí)

0 引言

隨著大數(shù)據(jù)與云計算技術(shù)的發(fā)展，眾多大數(shù)據(jù)存儲、計算框架在商業(yè)界和學(xué)術(shù)界得到廣泛的應(yīng)用和研究。其中，Spark計算框架由于其具有強(qiáng)大的計算能力、分布式可拓展性和容錯能力成為新一代計算框架中研究的熱點。

然而，對部署在分布式環(huán)境中的計算框架進(jìn)行性能監(jiān)控和分析一直被視為一個非常困難的問題[1]。這是由于在分布式環(huán)境當(dāng)中，可能導(dǎo)致系統(tǒng)性能下降的因素多種多樣，例如：用戶配置不當(dāng)、硬件故障、資源分配不公平等。若將系統(tǒng)進(jìn)一步部署到云環(huán)境中，那么同一主機(jī)上運(yùn)行的其他虛擬機(jī)會進(jìn)一步對系統(tǒng)性能造成影響。

目前，國內(nèi)外的研究大致采用三種方法對系統(tǒng)進(jìn)行監(jiān)控：1)基于日志的工作流分析；2)事件因果關(guān)系追蹤；3)動態(tài)追蹤。

文獻(xiàn)[2-9]使用分析系統(tǒng)日志的方法定位系統(tǒng)中性能下降的作業(yè)。分析日志的方法能夠在很大程度上降低用戶的工作量，在系統(tǒng)故障時，也可運(yùn)用這些結(jié)果來定位和排除故障；但該方法也有下述不足，由于被分析的日志或控制臺記錄的信息需要在分析之前指定，這就導(dǎo)致了記錄的信息量與分析效率之間的權(quán)衡問題。也就是說，若應(yīng)用執(zhí)行時記錄的信息過多，會導(dǎo)致應(yīng)用程序效率下降；反之，則可能導(dǎo)致提供給分析引擎的數(shù)據(jù)不足，不能準(zhǔn)確定位故障。

文獻(xiàn)[10-20]采用事件因果關(guān)系追蹤的方法。比起基于日志分析的追蹤技術(shù)，因果關(guān)系追蹤技術(shù)在監(jiān)控系統(tǒng)時會追蹤系統(tǒng)中各事件的關(guān)系。在系統(tǒng)發(fā)生故障時，用戶最先排查到的故障原因可能只是故障的表層原因。原因追蹤技術(shù)可以追蹤導(dǎo)致故障的事物流，從而幫助用戶準(zhǔn)確定位故障的根本原因。因此使用原因追蹤技術(shù)能更準(zhǔn)確地定位故障原因。比起日志分析技術(shù)，效率更高。

文獻(xiàn)[21-23]中使用的動態(tài)追蹤方法能最大限度減少追蹤時對系統(tǒng)性能的影響。這是因為動態(tài)追蹤技術(shù)在用戶不開啟追蹤功能時，對系統(tǒng)性能的影響幾乎為零；而開啟追蹤時，用戶每一次需要追蹤的信息也往往只與系統(tǒng)中一小部分模塊有關(guān)。但在動態(tài)追蹤中，用戶對系統(tǒng)代碼有比較深入的了解，才能指定需要追蹤的系統(tǒng)模塊。這種方法不適合普通用戶。

此外，以上監(jiān)控方法都沒有與云環(huán)境相結(jié)合。云平臺已在商業(yè)上廣泛地應(yīng)用，如Microsoft Azure[24]和Amazon EC2[25]都是知名云平臺提供商，在云環(huán)境中運(yùn)行的計算框架有更好的可拓展性與可伸縮性；與此同時，云環(huán)境中計算框架的性能特點也與傳統(tǒng)物理環(huán)境中的不盡相同。因此，以上方法不能準(zhǔn)確地對云環(huán)境中的計算框架進(jìn)行監(jiān)控和分析。

對此，本文提出一種對運(yùn)行在虛擬環(huán)境中Spark[26]的性能進(jìn)行監(jiān)控的系統(tǒng)和分析的方法，并實現(xiàn)了一套監(jiān)控與分析系統(tǒng)。本文中，Spark被部署在Docker[27]虛擬化容器中以模擬云環(huán)境。Docker容器為Spark作業(yè)提供了良好的資源隔離。本監(jiān)控系統(tǒng)通過在Spark中植入代碼和讀取Docker系統(tǒng)文件，以監(jiān)控Spark作業(yè)運(yùn)行時的資源消耗情況。使用植入代碼的方式能夠更準(zhǔn)確地提供Spark的運(yùn)行時狀態(tài)信息，如正在執(zhí)行的作業(yè)、執(zhí)行階段以及資源消耗情況。由于不同類型作業(yè)對資源的消耗會呈現(xiàn)相應(yīng)的特點，本文利用這些特點，采用高斯混合模型(Gaussian Mixture Model, GMM)，對采集到的信息進(jìn)行分析，并從中找出異常信息以及其對應(yīng)的Spark作業(yè)。實驗結(jié)果表明，本監(jiān)控系統(tǒng)異常檢測的有效性為90.2%；與此同時，其對Spark性能的影響僅為4.7%。

本文方法的優(yōu)勢主要有以下兩方面：1)本文方法可對作業(yè)資源消耗情況進(jìn)行實時分析并向用戶反饋異常作業(yè)。目前許多監(jiān)控系統(tǒng)，如Ganglia[28]，可以對集群中的主機(jī)進(jìn)行實時監(jiān)控；但由于集群可被多個用戶共享，同一時間內(nèi)可能有多個作業(yè)運(yùn)行，因此該種方式不能獲取每一個作業(yè)的資源消耗情況。另外一些研究，如文獻(xiàn)[11]，可實時重建作業(yè)執(zhí)行過程中的事件流，但其工作沒有涉及對作業(yè)性能的分析與反饋。

2)本文方法將監(jiān)控與Docker容器相結(jié)合，從而更準(zhǔn)確地獲取作業(yè)每個階段的資源消耗信息。監(jiān)控軟件大多針對集群中的主機(jī)節(jié)點，即使在單用戶環(huán)境，操作系統(tǒng)中的后臺進(jìn)程也會影響監(jiān)控的準(zhǔn)確性。雖然目前已有針對Docker的監(jiān)控軟件出現(xiàn)，用戶仍然需要手動將資源消耗情況與作業(yè)各個階段相對應(yīng)。

1 相關(guān)理論

1.1 Spark框架

Spark是一個開源的通用計算框架。由于高效的計算能力、易編程性、可拓展性和良好的容錯性，Spark在越來越多的企業(yè)中得到廣泛的應(yīng)用[29]。

Spark使用彈性分布式數(shù)據(jù)集(Resilient Distributed Datasets, RDD)作為內(nèi)存存儲機(jī)制。由于數(shù)據(jù)以RDD的形式存儲在內(nèi)存當(dāng)中，Spark的計算性能比起上一代Hadoop框架提升了10倍以上，對部分迭代型作業(yè)的性能提升甚至在100倍以上。RDD也為Spark提供了良好的容錯性能，通過對父RDD的計算，一個損壞或丟失的RDD可以被快速重建。

Spark由一個負(fù)責(zé)調(diào)度作業(yè)的Master節(jié)點和多個負(fù)責(zé)執(zhí)行作業(yè)的Worker節(jié)點組成。每個Worker節(jié)點可根據(jù)自身資源數(shù)量啟動一定數(shù)量的Executor。Executor是Spark中分配資源和執(zhí)行任務(wù)的單位。其使用的資源數(shù)量，如CPU個數(shù)和內(nèi)存用量，可由用戶指定。Spark可使用YARN作為底層的資源調(diào)度器。Spark on YARN的整體構(gòu)架如圖1所示。

圖1 Spark架構(gòu)Fig. 1 Architecture of Spark

1.2 Docker容器及優(yōu)點

Docker是一個開源的Linux軟件容器，能提供輕量級的虛擬化環(huán)境。Docker使用cgroup技術(shù)，能對單個操作系統(tǒng)上進(jìn)程間的CPU、內(nèi)存、網(wǎng)絡(luò)流量、文件系統(tǒng)等進(jìn)行隔離。相比于傳統(tǒng)虛擬化技術(shù)，Docker的優(yōu)勢如下：1)Docker不需要Hypervisor，直接運(yùn)行在操作系統(tǒng)之上，能在數(shù)秒之內(nèi)啟動。2)Docker在為軟件提供資源隔離的同時，自身基本不消耗系統(tǒng)資源。同一物理主機(jī)上能同時運(yùn)行的Docker實例可達(dá)上千個，極大提高了系統(tǒng)資源的利用率。3)Docker中可集成軟件運(yùn)行時需要的所有依賴庫，實現(xiàn)了軟件的“一次配置，多地運(yùn)行”，增強(qiáng)了軟件的可移植性。

在本文中，Spark的Executor運(yùn)行在Docker容器中。Docker為每個Executor分配資源，并為Executor與其他系統(tǒng)進(jìn)程之間實現(xiàn)資源隔離。由于Executor運(yùn)行時的網(wǎng)絡(luò)流量和磁盤讀寫率不能從Spark內(nèi)部獲取，本監(jiān)控系統(tǒng)通過監(jiān)控Docker的API文件，以獲取這些性能指標(biāo)。

1.3 高斯混合模型及EM求解算法

同一Spark作業(yè)在集群中多次執(zhí)行，正常情況下其具有相似的資源消耗特征。例如，k-means作業(yè)會占用大量CPU資源和少量網(wǎng)絡(luò)I/O資源。但由于Spark作業(yè)在不同配置的集群中資源消耗情況不相同，用戶不能將同一套分析參數(shù)應(yīng)用于不同的集群。即使在同一集群中，用戶也很難對大量作業(yè)的資源消耗情況進(jìn)行量化，從而進(jìn)一步標(biāo)記分類。此外，若要實現(xiàn)在線異常檢測，則要求算法的實時性。為滿足以上需求，選用高斯混合模型(GMM)作為異常檢測方法。高斯混合模型能適應(yīng)不同集群，根據(jù)歷史作業(yè)自動訓(xùn)練參數(shù)；并且，訓(xùn)練后的高斯混合模型能夠在O(n)時間內(nèi)將作業(yè)分類以檢測異常。

高斯混合模型是機(jī)器學(xué)習(xí)中常用的非監(jiān)督學(xué)習(xí)算法。它使用多個高斯概率密度函數(shù)來描述變量分布，不僅能將變量分類，還能計算出變量屬于每一個類別的概率。對于觀察樣本X={x1,x2,…,xN}和由K個高斯概率密度函數(shù)組成的高斯混合模型，每個高斯概率密度函數(shù)稱為一個組件(component)。樣本xi(1≤i≤N) 是D維向量，它屬于第j個組件的概率為：

(1)

其中，μj與Σj分別為第j個組件的期望向量與協(xié)方差矩陣。

高斯混合模型需要優(yōu)化的對數(shù)似然函數(shù)表示為：

(2)

使用EM算法可求出高斯混合模型的參數(shù)。EM算法的求解過程如下：

根據(jù)先驗知識，初始化每個組件的期望μj和協(xié)方差矩陣Σj。然后重復(fù)以下E-步和M-步，直到式(2)收斂：

E-步：

M-步：

πj=Nj/N

在EM算法中，E-步估算數(shù)據(jù)由每個組件生成的概率，M-步利用E-步的結(jié)果，估算每個高斯分布函數(shù)的參數(shù)值。每次E-步和M-步迭代完成后，利用M-步的結(jié)果，可重新計算對數(shù)似然函數(shù)式(2)。

不同Spark作業(yè)的資源消耗情況雖然不盡相同，但各自也具有一定的特點，如CPU密集型作業(yè)和I/O密集型作業(yè)。利用高斯混合模型，可根據(jù)Spark作業(yè)的資源消耗情況將其分類。由于高斯混合模型中包含樣本屬于每一個分類的概率，異常的Spark作業(yè)可以通過設(shè)置閾值檢測到。

2 監(jiān)控系統(tǒng)設(shè)計

在本文方法中，通過在Spark的Executor模塊植入代碼和讀取Docker文件，實現(xiàn)了對Spark的運(yùn)行時信息的監(jiān)控。使用植入代碼的方式，可以高效準(zhǔn)確地從Spark內(nèi)部獲取到其運(yùn)行時信息，如作業(yè)、階段的開始和結(jié)束時間等。獲取到的Spark和Docker監(jiān)控信息被傳遞給監(jiān)控系統(tǒng)，由監(jiān)控系統(tǒng)進(jìn)行整合并存儲到數(shù)據(jù)庫。監(jiān)控系統(tǒng)通過使用Spark歷史作業(yè)信息訓(xùn)練高斯混合模型。當(dāng)新作業(yè)提交時，監(jiān)控系統(tǒng)會在作業(yè)運(yùn)行的同時分析作業(yè)的性能指標(biāo)，并向用戶報告運(yùn)行異常的作業(yè)。本文監(jiān)控系統(tǒng)的架構(gòu)如圖2所示，其中灰色部分為本文的主要工作。①用戶首先提交作業(yè)到Spark Master節(jié)點；②Master節(jié)點向運(yùn)行在Work節(jié)點上的Executor分配任務(wù)；③植入在Executor中的監(jiān)控管理器向監(jiān)控系統(tǒng)注冊任務(wù)并實時報告任務(wù)資源使用情況；④Docker監(jiān)控器收集并報告Docker資源使用情況；⑤整合后的信息整存儲到數(shù)據(jù)庫；⑥整合后的信息送到數(shù)據(jù)分析模塊；⑦分析模塊向用戶反饋異常的作業(yè)和階段。

圖2 監(jiān)控系統(tǒng)架構(gòu)Fig. 2 Architecture of the monitoring system

2.1 Spark代碼植入

在Spark中植入代碼時，必須權(quán)衡代碼抓取信息的能力和其對Spark性能的影響。具體來說，若植入的代碼不足，則不能抓取到足夠的Spark運(yùn)行時信息；反之，則可能導(dǎo)致Spark運(yùn)行性能下降。4.3節(jié)的實驗結(jié)果說明植入代碼和監(jiān)控系統(tǒng)對Spark作業(yè)的影響在合理范圍以內(nèi)。

Spark的Executor維護(hù)一個線程池，其中的所有任務(wù)都執(zhí)行在這個線程池中，每個任務(wù)占用一個線程。通過累加Executor中所有任務(wù)線程的CPU使用率，可以計算出該Executor此時的CPU用量的總和。

Spark任務(wù)的內(nèi)存由存儲內(nèi)存(storage memory)和執(zhí)行內(nèi)存(execution memory)兩部分組成。其中，存儲內(nèi)存是指任務(wù)的輸入數(shù)據(jù)占用的內(nèi)存。植入的代碼通過監(jiān)控該輸入數(shù)據(jù)對象的大小以獲取存儲內(nèi)存。另一方面，執(zhí)行內(nèi)存是指任務(wù)執(zhí)行過程中，洗牌(shuffle)、聚合(aggregate)和連接(join)操作產(chǎn)生的中間數(shù)據(jù)結(jié)構(gòu)占用的內(nèi)存。Spark內(nèi)部維護(hù)了一個記錄當(dāng)前執(zhí)行內(nèi)存消耗情況的數(shù)據(jù)結(jié)構(gòu)。通過讀取解析該數(shù)據(jù)結(jié)構(gòu)，可以實時獲取Spark的執(zhí)行內(nèi)存用量。

本監(jiān)控系統(tǒng)中，向Spark框架內(nèi)部新加入一個監(jiān)控管理器模塊(TracingManager)，以獲取Spark內(nèi)部運(yùn)行時信息。監(jiān)控管理器的主要功能包括向監(jiān)控系統(tǒng)：1)注冊任務(wù)；2)注銷任務(wù)；3)周期性報告任務(wù)CPU使用率：4)周期性報告任務(wù)內(nèi)存使用量。監(jiān)控管理器周期性報告的時間間隔為τ，且可由用戶指定。由于任務(wù)網(wǎng)絡(luò)傳輸速率和磁盤讀寫速率不能從Spark內(nèi)部準(zhǔn)確地獲取，本文將在2.2節(jié)中介紹從Docker中獲取這兩種信息的方法。在Spark中植入的主要方法及其功能如表1所示。

表1 植入代碼的主要方法及說明Tab. 1 Main methods and explanations of embedding codes

2.2 獲取Docker信息

Spark作業(yè)啟動時的同時，會向監(jiān)控系統(tǒng)注冊，注冊的信息包括作業(yè)啟動時間和使用Docker的標(biāo)識。本監(jiān)控系統(tǒng)通過該標(biāo)識在操作系統(tǒng)中定位Docker容器，并啟動一個Docker監(jiān)控器(DockerMonitor)。Docker監(jiān)控器周期性讀取Docker的API文件以獲取在其中運(yùn)行的Executor的網(wǎng)絡(luò)流量和磁盤使用率。

Docker關(guān)于網(wǎng)絡(luò)流量和磁盤讀寫的API文件中分別存儲Docker自啟動以來網(wǎng)絡(luò)流量和磁盤讀寫量的總和，若要獲取網(wǎng)絡(luò)傳輸率和磁盤讀寫速率則需要進(jìn)一步計算。本監(jiān)控系統(tǒng)使用以下公式計算Docker在某一時刻t的網(wǎng)絡(luò)傳輸(或接收)速率：

Net_Rate=(Total_Trafict-Total_Trafict-τ)/τ

類似地，磁盤讀取(或?qū)懭?速率用以下公式計算：

Disk_Rate=(Total_Bytet-Total_Bytet-τ)/τ

其中：τ為監(jiān)控系統(tǒng)每次讀取API文件的時間間隔；Total_Trafict和Total_Bytet分別表示Docker自啟動到時刻t，網(wǎng)絡(luò)傳輸(或接收)和與磁盤讀取(或?qū)懭?字節(jié)數(shù)總和。

2.3 信息整合與存儲

為了獲取作業(yè)階段在某一時刻對所有資源的使用情況，本監(jiān)控系統(tǒng)需要整合來自植入代碼和Docker監(jiān)控器的信息。植入代碼和Docker監(jiān)控器獲取的信息中除包含資源用量外，還有該條信息抓取時的時間戳和階段標(biāo)識。例如，任務(wù)job_i的第j個階段stage_j在時刻t的CPU使用量為v，這條信息可表示為三元組[job_i.stage_j,v,t]。利用任務(wù)標(biāo)識，可以唯一確定階段從屬的作業(yè)。經(jīng)過整合之后，作業(yè)在時刻t對所有類型資源的使用情況表示為一個6維資源消耗向量：

M=(m1,m2,m3,m4,m5,m6)

其中:m1為CPU使用率；m2為內(nèi)存用量；m3為磁盤讀取速率；m4為磁盤寫入速率；m5為網(wǎng)絡(luò)接收速率；m6為網(wǎng)絡(luò)傳輸速率。

為了能重復(fù)使用監(jiān)控信息，需要將監(jiān)控信息持久化。本監(jiān)控系統(tǒng)使用Graphite[30]作為后臺數(shù)據(jù)庫。Graphite數(shù)據(jù)庫適用于存儲帶時間戳的數(shù)字信息，其每條數(shù)據(jù)由三元組[標(biāo)識，數(shù)據(jù)的值，時間戳]組成，因此本監(jiān)控系統(tǒng)可將整合后的信息三元組直接存儲到數(shù)據(jù)庫中。

2.4 模型訓(xùn)練

在2.2節(jié)和2.3節(jié)中抓取的原始數(shù)據(jù)包含噪聲，并且資源消耗向量各維度的量綱不同，需要對數(shù)據(jù)進(jìn)行預(yù)處理。在數(shù)據(jù)分析模塊檢測異常作業(yè)之前，還需要訓(xùn)練高斯混合模型。

2.4.1 數(shù)據(jù)預(yù)處理

經(jīng)過察看發(fā)現(xiàn)，作業(yè)的每個階段剛啟動時很短一段時間內(nèi)，其資源消耗向量中的每一項值都為0。這是由于作業(yè)階段從向監(jiān)控系統(tǒng)注冊到真正啟動執(zhí)行需要一段準(zhǔn)備時間。在數(shù)據(jù)預(yù)處理時，需要去除這些全零向量，以降低噪聲的干擾。

由于資源消耗向量各維度的量綱不同，為了使訓(xùn)練的結(jié)果更準(zhǔn)確，需要將數(shù)據(jù)標(biāo)準(zhǔn)化。本文選用離差標(biāo)準(zhǔn)化的方法，經(jīng)過標(biāo)準(zhǔn)化后的樣本值都被映射到[0,1]。在資源消耗向量中，CPU使用率本身已在[0,1]，而其他5項都需要進(jìn)行標(biāo)準(zhǔn)化處理。離差標(biāo)準(zhǔn)化公式如下：

x*=(x-μ)/(xmax-xmin)

其中：x和x*分別為標(biāo)準(zhǔn)化前后的樣本值；μ為樣本方差；xmin和xmin分別為樣本中的最大值和最小值。

2.4.2 參數(shù)訓(xùn)練

在訓(xùn)練參數(shù)和檢測異常階段，本文都以主機(jī)節(jié)點作為單位，也就是說——經(jīng)過訓(xùn)練以后，每一臺主機(jī)節(jié)點擁有各自獨(dú)立的模型參數(shù)，并只檢查在該節(jié)點上運(yùn)行的作業(yè)。當(dāng)Spark部署在異構(gòu)集群中(heterogeneous cluster)中時，不同硬件配置的主機(jī)節(jié)點會對作業(yè)的性能和資源消耗情況造成不同的影響。因此，不能使用同一套參數(shù)來檢測不同主機(jī)節(jié)點上的作業(yè)。各節(jié)點擁有各自獨(dú)立的模型參數(shù)使監(jiān)控系統(tǒng)能很好地夠適應(yīng)異構(gòu)集群環(huán)境。

利用來自作業(yè)的歷史數(shù)據(jù)，在參數(shù)訓(xùn)練階段EM算法會建立K個高斯分類的參數(shù)，每個分類代表具有某種特征的作業(yè)階段。由于EM算法對參數(shù)初值敏感，訓(xùn)練模型的過程中需要使用不同初始參數(shù)值進(jìn)行多次訓(xùn)練，最后取使1.3節(jié)中式(2)最大的訓(xùn)練結(jié)果作為模型參數(shù)。通過實驗發(fā)現(xiàn)，K=4時，監(jiān)控系統(tǒng)可以在有效監(jiān)測異常作業(yè)的同時兼顧Spark作業(yè)的運(yùn)行性能。

2.5 異常檢測

Spark作業(yè)內(nèi)部的不同階段對資源消耗的情況不盡相同。例如，作業(yè)的第一個階段通常會從磁盤讀取數(shù)據(jù)，從而造成很大的磁盤I/O開銷；而中間階段通常會在節(jié)點間傳輸數(shù)據(jù)，從而造成網(wǎng)絡(luò)I/O開銷。因此，本監(jiān)控系統(tǒng)以作業(yè)階段作為異常檢測的單位。

定義1 異常階段是指在一段時間T內(nèi)，有αT/τ條作業(yè)性能消耗向量屬于每個分類的概率都不超過σ的階段。其中：τ為抓取數(shù)據(jù)的時間間隔；α和σ均為實驗測出的閾值，0 ≤α,σ≤ 1。

定義1中規(guī)定，只有當(dāng)作業(yè)階段中長時間出現(xiàn)不能分類的性能消耗向量時，才將該作業(yè)階段劃分為異常作業(yè)。這避免了系統(tǒng)資源短時間波動引起的誤判。

監(jiān)控系統(tǒng)會在Spark作業(yè)運(yùn)行的同時將檢測到的異常作業(yè)階段反饋給用戶。

3 系統(tǒng)實現(xiàn)

本監(jiān)控系統(tǒng)由植入Spark的代碼和外部守護(hù)進(jìn)程兩部分組成。在Spark中植入了約500行Java代碼和約100行Scala代碼，植入代碼包括修改后的Executor和新加入的監(jiān)控管理器模塊(TracingManager)。修改后的Executor在任務(wù)啟動和完成時向監(jiān)控管理器報告；監(jiān)控管理器利用Java提供的API獲取Spark作業(yè)的CPU使用率和輸入數(shù)據(jù)對象大小，并與外部守護(hù)進(jìn)程通信。

守護(hù)進(jìn)程用大約3 600行Java代碼編寫。守護(hù)進(jìn)程的主要功能包括：1)記錄正在運(yùn)行的Spark作業(yè)；2)實時獲取Docker資源用量；3)實時分析資源用量并報告異常作業(yè)；4)將數(shù)據(jù)存儲到數(shù)據(jù)庫。植入代碼和守護(hù)進(jìn)程間使用Apache Thrift[31]協(xié)議通信。本文選用Graphite作為后臺數(shù)據(jù)庫。Graphite作為企業(yè)級時間序列數(shù)據(jù)庫，適用于存儲帶時間戳的監(jiān)控數(shù)據(jù)。

4 實驗結(jié)果與分析

本文針對監(jiān)控系統(tǒng)對Spark性能的影響和異常檢測的有效性設(shè)計了兩組實驗，并與其他監(jiān)控分析工具進(jìn)行對比。

在性能分析實驗中，部分其他工具采用離線分析模式(即當(dāng)作業(yè)完成之后，工具再對作業(yè)日志進(jìn)行分析)，無法獲取其對作業(yè)性能的直接影響；因此，該實驗選取Whodunit[10]、Gist[18]和Stitch[8]等在線監(jiān)控工具進(jìn)行對比。

在有效性分析實驗中，部分其他工具僅僅向用戶反饋帶時間戳的事件流，而異常檢測需要由用戶完成，因此該實驗選取可反饋異常信息的工具Iprof[7]進(jìn)行對比。由于Iprof是離線分析工具，本文不比較其對作業(yè)性能的影響。

4.1 實驗環(huán)境

為了測試監(jiān)控系統(tǒng)的性能，本文用9臺小型服務(wù)器搭建了Spark on YARN分布式環(huán)境，1臺作為Master節(jié)點，8臺作為Worker節(jié)點。9臺服務(wù)器的配置均為Intel Core i7- 2600 @ 3.4 GHz 8核CPU、8 GB內(nèi)存、500 GB/7 200 rpm；服務(wù)器間用千兆網(wǎng)絡(luò)連接。操作系統(tǒng)版本為Ubuntu Server 16.04?；赟park-2.1.0版本植入代碼，使用cluster模式運(yùn)行在hadoop-2.7.3版本上。Docker鏡像版本為sequenceiq/hadoop-docker-2.4.0。Graphite數(shù)據(jù)庫版本為0.10，部署在Master節(jié)點上。

測試數(shù)據(jù)選用標(biāo)準(zhǔn)測試集HiBench-6.0[32]的5個作業(yè)：wordcount、terasort、k-means、baye和pagerank，每個作業(yè)數(shù)據(jù)量及說明如表2所示。

表2 測試數(shù)據(jù)的作業(yè)名稱、數(shù)據(jù)量及說明Tab. 2 Name, data volume and description of jobs for test

4.2 性能分析

監(jiān)控系統(tǒng)對Spark性能的影響應(yīng)在合理范圍以內(nèi)，以保證Spark作業(yè)正常運(yùn)行。為此，本文對比了Spark單獨(dú)運(yùn)行和Spark與監(jiān)控系統(tǒng)同時運(yùn)行時的性能，實驗結(jié)果如圖3所示。實驗表明，監(jiān)控系統(tǒng)僅使作業(yè)的執(zhí)行時間增加了平均4.7%。對于非CPU密集型作業(yè)，如wordcount和terasort，監(jiān)控系統(tǒng)對作業(yè)性能的影響不到5%。本文方法與其他監(jiān)控系統(tǒng)對作業(yè)性能影響的對比如表3所示。由表3可以看出，本文方法對作業(yè)性能的影響與Whodunit和Gist大致相當(dāng)，且優(yōu)于Stitch。

圖3 Spark單獨(dú)運(yùn)行和與監(jiān)控系統(tǒng)同時運(yùn)行性能對比Fig. 3 Performance comparison of Spark-alone and Spark with monitoring system

4.3 有效性分析

為了檢驗監(jiān)控系統(tǒng)對異常作業(yè)的檢測的有效性，在有其他作業(yè)干擾的情況下運(yùn)行HiBench Spark測試作業(yè)集，并將結(jié)果與Iprof[7]對比。本文規(guī)定，一個作業(yè)階段的執(zhí)行時間若比無干擾時慢20%或以上則為異常作業(yè)階段。干擾作業(yè)來自HiBench的Hadoop MapReduce測試作業(yè)集，在Spark作業(yè)運(yùn)行的同時隨機(jī)選取執(zhí)行。

實驗中，每個Spark作業(yè)在有干擾的情況下重復(fù)多次執(zhí)行。首先人工檢測Spark作業(yè)的異常階段，然后與監(jiān)控系統(tǒng)反饋的異常階段對比，以驗證監(jiān)控系統(tǒng)的有效性。在2.5節(jié)中，本文給出了異常作業(yè)的定義。經(jīng)過實驗發(fā)現(xiàn)，定義中的閾值取α=0.6、σ=0.4時，監(jiān)控系統(tǒng)可以較好地檢測出異常作業(yè)階段。表4為有效性測試的實驗結(jié)果。從表4中可看出，監(jiān)控系統(tǒng)對異常階段檢測的整體有效率為90.2%。本文監(jiān)控系統(tǒng)與Iprof異常檢測有效性分別為90.2%、73.0%。

表3 不同系統(tǒng)對作業(yè)性能影響的對比Tab. 3 Comparison of effects of different systems on job performance

表4 監(jiān)控系統(tǒng)檢測異常階段的有效性Tab. 4 Effectiveness of detecting abnormal phase of monitoring system

5 結(jié)語

本文針對分布式系統(tǒng)性能監(jiān)控及診斷困難的問題，提出并編寫了一套用于Spark作業(yè)性能監(jiān)控與分析的系統(tǒng)。該系統(tǒng)基于高斯混合模型，能夠?qū)崟r監(jiān)控Spark作業(yè)的資源消耗情況，并向用戶反饋性能受到干擾的作業(yè)。隨后，用戶可采取進(jìn)一步的措施以調(diào)整Spark作業(yè)，使其恢復(fù)正常運(yùn)行。實驗結(jié)果表明該系統(tǒng)在有效檢測異常作業(yè)的同時對作業(yè)性能造成的影響很小。

進(jìn)一步的研究可從以下三個方向展開：1)優(yōu)化異常檢測算法，使其具有更強(qiáng)的自動檢測能力；2)進(jìn)一步分析并找出使作業(yè)性能下降的瓶頸資源；3)利用資源消耗信息進(jìn)行作業(yè)調(diào)度，最大化利用集群資源。

References)

[1] SAMBASIVAN R R, SHAFER I, SIGELMAN B H, et al. Principled workflow-centric tracing of distributed systems [C]// SoCC 2016: Proceeding of the 2016 Seventh ACM symposium on Cloud Computing. New York: ACM, 2016: 401-414.

[2] KAVULYA S P, DANIELS S, JOSHI K, et al. Draco: statistical diagnosis of chronic problems in large distributed systems [C]// DSN 2012: Proceedings of the 2012 42nd Annual IEEE/IFIP International Conference on Dependable System and Networks. Washington, DC: IEEE Computer Society, 2012: 1-12.

[3] SAMBASIVAN R R, ZHENG A X, DE ROSA M, et al. Diagnosing performance changes by comparing request flows [C]// NSDI’11: Proceeding of the 2011 8th USENIX Conference on Networked Systems Design and Implementation. Berkeley, CA: USENIX Association, 2011: 43-56.

[4] NAGARAJ K, KILLIAN C, NEVILLE J. Structured comparative analysis of systems logs to diagnose performance problems [C]// NSDI 2012: Proceedings of the 2012 9th USENIX Conference on Networked Systems Design and Implementation. Berkeley, CA: USENIX Association, 2012: 353-366.

[5] OLINER A J, KULKARNI A V, AIKEN A. Using correlated surprise to infer shared influence [C]// DSN 2010: Proceedings of the 2010 IEEE/IFIP International Conference on Dependable Systems and Networks. Piscataway, NJ: IEEE, 2010: 191-200.

[6] XU W, HUANG L, FOX A, et al. Detecting large-scale system problems by mining console logs [C]// SOSP’09: Proceedings of the 2009 ACM SIGOPS 22nd Symposium on Operating Systems. New York: ACM, 2009: 117-132.

[7] ZHAO X, ZHANG Y, LION D, et al. Iprof: a non-intrusive request flow profiler for distributed systems [C]// OSDI 2014: Proceedings of the 2014 11th USENIX Conference on Operating Systems Design and Implementation. Berkeley, CA: USENIX Association, 2014: 629-644.

[8] ZHAO X, RODRIGUES K, LUO Y, et al. Non-intrusive performance profiling for entire software stacks based on the flow reconstruction principle [C]// OSDI 2016: Proceedings of the 2016 12th USENIX Symposium on Operating System Design and Implementation. Berkeley, CA: USENIX Association, 2016: 603-618.

[9] 劉海寶,蔡皖東,許俊杰,等.分布式網(wǎng)絡(luò)行為監(jiān)控系統(tǒng)設(shè)計與實現(xiàn)[J].微電子學(xué)與計算機(jī),2006,23(3):76-79. (LIU H B, CAI W D, XU J J, et al. Design and implement of distributed network behavior monitoring system [J]. Microelectronics & Computer, 2006, 23(3): 76-79.)

[10] CHANDA A, COX A L, ZWAENEPOEL W. Whodunit: transactional profiling for multi-tier applications [C]// EuroSys 2007: Proceedings of the 2007 2nd ACM SIGOPS/EuroSys European Conference on Computer Systems. New York: ACM, 2007: 17-30.

[11] BARHAM P, DONNELLY A, ISAACS R, et al. Using magpie for request extraction and workload modelling [C]// OSDI 2004: Proceedings of the 2004 6th USENIX Symposium on Operating Systems Design and Implementation. Berkeley, CA: USENIX Association, 2004: 259-272.

[12] CHEN M Y, ACCARDI A, KICIMAN E, et al. Path-based failure and evolution management [C]// NSDI 2004: Proceedings of the 1st USENIX Conference on Networked Systems Design and Implementation. Berkeley, CA: USENIX Association, 2004: 23-36.

[13] REYNOLDS P, KILLIAN C E, WIENER J L, et al. Pip: detecting the unexpected in distributed systems [C]// NSDI 2006: Proceedings of the 2006 3rd USENIX Conference on Networked Systems Design and Implementation. Berkeley, CA: USENIX Association, 2006: 115-128.

[14] THERESKA E, SALMON B, STRUNK J, et al. Stardust: tracking activity in a distributed storage system [C]// Proceedings of the 2006 Joint International Conference on Measurement and Modeling of Computer Systems. New York: ACM, 2006: 3-14.

[15] FONSECA R, PORTER G, KATZ R H, et al. X-trace: a pervasive network tracing framework [C]// NSDI 2007: Proceedings of the 2007 4th USENIX Conference on Networked Systems Design and Implementation. Berkeley, CA: USENIX Association, 2007: 20-33.

[16] MACE J, BODIK P, FONSECA R, et al. Retro: targeted resource management in multi-tenant distributed systems [C]// NSDI 2015: Proceedings of the 2015 12th USENIX Conference on Networked Systems Design and Implementation. Berkeley, CA: USENIX Association, 2015: 589-603.

[17] SIGELMAN B H, BARROSO L A, BURROWS M, et al. Dapper, a large-scale distributed systems tracing infrastructure, GoogleTechnical Report dapper- 2010- 1 [R]. Mountain View: Google, 2010: 29.

[18] KASIKCI B, SCHUBERT B, PEREIRA C, et al. Failure sketching: a technique for automated root cause diagnosis of in-production failures [C]// SOSP 2015: Proceeding of the 25th ACM Symposium on Operating Systems Principles. New York: ACM, 2015:344-360.

[19] 樓樺.服務(wù)器監(jiān)控系統(tǒng)的實現(xiàn)[D].鄭州: 鄭州大學(xué),2004:25-28.(LOU H. Implementation of server’s monitoring system [D]. Zhengzhou: Zhengzhou University, 2004: 25-28.)

[20] 和榮,肖海力.基于Nagios的監(jiān)控平臺的設(shè)計與實現(xiàn)[J].科研信息化技術(shù)與應(yīng)用,2014,5(5):77-85.(HE R, XIAO H L. A monitor platform based on Nagios [J]. E-Science Technology & Application, 2014, 5(5): 77-85.)

[21] CANTRILL B M, SHAPIRO M W, LEVENTHAL A H. Dynamic instrumentation of production systems [C]// USENIX 2004: Proceedings of the 2004 USENIX Annual Technical Conference. Berkeley, CA: USENIX Association, 2004: 15-28.

[22] ERLINGSSON U, PEINADO M, PETER S, et al. Fay: extensible distributed tracing from kernels to clusters[J]. ACM Transactions on Computer Systems, 2012, 30(4): Article No. 13.

[23] MACE J, ROELKE R, FONSECA R. Pivot tracing: dynamic causal monitoring for distributed systems [C]// SOSP 2015: Proceedings of the 2015 25th Symposium on Operating Systems Principles. New York: ACM, 2015: 378-393.

[24] Microsoft. Microsoft azure: cloud computing platform & services [EB/OL]. [2017- 04- 15]. https://azure.microsoft.com/en-us/?v=17.14.

[25] Amazon Web Service, Inc. Elastic Compute Cloud (EC2) — cloud server & hosting — AWS [EB/OL]. [2017- 04- 15]. https://aws.amazon.com/ec2/.

[26] Apache. Apache Spark: lightning-fast cluster computing [EB/OL]. [2017- 04- 15]. https://spark.apache.org/.

[27] Docker, Inc. Docker — Build, ship, and run [EB/OL]. [2017- 04- 15]. https://www.docker.com/.

[28] Ganglia. Ganglia monitoring system [EB/OL]. [2017- 04- 15]. http://ganglia.sourceforge.net/.

[29] YAN Y, GAO Y, CHEN Y, et al. TR-Spark: transient computing for big data analytics [C]// SoCC 2016: Proceeding of the 2016 Seventh ACM Symposium on Cloud Computing. New York: ACM, 2016: 484-496.

[30] Graphite. Graphite documentation [DB/OL]. [2017- 03- 14]. https://graphite.readthedocs.io/.

[31] Apache. Apache thrift — home [EB/OL]. [2017- 02- 17]. https://thrift.apache.org/.

[32] GitHub, Inc. Intel — Hadoop/Hibench [EB/OL]. [2017- 03- 30]. https://github.com/intel-hadoop/HiBench/.

PIAidi, born in 1993, M. S. candidate. His research interests include big data processing, cloud computing.

YUJian, born in 1975, Ph. D., lecturer. His research interests include Internet of things, big data processing.

ZHOUXiaobo, born in 1973, Ph. D., professor. His research interests include cloud computing, big data parallel processing, distributed system, data center.

Learning-basedperformancemonitoringandanalysisforSparkincontainerenvironments

PI Aidi1,2, YU Jian1,2, ZHOU Xiaobo1,2*

(1.DepartmentofComputerScienceandTechnology,TongjiUniversity,Shanghai201804,China;2.KeyLaboratoryofEmbeddedSystemandServiceComputing,MinistryofEducation(TongjiUniversity),Shanghai201804,China)

The Spark computing framework has been adopted as the framework for big data analysis by an increasing number of enterprises. However, the complexity of the system is increased due to the characteristic that it is typically deployed in distributed and cloud environments. Therefore, it is always considered to be difficult to monitor the performance of the Spark framework and finding jobs that lead to performance degradation. In order to solve this problem, a real-time monitoring and analysis method for Spark performance in distributed container environment was proposed and compiled. Firstly, the resource consumption information of jobs at runtime was acquired and integrated through the implantation of code in Spark and monitoring of Application Program Interface (API) files in Docker containers. Then, the Gaussian Mixture Model (GMM) was trained based on job history information of Spark. Finally, the trained model was used to classify the resource consumption information of Spark jobs at runtime and find jobs that led to performance degradation. The experimental results show that, the proposed method can detect 90.2% of the abnormal jobs and it only introduces 4.7% degradation to the performance of Spark jobs. The proposde method can lighten the burden of error checking and help users find the abnormal jobs of Spark in a shorter time.

Spark; container; distributed monitoring system; Gaussian Mixture Model (GMM); machine learning

2017- 05- 16;

2017- 07- 14。

皮艾迪(1993—)，男，上海人，碩士研究生，主要研究方向：大數(shù)據(jù)處理、云計算； 喻劍(1975—)，男，浙江義烏人，講師，博士，主要研究方向：物聯(lián)網(wǎng)、大數(shù)據(jù)處理； 周笑波(1973—)，男，浙江臺州人，教授，博士生導(dǎo)師，博士，主要研究方向：云計算、大數(shù)據(jù)并行處理、分布式系統(tǒng)、數(shù)據(jù)中心。

1001- 9081(2017)12- 3586- 06

10.11772/j.issn.1001- 9081.2017.12.3586

(*通信作者電子郵箱xzhou@#edu.cn)

TP393.06; TP18

A