1.5 錯誤容忍機制

由于不能避免系統(tǒng)和用戶代碼的Bug、節(jié)點宕機、網(wǎng)絡(luò)異常、磁盤損壞等軟硬件可靠性問題，分布式文件系統(tǒng)在設(shè)計時一般都會考慮錯誤容忍機制，在實現(xiàn)時也會針對各種失效情況采取相應(yīng)措施。分布式大數(shù)據(jù)并行處理框架也不例外，設(shè)計了各種針對Master節(jié)點失效、task執(zhí)行失敗等問題的錯誤容忍機制。然而，對于task的執(zhí)行失敗問題，框架的錯誤容忍機制比較簡單，只是選擇合適節(jié)點重新運行該task。對于某些可靠性問題引起的task執(zhí)行失敗，如內(nèi)存溢出等，簡單地重新運行task并不能解決問題，因為內(nèi)存溢出的問題很有可能會重復(fù)出現(xiàn)。現(xiàn)有框架的另一個局限是，一般用戶在出錯時很難找到真正的出錯原因，即使是十分熟悉框架運行細(xì)節(jié)的用戶，在缺乏分析診斷工具的情況下，也難以快速找到出錯原因。下面我們總結(jié)分析一下在錯誤容忍機制方面的前沿工作。

在大數(shù)據(jù)應(yīng)用錯誤分析方面：Li等[53]研究了250個SCOPE作業(yè)（運行在微軟的Dryad框架之上）的故障錯誤，發(fā)現(xiàn)錯誤發(fā)生的主要原因是未定義的列、錯誤的數(shù)據(jù)模式、不正確的行格式等。Kavulya等[54]分析了4100個在Yahoo！管理的集群上執(zhí)行失敗的Hadoop作業(yè)，發(fā)現(xiàn)36%的故障是數(shù)組訪問越界造成的，還有23%的故障是因為I/O異常。Xu等[55]研究了123個Hadoop/Spark應(yīng)用中的內(nèi)存溢出錯誤，發(fā)現(xiàn)內(nèi)存溢出的主要原因包括應(yīng)用配置異常、數(shù)據(jù)流異常、代碼空間復(fù)雜度過高和框架內(nèi)存管理缺陷等。

在大數(shù)據(jù)應(yīng)用錯誤診斷方面：Titian[56]通過記錄Spark應(yīng)用中全部中間數(shù)據(jù)和數(shù)據(jù)依賴關(guān)系來追蹤出錯的數(shù)據(jù)路徑。BigDebug[57]為Spark應(yīng)用提供了斷點、觀察點、細(xì)粒度數(shù)據(jù)追蹤等調(diào)試功能。Xu等[58]設(shè)計實現(xiàn)了Hadoop MapReduce的內(nèi)存溢出錯誤診斷工具Mprof，它可以建立執(zhí)行任務(wù)內(nèi)存用量與數(shù)據(jù)流量的定量關(guān)系。在此基礎(chǔ)上，Mprof 設(shè)計了多種內(nèi)存溢出錯誤診斷規(guī)則，這些規(guī)則根據(jù)應(yīng)用配置、數(shù)據(jù)流量與任務(wù)內(nèi)存用量的關(guān)聯(lián)關(guān)系來定位內(nèi)存溢出錯誤的相關(guān)代碼、數(shù)據(jù)，以及不恰當(dāng)?shù)呐渲脜?shù)。

在大數(shù)據(jù)應(yīng)用錯誤修復(fù)方面：Interruptile Tasks[59]改進了現(xiàn)有的task，使得task具備一定的錯誤容忍能力。當(dāng)task在運行時遇到內(nèi)存用量過大或者內(nèi)存溢出的問題時，Interruptile Tasks會暫停當(dāng)前task的運行，回收部分運行數(shù)據(jù)及中間結(jié)果，并將不能回收的結(jié)果溢寫（spill）到磁盤上，然后執(zhí)行用戶定義的interrupt邏輯，等到內(nèi)存用量下降到一定程度后，再讓task繼續(xù)運行。