引言

隨著大數(shù)據(jù)時(shí)代的來(lái)臨，大數(shù)據(jù)產(chǎn)品層出不窮。我們最近也對(duì)一款業(yè)內(nèi)非常火的大數(shù)據(jù)產(chǎn)品 - Apache Flink做了調(diào)研，今天與大家分享一下。Apache Flink(以下簡(jiǎn)稱(chēng)flink) 是一個(gè)旨在提供‘一站式’ 的分布式開(kāi)源數(shù)據(jù)處理框架。是不是聽(tīng)起來(lái)很像spark?沒(méi)錯(cuò)，兩者都希望提供一個(gè)統(tǒng)一功能的計(jì)算平臺(tái)給用戶。雖然目標(biāo)非常類(lèi)似，但是flink在實(shí)現(xiàn)上和spark存在著很大的區(qū)別，flink是一個(gè)面向流的處理框架，輸入在flink中是無(wú)界的，流數(shù)據(jù)是flink中的頭等公民。說(shuō)到這里，大家一定覺(jué)得flink和storm有幾分相似，確實(shí)是這樣。那么有spark和storm這樣成熟的計(jì)算框架存在，為什么flink還能占有一席之地呢?今天我們就從流處理的角度將flink和這兩個(gè)框架進(jìn)行一些分析和比較。

一：本文的流框架基于的實(shí)現(xiàn)方式

本文涉及的流框架基于的實(shí)現(xiàn)方式分為兩大類(lèi)。第一類(lèi)是Native Streaming，這類(lèi)引擎中所有的data在到來(lái)的時(shí)候就會(huì)被立即處理，一條接著一條(HINT： 狹隘的來(lái)說(shuō)是一條接著一條，但流引擎有時(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è)基于Micro-batch實(shí)現(xiàn)的就是storm trident，它是對(duì)storm的更高層的抽象，因?yàn)橐詁atch為單位，所以storm trident的一些處理變的簡(jiǎn)單且高效。

二： 流框架比較的關(guān)鍵指標(biāo)

從流處理的角度將flink與spark和storm這兩個(gè)框架進(jìn)行比較，會(huì)主要關(guān)注以下幾點(diǎn)，后續(xù)的對(duì)比也主要基于這幾點(diǎn)展開(kāi)：

• 功能性(Functionality)- 是否能很好解決流處理功能上的痛點(diǎn) , 比如event time和out of order data。
• 容錯(cuò)性(Fault Tolerance) - 在failure之后能否恢復(fù)到故障之前的狀態(tài)，并輸出一致的結(jié)果;此外容錯(cuò)的代價(jià)也是越低越好，因?yàn)槠渲苯佑绊懶阅堋?• 吞吐量(throughputs)& 延時(shí)(latency) - 性能相關(guān)的指標(biāo)，高吞吐和低延遲某種意義上是不可兼得的，但好的流引擎應(yīng)能兼顧高吞吐&低延時(shí)。

功能性(Functionality)

1 Event time&Window Operation

