來(lái)看看Spark和Flink各自的優(yōu)劣和主要區(qū)別

2018和2019年是大數(shù)據(jù)領(lǐng)域蓬勃發(fā)展的兩年，自2019年伊始，實(shí)時(shí)流計(jì)算技術(shù)開(kāi)始步入普通開(kāi)發(fā)者視線，各大公司都在不遺余力地試用新的流計(jì)算框架，實(shí)時(shí)流計(jì)算引擎Spark Streaming、Kafka Streaming、Beam和Flink持續(xù)火爆。

最近Spark社區(qū)，來(lái)自Databricks、NVIDIA、Google以及阿里巴巴的工程師們正在為Apache Spark 3.0添加原生的GPU調(diào)度支持，參考（SPARK-24615和SPARK-24579）該方案將填補(bǔ)了Spark在GPU資源的任務(wù)調(diào)度方面的空白，極大擴(kuò)展了Spark在深度學(xué)習(xí)、信號(hào)處理的應(yīng)用場(chǎng)景。

與此同時(shí)，2019年1月底，阿里巴巴內(nèi)部版本Blink正式開(kāi)源！一石激起千層浪，Blink開(kāi)源的消息立刻刷爆朋友圈，整個(gè)大數(shù)據(jù)計(jì)算領(lǐng)域一直以來(lái)由Spark獨(dú)領(lǐng)風(fēng)騷，瞬間成為兩強(qiáng)爭(zhēng)霸的時(shí)代。那么未來(lái)Spark和Blink的發(fā)展會(huì)碰撞出什么樣的火花？誰(shuí)會(huì)成為大數(shù)據(jù)實(shí)時(shí)計(jì)算領(lǐng)域最亮的那顆星？

我們接下來(lái)看看Spark和Flink各自的優(yōu)劣和主要區(qū)別。

底層機(jī)制

Spark的數(shù)據(jù)模型是彈性分布式數(shù)據(jù)集 RDD(Resilient Distributed Dattsets)，這個(gè)內(nèi)存數(shù)據(jù)結(jié)構(gòu)使得spark可以通過(guò)固定內(nèi)存做大批量計(jì)算。初期的Spark Streaming是通過(guò)將數(shù)據(jù)流轉(zhuǎn)成批(micro-batches)，即收集一段時(shí)間(time-window)內(nèi)到達(dá)的所有數(shù)據(jù)，并在其上進(jìn)行常規(guī)批處，所以嚴(yán)格意義上，還不能算作流式處理。但是Spark從2.x版本開(kāi)始推出基于 Continuous Processing Mode的 Structured Streaming，支持按事件時(shí)間處理和端到端的一致性，但是在功能上還有一些缺陷，比如對(duì)端到端的exactly-once語(yǔ)義的支持。

一個(gè)典型的Spark DAG示意圖

Flink是統(tǒng)一的流和批處理框架，基本數(shù)據(jù)模型是數(shù)據(jù)流，以及事件(Event)的序列，F(xiàn)link從設(shè)計(jì)之初秉持了一個(gè)觀點(diǎn):批是流的特例。每一條數(shù)據(jù)都可以出發(fā)計(jì)算邏輯，那么Flink的流特性已經(jīng)在延遲方面占得天然優(yōu)勢(shì)。

一個(gè)典型的Flink workflow示意圖

Flink還提供了一個(gè)獨(dú)特的概念叫做有狀態(tài)的計(jì)算，它被用來(lái)處理一種情況：數(shù)據(jù)的處理和之前處理過(guò)的數(shù)據(jù)或者事件有關(guān)聯(lián)。比如，在做聚合操作的時(shí)候，一個(gè)批次的數(shù)據(jù)聚合的結(jié)果依賴于之前處理過(guò)的批次。早期的Spark用戶會(huì)經(jīng)常受此類問(wèn)題所困擾，直到Structured Streaming的出現(xiàn)才得已解決。

Flink從一開(kāi)始就引入了state的概念來(lái)處理這種問(wèn)題。為狀態(tài)計(jì)算提供了一個(gè)通用的解決方案。

周邊生態(tài)

