流式計(jì)算引擎對(duì)比分析

1、實(shí)時(shí)計(jì)算框架比照-flink , storm , spark三者的區(qū)別我相信有不少的工程師都有著這樣的處境,在學(xué)flink之前很好奇flink , storm , spark的區(qū)別是什么,為什么現(xiàn)在很多企業(yè)都在往flink方向轉(zhuǎn)它的優(yōu)勢是什么,為什么不適用 storm ,為什么不適用spark有限數(shù)據(jù)集和無限數(shù)據(jù)集1 .有限數(shù)據(jù)集：數(shù)據(jù)大小有限固定大小,比方固定的文件,用于批 處理,這一類數(shù)據(jù)主要用于 mr , hive , pig , spark等批計(jì)算引擎.2 .無限數(shù)據(jù)集：數(shù)據(jù)持續(xù)增長屬于無限大小,比方kafka中的日志數(shù)據(jù),總是有新數(shù)據(jù)進(jìn)入,并且不知道什么時(shí)候結(jié)束或者是永遠(yuǎn)不結(jié)束,用于

2、 流式處理,這一類數(shù)據(jù)主要用于 storm , spark streaming , flink等一些流式 計(jì)算引擎.apache計(jì)算引擎的開展關(guān)系在apche中的三篇論文鑒定大數(shù)據(jù)的根底其中mr收到其中一篇論文的啟發(fā)創(chuàng)造了 mapreduce ,同時(shí)隨著時(shí)代的開展也出現(xiàn)了其他的技術(shù)技術(shù).1 .第一代計(jì)算引擎 mapreducemapreduce作為第一個(gè)計(jì)算引擎,用于批處理,是計(jì)算引擎的先驅(qū),內(nèi)部支持機(jī)器學(xué)習(xí)但是現(xiàn)在機(jī)器學(xué)習(xí)庫不在更新,并且 mapreduce編寫十分的耗時(shí),開發(fā)效率低,開發(fā)時(shí)間本錢太大,所以很少有企業(yè)寫mapreduce 來跑程序.2 .第二代計(jì)算引擎pig/hive作為第二

3、代引擎pig/hive 對(duì)hadoop 如果不知道hadoop的話,建 議不要看了.進(jìn)行了嵌套,其存儲(chǔ)基于hdfs ,計(jì)算基于mr ,hive/pig在處理任務(wù)時(shí)首先會(huì)把本身的代碼解析為一個(gè)個(gè)m/r任務(wù),這樣就大大的降低了 mr的編寫編寫本錢.pig有自己的腳本語言屬于,比hive更加的靈活hive屬于類sql語法,雖然沒有pig靈活,但是對(duì)于現(xiàn)在程序員都會(huì) sql的世界來說大家更喜歡使用hivepig/hive 只支持批處理,且支持機(jī)器學(xué)習(xí)hivemall 3 .第三代計(jì)算引擎 spark/storm隨著時(shí)代的開展,企業(yè)對(duì)數(shù)據(jù)實(shí)時(shí)處理的需求愈來愈大,所以就出現(xiàn)了 storm/spark這兩者

4、有著自己的計(jì)算模式storm屬于真正的流式處理,低延遲ms級(jí)延遲,高吞吐,且每條 數(shù)據(jù)都會(huì)觸發(fā)計(jì)算.spark屬于批處理轉(zhuǎn)化為流處理即將流式數(shù)據(jù)根據(jù)時(shí)間切分成小批次進(jìn)行計(jì)算,比照與storm而言延遲會(huì)高于0.5s s級(jí)延遲,但是性能上的消耗 低于storm o “流式計(jì)算是批次計(jì)算的特例流式計(jì)算是拆分計(jì)算的結(jié)果4 .第四代計(jì)算引擎flinkflink2021年出現(xiàn)在apache ,后來又被阿里巴巴技術(shù)團(tuán)隊(duì)進(jìn)行優(yōu)化這 里我身為國人為之自豪為blink , flink支持流式計(jì)算也支持的批次處理.flink為流式計(jì)算而生屬于每一條數(shù)據(jù)觸發(fā)計(jì)算,在性能的消耗低于storm , 吞吐量高于 storm

