王欣　周云才

摘要：隨著大數(shù)據(jù)技術(shù)的不斷發(fā)展，數(shù)據(jù)分析越來越受到人們的關(guān)注，Spark 作為大規(guī)模數(shù)據(jù)處理的快速通用的計算引擎，由于它的高速性而被各大商家應(yīng)用于實際生產(chǎn)過程中。本文通過隱馬爾科夫模型（HMM），選擇在實際生產(chǎn)過程中，在進行海量的數(shù)據(jù)分析過程中出現(xiàn)的異常進行分析，以實際任務(wù)執(zhí)行時的：內(nèi)存溢出、垃圾回收異常、序列化異常為指標，根據(jù)實際出現(xiàn)異常時的提示，來確定HMM狀態(tài)空間、確定相應(yīng)的觀測值、計算相關(guān)的參數(shù)，進而構(gòu)建針對于Spark作業(yè)工作過程中的出現(xiàn)異常時的隱馬爾科夫模型，用來揭示引發(fā)異常的類型，來對實際生產(chǎn)過程中出現(xiàn)此類問題時提供可靠的類型診斷。

關(guān)鍵詞：spark；隱馬爾科夫模型；內(nèi)存溢出；異常；內(nèi)存管理

中圖分類號：TP31 文獻標志碼：A 文章編號：1009-3044（2018）11-0198-03

Spark Operation Anomaly Analysis Based on Hidden Markov Model

WANG Xin，ZHOU Yun-cai

（Yangtze University，Jingzhou 434023，China）

Abstract： With the continuous development of big data technology， data analysis has attracted more and more attention. Spark， a fast and universal computing engine for large-scale data processing， has been used by major merchants in the actual production process due to its high speed. This paper uses hidden Hidden Markov Model （HMM） to select the analysis of abnormalities that occur in the process of mass data analysis in the actual production process. When actual tasks are executed， memory overflow， garbage collection anomalies， and serialization anomalies are Indicators， according to the actual occurrence of abnormal prompts， to determine the HMM state space， determine the corresponding observations， calculate the relevant parameters， and then build a Hidden Markov model for exceptions in the Spark job process， to reveal The type of exception that is thrown to provide a reliable type diagnosis when such problems occur in the actual production process.

Key words：spark； hidden markov model； memory overflow； exceptions； memory management

1 概述

Spark是UC Berkeley計算機教授Ion Stoica 在2009年發(fā)起的，隨后被Apache軟件基金會接管的類似于Hadoop MapReduce的通用并行計算框架，是當前大數(shù)據(jù)領(lǐng)域最活躍的開源項目之一[1]。Spark是基于MapReduce計算框架實現(xiàn)的分布式計算，擁有Hadoop MapReduce所具有的優(yōu)點；但不同于MapReduce。

在現(xiàn)實生活中隱馬爾科夫模型廣泛應(yīng)用于圖像處理、語音識別、模式識別、信息處理預(yù)測以及股票風險預(yù)測等領(lǐng)域，同時在機器異常狀態(tài)預(yù)測、風險預(yù)警、風投決策等生產(chǎn)環(huán)境中都有廣泛的應(yīng)用。在大型的電商公司，對于日常的點擊、收藏、購買等行為的日志分析尤為重要，而在針對于海量數(shù)據(jù)的分析過程中spark作為基于內(nèi)存的一種大數(shù)據(jù)處理解決方案，越來越受到各大電商公司的關(guān)注[2]。在Spark Streaming持續(xù)計算過程中，在針對于日志進行實時、連續(xù)的分析中難免會出現(xiàn)很多應(yīng)用運行異常，而由于內(nèi)存引起的異常正是其中尤為重要的一種，在實際生產(chǎn)環(huán)境中經(jīng)常遇到。在異常處理過程中，可知的當前異常信息提示只與處理異常的上一次有關(guān)，而與之前的狀態(tài)無關(guān)，且該過程滿足運用隱馬爾科夫模型的無后效性的條件，因此在spark作業(yè)中出現(xiàn)內(nèi)存異常時，可以采用隱馬爾科夫模型來分析異常出現(xiàn)的原因以及根據(jù)作業(yè)內(nèi)存需要和實際內(nèi)存的空閑量來預(yù)測作業(yè)是否會發(fā)生內(nèi)存方面的異常，以便快速的解決問題。

