九月的柏林，比杭州多了一絲清冽，與之相對應的，是如火如荼的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新的發展方向有兩個，第一個是在傳統數據處理領域：包括批流統一、機器學習、以及如何把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引擎可以認爲是一種特殊的批處理場景，有着自己特殊的需求和特性。
本文作者：期待直播的