Flink 的新方向在哪裏？這場頂級盛會給出了答案

九月的柏林，比杭州多了一絲清冽，與之相對應的，是如火如荼的2018 Flink Forward Berlin（以下簡稱FFB）會場。在這個初秋，Apache Flink 核心貢獻者、行業先鋒、實踐專家在這裏齊聚一堂，圍繞Flink發展示狀，生態與將來，共話計算之浪潮。值得一提的是，阿里巴巴做爲ApacheFlink主要貢獻方，受邀參與這次盛會，並發表演講。

本文主要來自阿里巴巴研究員量仔和阿里巴巴資深技術專家莫問在2018 Flink Forward Berlin會後的分享。

衆所周知，Apache Flink是一款分佈式、高性能、高可用、高精確的爲數據流應用而生的開源流式處理框架。Flink的核心是在數據流上提供數據分發、通訊、具有容錯的分佈式計算。同時，Flink在流處理引擎上提供了批流融合計算能力，以及SQL表達能力。

Flink Forward旨在聚集大數據領域一流人才共同探討流計算、實時分析等領先技術。經過參會不只能夠了解到Flink社區的最新動態和發展計劃，還能夠了解到國內外一線大廠圍繞Flink生態的生產實踐經驗，是Flink開發者和使用者不可錯過的盛會。

Leager 橫空出世， ACID有新解

這次柏林Flink Forward上對於Flink的將來，展示出了幾個新的方向：第一，Flink在解決傳統的分佈式事務（ACID）上作了更多改進。這次柏林Flink Forward上針對ACID提出了一種新的解法，這種方式比傳統的分佈式事務在性能上有更強的優點，走出了Streaming原有的領域和相關方面的擴張。Flink建立初期主要解決的是流計算方向的問題，隨着生態的發展，同時也爲解決多方面的需求，Flink 不斷提高其解決更多場景的能力。正因如此，當下Flink正在作的場景就是從流計算向一個通用的場景轉變。

第二，阿里巴巴在FFB上宣佈對於批和流兩種計算模型作了更深度的融合，批計算能力對比當前Flink社區版本有了數量級的提高；與此同時，在大數據生態方面，Flink從流處理到如今的批流融合，獲得了質的飛躍。從長遠角度看，不管是機器學習仍是到其餘各個方面的場景，會逐漸將整個Flink生態完善起來。

同時，在大會第一天上午的主論壇中，dataArtisans重磅發佈了基於雲計算的分佈式事務（ACID）的產品Leager，目前Leager發佈了2個版本，一個是可試用的單機Streaming版本，另一個是River版本，在DA Platform上有售賣。

Leager API在github上能夠查看：

https://github.com/dataArtisans/da-streamingledger

大會現場，經過一個簡單的Demo，dataArtisans CTO Stephan Ewen 向聽衆介紹了在金融行業如何經過Leager解決銀行的轉帳問題。這是 Flink 生態上，一個新的分佈式事務的解決方案。

批流統一，大勢所趨

Flink在建立之初，就憑藉其能夠優雅支持多種計算模式的架構，被業界認爲具有先天優點，這也是幾年前阿里巴巴選擇Flink引擎的一個重要緣由。現在阿里憑藉其領先的技術水平，持續優化Flink在批計算處理方面的性能，使批與流之間的界限日漸消弭，真正實現批流統一。

對比Flink，其勁敵Spark也有流批統一的概念，但作法與之大有不一樣。Spark是基於批處理作流處理，而且Spark在架構上先天不足，致使其在性能上的提高舉步維艱，同時，自然批處理爲主的架構爲Spark進一步提升吞吐量帶來巨大障礙。而Flink的批流統一，從另一個方向去看，是將流做爲一切計算的基礎。這個方案與Spark相比，最本質的區別在於：第一， Flink是自然的流處理引擎，容許其在流上作到極致；第二，在流上作批，架構上容許把批處理也作到極致。

儘管在當初選擇大數據計算引擎時，Spark不管是從熱度仍是生態角度也許都比Flink更勝一籌。但從長遠考慮，阿里看到其在架構上存在幾乎難以逾越的鴻溝，雖然Flink如今沒有Spark生態那麼火熱，可是Flink的先天架構優點，加之諸如阿里這些大廠的支持，相信Flink會開闢出一片新的天空，且走的更遠。

三年前，在內部啓動Flink時，因其開源產品的特性，很難知足阿里大致量的特定場景需求，爲了將Flink在阿里巴巴真正運行起來，阿里巴巴實時計算團隊作了大量的優化，並命名Flink在阿里巴巴內部的版本爲Blink。Blink在迭代優化的過程當中，也在不斷向社區捐贈代碼，真正作到「取之開源，用之開源」。

