當前位置:編程學習大全網 - 源碼下載 - Apache Flink現在在大數據處理方面能夠和Apache Spark分庭抗禮麽

Apache Flink現在在大數據處理方面能夠和Apache Spark分庭抗禮麽

我們是否還需要另外壹個新的數據處理引擎?當我第壹次聽到flink的時候這是我是非常懷疑的。在大數據領域,現在已經不缺少數據處理框架了,但是沒有壹個框架能夠完全滿足不同的處理需求。自從Apache spark出現後,貌似已經成為當今把大部分的問題解決得最好的框架了,所以我對另外壹款解決類似問題的框架持有很強烈的懷疑態度。

不過因為好奇,我花費了數個星期在嘗試了解flink。壹開始仔細看了flink的幾個例子,感覺和spark非常類似,心理就傾向於認為flink又是壹個模仿spark的框架。但是隨著了解的深入,這些API體現了壹些flink的新奇的思路,這些思路還是和spark有著比較明顯的區別的。我對這些思路有些著迷了,所以花費了更多的時間在這上面。

flink中的很多思路,例如內存管理,dataset API都已經出現在spark中並且已經證明 這些思路是非常靠譜的。所以,深入了解flink也許可以幫助我們分布式數據處理的未來之路是怎樣的

在後面的文章裏,我會把自己作為壹個spark開發者對flink的第壹感受寫出來。因為我已經在spark上幹了2年多了,但是只在flink上接觸了2到3周,所以必然存在壹些bias,所以大家也帶著懷疑和批判的角度來看這篇文章吧。

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

// 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都長得很像,這樣很方便開發者從壹個引擎切換到另外壹個引擎。我感覺以後這種Collection API會成為寫data pipeline的標配。

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勝

SQL interface

目前spark-sql是spark裏面最活躍的組件之壹,Spark提供了類似Hive的sql和Dataframe這種DSL來查詢結構化數據,API很成熟,在流式計算中使用很廣,預計在流式計算中也會發展得很快。

至於flink,到目前為止,Flink Table API只支持類似DataFrame這種DSL,並且還是處於beta狀態,社區有計劃增加SQL 的interface,但是目前還不確定什麽時候才能在框架中用上。

所以這個部分,spark勝出。

Data source Integration

Spark的數據源 API是整個框架中最好的,支持的數據源包括NoSql db,parquet,ORC等,並且支持壹些高級的操作,例如predicate push down

Flink目前還依賴map/reduce InputFormat來做數據源聚合。

這壹場spark勝

Iterative processing

spark對機器學習的支持較好,因為可以在spark中利用內存cache來加速機器學習算法。

但是大部分機器學習算法其實是壹個有環的數據流,但是在spark中,實際是用無環圖來表示的,壹般的分布式處理引擎都是不鼓勵試用有環圖的。

但是flink這裏又有點不壹樣,flink支持在runtime中的有環數據流,這樣表示機器學習算法更有效而且更有效率。

這壹點flink勝出。

Stream as platform vs Batch as Platform

Spark誕生在Map/Reduce的時代,數據都是以文件的形式保存在磁盤中,這樣非常方便做容錯處理。

Flink把純流式數據計算引入大數據時代,無疑給業界帶來了壹股清新的空氣。這個idea非常類似akka-streams這種。

成熟度

目前的確有壹部分吃螃蟹的用戶已經在生產環境中使用flink了,不過從我的眼光來看,Flink還在發展中,還需要時間來成熟。

結論

目前Spark相比Flink是壹個更為成熟的計算框架,但是Flink的很多思路很不錯,Spark社區也意識到了這壹點,並且逐漸在采用Flink中的好的設計思路,所以學習壹下Flink能讓妳了解壹下Streaming這方面的更迷人的思路。

  • 上一篇:個人賬戶收款多少會被監控
  • 下一篇:期貨怎麽算盈利 具體怎麽操作 別說廢話
  • copyright 2024編程學習大全網