任何新技術(shù)的引入都會(huì)歷經(jīng)陌生到熟悉，從最初新技術(shù)帶來的驚喜，到后來遇到困難時(shí)的一籌莫展和惆悵，再到問題解決后的愉悅，大數(shù)據(jù)新貴Spark同樣不能免俗?！洞髷?shù)據(jù)平臺(tái)搭建與高性能計(jì)算最佳實(shí)戰(zhàn)》培訓(xùn)專家鐘老師介紹了Spark過程中常見的一些問題

問題一：跑很大的數(shù)據(jù)集

會(huì)遇到org.apache.spark.SparkException: Error communicating with MapOutputTracker

這個(gè)錯(cuò)誤報(bào)得很隱晦，從錯(cuò)誤日志看，是Spark集群partition了，但如果觀察物理機(jī)器的運(yùn)行情況，會(huì)發(fā)現(xiàn)磁盤I/O非常高。進(jìn)一步分析會(huì)發(fā)現(xiàn)原因是Spark在處理大數(shù)據(jù)集時(shí)的shuffle過程中生成了太多的臨時(shí)文件，造成了操作系統(tǒng)磁盤I/O負(fù)載過大。找到原因后，解決起來就很簡(jiǎn)單了，設(shè)置spark.shuffle.consolidateFiles為true。這個(gè)參數(shù)在默認(rèn)的設(shè)置中是false的，對(duì)于linux的ext4文件系統(tǒng)，建議大家還是默認(rèn)設(shè)置為true吧。Spark官方文檔的描述也建議ext4文件系統(tǒng)設(shè)置為true來提高性能。

　　問題二：運(yùn)行時(shí)報(bào)Fetch failure錯(cuò)

在大數(shù)據(jù)集上，運(yùn)行Spark程序，在很多情況下會(huì)遇到Fetch failure的錯(cuò)。由于Spark本身設(shè)計(jì)是容錯(cuò)的，大部分的Fetch failure會(huì)經(jīng)過重試后通過，因此整個(gè)Spark任務(wù)會(huì)正常跑完，不過由于重試的影響，執(zhí)行時(shí)間會(huì)顯著增長。造成Fetch failure的根本原因則不盡相同。從錯(cuò)誤本身看，是由于任務(wù)不能從遠(yuǎn)程的節(jié)點(diǎn)讀取shuffle的數(shù)據(jù)，具體原因則需要利用：

查看Spark的運(yùn)行日志，從而找到造成Fetch failure的根本原因。其中大部分的問題都可以通過合理的參數(shù)配置以及對(duì)程序進(jìn)行優(yōu)化來解決。2014年Spark Summit China上陳超的那個(gè)專題，對(duì)于如何對(duì)Spark性能進(jìn)行優(yōu)化，有非常好的建議。

當(dāng)然，在使用Spark過程中還遇到過其他不同的問題，不過由于Spark本身是開源的，通過源代碼的閱讀，以及借助開源社區(qū)的幫助，大部分問題都可以順利解決。

鐘老師最后總結(jié)道，Spark目前已經(jīng)取得了長足的發(fā)展，圍繞Spark的大數(shù)據(jù)生態(tài)系統(tǒng)也逐漸的完善。Spark 1.3引入了一個(gè)新的DataFrame API，這個(gè)新的DataFrame API將會(huì)使得Spark對(duì)于數(shù)據(jù)的處理更加友好。同樣出自于AMPLab的分布式緩存系統(tǒng)Tachyon因?yàn)槠渑cSpark的良好集成也逐漸引起了人們的注意。鑒于在業(yè)務(wù)場(chǎng)景中，很多基礎(chǔ)數(shù)據(jù)是需要被多個(gè)不同的Spark任務(wù)重復(fù)使用，下一步，我們將會(huì)在架構(gòu)中引入Tachyon來作為緩存層。另外，隨著SSD的日益普及，我們后續(xù)的計(jì)劃是在集群中每臺(tái)機(jī)器都引入SSD存儲(chǔ)，配置Spark的shuffle的輸出到SSD，利用SSD的高速隨機(jī)讀寫能力，進(jìn)一步提高大數(shù)據(jù)處理效率。

在機(jī)器學(xué)習(xí)方面，H2O機(jī)器學(xué)習(xí)引擎也和Spark有了良好的集成從而產(chǎn)生了Sparkling-water。相信利用Sparking-water，作為一家創(chuàng)業(yè)公司，我們也可以利用深度學(xué)習(xí)的力量來進(jìn)一步挖掘數(shù)據(jù)的價(jià)值。