潘偉博， 汪海濤， 姜 瑛， 陳 星， 田 帥

(昆明理工大學 信息工程與自動化學院， 云南 昆明 650500)

Hadoop[1]是一種分布式系統(tǒng)平臺，可以有效地劃分大規(guī)模數(shù)據(jù)，以并行方式均勻地映射和分發(fā)任務，目前已經(jīng)被廣泛應用于大數(shù)據(jù)與云計算等領域[2]。但隨著Hadoop集群節(jié)點數(shù)量的增加，集群以及節(jié)點在管理和維護方面的困難也不斷增加。當Hadoop集群中某些節(jié)點發(fā)生異常時，會導致集群整體作業(yè)性能降低，但用戶很難檢測和識別導致節(jié)點異常的原因。首先，Hadoop日志數(shù)據(jù)難以讀取且不規(guī)則，并且沒有直接的方法來判斷節(jié)點是否發(fā)生異常；其次，發(fā)生異常時日志數(shù)據(jù)中關于節(jié)點錯誤的信息很少。因此，及時發(fā)現(xiàn)異常節(jié)點并診斷原因是至關重要的。

在早期的研究中，通常使用離線檢測技術分析歷史數(shù)據(jù)來診斷Hadoop集群中的異常節(jié)點[3-4]。Pan等[5]提出了一種基于體系結構層性能指標分析的方法，通過Ganesha工具檢測Hadoop集群中的異常節(jié)點。Guo等[6]提出了一種針對Hadoop集群日志數(shù)據(jù)進行自動化分析方法，通過提取分布式系統(tǒng)執(zhí)行控制流和數(shù)據(jù)流的狀態(tài)進行初步節(jié)點異常檢測。Tang等[7]提出了一種Hadoop集群異常檢測視圖工具，從時間、空間與性能度量三個性能指標分析Hadoop集群中可能出現(xiàn)的問題。隨著集群節(jié)點數(shù)量的不斷增加，實時檢測異常節(jié)點變得越來越重要。Manjunatha等[8]基于Spark框架提出了一種混合分層算法，通過學習每個備份端點的特征，自動地選擇一組異常值進行檢測。Fathnia等[9]提出了一種輕量級異常檢測工具，結合日志信息分析和系統(tǒng)指標檢測異常節(jié)點。Habeeb等[10]提出了一種適用于大規(guī)模在線數(shù)據(jù)流的異常檢測策略，進行異常節(jié)點檢測。但此類方法需要在實時監(jiān)控之前訓練數(shù)據(jù)，訓練過程不僅耗時，而且訓練得到的閾值會隨著Hadoop集群規(guī)模的增大或者減小而失效。

針對上述問題，本文提出了一種Hadoop集群異常節(jié)點實時檢測與診斷算法，檢測Hadoop集群中的異常節(jié)點，并診斷導致節(jié)點發(fā)生異常的根本原因。

1 原理及方法

1.1 算法概述

本文提出的算法分為異常節(jié)點檢測與診斷節(jié)點異常根本原因兩個階段，整體架構如圖1所示。首先基于正常狀態(tài)下各節(jié)點性能相似性原理[11]，使用Logstash工具收集Hadoop集群節(jié)點運行日志中的任務狀態(tài)信息，同時將reduce任務個數(shù)換為map任務個數(shù)，使用異常節(jié)點檢測算法捕獲異常節(jié)點。發(fā)現(xiàn)異常節(jié)點后，利用Perf性能分析工具收集體系結構性能信息，再通過異常節(jié)點診斷算法診斷導致該節(jié)點異常的原因。

圖1 Hadoop集群異常節(jié)點實時 檢測與診斷算法整體框架

1.2 數(shù)據(jù)獲取

YARN是Hadoop集群資源管理器，將資源管理與任務調(diào)度監(jiān)控拆分為單獨的守護進程，并且YARN擁有一個全局資源管理器和每個應用程序管理器。容器是YARN對資源的抽象，并且封裝了節(jié)點上的大量資源。在Hadoop 2.0之后，基于YARN的應用程序管理器作為一個編號為000001的任務在容器中運行，可以將其視為具有所有者日志的特殊任務，該任務類似于map任務和reduce任務。容器中的syslog文件實時記錄著Hadoop任務的運行狀態(tài)，分別記錄分配map任務的類別、時間、任務編號與運行節(jié)點等信息。通過分析收集到的日志數(shù)據(jù)，就可以獲得當前Hadoop集群的運行狀態(tài)，并利用正常狀態(tài)下節(jié)點之間的行為相似性來檢測異常。為了分析導致節(jié)點發(fā)生異常的原因，本文定義了3種基于體系結構層的性能指標，分別是CPU使用率、內(nèi)存使用率與I/O負載。通過定期從集群節(jié)點收集3種性能指標數(shù)據(jù)，并分析該時刻系統(tǒng)結構層性能指標狀態(tài)來確定導致節(jié)點異常的原因。系統(tǒng)結構性能指標信息如表1所示。

