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

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

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

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

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

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

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

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

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

　　Spark流——微批處理的回歸

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

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

　　結(jié)束語

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

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