在大數(shù)據(jù)領(lǐng)域，任何一個(gè)項(xiàng)目的火爆都被離不開(kāi)完善的技術(shù)棧，Spark和Flink都基于對(duì)底層數(shù)據(jù)和計(jì)算調(diào)度的高度抽象的內(nèi)核上開(kāi)發(fā)出了批處理，流處理，結(jié)構(gòu)化數(shù)據(jù)，圖數(shù)據(jù)，機(jī)器學(xué)習(xí)等不同套件，完成對(duì)絕大多數(shù)數(shù)據(jù)分析領(lǐng)域的場(chǎng)景的支持，意圖統(tǒng)一數(shù)據(jù)分析領(lǐng)域。

Flink和Spark都是由Scla和Java混合編程實(shí)現(xiàn)，Spark的核心邏輯由Scala完成，而Flink的主要核心邏輯由Java完成。在對(duì)第三方語(yǔ)言的支持上，Spark支持的更為廣泛，Spark幾乎完美的支持Scala，Java，Python，R語(yǔ)言編程。

Spark周邊生態(tài)(圖來(lái)源于官網(wǎng))

與此同時(shí)，F(xiàn)link&Spark官方都支持與存儲(chǔ)系統(tǒng)如HDFS，S3的集成，資源管理/調(diào)度Yarn，Mesos，K8s等集成，數(shù)據(jù)庫(kù)Hbase，Cassandra，消息系統(tǒng)Amazon，Kinesis，Kafka等。

Flink周邊生態(tài)(圖來(lái)源于官網(wǎng))

在最近的Spark+AI峰會(huì)上，Databricks公司推出了自己的統(tǒng)一分析平臺(tái)(Unified Analytics Platform)，目標(biāo)是使戶在一個(gè)系統(tǒng)里解決盡可能多的數(shù)據(jù)需求。Flink的目標(biāo)和Spark一致，包含AI的統(tǒng)一平臺(tái)也是Flink的發(fā)展方向，從技術(shù)上來(lái)看，F(xiàn)link是完全有能力支持對(duì)機(jī)器學(xué)習(xí)和深度學(xué)習(xí)的集成，但目前來(lái)看，F(xiàn)link仍有很長(zhǎng)的路要走。

未來(lái)趨勢(shì)

2018年是機(jī)器學(xué)習(xí)和深度學(xué)習(xí)元年，ML在數(shù)據(jù)處理領(lǐng)域占比越來(lái)越重。Spark和Flink在做好實(shí)時(shí)計(jì)算的同時(shí)，誰(shuí)能把握住這次機(jī)會(huì)就可以在未來(lái)的發(fā)展中占得先機(jī)。另外隨著5G的發(fā)展，網(wǎng)絡(luò)傳輸不再是瓶頸之時(shí)，IOT的爆發(fā)式發(fā)展也將會(huì)是實(shí)時(shí)計(jì)算需求爆發(fā)之時(shí)，屆時(shí)Flink在流式計(jì)算中的天然優(yōu)勢(shì)將發(fā)揮的淋漓盡致，Blink的開(kāi)源和阿里巴巴對(duì)Blink的加持無(wú)疑又給Flink未來(lái)的發(fā)展注入一針強(qiáng)心劑。

總結(jié)

Spark和Flink發(fā)展至今，基本上已經(jīng)是實(shí)時(shí)計(jì)算領(lǐng)域的事實(shí)標(biāo)準(zhǔn)。兩者在易用性和生態(tài)系統(tǒng)建設(shè)上都投入了大量的資源，是現(xiàn)在和未來(lái)一段時(shí)間內(nèi)大數(shù)據(jù)領(lǐng)域最有有力的競(jìng)爭(zhēng)者。二者的發(fā)展是競(jìng)爭(zhēng)中伴隨著互相促進(jìn)，在與機(jī)器學(xué)習(xí)集成和統(tǒng)一處理平臺(tái)的建設(shè)上雙方各有優(yōu)劣，誰(shuí)能盡早補(bǔ)齊短板就會(huì)在未來(lái)的發(fā)展中占得優(yōu)勢(shì)。對(duì)于普通大數(shù)據(jù)領(lǐng)域的開(kāi)發(fā)者而言，當(dāng)下也是最好的時(shí)代，可以見(jiàn)證兩大數(shù)據(jù)引擎的蓬勃發(fā)展，除了學(xué)習(xí)別無(wú)選擇，這何嘗不是是一種幸運(yùn)?