park作為Apache頂級的開源項目，項目主頁見http://spark.apache.org。在迭代計算，交互式查詢計算以及批量流計算方面都有相關(guān)的子項目，如Shark、Spark Streaming、MLbase、GraphX、SparkR等。從13年起Spark開始舉行了自已的Spark Summit會議，會議網(wǎng)址見http://spark-summit.org。Amplab實驗室單獨成立了獨立公司Databricks來支持Spark的研發(fā)。

為了滿足挖掘分析與交互式實時查詢的計算需求，騰訊大數(shù)據(jù)使用了Spark平臺來支持挖掘分析類計算、交互式實時查詢計算以及允許誤差范圍的快速查詢計算，目前騰訊大數(shù)據(jù)擁有超過200臺的Spark集群，并獨立維護Spark和Shark分支。Spark集群已穩(wěn)定運行2年，我們積累了大量的案例和運營經(jīng)驗?zāi)芰Γ硗舛鄠€業(yè)務(wù)的大數(shù)據(jù)查詢與分析應(yīng)用，已在陸續(xù)上線并穩(wěn)定運行。在SQL查詢性能方面普遍比MapReduce高出2倍以上，利用內(nèi)存計算和內(nèi)存表的特性，性能至少在10倍以上。在迭代計算與挖掘分析方面，精準推薦將小時和天級別的模型訓練轉(zhuǎn)變?yōu)镾park的分鐘級別的訓練，同時簡潔的編程接口使得算法實現(xiàn)比MR在時間成本和代碼量上高出許多。

Spark VS MapReduce

盡管MapReduce適用大多數(shù)批處理工作，并且在大數(shù)據(jù)時代成為企業(yè)大數(shù)據(jù)處理的首選技術(shù)，但由于以下幾個限制，它對一些場景并不是最優(yōu)選擇：

• 缺少對迭代計算以及DAG運算的支持
• Shuffle過程多次排序和落地，MR之間的數(shù)據(jù)需要落Hdfs文件系統(tǒng)

Spark在很多方面都彌補了MapReduce的不足，比MapReduce的通用性更好，迭代運算效率更高，作業(yè)延遲更低，它的主要優(yōu)勢包括：

• 提供了一套支持DAG圖的分布式并行計算的編程框架，減少多次計算之間中間結(jié)果寫到Hdfs的開銷
• 提供Cache機制來支持需要反復(fù)迭代計算或者多次數(shù)據(jù)共享，減少數(shù)據(jù)讀取的IO開銷
• 使用多線程池模型來減少task啟動開稍，shuffle過程中避免不必要的sort操作以及減少磁盤IO操作
• 廣泛的數(shù)據(jù)集操作類型

MapReduce由于其設(shè)計上的約束只適合處理離線計算，在實時查詢和迭代計算上仍有較大的不足，而隨著業(yè)務(wù)的發(fā)展，業(yè)界對實時查詢和迭代分析有更多的需求，單純依靠MapReduce框架已經(jīng)不能滿足業(yè)務(wù)的需求了。Spark由于其可伸縮、基于內(nèi)存計算等特點，且可以直接讀寫Hadoop上任何格式的數(shù)據(jù)，成為滿足業(yè)務(wù)需求的最佳候選者。

應(yīng)用Spark的成功案例

目前大數(shù)據(jù)在互聯(lián)網(wǎng)公司主要應(yīng)用在廣告、報表、推薦系統(tǒng)等業(yè)務(wù)上。在廣告業(yè)務(wù)方面需要大數(shù)據(jù)做應(yīng)用分析、效果分析、定向優(yōu)化等，在推薦系統(tǒng)方面則需要大數(shù)據(jù)優(yōu)化相關(guān)排名、個性化推薦以及熱點點擊分析等。

