我們是否還需要另外一個新的數(shù)據(jù)處理引擎？當我第一次聽到flink的時候這是我是非常懷疑的。在大數(shù)據(jù)領域，現(xiàn)在已經(jīng)不缺少數(shù)據(jù)處理框架了，但是沒有一個框架能夠完全滿足不同的處理需求。自從Apache spark出現(xiàn)后，貌似已經(jīng)成為當今把大部分的問題解決得最好的框架了，所以我對另外一款解決類似問題的框架持有很強烈的懷疑態(tài)度。
不過因為好奇，我花費了數(shù)個星期在嘗試了解flink。一開始仔細看了flink的幾個例子，感覺和spark非常類似，心理就傾向于認為flink又是一個模仿spark的框架。但是隨著了解的深入，這些API體現(xiàn)了一些flink的新奇的思路，這些思路還是和spark有著比較明顯的區(qū)別的。我對這些思路有些著迷了，所以花費了更多的時間在這上面。
flink中的很多思路，例如內(nèi)存管理，dataset API都已經(jīng)出現(xiàn)在spark中并且已經(jīng)證明 這些思路是非?？孔V的。所以，深入了解flink也許可以幫助我們分布式數(shù)據(jù)處理的未來之路是怎樣的
在后面的文章里，我會把自己作為一個spark開發(fā)者對flink的第一感受寫出來。因為我已經(jīng)在spark上干了2年多了，但是只在flink上接觸了2到3周，所以必然存在一些bias，所以大家也帶著懷疑和批判的角度來看這篇文章吧。
Apache Flink是什么
flink是一款新的大數(shù)據(jù)處理引擎，目標是統(tǒng)一不同來源的數(shù)據(jù)處理。這個目標看起來和spark和類似。沒錯，flink也在嘗試解決spark在解決的問題。這兩套系統(tǒng)都在嘗試建立一個統(tǒng)一的平臺可以運行批量，流式，交互式，圖處理，機器學習等應用。所以，flink和spark的目標差別并不大，他們最主要的區(qū)別在于實現(xiàn)的細節(jié)。
后面我會重點從不同的角度對比這兩者。
Apache Spark vs Apache Flink
1.抽象 Abstraction
spark中，對于批處理我們有RDD,對于流式，我們有DStream，不過內(nèi)部實際還是RDD.所以所有的數(shù)據(jù)表示本質(zhì)上還是RDD抽象。
后面我會重點從不同的角度對比這兩者。在flink中，對于批處理有DataSet，對于流式我們有DataStreams?？雌饋砗蛃park類似，他們的不同點在于：
一）DataSet在運行時是表現(xiàn)為運行計劃(runtime plans)的
在spark中，RDD在運行時是表現(xiàn)為java objects的。通過引入Tungsten，這塊有了些許的改變。但是在flink中是被表現(xiàn)為logical plan(邏輯計劃)的，聽起來很熟悉？沒錯，就是類似于spark中的dataframes。所以在flink中你使用的類Dataframe api是被作為第一優(yōu)先級來優(yōu)化的。但是相對來說在spark RDD中就沒有了這塊的優(yōu)化了。
flink中的Dataset，對標spark中的Dataframe，在運行前會經(jīng)過優(yōu)化。
在spark 1.6，dataset API已經(jīng)被引入spark了，也許最終會取代RDD 抽象。
二）Dataset和DataStream是獨立的API
在spark中，所有不同的API，例如DStream，Dataframe都是基于RDD抽象的。但是在flink中，Dataset和DataStream是同一個公用的引擎之上兩個獨立的抽象。所以你不能把這兩者的行為合并在一起操作，當然，flink社區(qū)目前在朝這個方向努力(https://issues.apache.org/jira/browse/FLINK-2320)，但是目前還不能輕易斷言最后的結果。
2.內(nèi)存管理
一直到1.5版本，spark都是試用java的內(nèi)存管理來做數(shù)據(jù)緩存，明顯很容易導致OOM或者gc。所以從1.5開始，spark開始轉向精確的控制內(nèi)存的使用，這就是tungsten項目了
flink從第一天開始就堅持自己控制內(nèi)存試用。這個也是啟發(fā)了spark走這條路的原因之一。flink除了把數(shù)據(jù)存在自己管理的內(nèi)存以外，還直接操作二進制數(shù)據(jù)。在spark中，從1.5開始，所有的dataframe操作都是直接作用在tungsten的二進制數(shù)據(jù)上。

3.語言實現(xiàn)
spark是用scala來實現(xiàn)的，它提供了Java，Python和R的編程接口。
flink是java實現(xiàn)的，當然同樣提供了Scala API
所以從語言的角度來看，spark要更豐富一些。因為我已經(jīng)轉移到scala很久了，所以不太清楚這兩者的java api實現(xiàn)情況。
4.API
spark和flink都在模仿scala的collection API.所以從表面看起來，兩者都很類似。下面是分別用RDD和DataSet API實現(xiàn)的word count

// Spark wordcount
object WordCount {

def main(args: Array[String]) {

val env = new SparkContext("local","wordCount")

val data = List("hi","how are you","hi")

val dataSet = env.parallelize(data)

val words = dataSet.flatMap(value => value.split("\\s+"))

val mappedWords = words.map(value => (value,1))

val sum = mappedWords.reduceByKey(_+_)

println(sum.collect())

}

}

// Flink wordcount
object WordCount {

def main(args: Array[String]) {

val env = ExecutionEnvironment.getExecutionEnvironment

val data = List("hi","how are you","hi")

val dataSet = env.fromCollection(data)

val words = dataSet.flatMap(value => value.split("\\s+"))

val mappedWords = words.map(value => (value,1))

val grouped = mappedWords.groupBy(0)

val sum = grouped.sum(1)

println(sum.collect())
}

}
不知道是偶然還是故意的，API都長得很像，這樣很方便開發(fā)者從一個引擎切換到另外一個引擎。我感覺以后這種Collection API會成為寫data pipeline的標配。
Steaming
spark把streaming看成是更快的批處理，而flink把批處理看成streaming的special case。這里面的思路決定了各自的方向，其中兩者的差異點有如下這些：

實時 vs 近實時的角度
flink提供了基于每個事件的流式處理機制，所以可以被認為是一個真正的流式計算。它非常像storm的model。
而spark，不是基于事件的粒度，而是用小批量來模擬流式，也就是多個事件的集合。所以spark被認為是近實時的處理系統(tǒng)。

Spark streaming 是更快的批處理，而Flink Batch是有限數(shù)據(jù)的流式計算。
雖然大部分應用對準實時是可以接受的，但是也還是有很多應用需要event level的流式計算。這些應用更愿意選擇storm而非spark streaming，現(xiàn)在，flink也許是一個更好的選擇。

流式計算和批處理計算的表示
spark對于批處理和流式計算，都是用的相同的抽象：RDD，這樣很方便這兩種計算合并起來表示。而flink這兩者分為了DataSet和DataStream，相比spark，這個設計算是一個糟糕的設計。

對 windowing 的支持
因為spark的小批量機制，spark對于windowing的支持非常有限。只能基于process time，且只能對batches來做window。
而Flink對window的支持非常到位，且Flink對windowing API的支持是相當給力的，允許基于process time,data time,record 來做windowing。
我不太確定spark是否能引入這些API，不過到目前為止，F(xiàn)link的windowing支持是要比spark好的。
Steaming這部分flink勝

SQL interface
目前spark-sql是spark里面最活躍的組件之一，Spark提供了類似Hive的sql和Dataframe這種DSL來查詢結構化數(shù)據(jù)，API很成熟，在流式計算中使用很廣，預計在流式計算中也會發(fā)展得很快。
至于flink，到目前為止，F(xiàn)link Table API只支持類似DataFrame這種DSL，并且還是處于beta狀態(tài)，社區(qū)有計劃增加SQL 的interface，但是目前還不確定什么時候才能在框架中用上。
所以這個部分，spark勝出。

Data source Integration

Spark的數(shù)據(jù)源 API是整個框架中最好的，支持的數(shù)據(jù)源包括NoSql db,parquet,ORC等，并且支持一些高級的操作，例如predicate push down
Flink目前還依賴map/reduce InputFormat來做數(shù)據(jù)源聚合。
這一場spark勝

Iterative processing
spark對機器學習的支持較好，因為可以在spark中利用內(nèi)存cache來加速機器學習算法。
但是大部分機器學習算法其實是一個有環(huán)的數(shù)據(jù)流，但是在spark中，實際是用無環(huán)圖來表示的，一般的分布式處理引擎都是不鼓勵試用有環(huán)圖的。
但是flink這里又有點不一樣，flink支持在runtime中的有環(huán)數(shù)據(jù)流，這樣表示機器學習算法更有效而且更有效率。
這一點flink勝出。

Stream as platform vs Batch as Platform
Spark誕生在Map/Reduce的時代，數(shù)據(jù)都是以文件的形式保存在磁盤中，這樣非常方便做容錯處理。
Flink把純流式數(shù)據(jù)計算引入大數(shù)據(jù)時代，無疑給業(yè)界帶來了一股清新的空氣。這個idea非常類似akka-streams這種。
成熟度
目前的確有一部分吃螃蟹的用戶已經(jīng)在生產(chǎn)環(huán)境中使用flink了，不過從我的眼光來看，F(xiàn)link還在發(fā)展中，還需要時間來成熟。
結論
目前Spark相比Flink是一個更為成熟的計算框架，但是Flink的很多思路很不錯，Spark社區(qū)也意識到了這一點，并且逐漸在采用Flink中的好的設計思路，所以學習一下Flink能讓你了解一下Streaming這方面的更迷人的思路。