[[326093]]

前言

做大數(shù)據(jù)絕對(duì)躲不過的一個(gè)熱門話題就是實(shí)時(shí)流計(jì)算，而提到實(shí)時(shí)流計(jì)算，就不得不提 Spark 和 Flink。Spark 從 2014 年左右開始迅速流行，剛推出時(shí)除了在某些場(chǎng)景比 Hadoop MapReduce 帶來幾十到上百倍的性能提升外，還提出了用一個(gè)統(tǒng)一的引擎支持批處理、流處理、交互式查詢、機(jī)器學(xué)習(xí)等常見的數(shù)據(jù)處理場(chǎng)景。憑借高性能和全面的場(chǎng)景支持，Spark 早已成為眾多大數(shù)據(jù)開發(fā)者的最愛。

正在 Spark 如日中天高速發(fā)展的時(shí)候，2016 年左右 Flink 開始進(jìn)入大眾的視野并逐漸廣為人知。由于Spark在數(shù)據(jù)流的實(shí)時(shí)處理中較弱，而Flink 憑借更優(yōu)的流處理引擎，同時(shí)也支持各種處理場(chǎng)景，成為 Spark 的有力挑戰(zhàn)者。

本文對(duì) Spark 和 Flink 進(jìn)行了全面分析與對(duì)比，且看下一代大數(shù)據(jù)計(jì)算引擎之爭(zhēng)，誰主沉浮?

Spark簡(jiǎn)介

Spark是基于內(nèi)存的計(jì)算框架，計(jì)算速度非?？臁Ｈ绻胍獙?duì)接外部的數(shù)據(jù)，比如HDFS讀取數(shù)據(jù)，需要事先搭建一個(gè)Hadoop 集群。Apache Spark是一個(gè)開源集群運(yùn)算框架，相對(duì)于Hadoop的MapReduce會(huì)在運(yùn)行完工作后將中介數(shù)據(jù)存放到磁盤中，Spark使用了存儲(chǔ)器內(nèi)運(yùn)算技術(shù)，能在數(shù)據(jù)尚未寫入硬盤時(shí)即在存儲(chǔ)器內(nèi)分析運(yùn)算。

Flink簡(jiǎn)介

Flink 是一個(gè)針對(duì)流數(shù)據(jù)和批數(shù)據(jù)的分布式處理引擎。它主要是由 Java 代碼實(shí)現(xiàn)。目前主要還是依靠開源社區(qū)的貢獻(xiàn)而發(fā)展。對(duì) Flink 而言，其所要處理的主要場(chǎng)景就是流數(shù)據(jù)，批數(shù)據(jù)只是流數(shù)據(jù)的一個(gè)極限特例而已。再換句話說，F(xiàn)link 會(huì)把所有任務(wù)當(dāng)成流來處理，這也是其最大的特點(diǎn)。Flink 可以支持本地的快速迭代，以及一些環(huán)形的迭代任務(wù)。

Flink 和 Spark 對(duì)比

Spark和Flink都支持批處理和流處理，接下來讓我們對(duì)這兩種流行的數(shù)據(jù)處理框架在各方面進(jìn)行對(duì)比。首先，這兩個(gè)數(shù)據(jù)處理框架有很多相同點(diǎn)。

• 都基于內(nèi)存計(jì)算;
• 都有統(tǒng)一的批處理和流處理APl，都支持類似SQL的編程接口;
• 都支持很多相同的轉(zhuǎn)換操作，編程都是用類似于Scala Collection APl的函數(shù)式編程模式;
• 都有完善的錯(cuò)誤恢復(fù)機(jī)制;
• 都支持Exactly once的語義一致性。

當(dāng)然，它們的不同點(diǎn)也是相當(dāng)明顯，我們可以從4個(gè)不同的角度來看。

• 從流處理的角度來講，Spark基于微批量處理，把流數(shù)據(jù)看成是一個(gè)個(gè)小的批處理數(shù)據(jù)塊分別處理，所以延遲性只能做到秒級(jí)。而Flink基于每個(gè)事件處理，每當(dāng)有新的數(shù)據(jù)輸入都會(huì)立刻處理，是真正的流式計(jì)算，支持毫秒級(jí)計(jì)算。由于相同的原因，Spark只支持基于時(shí)間的窗口操作(處理時(shí)間或者事件時(shí)間)，而Flink支持的窗口操作則非常靈活，不僅支持時(shí)間窗口，還支持基于數(shù)據(jù)本身的窗口，開發(fā)者可以自由定義想要的窗口操作。
• 從SQL 功能的角度來講，Spark和Flink分別提供SparkSQL和Table APl提供SQL交互支持。兩者相比較，Spark對(duì)SQL支持更好，相應(yīng)的優(yōu)化、擴(kuò)展和性能更好，而Flink在SQL支持方面還有很大提升空間。
• 從迭代計(jì)算的角度來講，Spark對(duì)機(jī)器學(xué)習(xí)的支持很好，因?yàn)榭梢栽趦?nèi)存中緩存中間計(jì)算結(jié)果來加速機(jī)器學(xué)習(xí)算法的運(yùn)行。但是大部分機(jī)器學(xué)習(xí)算法其實(shí)是一個(gè)有環(huán)的數(shù)據(jù)流，在Spark中，卻是用無環(huán)圖來表示。而Flink支持在運(yùn)行時(shí)間中的有環(huán)數(shù)據(jù)流，從而可以更有效的對(duì)機(jī)器學(xué)習(xí)算法進(jìn)行運(yùn)算。
• 從相應(yīng)的生態(tài)系統(tǒng)角度來講，Spark 的社區(qū)無疑更加活躍。Spark可以說有著Apache旗下最多的開源貢獻(xiàn)者，而且有很多不同的庫來用在不同場(chǎng)景。而Flink由于較新，現(xiàn)階段的開源社區(qū)不如Spark活躍，各種庫的功能也不如Spark全面。但是Flink還在不斷發(fā)展，各種功能也在逐漸完善。

如何選擇Spark和Flink

對(duì)于以下場(chǎng)景，你可以選擇 Spark。

• 數(shù)據(jù)量非常大而且邏輯復(fù)雜的批數(shù)據(jù)處理，并且對(duì)計(jì)算效率有較高要求(比如用大數(shù)據(jù)分析來構(gòu)建推薦系統(tǒng)進(jìn)行個(gè)性化推薦、廣告定點(diǎn)投放等);
• 基于歷史數(shù)據(jù)的交互式查詢，要求響應(yīng)較快;
• 基于實(shí)時(shí)數(shù)據(jù)流的數(shù)據(jù)處理，延遲性要求在在數(shù)百毫秒到數(shù)秒之間。

結(jié)語

任何技術(shù)都不是孤立發(fā)展的，大數(shù)據(jù)技術(shù)更是如此。放眼未來，無論是Spark還是Flink，兩者的發(fā)展重點(diǎn)都將是數(shù)據(jù)科學(xué)和平臺(tái)API化，使其生態(tài)系統(tǒng)越來越完善。亦或許，會(huì)有更新的大數(shù)據(jù)處理引擎出現(xiàn)，誰知道呢。