流式計算引擎對比分析

1、實時計算框架比照-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等批計算引擎.2 .無限數(shù)據(jù)集：數(shù)據(jù)持續(xù)增長屬于無限大小,比方kafka中的日志數(shù)據(jù),總是有新數(shù)據(jù)進入,并且不知道什么時候結(jié)束或者是永遠不結(jié)束,用于

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19、reaming sql 的支持還是比擬初級的.在當(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對于kafka的兼容性非常好,支持 ka

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

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

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

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

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

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

26、nchmark ,我們可以看出 storm在翻開ack容錯機制后,throughputs 下降非常明顯.而flink在開啟 checkpoint和關(guān)閉的情況下throughputs 變化不大,說明flink的容錯機制確 實代價不高.比照官網(wǎng)的 benchmark ,我們也進行了 throughputs 的測試, 實測結(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 實現(xiàn),提升了 throu