作者觀察到Apache Spark 最近發(fā)出一些不同尋常的事件，Databricks將提供$14M美金支持Spark，Cloudera決定支持Spark，Spark被認為是大數(shù)據(jù)領域的大事情。

美好的***印象

作者認為自己已經(jīng)與Scala的API(Spark使用Scala編寫)打交道了一段時間，說實話，起初是相當深刻的印象，因為Spark是看上去這么小而好。基本的抽象是有彈性分布式數(shù)據(jù)集（RDD），以及基本上分布的不可改變集合，可以基于本地文件定義后通過HDFS存儲在Hadoop中，并提供諸如Scala風格的map foreach等函數(shù)操作。 

給人的***反應是“等等，這是基本的分布式集合嗎？”Hadoop可比這多得多，分布式文件系統(tǒng)，特別是Map Reduce，支持各種數(shù)據(jù)格式，數(shù)據(jù)來源，單元測試，集群變種的支持等等。

當然Spark也支持更復雜的操作如joins, group-by, 或reduce-by 操作，可以建模復雜的數(shù)據(jù)流。

隨著時間的推移，開始明白了Spark的簡約是針對Hadoop的Java API。在Hadoop中即使最簡單你的案例也有不少代碼。但是從概念上說，Hadoop是很簡單的，因為它僅提供了兩個基本的操作，并行的mao和一個reduce操作。如果在對一些類似的分布式集合以同樣的方式表達，其實只有一個更小的接口（如Scalding的一些項目實際構建這樣的事情，代碼看起來與SPark非常相似）。

為了說服自己，作者繼續(xù)研究，發(fā)現(xiàn)Spark實際提供了一個不平凡的操作集 ，RDD是Spark的基本構建塊，類似分布的不可變集合。象map湖泊foreach等操作很容易并行操作，而且實現(xiàn)兩個RDD和集合的基于一個共同Key的Join操作。也能基于一個Key使用用戶定義的功能實現(xiàn)聚合reduce操作。

在字數(shù)統(tǒng)計的例子，你能map一段文本的所有文字，然后通過單詞reduce他們，***總結(jié)出單詞的個數(shù)。RDD能夠從磁盤讀取然后保持在內(nèi)存中，提高了性能，這和Hadoop大部分基于磁盤的速度要快多。

有趣的是Spark容錯方式。取代持久或檢查點中間結(jié)果，Spark記住導致某個數(shù)據(jù)集的操作順序(banq注：類似EventSourcing，記住導致狀態(tài)的系列事件)。因此，當一個節(jié)點出現(xiàn)故障時，Spark會重建基于存儲的數(shù)據(jù)集。他們認為，這其實并不壞，因為其他節(jié)點將幫助重建。因此，在本質(zhì)上，相對于基本原始的Hadoop，Spark具有更小的接口（其中仍可能成為未來同樣臃腫），但也有很多項目在Hadoop之上（比如Twitter的Scalding，），它實現(xiàn)了一個類似的水平表現(xiàn)力。其它主要區(qū)別在于，Spark是默認情況下在內(nèi)存，這自然導致了性能改善，并且甚至允許運行的迭代算法。Spark沒有內(nèi)置的迭代支持，不過，這只是他們聲稱它是如此之快，你可以運行迭代，如果你想

Spark還帶有一個數(shù)據(jù)流處理模式，這是一個文件，該文件概述了設計是相當不錯。Spark因此與Twitter的Storm框架不同之處。Storm基本上是一個管道，你推入獨立的事件，然后得到以分布式方式的處理結(jié)果。相反，Spark那里事件是收集的，然后在很短的時間間隔內(nèi)（假設每5秒）以批處理方式處理。所收集的數(shù)據(jù)成為自己一個RDD，然后使用通常的一套Spark應用進行處理。

這種模式是對慢節(jié)點和容錯更健壯，同時又有5秒的時間間隔通常是足夠快于大多數(shù)應用。我不是很確定這一點，因為分布式計算總是非常復雜的，這種方法使用非實時流部分很好地統(tǒng)一了實時流處理，這當然是正確的。

由于RDD的不可變性，如果你需要對一些數(shù)據(jù)項目進行少量改變，你得自己做一個整個數(shù)據(jù)集的拷貝，這可以使用并行完成，但是當然也是有成本的，基于Copy-on-write的實現(xiàn)也許在這里更有效，但是如今還沒有實現(xiàn)。

原文鏈接：http://www.jdon.com/46098