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

banq發表於2014-01-20
ApacheSpark大資料


Spark是一個基於記憶體in-memory資料處理平臺，相容於Hadoop 資料來源但是比Hadoop MapReduce執行得快得多。.特別適合於機器學習處理。

該文作者觀察到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非常相似）。

為了說服自己，作者繼續研究，發現星火後實際提供了一個不平凡的操作集 ，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的實現也許在這裡更有效，但是如今還沒有實現。

不變性是很時尚，但是也會遭到質疑，推薦一篇關於現實中可變和不可變資料混合策略的文章


[該貼被banq於2014-01-20 09:41修改過]

相關文章