作為通用的并行處理框架，Spark具有類似Hadoop的一些優(yōu)點(diǎn)，而且Spark采用了更好的內(nèi)存管理，在迭代計(jì)算上具有比Hadoop更高的效率，Spark還提供了更為廣泛的數(shù)據(jù)集操作類型，大大方便了用戶的開發(fā)，checkpoint的應(yīng)用使Spark具有很強(qiáng)容錯(cuò)能力，眾多優(yōu)越的性能和比Hadoop更廣泛的適用面讓Spark的進(jìn)一步發(fā)展值得期待。

　　Apache Spark現(xiàn)在名聲大噪。為支持Spark項(xiàng)目成立的 Databricks公司 從Andereessen Horowittz那里募集了1400萬(wàn)美元，Cloudera也已決定全力支持Spark，還有眾多其它公司也積極地加入這件大事。所以我覺得這正是我應(yīng)該認(rèn)真了解一下這場(chǎng)躁動(dòng)的時(shí)候。

　　我研究了一段時(shí)間的Scala API(用Scala寫的Spark)，老實(shí)說(shuō)一開始我很失望，因?yàn)镾park看起來(lái)真的太不起眼了?；镜某橄笫荝esilient Distributed Datasets(RDDs)和基本分布式不可變集，可以基于本地文件或通過HDFS存儲(chǔ)在Hadoop上的文件定義，提供常用的Scala-style集合操作(如映射，foreach等)。

　　我的***反應(yīng)是"沒搞錯(cuò)吧，這真是基本分布式集合嗎？"。相比之下Hadoop就顯得豐富多了：分布式文件系統(tǒng)，眾所周知的Map Reduce，支持所有類型的數(shù)據(jù)格式、 數(shù)據(jù)源、單元測(cè)試、聚類變量等。

　　其他人很快就指出還有更多，事實(shí)上Spark也提供更復(fù)雜的操作(如join、依據(jù)操作分組或規(guī)約)，這樣你就可以為相當(dāng)復(fù)雜的數(shù)據(jù)流建模(雖然沒有迭代)。

　　隨著時(shí)間的推移我恍然大悟，原來(lái)Spark所謂的簡(jiǎn)單其實(shí)說(shuō)的大多是關(guān)于Hadoop中的Java API而不是Spark本身。即使是簡(jiǎn)單的例子在Hadoop中通常也會(huì)有大量的樣板代碼。但從概念上講，Hadoop非常簡(jiǎn)單，它只提供了兩種基本操作：并行的映射(Map)和規(guī)約(Reduce)操作。如果用相同的方式，對(duì)表示相似分布式集合，事實(shí)上將有更小的接口(有些項(xiàng)目像 Scalding就是處理類似的事情，并且代碼看起來(lái)很類似Spark)。

　　Spark實(shí)際上提供了一組重要的操作，在這一點(diǎn)讓我信服以后，我通過這個(gè) 論文進(jìn)行了更深入的研究，它描述了通用的架構(gòu)。RDDs 是Spark的基本構(gòu)造模塊，實(shí)際上真的很像分布式不可變集。這些定義的操作(如map或foreach)，容易地進(jìn)行并行處理;還有join運(yùn)算，需要兩個(gè)RDDs和收集基于一個(gè)共同鍵的條目;以及依據(jù)操作規(guī)約，通過用戶指定基于鍵的函數(shù)來(lái)聚合條目。在單詞計(jì)數(shù)示例中，計(jì)數(shù)一次就將文本映射到所有的單詞，然后用鍵對(duì)他們進(jìn)行規(guī)約，以此來(lái)實(shí)現(xiàn)字?jǐn)?shù)統(tǒng)計(jì)。RDDs可以從磁盤中讀取，然后為提高速度而保留在內(nèi)存中，他們也可以被緩存，那樣你就不需要每次都重讀他們。僅那樣就比Hadoop快了很多，這大部分是基于磁盤的速度。

　　容錯(cuò)機(jī)制也是Spark的亮點(diǎn)之一。取代給中間結(jié)果進(jìn)行持久化或建立檢查點(diǎn)，Spark會(huì)記住產(chǎn)生某些數(shù)據(jù)集的操作序列。因此，當(dāng)一個(gè)節(jié)點(diǎn)出現(xiàn)故障時(shí)，Spark會(huì)根據(jù)存儲(chǔ)信息重新構(gòu)造數(shù)據(jù)集。他們認(rèn)為這樣也不錯(cuò)，因?yàn)槠渌?jié)點(diǎn)將會(huì)幫助重建。

　　所以本質(zhì)上，Spark相比純粹的Hadoop，有更小的接口(可能在將來(lái)也會(huì)變得臃腫)，但有許多基于之上的項(xiàng)目(例如像Twitter的 Scalding)達(dá)到了類似水平的表現(xiàn)。其他的主要區(qū)別是Spark默認(rèn)情況下是在內(nèi)存中，這自然帶來(lái)性能上很大的改善，甚至允許運(yùn)行的迭代算法。雖然Spark已也沒有內(nèi)置對(duì)迭代的支持，不過，就像他們宣稱的那樣：只要你想要，它就可以快到讓你可以進(jìn)行迭代。

　　Spark流——微批處理的回歸

　　Spark還配有一個(gè)流數(shù)據(jù)處理模型，這當(dāng)然讓我很感興趣。還有一篇對(duì)設(shè)計(jì)總結(jié)得很漂亮的 論文。與Twitter的 Storm框架相比，Spark采用了一種有趣而且獨(dú)特的辦法。Storm基本上是像是放入獨(dú)立事務(wù)的管道，在其中事務(wù)會(huì)得到分布式的處理。相反，Spark采用一個(gè)模型收集事務(wù)，然后在短時(shí)間內(nèi)(我們假設(shè)是5秒)以批處理的方式處理事件。所收集的數(shù)據(jù)成為他們自己的RDD，然后使用Spark應(yīng)用程序中常用的一組進(jìn)行處理。

　　作者聲稱這種模式是在緩慢節(jié)點(diǎn)和故障情況下會(huì)更加穩(wěn)健，而且5秒的時(shí)間間隔通常對(duì)于大多數(shù)應(yīng)用已經(jīng)足夠快了。對(duì)于這一點(diǎn)，我不太確定，因?yàn)榉植际接?jì)算總是很復(fù)雜，我不相信你能隨意說(shuō)有些東西是就比其他人的好。這種方法也很好地統(tǒng)一了流式處理與非流式處理部分，這一點(diǎn)是千真萬(wàn)確的。

　　結(jié)束語(yǔ)

　　Spark在我看來(lái)還是很有前途的，加上Spark被給予的支持和獲得的關(guān)注，我堅(jiān)信它將成熟起來(lái)并將在這個(gè)領(lǐng)域扮演更加重要的角色。當(dāng)然，它不可能適用于所有場(chǎng)景，正如作者承認(rèn)的那樣，基于RDD穩(wěn)定性只更改很少條目的操作就不適合。原則上，你必須對(duì)整個(gè)數(shù)據(jù)集備份，即使你只是想要更改一個(gè)條目。這可以很好地并行處理，但成本很高。copy-on-write在這里可能更有效，但是還未被實(shí)現(xiàn)。

　　最上層是在TU Berlin的研究項(xiàng)目，有類似的目標(biāo)，然而卻通過更為復(fù)雜的操作(如迭代)來(lái)發(fā)展，不僅是為了容錯(cuò)能力存儲(chǔ)一系列操作，而且要將它們用于全局調(diào)度優(yōu)化和平行化。