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

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

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

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

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

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

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

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

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

　　Spark流——微批處理的回歸

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

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

　　結束語

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

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