2 Spark作業(yè)執(zhí)行機制簡介

Spark稱為快數(shù)據(jù)，比Hadoop的傳統(tǒng)處理方式MapReduce有著很大的差別，效率至少提高100倍以上。Spark是基于內(nèi)存的編程模型，它可以把中間的迭代過程不放在磁盤中，直接數(shù)據(jù)不落地在內(nèi)存中執(zhí)行，極大地提高了它的執(zhí)行速度[1]。Spark主要包括四個大的模塊，下面只要介紹下在實際生產(chǎn)過程中尤為重要的、也是出現(xiàn)任務(wù)運行異常最多的Streaming模塊[6]。

在實際的生產(chǎn)過程中，流式計算最容易出現(xiàn)的異常就是內(nèi)存溢出、GC異常以及序列化異常。試想下，在針對于實時數(shù)據(jù)進行處理時，由于出現(xiàn)各種異常而未能夠及時的得到解決，而造成整個應(yīng)用中止，是會造成巨大損失的。本文主要對在任務(wù)執(zhí)行過程中經(jīng)常出現(xiàn)的OOM異常、GC異常和序列化異常等，結(jié)合隱馬爾科夫模型對異常類型進行分析，以便后續(xù)解決問題。

Spark在一個Executor中的內(nèi)存模型分為三塊，一塊是execution內(nèi)存，一塊是storage內(nèi)存，一塊是other內(nèi)存。execution內(nèi)存是執(zhí)行內(nèi)存，shuffle的數(shù)據(jù)也會先緩存在這個內(nèi)存中，滿了再寫入磁盤，能夠減少IO。其實map過程也是在這個內(nèi)存中執(zhí)行的。同時，這部分內(nèi)存也是造成OOM的主要地方[4]。storage內(nèi)存是存儲broadcast，cache，persist數(shù)據(jù)的地方。other內(nèi)存是程序執(zhí)行時預(yù)留給自己的內(nèi)存，由此可見，在作業(yè)執(zhí)行的過程中，每次的shuffle操作都會引起大量的map/reduce操作，這也就很有可能產(chǎn)生異常，在實際生產(chǎn)過程中，shuffle操作前后也是最容易發(fā)生異常的地方。

在作業(yè)執(zhí)行過程中，內(nèi)存十分重要。因為spark這項技術(shù)本身就是基于內(nèi)存的計算模型，因此在作業(yè)執(zhí)行過程中，前期的lazy特性部分執(zhí)行結(jié)束后，涉及內(nèi)存的使用部分往往就會是異常的高發(fā)區(qū)。其中OOM異常主要是指內(nèi)存的溢出；GC異常代表的是垃圾回收異常，作業(yè)在執(zhí)行之中，不可避免的都要創(chuàng)建新的中間變量，這樣的變量就會在內(nèi)存中開辟空間來存儲，并且這個可以容納中間變量的總空間大小是一定的，GC機制會在每次任務(wù)過程中以及結(jié)束后，及時的清理此空間中的緩存數(shù)據(jù)，雖然如此，但是試想一下，如果一次傳入的中間數(shù)據(jù)太大的話會出現(xiàn)什么情況？在針對海量數(shù)據(jù)的處理的時候，可以預(yù)見各式各樣的數(shù)據(jù)肯定需要序列化以及反序列化過程，而針對于序列化或者反序列化之后的數(shù)據(jù)的存儲也是在內(nèi)存中，不同的是，會分批次存儲，但是在作業(yè)7*24的工作模式下，也是很有可能出現(xiàn)序列化的異常的。

3 HMM基本原理

隱馬爾科夫模型（HMM）是馬爾科夫鏈的一種實際應(yīng)用，是用來根據(jù)可見狀態(tài)鏈去預(yù)測未來狀態(tài)（也叫隱藏狀態(tài)鏈）的一種行之有效的方法[3]。

