任何新技術(shù)的引入都會歷經(jīng)陌生到熟悉，從最初新技術(shù)帶來的驚喜，到后來遇到困難時的一籌莫展和惆悵，再到問題解決后的愉悅，大數(shù)據(jù)新貴Spark同樣不能免俗。大數(shù)據(jù)Hadoop與Spark架構(gòu)應(yīng)用實戰(zhàn)》專家鐘老師介紹了Spark過程中常見的一些問題

問題一：跑很大的數(shù)據(jù)集的時候，會遇到org.apache.spark.SparkException: Error communicating with MapOutputTracker

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

問題二：運行時報Fetch failure錯

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

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

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

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

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