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

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

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

問題二：運行時報Fetch failure錯

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

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

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

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

在機器學習方面，H2O機器學習引擎也和Spark有了良好的集成從而產生了Sparkling-water。相信利用Sparking-water，作為一家創業公司，我們也可以利用深度學習的力量來進一步挖掘數據的價值。