其模型參數(shù)為：

λ=（N， M， A， B， π）

其中，N表示的是馬爾科夫鏈中隱含狀態(tài)的個數(shù)；M表示可見狀態(tài)對應(yīng)的數(shù)目；A表示隱含狀態(tài)之間的轉(zhuǎn)移概率矩陣；B表示可見狀態(tài)的概率矩陣；π表示初始狀態(tài)的概率矩陣。簡化的表示方法為λ=（A， B， π）。

在作業(yè)執(zhí)行出現(xiàn)異常的過程中，基本的隱馬爾可夫組成如圖1所示。

在本文中，主要是使用了Viterbi算法對在作業(yè)執(zhí)行過程出現(xiàn)的異常時的可見狀態(tài)序列（提示信息）來計算出概率最大的隱含狀態(tài)序列（異常類型），其實就是傳統(tǒng)的解碼問題，只不過這里主要針對的就是在作業(yè)執(zhí)行到shuffle操作時，出現(xiàn)異常的分析預(yù)測[7]。首先，定義一個隨機變量qt（i），來表示t時刻沿著路徑q1，q2，...，qt來生成相應(yīng)的可見狀態(tài)序列Q1，Q2，...，Qt，其中qt=αi，α是來標示在時刻t狀態(tài)為i的所有單個路徑（q1，q2，...，qi）的概率最大值：

αt（i）=maxq1，q2，...qi-1p（q1，q2，...，qi，qi=αi，Q1，Q2，...，Qt|λ）。

其中要求的概率最大的狀態(tài)序列Q推導(dǎo)過程如下。

首先進行初始化：

αt（i） = πibi（Qi），其中1≤i≤N

Φt（i） = Qi，其中1≤i≤N

然后進行遞歸計算：

ΦT（j） = argmax1≤i≤N[α（i）aij]，其中1≤t≤T，1≤j≤N

最終：

P = max1≤i≤N[αT（i）]

概率最大的序列求解為：

Qt = ΦT + 1（Qt + 1），其中t = T-1，T-2，...，1

圖2表示的是各個狀態(tài)之間的轉(zhuǎn)換概率示意圖。有圖可以看出在不同的狀態(tài)之間是存在這轉(zhuǎn)移概率的，也就是說在某一個時刻t時的可見序列Q1，Q2，...，Qt-1的情況下，狀態(tài)從q1，q2，...，qN到qi的最大轉(zhuǎn)移概率下的路徑[9]。

4 spark異常產(chǎn)生

隨著人類社會的發(fā)展，人們越來越重視數(shù)據(jù)背后隱藏的信息，而Spark作為處理海量中的翹楚。因此在實際生產(chǎn)環(huán)境中被廣泛使用，此時異常的診斷是尤為重要的，如何快速的根據(jù)提示信息確定異常的種類十分重要，因為只有確定了異常的類型才能準確的定位出引發(fā)異常的原因，避免多種異常提示信息一樣而造成的異常處理失敗的情況。而這個過程其實從本質(zhì)上講是一個模式識別的問題，而HMM的一個重要功能就是模式識別。因此本文采用隱馬爾科夫模型來實現(xiàn)異常類型的診斷。

在Spark作業(yè)執(zhí)行的過程中，shuffle過程是最容易引起異常的產(chǎn)生，也是作業(yè)執(zhí)行過程中最需要進行優(yōu)化的地方，其中內(nèi)存作為整個作業(yè)實際的執(zhí)行位置而顯得十分重要。本文主要針對內(nèi)存溢出（OOM）、垃圾回收異常（GC）、序列化異常等三類異常情況進行分析。

