Park是Apache的頂級(jí)開源項(xiàng)目。有關(guān)項(xiàng)目主頁，請(qǐng)參閱http://spark.apache.org。迭代計(jì)算，交互式查詢計(jì)算和批量流量計(jì)算等相關(guān)子項(xiàng)目，如Shark，Spark Streaming，MLbase，GraphX，SparkR等。自13年以來，Spark一直舉辦自己的Spark Summit會(huì)議，會(huì)議地址為http://spark-summit.org。 Amplab Labs已經(jīng)建立了一個(gè)獨(dú)立的公司Databricks，以支持Spark的開發(fā)。

為了滿足挖掘分析和交互式實(shí)時(shí)查詢的計(jì)算需求，騰訊大數(shù)據(jù)使用Spark平臺(tái)支持挖掘分析計(jì)算，交互式實(shí)時(shí)查詢計(jì)算以及允許誤差范圍的快速查詢計(jì)算。目前，騰訊大數(shù)據(jù)已超過200個(gè)單位。 Spark集群并獨(dú)立維護(hù)Spark和Shark分支。 Spark集群已經(jīng)穩(wěn)定運(yùn)行了2年。我們積累了大量的案例和運(yùn)營經(jīng)驗(yàn)?zāi)芰Α４送猓喾N服務(wù)的大數(shù)據(jù)查詢和分析應(yīng)用程序已在線且穩(wěn)定。在SQL查詢性能方面，它通常比MapReduce高2倍多。使用內(nèi)存計(jì)算和內(nèi)存表功能，性能至少是10倍。在迭代計(jì)算和挖掘分析中，強(qiáng)烈建議將小時(shí)和日級(jí)模型訓(xùn)練轉(zhuǎn)換為Spark的分鐘級(jí)訓(xùn)練，而簡單的編程接口使得算法實(shí)現(xiàn)在時(shí)間成本和代碼大小方面遠(yuǎn)高于MR。

Spark VS MapReduce

盡管MapReduce適用于大多數(shù)批處理，并且是大數(shù)據(jù)時(shí)代企業(yè)大數(shù)據(jù)處理的首選技術(shù)，但由于以下限制，它在某些情況下并非最佳：

缺乏對(duì)迭代計(jì)算和DAG操作的支持。隨機(jī)處理多種類別和著陸，MR之間的數(shù)據(jù)需要落入Hdfs文件系統(tǒng)

在許多方面，Spark彌補(bǔ)了MapReduce的缺點(diǎn)，MapReduce優(yōu)于MapReduce，更有效的迭代操作和更低的作業(yè)延遲。它的主要優(yōu)點(diǎn)包括：

為支持DAG圖的分布式并行計(jì)算提供一組編程框架。減少多次計(jì)算之間的開銷。寫入Hdfs的開銷提供了一種Cache機(jī)制來支持IO，這需要迭代迭代或多個(gè)數(shù)據(jù)共享來減少數(shù)據(jù)讀取。 Overhead使用多線程池模型來減少task匯海的打開，避免在shuffle期間進(jìn)行不必要的排序操作，并減少磁盤IO操作。廣泛的數(shù)據(jù)集操作類型

由于其設(shè)計(jì)約束，MapReduce僅適用于離線計(jì)算。實(shí)時(shí)查詢和迭代計(jì)算仍然存在很大的不足。隨著業(yè)務(wù)的發(fā)展，業(yè)界對(duì)實(shí)時(shí)查詢和迭代分析的需求更多，僅依靠MapReduce。該框架不再能夠滿足業(yè)務(wù)需求。由于其可擴(kuò)展性，基于內(nèi)存的計(jì)算等，Spark可以直接在Hadoop上以任何格式讀寫數(shù)據(jù)，并成為滿足業(yè)務(wù)需求的最佳候選者。

應(yīng)用Spark的成功故事

目前，大數(shù)據(jù)主要用于互聯(lián)網(wǎng)公司的廣告，報(bào)告，推薦系統(tǒng)和其他服務(wù)。在廣告業(yè)務(wù)中，需要大數(shù)據(jù)進(jìn)行應(yīng)用分析，效果分析，定位優(yōu)化等。在推薦系統(tǒng)中，需要大數(shù)據(jù)優(yōu)化相關(guān)排名，個(gè)性化推薦和熱點(diǎn)點(diǎn)擊分析。