5、 , 延時(shí)低于 storm , 并且比 storm 更加易于編寫.由于storm如果要實(shí)現(xiàn)窗口需要自己編寫邏輯,但是 flink中有窗口方法.flink內(nèi)部支持多種函數(shù),其中包括窗口函數(shù)和各種算子這一點(diǎn)和spark很像,但是在性能和實(shí)時(shí)上spark是沒有方法比擬的flink支持僅一次語義保證數(shù)據(jù)不喪失flink支持通過envent time 來限制窗口時(shí)間,支持亂序時(shí)間和時(shí)間處理這點(diǎn)我覺得很厲害對(duì)于批次處理flink的批處理可以理解為“批次處理是流式處理的特例批次計(jì)算是流式計(jì)算的合并結(jié)果區(qū)別比照總結(jié)這里用一張圖來做第一點(diǎn)的比照1產(chǎn)品篌型API保證狀I(lǐng)S容傳機(jī)制狀態(tài)治理stormIMative組

6、合式AHeest- onceRecord ACKs (W.M)無LowLowIndentmirco-Mching組合式ExecMy- onceRecord ACKs基于操作W*一上MediumMediumSpark streamingmiroa- batching興明式舄范震注ZEE«Exectly- onceRDD Checkpoint (1WM CnHWart)基于StreamMediumHighFlmk Ma live 聲明式 xeclly- Checkpoint 基于操作Low Highonce相比于storm , spark和flink兩個(gè)都支持窗口和算子,減少了不少的 編

7、程時(shí)間flink相比于storm和spark , flink支持亂序和延遲時(shí)間在實(shí)際場景 中,這個(gè)功能很牛逼,個(gè)人覺得就這個(gè)功能就可以錘爆spark對(duì)于spark而言他的優(yōu)勢就是機(jī)器學(xué)習(xí),如果我們的場景中對(duì)實(shí)時(shí)要求 不高可以考慮spark,但是如果是要求很高就考慮使用flink,比方對(duì)用戶異常消費(fèi)進(jìn)行監(jiān)控,如果這個(gè)場景使用spark的話那么等到系統(tǒng)發(fā)現(xiàn)開始預(yù)警的時(shí)候0.5s,罪犯已經(jīng)完成了交易,可想而知在某些場景下flink的實(shí)時(shí)有多重要.Apache Flink以下簡稱flink是一個(gè)旨在提供一站式的分布式開源數(shù)據(jù)處理框架.是不是聽起來很像 spark ?沒錯(cuò),兩者都希望提供一個(gè)統(tǒng)一 功能的

8、計(jì)算平臺(tái)給用戶.雖然目標(biāo)非常類似,但是 flink在實(shí)現(xiàn)上和spark存 在著很大的區(qū)別,flink是一個(gè)面向流的處理框架,輸入在 flink中是無界的, 流數(shù)據(jù)是flink中的頭等公民.說到這里,大家一定覺得flink和storm有幾分相似,確實(shí)是這樣.那么有spark和storm這樣成熟的計(jì)算框架存在,為什么 flink還能占有一席之地呢？今天我們就從流處理的角度將 flink和這兩個(gè)框架 進(jìn)行一些分析和比擬.1本文的流框架基于的實(shí)現(xiàn)方式本文涉及的流框架基于的實(shí)現(xiàn)方式分為兩大類.第一類是NativeStreaming ,這類引擎中所有的data在到來的時(shí)候就會(huì)被立即處理,一條接著 一條HI

9、NT:狹隘的來說是一條接著一條,但流引擎有時(shí)會(huì)為提升性能緩存 一小局部data然后一次性處理,其中的代表就是storm和flink.第二種那么是基于Micro-batch ,數(shù)據(jù)流被切分為一個(gè)一個(gè)小的批次,然后再逐個(gè)被引擎處理.這些batch 一般是以時(shí)間為單位進(jìn)行切分,單位一般是秒,其中 的典型代表那么是spark 了,不管是老的spark DStream 還是2.0以后推出的 spark structured streaming都是這樣的處理機(jī)制；另外一個(gè)基于Microbatch 實(shí)現(xiàn)的就是storm trident ,它是對(duì)storm 的更高層的抽象,由于以 batch為單位,所以sto

