2018和2019年是大數(shù)據(jù)領(lǐng)域蓬勃發(fā)展的兩年，自2019年伊始，實時流計算技術(shù)開始步入普通開發(fā)者視線，各大公司都在不遺余力地試用新的流計算框架，實時流計算引擎Spark Streaming、Kafka Streaming、Beam和Flink持續(xù)火爆。
最近Spark社區(qū)，來自Databricks、NVIDIA、Google以及阿里巴巴的工程師們正在為Apache Spark 3.0添加原生的GPU調(diào)度支持，參考（SPARK-24615和SPARK-24579）該方案將填補了Spark在GPU資源的任務(wù)調(diào)度方面的空白，極大擴展了Spark在深度學習、信號處理的應(yīng)用場景。
與此同時，2019年1月底，阿里巴巴內(nèi)部版本Blink正式開源！一石激起千層浪，Blink開源的消息立刻刷爆朋友圈，整個大數(shù)據(jù)計算領(lǐng)域一直以來由Spark獨領(lǐng)風騷，瞬間成為兩強爭霸的時代。那么未來Spark和Blink的發(fā)展會碰撞出什么樣的火花？誰會成為大數(shù)據(jù)實時計算領(lǐng)域最亮的那顆星？
我們接下來看看Spark和Flink各自的優(yōu)劣和主要區(qū)別。
底層機制
Spark的數(shù)據(jù)模型是彈性分布式數(shù)據(jù)集 RDD(Resilient Distributed Dattsets)，這個內(nèi)存數(shù)據(jù)結(jié)構(gòu)使得spark可以通過固定內(nèi)存做大批量計算。初期的Spark Streaming是通過將數(shù)據(jù)流轉(zhuǎn)成批(micro-batches)，即收集一段時間(time-window)內(nèi)到達的所有數(shù)據(jù)，并在其上進行常規(guī)批處，所以嚴格意義上，還不能算作流式處理。但是Spark從2.x版本開始推出基于 Continuous Processing Mode的 Structured Streaming，支持按事件時間處理和端到端的一致性，但是在功能上還有一些缺陷，比如對端到端的exactly-once語義的支持。
一個典型的Spark DAG示意圖
Flink是統(tǒng)一的流和批處理框架，基本數(shù)據(jù)模型是數(shù)據(jù)流，以及事件(Event)的序列，F(xiàn)link從設(shè)計之初秉持了一個觀點:批是流的特例。每一條數(shù)據(jù)都可以出發(fā)計算邏輯，那么Flink的流特性已經(jīng)在延遲方面占得天然優(yōu)勢。
一個典型的Flink workflow示意圖
Flink還提供了一個獨特的概念叫做有狀態(tài)的計算，它被用來處理一種情況：數(shù)據(jù)的處理和之前處理過的數(shù)據(jù)或者事件有關(guān)聯(lián)。比如，在做聚合操作的時候，一個批次的數(shù)據(jù)聚合的結(jié)果依賴于之前處理過的批次。早期的Spark用戶會經(jīng)常受此類問題所困擾，直到Structured Streaming的出現(xiàn)才得已解決。
Flink從一開始就引入了state的概念來處理這種問題。為狀態(tài)計算提供了一個通用的解決方案。
周邊生態(tài)
在大數(shù)據(jù)領(lǐng)域，任何一個項目的火爆都被離不開完善的技術(shù)棧，Spark和Flink都基于對底層數(shù)據(jù)和計算調(diào)度的高度抽象的內(nèi)核上開發(fā)出了批處理，流處理，結(jié)構(gòu)化數(shù)據(jù)，圖數(shù)據(jù)，機器學習等不同套件，完成對絕大多數(shù)數(shù)據(jù)分析領(lǐng)域的場景的支持，意圖統(tǒng)一數(shù)據(jù)分析領(lǐng)域。
Flink和Spark都是由Scla和Java混合編程實現(xiàn)，Spark的核心邏輯由Scala完成，而Flink的主要核心邏輯由Java完成。在對第三方語言的支持上，Spark支持的更為廣泛，Spark幾乎完美的支持Scala，Java，Python,R語言編程。
Spark周邊生態(tài)(圖來源于官網(wǎng))
與此同時，F(xiàn)link&Spark官方都支持與存儲系統(tǒng)如HDFS,S3的集成，資源管理/調(diào)度 Yarn，Mesos，K8s等集成，數(shù)據(jù)庫Hbase,Cassandra,消息系統(tǒng)Amazon，Kinesis，Kafka等。
Flink周邊生態(tài)(圖來源于官網(wǎng))
在最近的Spark+AI峰會上,Databricks公司推出了自己的統(tǒng)一分析平臺(Unified Analytics Platform)，目標是使戶在一個系統(tǒng)里解決盡可能多的數(shù)據(jù)需求。Flink的目標和Spark一致，包含AI的統(tǒng)一平臺也是Flink的發(fā)展方向，從技術(shù)上來看，F(xiàn)link是完全有能力支持對機器學習和深度學習的集成，但目前來看，F(xiàn)link仍有很長的路要走。
未來趨勢
2018年是機器學習和深度學習元年，ML在數(shù)據(jù)處理領(lǐng)域占比越來越重。Spark和Flink在做好實時計算的同時，誰能把握住這次機會就可以在未來的發(fā)展中占得先機。另外隨著5G的發(fā)展，網(wǎng)絡(luò)傳輸不再是瓶頸之時，IOT的爆發(fā)式發(fā)展也將會是實時計算需求爆發(fā)之時，屆時Flink在流式計算中的天然優(yōu)勢將發(fā)揮的淋漓盡致，Blink的開源和阿里巴巴對Blink的加持無疑 又給Flink未來的發(fā)展注入一針強心劑。
總結(jié)
Spark和Flink發(fā)展至今，基本上已經(jīng)是實時計算領(lǐng)域的事實標準。兩者在易用性和生態(tài)系統(tǒng)建設(shè)上都投入了大量的資源，是現(xiàn)在和未來一段時間內(nèi)大數(shù)據(jù)領(lǐng)域最有有力的競爭者。二者的發(fā)展是競爭中伴隨著互相促進，在與機器學習集成和統(tǒng)一處理平臺的建設(shè)上雙方各有優(yōu)劣，誰能盡早補齊短板就會在未來的發(fā)展中占得優(yōu)勢。對于普通大數(shù)據(jù)領(lǐng)域的開發(fā)者而言，當下也是最好的時代，可以見證兩大數(shù)據(jù)引擎的蓬勃發(fā)展，除了學習別無選擇，這何嘗不是是一種幸運?
參考目錄：
http://datastrophic.io/core-concepts-architecture-and-internals-of-apache-spark
https://databricks.com/spark/about
https://ci.apache.org/projects/flink/flink-docs-stable/release-notes/flink-1.7.html
http://spark.apache.org