作業(yè)的執(zhí)行過程是這樣的：客戶端提交作業(yè)應(yīng)用給Master，Master會隨機的在一個Worker節(jié)點上面啟動Driver進程，其實就是SchedulerBackend。與此同時Worker創(chuàng)建一個DriverRunner線程，作為SchedulerBackend進程的啟動進程。 另外Master會在集群中另外的Worker節(jié)點上面啟動Exeuctor進程，即ExecutorBackend，并且Worker會同時創(chuàng)建一個ExecutorRunner線程，作為ExecutorBackend進程的啟動進程[7]。 ExecutorBackend進程啟動后會向Driver注冊。SchedulerBackend進程是整個作業(yè)執(zhí)行的開始，其中包含了DAGScheduler進程，此進程會根據(jù)用戶程序，生成執(zhí)行計劃，并調(diào)度執(zhí)行。對于每個stage的task，都會被存放到TaskScheduler中，ExecutorBackend向SchedulerBackend匯報的時候把TaskScheduler中的task調(diào)度到ExecutorBackend執(zhí)行。 所有stage都完成后作業(yè)結(jié)束[5]。

在作業(yè)的執(zhí)行過程中，作業(yè)的執(zhí)行目的肯定是為了處理海量的數(shù)據(jù)，而海量的日志數(shù)據(jù)在實際的處理過程中，要么是離線分批次分析、要么是實時的傳輸進行處理，在這個過程中肯定要涉及數(shù)據(jù)的序列化問題，而在這種異常中，它的提示信息（可見狀態(tài)）為timeout、內(nèi)存太小、數(shù)據(jù)不平衡、序列化異常（數(shù)據(jù)不可被序列化）等四種。隨著作業(yè)的執(zhí)行，前面的transform操作，都是具有l(wèi)azy特性的，也就是說并不會立即執(zhí)行，只有遇到action操作（shuffle）時，才會根據(jù)上述的過程提交task，來運行作業(yè)中的task。而在shuffle過程的前后，分為map操作和reduce操作，會將task提交到TaskScheduler中具體執(zhí)行。這個過程需要大量的使用內(nèi)存資源，這樣就會很容易引發(fā)異常，實際上shuffle過程也是優(yōu)化的重災(zāi)區(qū)。其一就是內(nèi)存溢出（OOM），它的相應(yīng)的提示信息是大量對象（數(shù)據(jù)分塊不合理）、數(shù)據(jù)不平衡、單個文件過大等三種。其二就是垃圾回收異常（GC），指的是臨時變量異常，它的提示信息是內(nèi)存太小、分片?。▎蝹€文件太大）等兩種。

5 HMM的構(gòu)建與訓(xùn)練

首先為上述的在Spark作業(yè)執(zhí)行過程中出現(xiàn)的三類異常分別訓(xùn)練一個HMM模型。其中可見狀態(tài)分別為當作業(yè)執(zhí)行出現(xiàn)異常時每一種的提示信息，而隱含狀態(tài)為各種異常的類型，這樣就能夠快速的定位到出現(xiàn)異常的位置，便于采取后續(xù)的異常解決或者優(yōu)化執(zhí)行過程。

訓(xùn)練模型的步驟如下：

①采集三大類異常下的5種不同的訓(xùn)練狀態(tài)，并在具體的作業(yè)執(zhí)行過程中觀察具體的提示異常信息，來作為不同類型異常的觀察序列的輸入模型。

②根據(jù)之前闡述過的λ=（A， B， π）來建立HMM模型，并且確定此模型的初始值。然后Spark異常的提示類型，來設(shè)定初始值的狀態(tài)概率，初始值狀態(tài)轉(zhuǎn)換概率矩陣為：

[A=1/31/31/300001/21/201/41/401/41/4]

其中，行的概念代表的是異常的三大類型，而列的概念代表的是5種不同的訓(xùn)練狀態(tài)，也就是不同的提示信息，與狀態(tài)轉(zhuǎn)換概率矩陣對應(yīng)的依次是：大量對象、數(shù)據(jù)不平衡、單個文件太大、內(nèi)存太小、序列化異常等。

③運行不同的測試程序，讓其出現(xiàn)不同類型的異常，并且記錄下相應(yīng)的異常提示信息，也就是所謂的可見狀態(tài)序列，用來計算模型的初始化參數(shù)。設(shè)定可見狀態(tài)序列的時間長度是100，通過混合高斯概率密度函數(shù)來觀測表示實際可見狀態(tài)的概率矩陣為：