1.1Event time• event time - 指數(shù)據(jù)或者事件真正發(fā)生時(shí)間 , 比如用戶點(diǎn)擊網(wǎng)頁(yè)時(shí)產(chǎn)生一條點(diǎn)擊事件的數(shù)據(jù)，點(diǎn)擊時(shí)間就是這條數(shù)據(jù)固有的event time。 • processing time - 指計(jì)算框架處理這條數(shù)據(jù)的時(shí)間。 (具體關(guān)于時(shí)間的定義可以參看flink文檔 http://t.cn/RaTnsdy。)

spark DStream和storm 1.0以前版本往往都折中地使用processing time來(lái)近似地實(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ù)的問(wèn)題。為了解決這個(gè)問(wèn)題， spark、storm及flink都參考streaming 102 (http://t.cn/RbQCUmJ)引入了watermark和lateness的概念。

watermark: 是引擎處理事件的時(shí)間進(jìn)度，代表一種狀態(tài)，一般隨著數(shù)據(jù)中的event time的增長(zhǎng)而增長(zhǎng)。比如 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ù)， 那么就說(shuō)明這條數(shù)據(jù)是遲到的。

lateness: 表示可以容忍遲到的程度，在lateness可容忍范圍內(nèi)的數(shù)據(jù)還會(huì)參與計(jì)算，超過(guò)的會(huì)被丟棄。

1.2Window Operation

下面主要比較在使用window的操作中，spark structured streaming 和flink對(duì)event time處理機(jī)制的不同。

flink 首先，我們結(jié)合圖來(lái)看flink， 時(shí)間軸從左往右增大。當(dāng)watermark WM處于時(shí) 間窗口區(qū)間內(nèi)時(shí)，即WM ∈ [start, end] , event time落在窗口范圍內(nèi)的任何亂序數(shù)據(jù)都會(huì)被接受;隨著WM的增長(zhǎng)并超過(guò)了窗口的結(jié)束時(shí)間，但還未超過(guò)可容忍的lateness時(shí)間范圍，即WM ∈ (window_end,window_end+ lateness]， 這時(shí)亂序數(shù)據(jù)仍然可以被接受; 只有當(dāng)WM超過(guò) window_end+lateness, 即WM ∈ (window_end+ lateness, ∞)， 遲到的數(shù)據(jù)將會(huì)被丟棄。

fiink中watermark的計(jì)算也比較靈活，可以選擇build-in的(如最大時(shí)間戳)，也可以通過(guò)集成接口自定義實(shí)現(xiàn)。此外，用戶可以選擇周期性更新或者事件觸發(fā)更新watermark。

spark 首先,spark中watermark是通過(guò)上一個(gè)batch最大的timestamp再減去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文檔 (http://t.cn/RaTnvVQ)。

下面來(lái)比較一下兩者實(shí)現(xiàn)細(xì)節(jié)上的不同：

• lateness定義: 在spark中，遲到被定義為data的event time和watermark的比較結(jié)果，當(dāng)data的event time < watermark時(shí)，data被丟棄;flink中只有在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ā)一次或多次，第一次在watermark >= window_end后立刻觸發(fā)(main fire)，接著會(huì)在遲到數(shù)據(jù)到來(lái)后進(jìn)行增量觸發(fā)。spark只會(huì)在watermark(包含lateness)過(guò)了window_end之后才會(huì)觸發(fā)，雖然計(jì)算結(jié)果一次性正確，但觸發(fā)比f(wàn)link起碼多了一個(gè)lateness的延遲。

上面三點(diǎn)可見(jiàn)flink在設(shè)計(jì)event time處理模型還是較優(yōu)的：watermark的計(jì)算實(shí)時(shí)性高，輸出延遲低，而且接受遲到數(shù)據(jù)沒(méi)有spark那么受限。不光如此，flink提供的window programming模型非常的靈活，不但支持spark、storm沒(méi)有的session window，而且只要實(shí)現(xiàn)其提供的WindowAssigner、Trigger、Evictor就能創(chuàng)造出符合自身業(yè)務(wù)邏輯的window，功能非常強(qiáng)大。

2 SQL API

目前flink相比spark，對(duì)streaming sql的支持還是比較初級(jí)的。在當(dāng)前最新1.2版本中，僅支持Selection、Projection、Union、Tumble，不支持Aggregation、 Join、Top N、 Sort。計(jì)劃中1.3版本將支持 Window Aggregation(sum、max、 min、avg), 但依然不支持Distinct。相比f(wàn)link，當(dāng)前最新版本的spark structured streaming僅僅不支持Top N、Distinct。

3 Kafka Source Integration

flink對(duì)于kafka的兼容性非常好，支持kafka 0.8、0.9、0.10;相反，spark structured streaming只支持kafka0.10或更高版本。

4 Interoperation with Static Data

spark底層對(duì)static batch data和streaming data有共同的rdd抽象，完美兼容互操作。而flink中DataSet 和 DataStream是完全獨(dú)立的，不可以直接交互。

此外，flink還可以運(yùn)行storm的topology，帶來(lái)較強(qiáng)的移植性。另外一個(gè)有趣的功能是可以自由調(diào)整job latency and throughputs的取舍關(guān)系，比如需要high throughputs的程序可以犧牲latency來(lái)獲得更大的throughputs。

容錯(cuò)性(Fault Tolerance)

spark依賴(lài)checkpoint機(jī)制來(lái)進(jìn)行容錯(cuò)，只要batch執(zhí)行到doCheckpoint操作前掛了，那么該batch就會(huì)被完整的重新計(jì)算。spark可以保證計(jì)算過(guò)程的exactly once(不包含sink的exactly once)。

storm的容錯(cuò)通過(guò)ack機(jī)制實(shí)現(xiàn)，每個(gè)bolt或spout處理完成一條data后會(huì)發(fā)送一條ack消息給acker bolt。當(dāng)該條data被所有節(jié)點(diǎn)都處理過(guò)后，它會(huì)收到來(lái)自所有節(jié)點(diǎn)ack， 這樣一條data處理就是成功的。storm可以保證數(shù)據(jù)不丟失，但是只能達(dá)到at least once語(yǔ)義。此外，因?yàn)樾枰織ldata都做ack，所以容錯(cuò)的開(kāi)銷(xiāo)很大。storm trident是基于micro¬batched實(shí)現(xiàn)了exactly once語(yǔ)義。

