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

美好的***印象

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

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

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

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

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

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

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

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

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

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

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