第七色在线视频,2021少妇久久久久久久久久,亚洲欧洲精品成人久久av18,亚洲国产精品特色大片观看完整版,孙宇晨将参加特朗普的晚宴

為了賬號(hào)安全,請(qǐng)及時(shí)綁定郵箱和手機(jī)立即綁定
已解決430363個(gè)問(wèn)題,去搜搜看,總會(huì)有你想問(wèn)的

如何選擇Apache Spark和Apache Flink?

如何選擇Apache Spark和Apache Flink?

慕哥9229398 2018-10-03 14:10:58
如何選擇Apache Spark和Apache Flink
查看完整描述

1 回答

?
神不在的星期二

TA貢獻(xiàn)1963條經(jīng)驗(yàn) 獲得超6個(gè)贊

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

3.語(yǔ)言實(shí)現(xiàn)
spark是用scala來(lái)實(shí)現(xiàn)的,它提供了Java,Python和R的編程接口。
flink是java實(shí)現(xiàn)的,當(dāng)然同樣提供了Scala API
所以從語(yǔ)言的角度來(lái)看,spark要更豐富一些。因?yàn)槲乙呀?jīng)轉(zhuǎn)移到scala很久了,所以不太清楚這兩者的java api實(shí)現(xiàn)情況。
4.API
spark和flink都在模仿scala的collection API.所以從表面看起來(lái),兩者都很類(lèi)似。下面是分別用RDD和DataSet API實(shí)現(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都長(zhǎng)得很像,這樣很方便開(kāi)發(fā)者從一個(gè)引擎切換到另外一個(gè)引擎。我感覺(jué)以后這種Collection API會(huì)成為寫(xiě)data pipeline的標(biāo)配。
Steaming
spark把streaming看成是更快的批處理,而flink把批處理看成streaming的special case。這里面的思路決定了各自的方向,其中兩者的差異點(diǎn)有如下這些:

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

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

流式計(jì)算和批處理計(jì)算的表示
spark對(duì)于批處理和流式計(jì)算,都是用的相同的抽象:RDD,這樣很方便這兩種計(jì)算合并起來(lái)表示。而flink這兩者分為了DataSet和DataStream,相比spark,這個(gè)設(shè)計(jì)算是一個(gè)糟糕的設(shè)計(jì)。

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

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

Data source Integration

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

Iterative processing
spark對(duì)機(jī)器學(xué)習(xí)的支持較好,因?yàn)榭梢栽趕park中利用內(nèi)存cache來(lái)加速機(jī)器學(xué)習(xí)算法。
但是大部分機(jī)器學(xué)習(xí)算法其實(shí)是一個(gè)有環(huán)的數(shù)據(jù)流,但是在spark中,實(shí)際是用無(wú)環(huán)圖來(lái)表示的,一般的分布式處理引擎都是不鼓勵(lì)試用有環(huán)圖的。
但是flink這里又有點(diǎn)不一樣,flink支持在runtime中的有環(huán)數(shù)據(jù)流,這樣表示機(jī)器學(xué)習(xí)算法更有效而且更有效率。
這一點(diǎn)flink勝出。

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



查看完整回答
反對(duì) 回復(fù) 2018-10-20
  • 1 回答
  • 0 關(guān)注
  • 1339 瀏覽
慕課專(zhuān)欄
更多

添加回答

舉報(bào)

0/150
提交
取消
微信客服

購(gòu)課補(bǔ)貼
聯(lián)系客服咨詢(xún)優(yōu)惠詳情

幫助反饋 APP下載

慕課網(wǎng)APP
您的移動(dòng)學(xué)習(xí)伙伴

公眾號(hào)

掃描二維碼
關(guān)注慕課網(wǎng)微信公眾號(hào)