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

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

Spark VS MapReduce

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

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

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

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

由于其設(shè)計(jì)約束，MapReduce僅適用于離線計(jì)算。實(shí)時(shí)查詢(xún)和迭代計(jì)算仍然存在很大的不足。隨著業(yè)務(wù)的發(fā)展，業(yè)界對(duì)實(shí)時(shí)查詢(xún)和迭代分析的需求更多，僅依靠MapReduce。該框架不再能夠滿足業(yè)務(wù)需求。由于其可擴(kuò)展性，基于內(nèi)存的計(jì)算等，Spark可以直接在Hadoop上以任何格式讀寫(xiě)數(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)用場(chǎng)景的一般特征是大的計(jì)算復(fù)雜性和高效率要求。 Spark滿足了這些要求，該項(xiàng)目得到了開(kāi)源社區(qū)的廣泛關(guān)注和贊譽(yù)。在過(guò)去兩年中，它已發(fā)展成為大數(shù)據(jù)處理領(lǐng)域最受歡迎的開(kāi)源項(xiàng)目。

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

1.騰訊

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

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

2.雅虎

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

3.淘寶

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

4.優(yōu)酷土豆

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

最后，這些應(yīng)用場(chǎng)景不適合在MapReduce中處理。相比之下，發(fā)現(xiàn)Spark性能比MapReduce好得多。首先，交互式查詢(xún)響應(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ù)。