這些應(yīng)用場景的普遍特點是計算量大、效率要求高。Spark恰恰滿足了這些要求，該項目一經(jīng)推出便受到開源社區(qū)的廣泛關(guān)注和好評。并在近兩年內(nèi)發(fā)展成為大數(shù)據(jù)處理領(lǐng)域最炙手可熱的開源項目。

本章將列舉國內(nèi)外應(yīng)用Spark的成功案例。

1. 騰訊

廣點通是最早使用Spark的應(yīng)用之一。騰訊大數(shù)據(jù)精準推薦借助Spark快速迭代的優(yōu)勢，圍繞“數(shù)據(jù)+算法+系統(tǒng)”這套技術(shù)方案，實現(xiàn)了在“數(shù)據(jù)實時采集、算法實時訓練、系統(tǒng)實時預(yù)測”的全流程實時并行高維算法，最終成功應(yīng)用于廣點通pCTR投放系統(tǒng)上，支持每天上百億的請求量。

基于日志數(shù)據(jù)的快速查詢系統(tǒng)業(yè)務(wù)構(gòu)建于Spark之上的Shark，利用其快速查詢以及內(nèi)存表等優(yōu)勢，承擔了日志數(shù)據(jù)的即席查詢工作。在性能方面，普遍比Hive高2-10倍，如果使用內(nèi)存表的功能，性能將會比Hive快百倍。

2. Yahoo

Yahoo將Spark用在Audience Expansion中的應(yīng)用。Audience Expansion是廣告中尋找目標用戶的一種方法：首先廣告者提供一些觀看了廣告并且購買產(chǎn)品的樣本客戶，據(jù)此進行學習，尋找更多可能轉(zhuǎn)化的用戶，對他們定向廣告。Yahoo采用的算法是logistic regression。同時由于有些SQL負載需要更高的服務(wù)質(zhì)量，又加入了專門跑Shark的大內(nèi)存集群，用于取代商業(yè)BI/OLAP工具，承擔報表/儀表盤和交互式/即席查詢，同時與桌面BI工具對接。目前在Yahoo部署的Spark集群有112臺節(jié)點，9.2TB內(nèi)存。

3. 淘寶

阿里搜索和廣告業(yè)務(wù)，最初使用Mahout或者自己寫的MR來解決復(fù)雜的機器學習，導(dǎo)致效率低而且代碼不易維護。淘寶技術(shù)團隊使用了Spark來解決多次迭代的機器學習算法、高計算復(fù)雜度的算法等。將Spark運用于淘寶的推薦相關(guān)算法上,同時還利用Graphx解決了許多生產(chǎn)問題，包括以下計算場景：基于度分布的中樞節(jié)點發(fā)現(xiàn)、基于最大連通圖的社區(qū)發(fā)現(xiàn)、基于三角形計數(shù)的關(guān)系衡量、基于隨機游走的用戶屬性傳播等。

4. 優(yōu)酷土豆

優(yōu)酷土豆在使用Hadoop集群的突出問題主要包括：第一是商業(yè)智能BI方面，分析師提交任務(wù)之后需要等待很久才得到結(jié)果；第二就是大數(shù)據(jù)量計算，比如進行一些模擬廣告投放之時，計算量非常大的同時對效率要求也比較高，最后就是機器學習和圖計算的迭代運算也是需要耗費大量資源且速度很慢。

最終發(fā)現(xiàn)這些應(yīng)用場景并不適合在MapReduce里面去處理。通過對比，發(fā)現(xiàn)Spark性能比MapReduce提升很多。首先，交互查詢響應(yīng)快，性能比Hadoop提高若干倍；模擬廣告投放計算效率高、延遲小（同hadoop比延遲至少降低一個數(shù)量級）；機器學習、圖計算等迭代計算，大大減少了網(wǎng)絡(luò)傳輸、數(shù)據(jù)落地等，極大的提高的計算性能。目前Spark已經(jīng)廣泛使用在優(yōu)酷土豆的視頻推薦（圖計算）、廣告業(yè)務(wù)等。