您好,登錄后才能下訂單哦!
王海濤,曾經(jīng)在微軟的 SQL Server和大數(shù)據(jù)平臺組工作多年。帶領(lǐng)團隊建立了微軟對內(nèi)的 Spark 服務(wù),主打 Spark Streaming。去年加入阿里實時計算部門,參與改進阿里基于 Apache Flink 的Blink 平臺。
導(dǎo)讀: 做大數(shù)據(jù)絕對躲不過的一個熱門話題就是實時流計算,而提到實時流計算,就不得不提 Spark 和 Flink。Spark 從 2014 年左右開始迅速流行,剛推出時除了在某些場景比 Hadoop MapReduce 帶來幾十到上百倍的性能提升外,還提出了用一個統(tǒng)一的引擎支持批處理、流處理、交互式查詢、機器學(xué)習(xí)等常見的數(shù)據(jù)處理場景。憑借高性能和全面的場景支持,Spark 早已成為眾多大數(shù)據(jù)開發(fā)者的最愛。
正在 Spark 如日中天高速發(fā)展的時候,2016 年左右 Flink 開始進入大眾的視野并逐漸廣為人知。在人們開始使用 Spark 之后,發(fā)現(xiàn) Spark 雖然支持各種常見場景,但并不是每一種都同樣好用。數(shù)據(jù)流的實時處理就是其中相對較弱的一環(huán)。Flink 憑借更優(yōu)的流處理引擎,同時也支持各種處理場景,成為 Spark 的有力挑戰(zhàn)者。當然,Spark 也在不斷增強其實時流處理能力,在今年 2 月份發(fā)布的 2.3 版本中引入了持續(xù)流式處理模型,可將流處理延遲降低至毫秒級別。
本文對 Spark 和 Flink 的技術(shù)與場景進行了全面分析與對比,且看下一代大數(shù)據(jù)計算引擎之爭,誰主沉???
自從數(shù)據(jù)處理需求超過了傳統(tǒng)數(shù)據(jù)庫能有效處理的數(shù)據(jù)量之后,Hadoop 等各種基于 MapReduce 的海量數(shù)據(jù)處理系統(tǒng)應(yīng)運而生。從2004 年 Google 發(fā)表 MapReduce 論文開始,經(jīng)過近10年的發(fā)展,基于 Hadoop 開源生態(tài)或者其它相應(yīng)系統(tǒng)的海量數(shù)據(jù)處理已經(jīng)成為業(yè)界的基本需求。
但是,很多機構(gòu)在開發(fā)自己的數(shù)據(jù)處理系統(tǒng)時都會發(fā)現(xiàn)需要面臨一系列的問題。從數(shù)據(jù)中獲取價值需要的投入遠遠超過預(yù)期。常見的問題包括:
cdn.xitu.io/2019/4/28/16a630d7d05c167b?w=975&h=514&f=png&s=244600">
(來源:https://mapr.com/developercentral/lambda-architecture/)
上圖是一個典型的lambda架構(gòu),只是包含了批處理和流處理兩種場景,就已經(jīng)牽涉到至少四五種技術(shù)了,還不算每種技術(shù)的可替代選擇。再加上實時查詢,交互式分析,機器學(xué)習(xí)等場景,每個場景都有幾種技術(shù)可以選擇,每個技術(shù)涵蓋的領(lǐng)域還有不同方式的重疊。結(jié)果就是一個業(yè)務(wù)經(jīng)常需要使用四五種以上的技術(shù)才能支持好一個完整的數(shù)據(jù)處理流程。加上調(diào)研選型,需要了解的數(shù)目還要多得多。
下圖是大數(shù)據(jù)領(lǐng)域的全景。有沒有暈?
大數(shù)據(jù)和 AI 全景 – 2018 (來源:http://mattturck.com/bigdata2018/)
開發(fā)和運行效率低下。因為牽涉到多種系統(tǒng),每種系統(tǒng)有自己的開發(fā)語言和工具,開發(fā)效率可想而知。而因為采用了多套系統(tǒng),數(shù)據(jù)需要在各個系統(tǒng)之間傳輸,也造成了額外的開發(fā)和運行代價,數(shù)據(jù)的一致也難以保證。在很多機構(gòu),實際上一半以上的開發(fā)精力花在了數(shù)據(jù)在各個系統(tǒng)之間的傳輸上。
復(fù)雜的運維。多個系統(tǒng),每個需要自己的運維,帶來更高的運維代價的同時也提高了系統(tǒng)出問題的可能。
數(shù)據(jù)質(zhì)量難以保證。數(shù)據(jù)出了問題難以跟蹤解決。
了解了這些問題以后,對Spark 從2014年左右開始迅速流行就比較容易理解了。Spark 在當時除了在某些場景比 Hadoop MapReduce 帶來幾十到上百倍的性能提升外,還提出了用一個統(tǒng)一的引擎支持批處理,流處理,交互式查詢,機器學(xué)習(xí)等常見的數(shù)據(jù)處理場景??催^在一個 Notebook 里完成上述所有場景的 Spark 演示,對比之前的數(shù)據(jù)流程開發(fā),對很多開發(fā)者來說不難做出選擇。經(jīng)過幾年的發(fā)展,Spark 已經(jīng)被視為可以完全取代 Hadoop 中的 MapReduce 引擎。
正在 Spark 如日中天高速發(fā)展的時候,2016年左右 Flink 開始進入大眾的視野并逐漸廣為人知。為什么呢?原來在人們開始使用 Spark 之后,發(fā)現(xiàn) Spark 雖然支持各種場見場景,但并不是每一種都同樣好用。數(shù)據(jù)流的實時處理就是其中相對較弱的一環(huán)。Flink 憑借更優(yōu)的流處理引擎,同時也支持各種處理場景,成為 Spark 的有力挑戰(zhàn)者。
Spark 和 Flink 是怎么做到這些的,它們之間又有那些異同,下面我們來具體看一下。
這一部分主要著眼于 Spark 和 Flink 引擎的架構(gòu)方面,更看重架構(gòu)帶來的潛力和限制?,F(xiàn)階段的實現(xiàn)成熟度和局限會在后續(xù)生態(tài)部分探討。
要理解 Spark 和 Flink 的 引擎特點,首先從數(shù)據(jù)模型開始。
Spark 的數(shù)據(jù)模型是彈性分布式數(shù)據(jù)集 RDD(Resilient Distributed Datasets)。 比起 MapReduce 的文件模型,RDD是一個更抽象的模型,RDD 靠血緣(lineage) 等方式來保證可恢復(fù)性。很多時候RDD可以實現(xiàn)為分布式共享內(nèi)存或者完全虛擬化(即有的中間結(jié)果 RDD 當下游處理完全在本地時可以直接優(yōu)化省略掉)。這樣可以省掉很多不必要的I/O,是早期 Spark 性能優(yōu)勢的主要原因。
Spark 用 RDD 上的變換(算子)來描述數(shù)據(jù)處理。每個算子(如 map,filter,join)生成一個新的 RDD。所有的算子組成一個有向無環(huán)圖(DAG)。Spark 比較簡單地把邊分為寬依賴和窄依賴。上下游數(shù)據(jù)不需要 shuffle 的即為窄依賴,可以把上下游的算子放在一個階段(stage) 里在本地連續(xù)處理,這時上游的結(jié)果 RDD可以 省略。下圖展示了相關(guān)的基本概念。更詳細的介紹在網(wǎng)上比較容易找到,這里就不花太多篇幅了。
Flink 任務(wù)圖 (來源:https://ci.apache.org/projects/flink/flink-docs-release-1.5/concepts/runtime.html)
在 DAG的執(zhí)行上,Spark 和 Flink 有一個比較顯著的區(qū)別。 在Flink 的流執(zhí)行模式中,一個事件在一個節(jié)點處理完后的輸出就可以發(fā)到下一個節(jié)點立即處理。這樣執(zhí)行引擎并不會引入額外的延遲。與之相應(yīng)的,所有節(jié)點是需要同時運行的。而 Spark 的 micro batch 和一般的batch 執(zhí)行一樣,處理完上游的 stage 得到輸出之后才開始下游的 stage。
在Flink的流執(zhí)行模式中,為了提高效率也可以把多個事件放在一起傳輸或者計算。但這完全是執(zhí)行時的優(yōu)化,可以在每個算子獨立決定,也不用像 RDD 等批處理模型中一樣和數(shù)據(jù)集邊界綁定,可以做更加靈活的優(yōu)化同時可以兼顧低延遲需求。
Flink 使用異步的 checkpoint 機制來達到任務(wù)狀態(tài)的可恢復(fù)性,以保證處理的一致性,所以在處理的主流程上可以做到數(shù)據(jù)源和輸出之間數(shù)據(jù)完全不用落盤,達到更高的性能和更低的延遲。
除了批處理之外,Spark 還支持實時數(shù)據(jù)流處理,交互式查詢,和機器學(xué)習(xí),圖計算等。
(來源: https://databricks.com/spark/about )
實時數(shù)據(jù)流處理和批處理主要區(qū)別就是對低延時的要求。Spark 因為 RDD 是基于內(nèi)存的,可以比較容易切成較小的塊來處理。如果能對這些小塊處理得足夠快,就能達到低延時的效果。
交互式查詢場景,如果數(shù)據(jù)能全在內(nèi)存,處理得足夠快的話,就可以支持交互式查詢。
從這些可以看出來,比起 Hadoop MapReduce, Spark 本質(zhì)上就是基于內(nèi)存的更快的批處理。然后用足夠快的批處理來實現(xiàn)各種場景。
(來源:https://www.slideshare.net/ParisCarbone/state-management-in-apache-flink-consistent-stateful-distributed-stream-processing)
前面說過,在Flink 中,如果輸入數(shù)據(jù)流是有邊界的,就自然達到了批處理的效果。這樣流和批的區(qū)別完全是邏輯上的,和處理實現(xiàn)獨立,用戶需要實現(xiàn)的邏輯也完全一樣,應(yīng)該是更干凈的一種抽象。后續(xù)會在深入對比流計算方面的時候做更深入的討論。
Flink 也提供了庫來支持機器學(xué)習(xí),圖計算等場景。從這方面來說和 Spark 沒有太大區(qū)別。
一個有意思的事情是用 Flink 的底層 API 可以支持只用 Flink集群實現(xiàn)一些數(shù)據(jù)驅(qū)動的分布式服務(wù)。有一些公司用 Flink集群實現(xiàn)了社交網(wǎng)絡(luò),網(wǎng)絡(luò)爬蟲等服務(wù)。這個也體現(xiàn)了 Flink 作為計算引擎的通用性,并得益于 Flink 內(nèi)置的靈活的狀態(tài)支持。
總的來說,Spark 和 Flink 都瞄準了在一個執(zhí)行引擎上同時支持大多數(shù)數(shù)據(jù)處理場景,也應(yīng)該都能做到這一點。主要區(qū)別就在于因為架構(gòu)本身的局限在一些場景會受到限制。比較突出的地方就是 Spark Streaming 的 micro batch 執(zhí)行模式。Spark 社區(qū)應(yīng)該也意識到了這一點,最近在持續(xù)執(zhí)行模式(continuous processing)方面開始發(fā)力。 具體情況會在后面介紹。
Flink 還有一個非常獨特的地方是在引擎中引入了托管狀態(tài)(managed state)。要理解托管狀態(tài),首先要從有狀態(tài)處理說起。如果處理一個事件(或一條數(shù)據(jù))的結(jié)果只跟事件本身的內(nèi)容有關(guān),稱為無狀態(tài)處理;反之結(jié)果還和之前處理過的事件有關(guān),稱為有狀態(tài)處理。稍微復(fù)雜一點的數(shù)據(jù)處理,比如說基本的聚合,都是有狀態(tài)處理。Flink 很早就認為沒有好的狀態(tài)支持是做不好留處理的,因此引入了 managed state 并提供了 API接口。
Spark 1.6 時的API狀態(tài)
Spark 的初衷之一就是用統(tǒng)一的編程模型來解決用戶的各種需求。在這方面一直很下功夫。最初基于 RDD 的 API 就可以做各種類型的數(shù)據(jù)處理。后來為了簡化用戶開發(fā),逐漸推出了更高層的DataFrame(在 RDD 中加了列變成結(jié)構(gòu)化數(shù)據(jù))和 Datasets(在 DataFrame 的列上加了類型),并在Spark 2.0 中做了整合(DataFrame = DataSet[Row])。Spark SQL 的支持也比較早就引入了。在加上各個處理類型API 的不斷改進,比如 Structured Streaming 以及和機器學(xué)習(xí)深度學(xué)習(xí)的交互,到了今天Spark 的 API 可以說是非常好用的,也是 Spark 最強的方面之一。
Spark 2.0 API (來源:https://databricks.com/blog/2016/07/14/a-tale-of-three-apache-spark-apis-rdds-dataframes-and-datasets.html)
Flink 的API也有類似的目標和發(fā)展路線。Flink 和 Spark 的核心 API 可以說是可以基本對應(yīng)的。今天Spark API 總體上更完備一下,比如說最近一兩年大力投入的和機器學(xué)習(xí)深度學(xué)習(xí)的整合方面。Flink 在流處理相關(guān)的方面還是領(lǐng)先一些,比如對 watermark,window,trigger 的各種支持。
Flink API (來源:https://ci.apache.org/projects/flink/flink-docs-release-1.5/concepts/programming-model.html)
Spark 和 Flink 都是通用的能夠支持超大規(guī)模數(shù)據(jù)處理,支持各種處理類型的計算引擎。兩個系統(tǒng)都有很多值得探討的方面在這里沒有觸及,比如 SQL 的優(yōu)化,和機器學(xué)習(xí)的集成等等。這里主要是試圖從最基本的架構(gòu)和設(shè)計方面來比較一下兩個系統(tǒng)。因為上層的功能在一定程度上是可以互相借鑒的,有足夠的投入應(yīng)該都能做好。而基本的設(shè)計改變起來會傷筋動骨,更困難一些。
Spark 和 Flink 的不同執(zhí)行模型帶來的最大的區(qū)別應(yīng)該還是在對流計算的支持上。最開始的 Spark Streaming 對流計算想得過于簡單,對復(fù)雜一點的計算用起來會有不少問題。從 Spark 2.0 開始引入的 Structured Streaming 重新整理了流計算的語義,支持按事件時間處理和端到端的一致性。雖然在功能上還有不少限制,比之前已經(jīng)有了長足的進步。不過 micro batch 執(zhí)行方式帶來的問題還是存在,特別在規(guī)模上去以后性能問題會比較突出。最近 Spark 受一些應(yīng)用場景的推動,也開始開發(fā)持續(xù)執(zhí)行模式。2.3里的實驗性發(fā)布還只支持簡單的 map 類的操作。
Spark 持續(xù)執(zhí)行模式狀態(tài)(來源:https://www.slideshare.net/databricks/continuous-processing-in-structured-streaming-with-jose-torres)
從最近 Spark+AI Summit 大會上的介紹來看(下圖),會發(fā)展成一個和 Flink 的流處理模式比較相似的執(zhí)行引擎。不過從下圖來看,主要的功能都還在開發(fā)中或者待開發(fā)。對將來能做到什么程度,和 Spark 原來的 batch 執(zhí)行引擎怎么結(jié)合,我們拭目以待。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。