flink使用Chandy-Chandy-Lamport Algorithm 來(lái)做Asynchronous Distributed Snapshots(異步分布式快照)，其本質(zhì)也是checkpoint。如下圖，flink定時(shí)往流里插入一個(gè)barrier(隔欄)，這些barriers把數(shù)據(jù)分割成若干個(gè)小的部分，當(dāng)barrier流到某個(gè)operator時(shí)，operator立即會(huì)對(duì)barrier對(duì)應(yīng)的一小部分?jǐn)?shù)據(jù)做checkpoint并且把barrier傳給下游(checkpoint操作是異步的，并不會(huì)打斷數(shù)據(jù)的處理)，直到所有的sink operator做完自己checkpoint后，一個(gè)完整的checkpoint才算完成。當(dāng)出現(xiàn)failure時(shí)，flink會(huì)從最新完整的checkpoint點(diǎn)開(kāi)始恢復(fù)。

flink的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)

1 .1吞吐量(throughputs)

spark是mirco-batch級(jí)別的計(jì)算，各種優(yōu)化做的也很好，它的throughputs是最大的。但是需要提一下，有狀態(tài)計(jì)算(如updateStateByKey算子)需要通過(guò)額外的rdd來(lái)維護(hù)狀態(tài)，導(dǎo)致開(kāi)銷(xiāo)較大，對(duì)吞吐量影響也較大。

storm的容錯(cuò)機(jī)制需要對(duì)每條data進(jìn)行ack，因此容錯(cuò)開(kāi)銷(xiāo)對(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的benchmark，我們可以看出storm在打開(kāi)ack容錯(cuò)機(jī)制后，throughputs下降非常明顯。而flink在開(kāi)啟checkpoint和關(guān)閉的情況下throughputs變化不大，說(shuō)明flink的容錯(cuò)機(jī)制確實(shí)代價(jià)不高。對(duì)比官網(wǎng)的benchmark，我們也進(jìn)行了throughputs的測(cè)試，實(shí)測(cè)結(jié)果是flink throughputs是storm的3.5倍，而且在解除了kafka集群和flink集群的帶寬瓶頸后，flink自身又提高了1.6倍。

1.2延遲(latency)

• spark基于micro-batch實(shí)現(xiàn)，提高了throughputs，但是付出了latency的代價(jià)。一般spark的latency是秒級(jí)別的。
• storm是native streaming實(shí)現(xiàn)，可以輕松的達(dá)到幾十毫秒級(jí)別的latency，在幾款框架中它的latency是最低的。storm trident是基于micro-batch實(shí)現(xiàn)的，latency較高。
• flink也是native streaming實(shí)現(xiàn)，也可以達(dá)到百毫秒級(jí)別的latency。

下圖是flink官網(wǎng)給出的和storm的latency對(duì)比benchmark。storm可以達(dá)到平均5毫秒以內(nèi)的latency，而flink的平均latency也在30毫秒以內(nèi)。兩者的99%的data都在55毫秒latency內(nèi)處理完成，表現(xiàn)都很優(yōu)秀。

三：總 結(jié)

綜合對(duì)比spark、storm和flink的功能、容錯(cuò)和性能(總結(jié)如下圖)

不難發(fā)現(xiàn)， flink是一個(gè)設(shè)計(jì)良好的框架，它不但功能強(qiáng)大，而且性能出色。此外它還有一些比較好設(shè)計(jì)，比如優(yōu)秀的內(nèi)存管理和流控。但是，flink目前成熟度較低，還存在著不少問(wèn)題，比如 SQL支持比較初級(jí);無(wú)法像storm一樣在不停止任務(wù)的情況下動(dòng)態(tài)調(diào)整資源;不能像spark一樣提供很好的streaming和static data的交互操作等。對(duì)于這些問(wèn)題，flink社區(qū)還在積極的跟進(jìn)，相信在更多公司和貢獻(xiàn)者的共同努力下，flink會(huì)發(fā)展的越來(lái)越好。