Apache Flink和Apache Spark有什麼異同？它們的發展前景分別怎樣？

01-29

發布

對Flink不是很了解，但是Spark目前的勢頭不可否認是蒸蒸日上，得到了業界（比如Hadoop的頭號選手Cloudera）的大力支持，很多傳統Hadoop生態系統裡面的玩家比如機器學習的頂級項目Mahout已經明確轉向Spark。另外資本市場也看好它，願意投資。從這個勢頭來看，Flink要搶Spark的光環很難。

就技術而言，我在mitbbs上偶然看到Spark的核心開發者之一的Reynold-Xin 對類似問題的回答，很精彩。我全文引用到這裡，大家看看他是怎麼看這個問題的。

——————————————————以下是引用————————————-——————

樓主會這麼說應該對兩個項目本身和項目背後的團隊都不是很了解吧。Spark並不是一

個in-memory Hadoop。關於這個，可以參見我Quora的回答： Quora - The best answer to any question

How-does-Apache-Spark-work/answer/Reynold-Xin

Flink以前名字叫做Stratosphere，其實和Spark一樣也有五年的歷史了，但是一直不溫

不火的。成熟度比Spark差了很遠，參與Flink社區的人不到Spark的五分之一。

個人意見：Flink之所以不溫不火的一個原因就是用了太多資料庫的傳統設計，反而忽略

了這些設計對實際應用的阻礙。很多這些設計在SQL query上是很有價值的，但是對於

general program卻可能得不償失。

比如說Flink一直比較崇尚從頭到尾的declarative，希望你把整個程序從頭到尾的都用

他的框架來寫。比如一個簡單的while/for loop，本來編程語言裡面已經有內置的loop

了，但是他卻強迫用戶利用他框架內置的loop的API。這樣子的下場是程序員如果要用

這個框架，反而需要去學習更多的東西。

另外一個例子是內存管理。Flink的內存管理其實沒有什麼特別的，在Spark內部也有一

個把Java object serialize了當做bytes存儲的模式，但是Spark可以支持把東西存儲

成bytes，也可以支持把東西存儲成Java object本身。雖然存儲成Java object本身代

價比較高，但是在很多應用下卻大大方便了用戶，使得用戶更簡易的編程。如果Spark

從一開始就強迫用戶必須把數據按照bytes來儲存，很多現有的Spark演算法可能實現程度

就要高好幾個台階。

我個人覺得Spark這種更分層的設計從長遠來說是更有活力和價值的。RDD本身就是一個

特別general的physical execution engine，然後在RDD之上通過Spark SQL實現了

DataFrame和SQL，適合structured data processing。因為DataFrame和SQL帶給了

engine本身更多的信息，所以可以實現一個更好的optimizer來優化實行。這個詳細請

參見我們SIGMOD 2015的論文： Deep Dive Into Databricks』 Big Speedup Plans for Apache Spark

-into-spark-sqls-catalyst-optimizer.html

Flink從去年開始有了一個明顯的趨勢，就是學習Spark。很多他們本來覺得特別好的設

計，他們現在都開始推翻，改成Spark的模式（比如說loop，action）。Road map的設

計其實可以用一句話來概括：「趕緊加上我們還沒有但是Spark有的。」代碼裡面Scala

的數目也越來越多，很多新的代碼都是完全用Scala寫的，拋棄了原來的Java。

說「學習」其實是比較客氣的話。仔細對比一下的話你會發現今年加入到Flink裡面的

代碼其實有很多和Spark的十分相似。有一小部分他們會在注釋裡面寫明是「參照」

Spark實現的（比如說ALS），有很多就直接原封不動的拷貝過去之後改了改函數和變數

名（比如說analyzer, optimizer, code generator），有點類似本科生作業作弊的感

覺。我本人貢獻給Spark的一些代碼就被他們原封不動的給絆倒了他們的代碼庫裡面。

甚至有些地方在API裡面還會有他們忘記刪掉的「Spark」出現。有時候我看了這些也覺

得比較搞笑，有一些我自己知道是錯誤的設計，但是因為時間關係暫時放在了Spark代