表1 體系結構性能指標

1.3 異常節(jié)點實時檢測與診斷

1.3.1 異常節(jié)點檢測算法

Hadoop集群節(jié)點通常具有類似的軟件和硬件條件，因此當有新任務提交給集群時，分配給每個節(jié)點的邏輯計算數(shù)量和數(shù)據(jù)處理大小應大致相同，且Hadoop集群中所有節(jié)點的執(zhí)行能力都遵循高斯分布。若某個節(jié)點發(fā)生異常，則該節(jié)點的執(zhí)行能力將下降。為了減少map任務和reduce任務之間的耦合性對Hadoop集群異常節(jié)點檢測的影響，本文將集群中每個節(jié)點的reduce任務轉換為map任務。因為Hadoop集群執(zhí)行任務時map階段和reduce階段并未完全分開執(zhí)行，map任務完成一部分后就會占用任務槽，然后立刻執(zhí)行reduce任務，并且reduce任務周期普遍較長，甚至會執(zhí)行到該作業(yè)結束。所以通過將reduce任務轉換為map任務可以同時考慮map任務和reduce任務，統(tǒng)計出執(zhí)行reduce任務時的耗時能夠執(zhí)行的map任務數(shù)量。例如，reduce任務已運行1 min，與此同時，在同一節(jié)點上的map任務的平均運行時間為20 s，則可以將reduce任務轉換為等效的3個map任務。

此外，為了避免節(jié)點異常而導致測量時間不準確，本文定義最近一次完成map任務的時間為轉換時的評估標準。因為最近一次的map任務執(zhí)行時間可以反映出節(jié)點當前的性能。本文定義集群中每個節(jié)點的任務邏輯完成數(shù)量為同一時間段內(nèi)reduce任務完成數(shù)量轉化為map任務的數(shù)量與map任務完成數(shù)量之和，并且該任務邏輯完成數(shù)量服從高斯分布。此外，考慮到本文搭建小規(guī)模集群(節(jié)點數(shù)量小于20)，因此使用t檢驗確定閾值，其中閾值可以根據(jù)給定的置信度和自由度來確定。同時，Hadoop集群中高于閾值的節(jié)點，若該節(jié)點的邏輯完成數(shù)量大于所有節(jié)點的邏輯完成數(shù)量平均值，該節(jié)點是誤報的正常節(jié)點；反之，則其為異常節(jié)點。異常節(jié)點實時檢測算法描述見算法1。

算法1 異常節(jié)點實時檢測算法

輸入：Hadoop集群節(jié)點nodei(i=1，2，…，n)。

輸出：異常節(jié)點abnomal_nodej(j=1，2，…，m)。

步驟1：將集群節(jié)點nodei執(zhí)行reduce任務數(shù)量轉換為map任務數(shù)量，即邏輯轉換數(shù)量Numreduce→map；

步驟2：將節(jié)點nodei同一時間段內(nèi)map任務數(shù)量與邏輯轉換數(shù)量Numreduce→map相加，得到節(jié)點nodei的任務邏輯完成數(shù)量nodeiNum；

步驟3：計算該時間段內(nèi)Hadoop集群中節(jié)點的任務邏輯完成數(shù)量的平均值nodeNumavg和方差nodeNumvar；

步驟4：通過設定的置信度和自由度得到t檢驗的閾值Tth；

步驟5：通過節(jié)點nodei任務邏輯完成數(shù)量nodeiNum、任務邏輯完成數(shù)量的平均值nodeNumavg和方差nodeNumvar以及自由度freedom，計算出節(jié)點nodei的t檢驗分數(shù)tscore；

步驟6：將節(jié)點nodei的t檢驗分數(shù)tscore和閾值Tth比較，任務邏輯完成數(shù)量nodeiNum和平均值nodeNumavg比較，得出該節(jié)點是否發(fā)生異常。

算法1中的nodei表示Hadoop集群中的第i個節(jié)點，abnomal_nodej為第j個異常節(jié)點，tscore是t檢驗分數(shù)。當tscore大于閾值Tth，并且任務的邏輯完成數(shù)量nodeiNum小于平均值nodeNumavg時，表示該節(jié)點為離群節(jié)點，即此時檢測到該節(jié)點發(fā)生異常。

1.3.2 異常節(jié)點診斷算法

Hadoop集群節(jié)點發(fā)生異常通常是由多種因素綜合導致，本文主要討論CPU使用率、內(nèi)存使用率與I/O負載3種性能指標導致的異常。當檢測到某個節(jié)點發(fā)生異常時，使用Pref性能分析工具周期性的收集并輸出該節(jié)點此時刻的體系結構層指標信息，然后結合上文提出的異常節(jié)點實時檢測算法診斷出導致節(jié)點異常的根本原因。CPU使用率、內(nèi)存使用率與I/O負載率的計算公式如下：

