[[326093]]

前言

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

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

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

Spark簡介

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

Flink簡介

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

Flink 和 Spark 對比

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

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

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

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

如何選擇Spark和Flink

對于以下場景，你可以選擇 Spark。

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

結(jié)語

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