導讀：Flink Forward是由Apache官方授權，Apache Flink 商業公司dataArtisans（Flink核心作者創辦）發起，阿裡巴巴、 Uber、Airbnb、Netflix等公司參與的國際型會議。日前Flink Forward柏林會議剛剛閉幕，今天，我們一起分享會議内容。
九月的柏林，比杭州多了一絲清冽，與之相對應的，是如火如荼的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引擎可以認為是一種特殊的批處理場景，有着自己特殊的需求和特性。