這些應(yīng)用場景的一般特征是大的計(jì)算復(fù)雜性和高效率要求。 Spark滿足了這些要求，該項(xiàng)目得到了開源社區(qū)的廣泛關(guān)注和贊譽(yù)。在過去兩年中，它已發(fā)展成為大數(shù)據(jù)處理領(lǐng)域最受歡迎的開源項(xiàng)目。

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

1.騰訊

Wide Point是最早使用Spark的應(yīng)用程序之一。騰訊大數(shù)據(jù)精確推薦具有Spark快速迭代的優(yōu)勢，圍繞“數(shù)據(jù)+算法+系統(tǒng)”技術(shù)解決方案，實(shí)現(xiàn)“數(shù)據(jù)實(shí)時(shí)采集，算法實(shí)時(shí)訓(xùn)練，系統(tǒng)實(shí)時(shí)預(yù)測”全程處理并行高維算法，最后，它成功應(yīng)用于廣泛的pCTR傳送系統(tǒng)，支持?jǐn)?shù)百億的日常請(qǐng)求。

基于日志數(shù)據(jù)，快速查詢系統(tǒng)服務(wù)建立在Spark上。 Shark利用其快速查詢和內(nèi)存表來進(jìn)行日志數(shù)據(jù)的即席查詢。在性能方面，它通常比Hive高2-10倍。如果使用內(nèi)存表的功能，性能將比Hive快100倍。

2.雅虎

雅虎在Audience Expansion中將Spark用于應(yīng)用程序。受眾群體擴(kuò)展是廣告客戶找到目標(biāo)用戶的一種方式：首先，廣告客戶提供觀看廣告和購買產(chǎn)品的樣本客戶，并學(xué)習(xí)如何找到更多潛在用戶并定位他們。雅虎使用的算法是邏輯回歸。同時(shí)，由于某些SQL工作負(fù)載需要更高的服務(wù)質(zhì)量，因此添加了專門用于Shark的大型內(nèi)存集群來替換商業(yè)BI/OLAP工具，進(jìn)行報(bào)表/儀表板和交互式/即席查詢，同時(shí)與桌面BI工具對(duì)接。目前在雅虎部署的Spark集群有112個(gè)節(jié)點(diǎn)和9.2TB的內(nèi)存。

3.淘寶

阿里搜索和廣告業(yè)務(wù)，最初使用Mahout或自編MR來解決復(fù)雜的機(jī)器學(xué)習(xí)，導(dǎo)致效率低下且代碼不易保護(hù)。淘寶技術(shù)團(tuán)隊(duì)使用Spark來解決具有高計(jì)算復(fù)雜度的多次迭代和算法的機(jī)器學(xué)習(xí)算法。將Spark應(yīng)用于淘寶的推薦相關(guān)算法，它也解決了Graphx的許多生產(chǎn)問題，包括以下計(jì)算場景：基于度分布的中心節(jié)點(diǎn)發(fā)現(xiàn)，基于最大連通圖的社區(qū)發(fā)現(xiàn)，基于三角計(jì)數(shù)的關(guān)系測量，基于用戶隨機(jī)游走的屬性傳播等。

4.優(yōu)酷土豆

優(yōu)酷在使用Hadoop集群時(shí)遇到的突出問題包括：首先是BI，分析師需要等待很長時(shí)間才能在提交任務(wù)后獲得結(jié)果;二是大數(shù)據(jù)的計(jì)算，例如在進(jìn)行一些模擬廣告時(shí)，計(jì)算量非常大，效率要求也比較高。最后，機(jī)器學(xué)習(xí)和圖形計(jì)算的迭代操作也需要大量資源并且非常慢。

最后，這些應(yīng)用場景不適合在MapReduce中處理。相比之下，發(fā)現(xiàn)Spark性能比MapReduce好得多。首先，交互式查詢響應(yīng)速度快，性能比Hadoop高幾倍;模擬廣告投放計(jì)算效率高，延遲小（與hadoop相比，順序減少至少一個(gè)數(shù)量級(jí)）;機(jī)器學(xué)習(xí)和圖形計(jì)算等迭代計(jì)算大大減少了網(wǎng)絡(luò)傳輸和數(shù)據(jù)。登陸等，大大提高了計(jì)算性能。目前，Spark廣泛使用了優(yōu)酷土豆的視頻推薦（圖形計(jì)算）和廣告業(yè)務(wù)。