(1)

(2)

(3)

其中CPUusage、Memeryusage、IOutil分別表示Hadoop集群節(jié)點的CPU使用率、內(nèi)存使用率、I/O負載率。

本文基于Hadoop集群節(jié)點的相似性診斷導致節(jié)點異常的原因。Hadoop集群中的節(jié)點在負載或者閑置的時候，各個節(jié)點的性能指標大致相同，當某個節(jié)點異常時，該節(jié)點的性能就會發(fā)生變化，并且可以表現(xiàn)在系統(tǒng)性能指標的使用率上。本文結合異常節(jié)點實時檢測算法和Hadoop集群節(jié)點的相似性診斷導致節(jié)點異常的原因。異常節(jié)點診斷算法見算法2。

算法2 異常節(jié)點診斷算法

輸入：異常節(jié)點abnomal_nodej(j=1，2，…，m)。

步驟1：計算異常節(jié)點abnomal_nodej的CPU使用率CPUusage、內(nèi)存使用率Memoryusage、I/O負載率IOutil；

步驟2：將計算得到的CPUusage、Memoryusage和IOutil三種系統(tǒng)結構指標按照升序分別排序；

步驟3：將CPUusage、Memoryusage和IOutil使用率低于20%和高于80%的標記為異常指標abnomal_indexi。

2 實驗

2.1 實驗設置

本文實驗部署6個服務器節(jié)點，包括1個主節(jié)點和5個從節(jié)點，詳細的Hadoop集群節(jié)點配置信息如表2所示。本文使用WordCount和TeraSort基準測試程序用于評估本文提出算法的有效性，其中WordCount程序用于計算給定輸入集中每個單詞的出現(xiàn)次數(shù)，TeraSort程序是對TeraGen程序生成的測試數(shù)據(jù)進行排序，然后通過TeraValidate程序校驗排序的準確性。本文實驗搭建集群規(guī)模小于20個節(jié)點，符合小樣本高斯分布，因此設置t檢驗的置信度freedom為0.05(符合高斯分布)。通過計算得到閾值Tth為1.94，同時設置Spark Streaming的批處理周期為5 s。

表2 服務器配置信息

在實驗中，本文模擬注入3種常見異常進行實驗。利用stress工具對CPU和內(nèi)存以及I/O生成負載。具體地，在作業(yè)運行之前和正在運行時向集群中的節(jié)點注入異常，然后評估異常對節(jié)點的性能影響，具體的異常注入信息如表3所示。

表3 異常注入詳細信息

實驗分為兩個階段，第一階段在Hadoop集群運行之前向節(jié)點注入異常，再執(zhí)行基準測試程序。然后利用節(jié)點相似性原理檢測異常節(jié)點，最后再分析體系結構性能指標診斷節(jié)點異常的根本原因。第二階段，在Hadoop集群運行期間向節(jié)點注入異常，然后在集群上運行基準測試程序。為了評估本文提出算法的有效性，本實驗分別使用精確率(Precision)、召回率(Recall)以及F1-score三個評價指標進行評估，其中三個評價指標的值越高，表示模型的性能越好。

2.2 實驗結果分析

本文在WordCount和TeraSort兩個基準測試程序上進行了實驗。通過對比不同狀態(tài)下的節(jié)點行為和集群中節(jié)點的各種資源利用率，來檢測和診斷集群中的異常節(jié)點。實驗結果表明本文提出的算法可以有效地實時檢測和診斷Hadoop集群中的異常節(jié)點。具體的實驗結果如圖2—圖9所示。

圖2 正常狀態(tài)節(jié)點行為 圖3 正常狀態(tài)節(jié)點資源使用率

由圖2和圖3可知，在Hadoop集群節(jié)點沒有發(fā)生異常的情況下，各個節(jié)點的行為基本一致，并且各個節(jié)點tscore分數(shù)都小于閾值Tth，該時刻Hadoop集群中各個節(jié)點的各種資源使用率也大致相同。從圖4和圖5可知，節(jié)點node5的任務邏輯完成數(shù)量nodeiNum遠遠小于其他節(jié)點，tscore分數(shù)也大于閾值Tth，說明該節(jié)點發(fā)生異常。并且該時刻該異常節(jié)點的CPU使用率大于80%，該節(jié)點異常的根本原因是CPU異常導致。通過觀察圖6和圖7可以發(fā)現(xiàn)，節(jié)點node5的行為同其他節(jié)點差異較大，同時tscore分數(shù)也大于閾值Tth，通過算法1可以檢測到該節(jié)點發(fā)生異常，然后通過對該節(jié)點各種資源使用率的分析可知，node5節(jié)點的內(nèi)存使用率大于80%，則內(nèi)存異常定義為導致該節(jié)點異常的原因。通過圖8和圖9可知節(jié)點node5的tscore分數(shù)也大于閾值Tth，說明節(jié)點node5被檢測到異常，再通過分析各種資源使用率可發(fā)現(xiàn)該節(jié)點的I/O負載小于20%，說明I/O負載異常是導致該節(jié)點異常的根本原因。

