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

美好的***印象

作者認(rèn)為自己已經(jīng)與Scala的API(Spark使用Scala編寫)打交道了一段時(shí)間，說實(shí)話，起初是相當(dāng)深刻的印象，因?yàn)镾park是看上去這么小而好?；镜某橄笫怯袕椥苑植际綌?shù)據(jù)集（RDD），以及基本上分布的不可改變集合，可以基于本地文件定義后通過HDFS存儲(chǔ)在Hadoop中，并提供諸如Scala風(fēng)格的map foreach等函數(shù)操作。 

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

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

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

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

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

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

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

這種模式是對慢節(jié)點(diǎn)和容錯(cuò)更健壯，同時(shí)又有5秒的時(shí)間間隔通常是足夠快于大多數(shù)應(yīng)用。我不是很確定這一點(diǎn)，因?yàn)榉植际接?jì)算總是非常復(fù)雜的，這種方法使用非實(shí)時(shí)流部分很好地統(tǒng)一了實(shí)時(shí)流處理，這當(dāng)然是正確的。

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

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