10、rm trident的一些處理變的簡單且高效.Apache FlinkMicro-batchNative Streaming2流框架比擬的關(guān)鍵指標(biāo)從流處理的角度將flink與spark和storm這兩個(gè)框架進(jìn)行比擬,會(huì)主要關(guān)注 以下幾點(diǎn),后續(xù)的比照也主要基于這幾點(diǎn)展開:?功能性(Functionality )-是否能很好解決流處理功能上的痛點(diǎn),比方event time 和 out of order data .?容錯(cuò)性(Fault Tolerance )-在failure之后能否恢復(fù)到故障之前的狀態(tài), 并輸出一致的結(jié)果；此外容錯(cuò)的代價(jià)也是越低越好,由于其直接影響性能.？吞吐量(throughp

11、uts)& 延時(shí)(latency)-性能相關(guān)的指標(biāo),高吞吐和低延遲 某種意義上是不可兼得的,但好的流引擎應(yīng)能兼顧高吞吐&低延時(shí).功能性(Functionality )01 Event time&Window Operation1 .Event time ? event time - 指數(shù)據(jù)或者事件真正發(fā)生時(shí)間 ,比方用戶點(diǎn)擊 網(wǎng)頁時(shí)產(chǎn)生一條點(diǎn)擊事件的數(shù)據(jù),點(diǎn)擊時(shí)間就是這條數(shù)據(jù)固有的event time.? processing time - 指計(jì)算框架處理這條數(shù)據(jù)的時(shí)間.(具體關(guān)于時(shí)間的定義可以參看 flink 文檔 :/t /RaTnsdy .)spark DStre

12、am 和storm 1.0 以前版本往往都折中地使用 processing time 來 近似地實(shí)現(xiàn)event time 相關(guān)的業(yè)務(wù).顯然,使用 processing time 模擬event time必然會(huì)產(chǎn)生一些誤差,特別是在產(chǎn)生數(shù)據(jù)堆積的時(shí)候,誤差那么更明顯,甚至導(dǎo)致計(jì)算結(jié)果不可用.在使用event time時(shí),自然而然需要解決由網(wǎng)絡(luò)延遲等因素導(dǎo)致的遲到或者亂序數(shù)據(jù)的問題.為了解決這個(gè)問題,spark、storm及flink都參考streaming 102 ( :/t /RbQCUmJ) 引入了 watermark 和 lateness 的概 念.watermark:是引擎處理事件的時(shí)間

13、進(jìn)度,代表一種狀態(tài),一般隨著數(shù)據(jù)中的 event time 的增長而增長.比方 watermark(t)代表整個(gè)流的event time 處理 進(jìn)度已經(jīng)到達(dá)t,時(shí)間是有序的,那么streaming不應(yīng)該會(huì)再收到timestamp t ' < t的數(shù)據(jù),而只會(huì)接受到 timestamp t ' >= t的數(shù)據(jù). 如 果收到一條timestamp t ' < t的數(shù)據(jù),那么就說明這條數(shù)據(jù)是遲到的.lateness:表示可以容忍遲到的程度,在lateness可容忍范圍內(nèi)的數(shù)據(jù)還會(huì)參 與計(jì)算,超過的會(huì)被丟棄.2 .Window Operation下面主要比擬在