碼裡面，準備以後改掉，不過沒多久這些錯誤的設計就出現在了Flink代碼裡面。不好

意思負面的東西說多了。

對於Spark設計我目前最大的不滿其實是RDD這個層面只是非常接近physical，但並不是

完全physical的（有一部分pipelining的優化）。如果重新設計Spark的話，我會主張

做出一個完全physical的layer。不過這個主要是出於代碼純粹性的考慮，對上層實現

其實沒有多大影響。以後基於DataFrame/SQL，Spark還會有很多優化的空間。傳統數據

庫的設計其實很簡單，大多數在analytics上也比較過時了。資料庫領域最近幾年在

analtyical query processing性能優化上有很多新穎的想法（比如說Hyper, X100, C-

Store/Vertica，DB2 BLU），我們會選擇性的在Spark上實現。我最近寫了一個新的

design doc，目前還沒有公開，預計接下來一兩個禮拜會發布出來，歡迎樓主指教。

Introduction to Apache Flink for Spark Developers : Flink vs Spark

雖然翻譯的還行，但也不能就說你是的觀點吧

剛過去看了看flink最近的發展，然後又回到spark的主頁上去看了看，我個人感覺，spark落後了

flink其實本質上就是直接借(chao)鑒(xi) spark的產物，就猶如spark對於hdmr的改良一樣，但是區別在於，flink在streaming上，比spark的設計要更為良好，spark的stream應該都很清楚了，是microbatch，本質上並不是嚴格的stream，flink將dataset分為batch和stream，我覺得是一個非常好的思路，因為本質上就不是一個東西，然後同時，flink對於業界的痛點也比較關心，具體表現在：

1）多語言的支持，比如一開始就提供了table api，就是sql的支持啦，當然不可能支持全部的sql標準，但是能支持多少是多少，這對於習慣了舊版本db的dba來說，是一個福音

2）python的支持，鑒於很多data scientists都是物理等專業出身，所以對於java，scala不熟悉也是正常的，估計學習時候都在寫python，所以這個介面很有必要，spark本身也有

3）clojure的支持，誒，有趣了，lisp的支持，fp的支持，這個spark還沒有，而且fp本來就是學術圈自娛自樂的東西，但是不管是不是自娛自樂，這個就是一個剛需和痛點，難道你不認為lisp家族比scala這種fp和oop的混雜語言要強不少？至少對於狂熱的fp愛好者而言

4）R的支持，我的天，這個痛點太精準了，所謂big data是什麼？到後面不就是應用統計學嗎？一開始線性代數，後面就是各種統計模型的應用啊，統計學生最擅長用啥？R嘛，不信你自己去問問，sas是商業收費的玩意，不可能讓apache提供介面

5）跟apache其它項目的對接，比如storm，比如tez

還有好些個項目還在孵化器階段就開始對接了

Apache Flink: Community

以上僅僅是個人的觀感，好久沒關注spark了，也許spark 2.0版本發布之後做了很多改變也未可知，但是總體感覺，flink的設計以及對於現實中痛點的把握，要比spark好一點

1、Spark在SQL上的優化，尤其是DataFrame到DataSet其實是借鑒的Flink的。Flink最初一開始對SQL支持得就更好。

2、Spark的cache in memory在Flink中是由框架自己判斷的，而不是用戶來指定的，因為Flink對數據的處理不像Spark以RDD為單位，就是一種細粒度的處理，對內存的規劃更好。

3、Flink原來用Java寫確實很難看，現在也在向Spark靠攏，Scala的支持也越來越好。不管怎麼說，二者目前都是在相互吸收。

PS：聽大師兄說，其實Flink一開始確實做得比Spark要好，但是沒人家會宣傳，投的會議也沒有Spark好，也就不溫不火了。我們組都準備轉向Flink了，確實挺看好Flink的。華為不是還戰略性投資Flink嗎，Flink還是挺不錯的。

flink是一個類似spark的「開源技術棧」，因為它也提供了批處理，流式計算，圖計算，互動式查詢，機器學習等。

