任何新技術的引入都會歷經陌生到熟悉，從最初新技術帶來的驚喜，到後來遇到困難時的一籌莫展和惆悵，再到問題解決後的愉悅，大資料新貴Spark同樣不能免俗。下面就列舉一些我們遇到的坑。

【坑一：跑很大的資料集的時候，會遇到org.apache.spark.SparkException: Errorcommunicating 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本身是開源的，通過原始碼的閱讀，以及藉助開源社群的幫助，大部分問題都可以順利解決。