目前，Spark作為一種高效的分布式計(jì)算系統(tǒng)，其價(jià)值已經(jīng)在國(guó)內(nèi)業(yè)界獲得了廣泛的認(rèn)可和尊重。2013年中期，隨著業(yè)務(wù)高速發(fā)展，越來(lái)越多的移動(dòng)設(shè)備側(cè)數(shù)據(jù)被各個(gè)不同的業(yè)務(wù)平臺(tái)收集。那么這些數(shù)據(jù)除了提供不同業(yè)務(wù)所需要的業(yè)務(wù)指標(biāo)，是否還蘊(yùn)藏著更多的價(jià)值？為了更好地挖掘數(shù)據(jù)潛在價(jià)值，很多企業(yè)決定建造自己的數(shù)據(jù)中心，將各業(yè)務(wù)平臺(tái)的數(shù)據(jù)匯集到一起，對(duì)覆蓋設(shè)備的相關(guān)數(shù)據(jù)進(jìn)行加工、分析和挖掘，從而探索數(shù)據(jù)的價(jià)值。   中培偉業(yè)《大數(shù)據(jù)Hadoop與Spark架構(gòu)應(yīng)用實(shí)戰(zhàn)》授課專家鐘老師指出，隨著Spark價(jià)值的日益彰顯，目前國(guó)內(nèi)專業(yè)領(lǐng)域已經(jīng)出現(xiàn)了全面擁抱Spark的局面。

進(jìn)入2014年，公司的業(yè)務(wù)有了長(zhǎng)足的發(fā)展，對(duì)比數(shù)據(jù)中心平臺(tái)建立時(shí)，每日處理的數(shù)據(jù)量亦翻了幾番。每日的排名計(jì)算所花的時(shí)間越來(lái)越長(zhǎng)，而基于Hive的即時(shí)計(jì)算只能支持日尺度的計(jì)算，如果到周這個(gè)尺度，計(jì)算所花的時(shí)間已經(jīng)很難忍受，到月這個(gè)尺度則基本上沒辦法完成計(jì)算。基于在Spark上的認(rèn)知和積累，是時(shí)候?qū)⒄麄€(gè)數(shù)據(jù)中心遷移到Spark上了。

國(guó)內(nèi)的很多同行已經(jīng)開始采用Spark來(lái)建造自己的大數(shù)據(jù)平臺(tái)，而Spark也變成了在ASF中最為活躍的項(xiàng)目之一。另外，越來(lái)越多的大數(shù)據(jù)相關(guān)的產(chǎn)品也逐漸在和Spark相融合或者在向Spark遷移。Spark無(wú)疑將會(huì)變?yōu)橐粋€(gè)相比Hadoop MapReduce更好的生態(tài)系統(tǒng)，這無(wú)疑讓那些擁抱Spark的人更多了一份動(dòng)力。

當(dāng)然，由于我國(guó)互聯(lián)網(wǎng)領(lǐng)域?qū)park的研究和應(yīng)用還處于初級(jí)階段，再加上Spark本身存在很多不足，因此在應(yīng)用Spark時(shí)難免會(huì)出現(xiàn)一些問題和困難。

任何新技術(shù)的引入都會(huì)歷經(jīng)陌生到熟悉，從最初新技術(shù)帶來(lái)的驚喜，到后來(lái)遇到困難時(shí)的一籌莫展和惆悵，再到問題解決后的愉悅，大數(shù)據(jù)新貴Spark同樣不能免俗。鐘老師指出，目前，Spark在運(yùn)行時(shí)常常會(huì)出現(xiàn)以下兩個(gè)方面的問題：

問題一：支撐大規(guī)模數(shù)據(jù)集運(yùn)行時(shí)，會(huì)遇到org.apache.spark.SparkException: Error communicating with MapOutputTracke。

這個(gè)錯(cuò)誤的顯示往往比較隱晦，從錯(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ù)載過大。找到原因后，解決起來(lái)就很簡(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來(lái)提高性能。

問題二：運(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ì)顯著增長(zhǎng)。造成Fetch failure的根本原因則不盡相同。

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

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

Spark在2014年取得了長(zhǎ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來(lái)作為緩存層。另外，隨著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í)的力量來(lái)進(jìn)一步挖掘數(shù)據(jù)的價(jià)值。

最后，鐘老師總結(jié)道，相信隨著Spark生態(tài)的日益完善，會(huì)有越來(lái)越多的企業(yè)將自己的數(shù)據(jù)處理遷移到Spark上來(lái)。而伴隨著越來(lái)越多的大數(shù)據(jù)工程師熟悉和了解Spark，國(guó)內(nèi)的Spark社區(qū)也會(huì)越來(lái)越活躍，Spark作為一個(gè)開源的平臺(tái)，相信也會(huì)有越來(lái)越多的華人變成Spark相關(guān)項(xiàng)目的Contributor，Spark也會(huì)變得越來(lái)越成熟和強(qiáng)大。