flink
也是內存計算，比較類似spark，但是不一樣的是，spark的計算模型基於RDD，將流式計算看成是特殊的批處理，他的DStream其實還是
RDD。而flink吧批處理當成是特殊的流式計算，但是批處理和流式計算的層的引擎是兩個，抽象了DataSet和DataStream。

flink在性能上也標新很好，流式計算延遲比spark少，能做到真正的流式計算，而spark只能是准流式計算。而且在批處理上，當迭代次數變多，flink的速度比spark還要快，所以如果flink早一點出來，或許比現在的Spark更火。

目前國內也有吃螃蟹的公司敢用flink，淘寶則是基於flink二次開發了Blink，但是flink遇到spark就應證了那句話：

既生瑜，何生亮！

三年不關注，發現spark已經有點」昨日黃花「了，感嘆大數據技術的演進之快。spark作者matei去了斯坦福另起爐灶搞起了專註ML的dawn框架（當然開源社區繁榮不會受一個人左右，但至少最關鍵的人離開了），而flink勢頭顯然蓋過了spark，雖然早期spark社區瞧不起flink（當時還不叫flink，挺長的一個單詞忘記了），指責flink抄spark代碼連注釋都抄過去了，不過flink由於底層基於streaming的計算模式，在實時計算領域天生有優勢，目前BAT如阿里巴巴因為有大量實時流計算的場景，典型的如雙十一大屏，所以這塊投入也非常大，ali基於flink開發了blink，詳細可以參考：

Blink: How Alibaba Uses Apache Flink? - data Artisansdata-artisans.com

阿里蔣曉偉談流計算和批處理引擎Blink，以及Flink和Spark的異同與優勢-博客-雲棲社區-阿里雲yq.aliyun.com

上面只是直觀的感受，看下具體的數據，從Github的數據來看，Flink離Spark還有一定差距；

還有Google Trends的數據，關注度還是差距不小，不過有了阿里超級流量的極致考驗，如果blink特性能反饋回flink社區那絕對算是重大利好。

話說回來，兩個類似的框架在pk也不是壞事，相互促進相互學習，但對於開發者選擇起來就比較糾結了。

Spark是Batch first，stream的功能通過mini-batch來近似

Flink是Stream first， Batch的功能通過Stream 來近似，為什麼Flink能用Stream來近似Batch呢？因為Flink有guarantee exactly once process的feature（對照：Storm就只敢說自己是at least once）

Flink 比Spark好的地方：

Stream給力，市面上最好的stream framework沒有之一

Stream 近似 Batch沒有硬傷（相反mini batch近似Stream會搞亂batch里的順序）。相當於自帶lambda architecture

Flink不足的地方：

用戶群沒有Spark多，stackoverflow上能找到的Solution少

Documentation還在完善中，尤其scala部分

java比scala啰嗦...

相信Flink是未來，因為這些缺點都是時間能解決的。

都別扯了,哪個好找工作就用哪個.好的東西多的去了,有毛用,然並卵

著作權歸作者所有。

商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。

作者：白喬

鏈接：Apache Flink vs Apache Spark

來源：CSDN博客

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社區目前在朝這個方向努力，但是目前還不能輕易斷言最後的結果。
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
// 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 = (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 = (value =&> (value,1))
　　val grouped = mappedWords.groupBy(0)
　　val sum = grouped.sum(1)
　　println(sum.collect())
　}
}
　　不知道是偶然還是故意的，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也許是一個更好的選擇。
流式計算和批處理計算的表示：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，不過到目前為止，Flink的windowing支持是要比Spark好的。Steaming這部分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這方面的更迷人的思路。

對於Flink我比較熟，應該是第四代的數據引擎！他包括了流式處理和批量的離線處理！而Spark和他的不同之處是在於默認把所有的計算都認為是批量計算而流式處理算是批量計算的一個特例！Flink 真好與他相反！flink真正意義做到了數據的實時處理！

個人覺得不管誰的想法新穎與否，「借鑒」別人的也好，始終性能決定未來