bj（Qt） =[m=1M]cjmN（QI，ujm，Ujm）

④重新計算分析到的初始值參數(shù)。

⑤將得到的初始值參數(shù)記性迭代運算，直到收斂于理想的初始值狀態(tài)轉(zhuǎn)換概率矩陣。

異常判定模型得到之后，分別運行100個事先準備的Spark應(yīng)用，產(chǎn)生不同類型的異常，然后代入到已經(jīng)訓(xùn)練好的HMM中，計算對數(shù)似然概率值P（Q|ɑn），其中對數(shù)的似然估計概率P（Q|ɑn），1≦i≦K 為概率最大時對應(yīng)的異常類型就是所得到的異常識別的結(jié)果。

根據(jù)隱馬爾科夫模型中的模式識別理論，對數(shù)似然估計概率的最大值所對應(yīng)的模型就是異常的類型判定結(jié)果。本文結(jié)合100個實驗測試樣本實例，分別運行觀察不同的異常提示，得到可見狀態(tài)序列，然后將其輸入到之前已經(jīng)訓(xùn)練好的HMM模型中，計算出似然估計概率P（Q|ɑn）。結(jié)果如表1所示。

由表1可知，在樣本實例輸入到HMM中得到的結(jié)果和預(yù)期的大相徑庭，但是在序列化以上的判定上概率表笑。這是因為在實際的生產(chǎn)環(huán)境中，在作業(yè)代碼的編寫過程中一般都會考慮到序列化的問題，而內(nèi)存溢出和垃圾回收異常時在作業(yè)運行過程中才能夠發(fā)現(xiàn)的，所以才會出現(xiàn)這樣的概率差異問題。

6 結(jié)束語

文中利用隱馬爾科夫模型對Spark作業(yè)在運行過程中出現(xiàn)的異常類型判定，取得了較好的效果。但是在模型的訓(xùn)練過程中，由于作業(yè)代碼的不同性以及集群資源的差異性，都會對實驗結(jié)果產(chǎn)生影響。所以在此模型的基礎(chǔ)上需要進一步完善的是在系統(tǒng)資源不同的集群上面運行相同的作業(yè)，來進一步完善異常類型的判定。

參考文獻：

[1] 夏俊鸞.Spark大數(shù)據(jù)處理技術(shù)[M].電子工業(yè)出版社.2015

[2] 黎文陽.大數(shù)據(jù)處理模型Apache Spark研究[J].現(xiàn)代計算機（專業(yè)版），2015（08）：55-60.

[3] 劉河生，高小榕，楊福生.隱馬爾可夫模型的原理與實現(xiàn)[J].國外醫(yī)學(xué).生物醫(yī)學(xué)工程分冊，2002（06）：253-259.

[4] 楊志偉，鄭烇，王嵩，等.異構(gòu)Spark集群下自適應(yīng)任務(wù)調(diào)度策略[J].計算機工程，2016，42（01）：31-35+40.

[5] 孟紅濤，余松平，劉芳，等.Spark內(nèi)存管理及緩存策略研究[J].計算機科學(xué)，2017，44（06）：31-35+74.

[6] 韓德志，陳旭光，雷雨馨， 等.基于Spark Streaming的實時數(shù)據(jù)分析系統(tǒng)及其應(yīng)用[J].計算機應(yīng)用，2017，37（05）：1263-1269.

[7] 吳佳，曾惟如，陳瀚霖， 等.基于隱馬爾可夫模型的軟件狀態(tài)評估預(yù)測方法[J].軟件學(xué)報，2016，27（12）：3208-3222.

[8] 李方偉，孫隨，朱江， 等.基于隱馬爾可夫模型的態(tài)勢評估方法[J].計算機工程與設(shè)計，2015，36（07）：1706-1711.

[9] 趙玲，許宏科.基于改進的灰色馬爾可夫鏈模型的交通事故預(yù)測[J].數(shù)學(xué)的實踐與認識，2013，43（20）：92-98.

[10] 李相勇，張南，蔣葛夫.道路交通事故灰色馬爾可夫預(yù)測模型[J].公路交通科技，2003（04）：98-100+104.