Apache Spark是大資料領域的下一個大傢伙嗎？

作者觀察到HTTP://www.aliyun.com/zixun/aggregation/14417.html">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