圖4 CPU異常節(jié)點行為 圖5 CPU異常節(jié)點資源使用率

圖6 內(nèi)存異常節(jié)點行為 圖7 內(nèi)存異常節(jié)點資源使用率

圖8 I/O異常節(jié)點行為 圖9 I/O異常節(jié)點資源使用率

為了進一步驗證本文提出算法的準確性和有效性，將本文提出的算法和傳統(tǒng)算法以及同類型先進的實時異常檢測算法進行比較。表4所示為在Hadoop集群中進行WordCount和TeraSort基準測試的實驗結果。從表中的實驗結果可知，融合了Hadoop日志信息和體系結構層信息的異常節(jié)點檢測算法相比于傳統(tǒng)的算法性能有所提升。Pan等[5]、Guo等[6]、Fathnia等[9]與Habeeb等[10]的實驗結果表明，將Hadoop日志信息和體系結構指標結合可以有效提高異常節(jié)點檢測和診斷的性能。從整體來看，本文提出的算法在Hadoop集群異常節(jié)點檢測評價指標準確率和召回率以及F1-score上優(yōu)于其他所有的方法。相較于傳統(tǒng)算法，基于Hadoop日志信息和體系結構層指標信息的異常階段節(jié)點檢測有了明顯的改善。此外，相較于現(xiàn)有的實時異常檢測算法，本文算法將reduce任務和map任務相互轉化，減少了耦合性的影響，從而提升了算法的有效性。

表4 不同算法基準測試實驗結果

此外，為了評估本文提出算法的泛化能力，在Hadoop集群節(jié)點運行時注入異常。具體地，在集群節(jié)點map任務完成20%、50%和80%時注入不同的異常，然后運行20次WordCount和TeraSort基準測試程序實驗。實驗結果表明本文提出的算法在Hadoop集群階段運行時依然可以檢測出異常節(jié)點，并診斷出導致異常的原因。詳細的實驗結果如表5、表6和表7所示。

表5 基準測試實驗結果(map任務完成20%)

表6 基準測試實驗結果(map任務完成50%)

表7 基準測試實驗結果(map任務完成80%)

從表中可知，在map任務完成度為20%和50%時注入異常，實驗結果和在Hadoop集群節(jié)點運行前注入異常基本一致，而當map任務完成度80%時注入異常，各項評價指標值有所降低。其原因是reduce階段和map階段任務并不是完全獨立執(zhí)行，在map任務完成部分后reduce任務就開始執(zhí)行，而且reduce任務的執(zhí)行時間普遍較長。本文提出算法主要依賴map任務，但是當map任務執(zhí)行完后，reduce任務還未執(zhí)行完畢，這將會導致節(jié)點發(fā)生異常而不能及時發(fā)現(xiàn)。

2.3 運行時間開銷分析

在實時檢測與診斷算法中，運行時間開銷是重要的影響因素，而且在Spark Streaming批處理機制中，需要在固定的周期內(nèi)完成計算并返回結果。如果實時檢測算法的時間復雜度太高，則會增加批處理的時間，進而影響Hadoop集群整體性能。

本文使用BigdataBench中提及的WordCount、TeraSort和Grep三種基準測試程序評估提出算法的運行時間開銷。將作業(yè)在沒有數(shù)據(jù)收集工具運行的情況下運行的時間定義為基線時間，然后將收集Hadoop日志數(shù)據(jù)和體系結構層指標數(shù)據(jù)的間隔設置為1 s，并測量作業(yè)在有數(shù)據(jù)收集工具運行時的完成時間作為對比。實驗結果如圖10所示，可以明顯得出本文提出算法引起的額外開銷很低。

圖10 運行時間開銷

3 總結

本文基于Hadoop集群節(jié)點行為性能相似性，設計并實現(xiàn)了Hadoop集群異常節(jié)點的實時檢測和診斷算法。該算法不但考慮了map任務和reduce任務之間的耦合性，而且本文提出的算法比傳統(tǒng)的Hadoop異常節(jié)點檢測與診斷算法精確率更高。通過在WordCount和TeraSort兩個基準測試程序驗證了本文提出算法的有效性。在未來的工作中，將進一步優(yōu)化異常檢測和診斷算法，使其適應更復雜情況，泛化能力更強。此外，針對異常誤報情況對集群異常節(jié)點檢測的影響，將提供其指標來區(qū)分集群是否真的發(fā)生異常。