14、使用 window 的操作中,spark structured streaming 和 flink對(duì)event time 處理機(jī)制的不同.flink首先,我們結(jié)合圖來看flink ,時(shí)間軸從左往右增大.當(dāng) watermarkWM 處于時(shí) 間窗口區(qū)間內(nèi)時(shí),即 WM start, end , event time 落在窗口 范圍內(nèi)的任何亂序數(shù)據(jù)都會(huì)被接受；隨著WM的增長并超過了窗口的結(jié)束時(shí)問,但還未超過可容忍的lateness時(shí)間范圍,即 WM (window_end,window_end+ lateness , 這時(shí)亂序數(shù)據(jù)仍然可以被接受； 只有當(dāng) WM 超過 window_end+latene

15、ss, 即 WM (window_end+ lateness,吟,遲到的數(shù)據(jù)將會(huì)被丟棄.O< window end W<windown_end WM>windnwn end + l<iteness +latt>n*ssFlinK handle late record nn windowfiink中watermark的計(jì)算也比擬靈活,可以選擇 build-in 的(如最大時(shí)間戳),也可以通過繼承接口自定義實(shí)現(xiàn).止匕外,用戶可以選擇周期性更新或者事件觸發(fā)更新watermark.spark 首先,spark 中watermark 是通過上一個(gè) batch 最大的time

16、stamp 再減去 lateness 得到的, 即 watermark = Max(last batch timestamps)-lateness.當(dāng)數(shù)據(jù)的event time 大于 watermark 時(shí),數(shù)據(jù)會(huì)被接受,否那么不論這條數(shù)據(jù)屬于哪個(gè)窗口都會(huì)被丟棄.細(xì)節(jié)請(qǐng)參考spark文檔( :/t /RaTnvVQ ).下面來比擬一下兩者實(shí)現(xiàn)細(xì)節(jié)上的不同：lateness 定義：在 spark 中, 遲至U被定義為 data 的event time 和watermark 的比擬結(jié)果,當(dāng) data 的 event time < watermark 時(shí),data 被丟棄；flink 中只有在

17、 watermark > window_end + lateness 的時(shí)候,data 才 會(huì)被丟棄 watermark 更新：spark 中 watermark 是上個(gè) batch 中的 max event time ,存在延遲；而在flink中是可以做到每條數(shù)據(jù)同步更新 watermark.window 觸發(fā)：flink中window 計(jì)算會(huì)觸發(fā)一次或?qū)掖?第一次在 watermark >= window_end后馬上觸發(fā)main fire , 接著會(huì)在遲到數(shù)據(jù)到來后進(jìn)行增量觸發(fā).spark只會(huì)在watermark 包含lateness 過了 window_end 之后才會(huì)觸發(fā)

18、,雖然計(jì)算結(jié)果一次性正確,但觸發(fā)比flink起碼多了一個(gè)lateness的延遲.上面三點(diǎn)可見flink在設(shè)計(jì)event time處理模型還是較優(yōu)的：watermark的計(jì) 算實(shí)時(shí)性高,輸出延遲低,而且接受遲到數(shù)據(jù)沒有spark那么受限.不光如此,flink提供的window programming模型非常的靈活,不但支持 spark、storm 沒有的session window ,而且只要實(shí)現(xiàn)其提供的 WindowAssigner 、 Trigger > Evictor就能創(chuàng)造出符合自身業(yè)務(wù)邏輯的 window ,功能非常強(qiáng)大.02 SQL API目前flink相比spark ,對(duì)st

19、reaming sql 的支持還是比擬初級(jí)的.在當(dāng) 前最新 1.2 版本中,僅支持 Selection、Projection、Union、Tumble ,不支 持 Aggregation 、Join、Top N、Sort.方案中 1.3 版本將支持 Window Aggregationsum 、 max、 min 、 avg,但依然不支持 Distinct .相比 flink ,當(dāng)前最新版本的 spark structured streaming僅僅不支持 Top N 、Distinct .03 Kafka Source Integrationflink對(duì)于kafka的兼容性非常好,支持 ka

20、fka 0.8、0.9、0.10；相反, spark structured streaming 只支持 kafka0.10 或更高版本.04 Interoperation with Static Dataspark 底層對(duì) static batch data 和 streaming data 有共同的 rdd 抽 象,完美兼容互操作.而flink中DataSet和DataStream 是完全獨(dú)立的,不 可以直接交互.此外,flink還可以運(yùn)行storm的topology ,帶來較強(qiáng)的移植性.另外 一個(gè)有趣的功能是可以自由調(diào)整 job latency and throughputs 的取舍關(guān)系,

21、 比方需要high throughputs的程序可以犧牲latency來獲得更大的throughputs .容錯(cuò)性(Fault Tolerance )spark依賴checkpoint 機(jī)制來進(jìn)行容錯(cuò),只要batch執(zhí)行到 doCheckpoint 操作前掛了,那么該batch就會(huì)被完整的重新計(jì)算.spark可 以保證計(jì)算過程的 exactly once(不包含sink的exactly once ).storm 的容錯(cuò)通過ack機(jī)制實(shí)現(xiàn),每個(gè)bolt或spout處理完成一條 data后會(huì)發(fā)送一條ack消息給acker bolt.當(dāng)該條data被所有節(jié)點(diǎn)都處理過 后,它會(huì)收到來自所有節(jié)點(diǎn)ack

22、,這樣一條data處理就是成功的.storm可 以保證數(shù)據(jù)不喪失,但是只能到達(dá) at least once 語義.止匕外,由于需要每條 data都彳ft ack,所以容錯(cuò)的開銷很大.storm trident 是基于micro?b atched實(shí)現(xiàn)了 exactly once 語義.flink 使用 Chandy-Chandy-Lamport Algorithm 來做 AsynchronousDistributed Snapshots異步分布式快照,其本質(zhì)也是 checkpoint .如下圖,flink定時(shí)往流里插入一個(gè)barrier 隔欄,這些barriers把數(shù)據(jù)分割成 假設(shè)干個(gè)小的局部,

23、當(dāng) barrier 流到某個(gè)operator 時(shí),operator 立即會(huì)對(duì) barrier對(duì)應(yīng)的一小局部數(shù)據(jù)做 checkpoint 并且把barrier傳給下游checkpoint操作是異步的,并不會(huì)打斷數(shù)據(jù)的處理,直到所有的 sink operator 做完自己checkpoint 后,一個(gè)完整的checkpoint 才算完成.當(dāng)出 現(xiàn)failure時(shí),flink會(huì)從最新完整的checkpoint 點(diǎn)開始恢復(fù).data streamnfcordb相/vcdrdsbanner nburnerf產(chǎn)ntjpart ofpart ofpan ofChedcpont nn-jcheckpontnc

24、heckpoint jflink的checkpoint 機(jī)制非常輕量,barrier不會(huì)打斷streaming 的流動(dòng),而且做checkpoint 操作也是異步的.其次,相比 storm 需要ack每條data , flink做的是small batch 的checkpoint ,容錯(cuò)的代價(jià)相對(duì)要低很多.最重要的是flink的checkpoint 機(jī)制能保證exactly once .吞吐量和延遲(Throughputs& Latency )01 吞吐量(throughputs )spark是mirco-batch 級(jí)別的計(jì)算,各種優(yōu)化做的也很好,它的throughputs 是最大的.

25、但是需要提一下,有狀態(tài)計(jì)算如 updateStateByKey 算子需要通過額外的rdd來維護(hù)狀態(tài),導(dǎo)致開銷較大, 對(duì)吞吐量影響也較大.storm的容錯(cuò)機(jī)制需要對(duì)每條data進(jìn)彳T ack ,因此容錯(cuò)開銷對(duì) throughputs 影響巨大,throughputs 下降甚至可以到達(dá)70%.storm trident 是基于 micro-batch 實(shí)現(xiàn)的,throughput 中等.flink的容錯(cuò)機(jī)制較為輕量,對(duì)throughputs 影響較小,而且擁有圖和 調(diào)度上的一些優(yōu)化機(jī)制,使得 flink可以到達(dá)很高throughputs .下列圖是flink官網(wǎng)給出的storm 和flink的be

26、nchmark ,我們可以看出 storm在翻開ack容錯(cuò)機(jī)制后,throughputs 下降非常明顯.而flink在開啟 checkpoint和關(guān)閉的情況下throughputs 變化不大,說明flink的容錯(cuò)機(jī)制確 實(shí)代價(jià)不高.比照官網(wǎng)的 benchmark ,我們也進(jìn)行了 throughputs 的測試, 實(shí)測結(jié)果是flink throughputs 是storm 的3.5倍,而且在解除了 kafka集群 和flink集群的帶寬瓶頸后,flink自身又提升了 1.6倍.Thmvghput for distribuled gr«pF|fc>WrAfk；c版 m-wcjt 守

27、91府 ip-醺W Etvc bw*cy «t WinSwm g'glimMrr.HC. (1 1 IT MC Ufl*incy *t Vth |p4KOF SkxfPs tauhKtpv*：itd"3G-1M m*K iMFf 4h Mtr pvrs W j f>y)iKft¥*tvd0000 EMC lMW*cy 11 Wth A-Eki,)QOQ40.00BO,OO 120.00 IMt.OD2C0.00(milliom <rl iv«vti pet MCMd)02 延遲(latency )spark 基于 micro-batch 實(shí)現(xiàn),提升了 throu