目前，阿里巴巴的實時業務場景，從搜索到廣告、數據平臺、安全等等。全部大的場景都是基於阿里巴巴內部版本Blink展開，同時經過Stream Compute產品在阿里提供公共雲服務。在Flink Forward上，阿里爲Flink提出的批流融合新突破，這也是架構上的一個新方向，並已經獲得了初步的成果和驗證。

蔣曉偉認爲Flink新的發展方向有兩個，第一個是在傳統數據處理領域：包括批流統1、機器學習、以及如何把AI workload融合進來；第二個是Flink和微服務的技術融合創新，從而爲在線服務領域帶來新的變革。這使得Flink在生態上，也會擁有大的想象空間。

Flink Forward過去只在德國柏林、美國舊金山舉辦。今年將由阿里巴巴做爲獨家承辦方將這一盛會引入中國，於今年12月在北京落地，共建生態。更多會議信息將於近期發佈，敬請關注。

關於Flink，也許你還想了解這些事情

Q：架構上，Flink和Spark相比最大的特色是什麼，爲何Flink更適合作批流融合統一引擎？

Flink底層是基於Streaming，而Spark底層是基於Batch;這是兩個大相徑庭的作法，Spark是在RDD的Batch上構建一切，所以Spark構建Streaming須要把RDD作的很是小。 在粗粒度上面構建一個細粒度，在計算上會有不少瓶頸，架構上的問題很難去解決，這也是Spark在Streaming上作的一些事。而Flink自然就是Streaming, Batch就是在Bounded Streaming上的延伸，在架構上是沒有多少損失的。所以Flink在走Batch這條路上走下去是沒有太多障礙的，而且阿里在Flink上面作了不少針對Batch場景的優化和改進，例如：JOB的調度以及容錯，數據Shuffe，任務執行優化上都作了不少工做。

Q： 機器學習在Flink平臺應用案例多嗎？Flink在AI時代怎麼同Spark競爭？

Flink平臺應用案例仍是較多的，在阿里內部，幾乎一半的計算都是在機器學習上，近年來至關重要的一個趨勢就是朝着實時機器學習發展。Flink的批流融合架構，使得其不管在離線仍是實時機器學習領域均可以發揮。首先，在深度學習方面，如今不少算法在業務場景中都獲得了很好的應用，做爲一個好的計算引擎，都須要和深度學習很好的集成，Flink在這方面也正在作大量的工做；其次，對於傳統的機器學習，阿里在Flink上也作了不少工做，並實現以及改進了不少機器學習算法。

Q：將來Flink和Blink發展差別性，或是有多少Feature沒辦法反饋給社區，對社區是否是一種損失？

阿里特殊的業務體量是不少公司暫時達不到的，這使得阿里在發展的過程當中會更早遇到一些技術瓶頸，天然也會更早的解決這些問題。在解決問題的過程當中，阿里會將對Flink的改進方案通過必定時間的驗證確保穩定可行後再貢獻給Flink開源社區。固然，Flink社區也是由不少其餘公司在支持和使用，因此向社區貢獻的過程和節奏是須要必定耐心和時間的，但這個過程確定會愈來愈快，愈來愈順暢。

Q：持續不按期的批處理算批仍是算流？

批和流的分類不是非黑即白的問題，兩者的界限會在批流統一趨勢下逐漸模糊。咱們真正要關心的問題是，選擇執行計劃是什麼樣的方式。好比一方面從Kafka流式獲取數據，同時按期還要從HBase批量獲取數據，這個時候已經分不清楚是批仍是流任務了，這就是真正的批流融合了。

Q： Flink DataSet和DataStream API是否能統一？

目前TableAPI/SQL是統一的，但DataSet和DataStream是針對流和批不一樣的2個API，阿里如今提出了一個更加底層的DAGAPI，即一個有限無環圖來表達計算拓撲的概念，這個拓撲能夠表達各類流或者批的語義，圖上的點表示算子（能夠是流也能夠是批算子），中間數據是流式傳輸仍是批處理傳輸，整個圖也能夠是流批混合的，例如：一個Source從Kafka讀一個DataStream，另外一個Source按期從HDFS或者HBase讀一個DataSet。其餘API均可以基於DAGAPI來定義語義，之後DataSet API也許能夠和DataStream整合掉，在DataStream中增長有限流的算子，就能夠實現批處理了。

Q： Flink SQL 跟 GreenPlum 這樣MPP架構的OLAP計算引擎 比起來優點在哪？

從處理場景來講，Flink SQL更廣一些，例如：Flink SQL不只支持短Query，還能夠有長query。Flink在Failover上面作的比較全面，但OLAP都是短Query，不怎麼須要Failover，所以OLAP引擎能夠認爲是一種特殊的批處理場景，有着本身特殊的需求和特性。

 

本文做者：期待直播的

本文來自雲棲社區合做夥伴「阿里技術」，瞭解相關信息能夠關注「阿里技術」。