Apache Flink是什么
Flink是一款新的大數據處理引擎，目標是統一不同來源的數據處理。這個目標看起來和Spark和類似。沒錯，Flink也在嘗試解決 Spark在解決的問題。這兩套系統都在嘗試建立一個統一的平台可以運行批量，流式，交互式，圖處理，機器學習等應用。所以，Flink和Spark的目 標差別並不大，他們最主要的區別在於實現的細節，后面我會重點從不同的角度對比這兩者。
Apache Spark vs Apache Flink
1、抽象 Abstraction
Spark中，對於批處理我們有RDD,對於流式，我們有DStream，不過內部實際還是RDD.所以所有的數據表示本質上還是RDD抽象。 后面我會重點從不同的角度對比這兩者。在Flink中，對於批處理有DataSet，對於流式我們有DataStreams。看起來和Spark類似，他 們的不同點在於：
（一）DataSet在運行時是表現為運行計划(runtime plans)的
在Spark中，RDD在運行時是表現為java objects的。通過引入Tungsten，這塊有了些許的改變。但是在Flink中是被表現為logical plan(邏輯計划)的，聽起來很熟悉？沒錯，就是類似於Spark中的dataframes。所以在Flink中你使用的類Dataframe api是被作為第一優先級來優化的。但是相對來說在Spark RDD中就沒有了這塊的優化了。
Flink中的Dataset，對標Spark中的Dataframe，在運行前會經過優化。在Spark 1.6，dataset API已經被引入Spark了，也許最終會取代RDD 抽象。
(二）Dataset和DataStream是獨立的API
在Spark中，所有不同的API，例如DStream，Dataframe都是基於RDD抽象的。但是在Flink中，Dataset和 DataStream是同一個公用的引擎之上兩個獨立的抽象。所以你不能把這兩者的行為合並在一起操作，當然，Flink社區目前在朝這個方向努力(https://issues.apache.org/jira/browse/Flink-2320)，但是目前還不能輕易斷言最后的結果。
2、內存管理
一直到1.5版本，Spark都是試用java的內存管理來做數據緩存，明顯很容易導致OOM或者gc。所以從1.5開始，Spark開始轉向精確的控制內存的使用，這就是tungsten項目了。
而Flink從第一天開始就堅持自己控制內存試用。這個也是啟發了Spark走這條路的原因之一。Flink除了把數據存在自己管理的內存以 外，還直接操作二進制數據。在Spark中，從1.5開始，所有的dataframe操作都是直接作用在tungsten的二進制數據上。
3、語言實現
Spark是用scala來實現的，它提供了Java，Python和R的編程接口。Flink是java實現的，當然同樣提供了Scala API
所以從語言的角度來看，Spark要更豐富一些。因為我已經轉移到scala很久了，所以不太清楚這兩者的java api實現情況。
4、API
Spark和Flink都在模仿scala的collection API.所以從表面看起來，兩者都很類似。下面是分別用RDD和DataSet API實現的word count
不知道是偶然還是故意的，API都長得很像，這樣很方便開發者從一個引擎切換到另外一個引擎。我感覺以后這種Collection API會成為寫data pipeline的標配。
5、Steaming
Spark把streaming看成是更快的批處理，而Flink把批處理看成streaming的special case。這里面的思路決定了各自的方向，其中兩者的差異點有如下這些：
實時 vs 近實時的角度
Flink提供了基於每個事件的流式處理機制，所以可以被認為是一個真正的流式計算。它非常像storm的model。
而Spark，不是基於事件的粒度，而是用小批量來模擬流式，也就是多個事件的集合。所以Spark被認為是近實時的處理系統。
Spark streaming 是更快的批處理，而Flink Batch是有限數據的流式計算。
雖然大部分應用對准實時是可以接受的，但是也還是有很多應用需要event level的流式計算。這些應用更願意選擇storm而非Spark streaming，現在，Flink也許是一個更好的選擇。
6、SQL interface
目前Spark-sql是Spark里面最活躍的組件之一，Spark提供了類似Hive的sql和Dataframe這種DSL來查詢結構化 數據，API很成熟，在流式計算中使用很廣，預計在流式計算中也會發展得很快。至於Flink，到目前為止，Flink Table API只支持類似DataFrame這種DSL，並且還是處於beta狀態，社區有計划增加SQL 的interface，但是目前還不確定什么時候才能在框架中用上。所以這個部分，Spark勝出。
7、外部數據源的整合
Spark的數據源 API是整個框架中最好的，支持的數據源包括NoSql db,parquet,ORC等，並且支持一些高級的操作，例如predicate push down。Flink目前還依賴map/reduce InputFormat來做數據源聚合。這一場Spark勝
8、Iterative processing
Spark對機器學習的支持較好，因為可以在Spark中利用內存cache來加速機器學習算法。但是大部分機器學習算法其實是一個有環的數據流，但是在Spark中，實際是用無環圖來表示的，一般的分布式處理引擎都是不鼓勵試用有環圖的。但是 Flink這里又有點不一樣，Flink支持在runtime中的有環數據流，這樣表示機器學習算法更有效而且更有效率。這一點Flink勝出。
9、Stream as platform vs Batch as Platform
Spark誕生在Map/Reduce的時代，數據都是以文件的形式保存在磁盤中，這樣非常方便做容錯處理。Flink把純流式數據計算引入大 數據時代，無疑給業界帶來了一股清新的空氣。這個idea非常類似akka-streams這種。成熟度目前的確有一部分吃螃蟹的用戶已經在生產環境中使 用Flink了，不過從我的眼光來看，Flink還在發展中，還需要時間來成熟。
結論
目前Spark相比Flink是一個更為成熟的計算框架，但是Flink的很多思路很不錯，Spark社區也意識到了這一點，並且逐漸在采用Flink中的好的設計思路，所以學習一下Flink能讓你了解一下Streaming這方面的更迷人的思路。