2019阿里雲峯會·上海開發者大會於7月24日盛大開幕，本次峯會與未來世界的開發者們分享開源大數據、IT基礎設施雲化、數據庫、雲原生、物聯網等領域的技術乾貨，共同探討前沿科技趨勢。本文整理自開源大數據專場中阿里巴巴高級技術專家楊克特（魯尼）先生的精彩演講，主要講解了Apache Flink過去和現在的發展情況，同時分享了對Apache Flink未來發展方向的理解。
以下內容根據演講視頻以及PPT整理而成。
一、Flink的過去
1.Flink 的出現
Apache Flink項目在捐獻給Apache之前，是由柏林工業大學博士生髮起的項目，當時的Flink系統還是一個基於流式Runtime的批處理引擎，主要解決的也是批處理的問題。2014年，Flink被捐獻給Apache，並迅速成爲Apache 的頂級項目之一。2014年8月份，Apache發佈了第一個Flink版本，Flink 0.6.0，在有了較好的流式引擎支持後，流計算的價值也隨之被挖掘和重視；同年12月，Flink發佈了0.7版本，正式推出了DataStream API，這也是目前Flink應用的最廣泛的API。
2.Flink 0.9
State的支持和處理是流計算系統難以迴避的存在，早期的流計算系統會將State的維護和管理交給用戶，如Storm和Spark Streaming。這種做法會帶來兩個問題，一方面提高了編寫流計算系統的門檻；另一方面，如果用戶自己維護State，容錯成本和系統提供Exactly Once 語義的成本將會提高。因此，2015年6月發佈的Flink 0.9版本引入了內置State支持，並支持多種State 類型，如ValueState、MapState、ListState 等。
同時爲了支持 Exactly Once 的一致性語義，還需要將本地的 State 組裝成一個全局的 Checkpoint。Flink 0.9中引入的Global Checkpoint機制是基於經典的Chandy-Lamport算法進行的改進。如圖，Flink 會在數據源中定期插入Barrier，框架在看到 Barrier 後會對本地的 State 做一個快照，然後再將 Barrier 往下游發送。我們可以近似的認爲處理 Checkpoint 的Barrier只會引出一個消息處理的 overhead，這和正常的消息處理量相比幾乎可以忽略不計。在引入 Chandy-Lamport 算法以後，Flink 在保證 Exactly Once 的前提下，提供高吞吐和延遲便不再是一個 tradeoff，可以同時保證高吞吐和低延遲，而其它系統在做類似設計時，往往需要在吞吐和延遲之間做取捨，高一致性會影響吞吐量，反之在大的吞吐下無法保證一致性。
3.Flink 1.0的基石
Flink 1.0 版本加入了基於事件時間的計算支持，引入了 Watermark 機制，可以高效的容忍亂序數據和遲到數據。Flink 1.0同時還內置支持了各種各樣的 window，開箱即用的滾動、滑動、會話窗口等，還可以靈活地自定義窗口。再加上 Flink 0.9 中加入的 State API 和高效的 Checkpoint 支持，這一切構成了 Flink 1.0 版本的基石。
二、阿里巴巴與Flink
2015年之後，阿里巴巴開始注意到 Flink 計算引擎，並且非常認可 Flink 系統設計理念的先進性，看好其發展前景，因此阿里巴巴內部開始大量使用 Flink，同時也對 Flink 做了大刀闊斧的改進。
1. 重構分佈式架構
在阿里和社區合作之後，考慮到阿里內部業務數據龐大、線上壓力非常大，因此第一個大刀闊斧的改進就是重構分佈式架構。早期的Flink在各個角色之間沒有清晰的劃分，大部分職責集中在同一角色中，比如作業的調度，資源的申請、Task 的分配等內容，並且，這個角色還需要管理集羣裏的所有作業，在作業量非常大的阿里內部場景，很快就暴露了這樣的瓶頸。在重構分佈式架構過程中，阿里有意識的將調度作業和申請資源的角色進行分離，設定了Job Manager和Resource Manager兩個職責，此後Resource Manager可以完全進行插件化處理，方便對接各種資源調度系統，如YARN和Kubernetes。以對接Kubernetes爲例，只需寫一個插件，所有的作業便可以順暢的運營在整個環境中，大大簡化了流程。同時，這個架構還支持每一個作業使用獨立的 Job Manager 和 Resource Manager，這樣也大大提升了擴展性，一個集羣可以輕鬆支持成千上萬的作業。
2. 增量 Checkpoint
爲了解決數十 TB 量級 State 數據，阿里在 Flink 中引入了增量 Checkpoint 機制。在早期版本中，Flink 在執行 Checkpoint 的時候，會將每個 Task 本地的 State 數據全量拷貝到可靠存儲上。當 State 的量級上到 TB 之後，每次都備份全量的數據顯然是一個無法接受的方案。增量 Checkpoint 機制也比較容易理解，就是在每一次 Checkpoint 時，不將所有 State 數據都刷新到可靠的存儲上，而只將這個 Checkpoint 週期內新增的 State 數據進行備份。而在作業碰到異常重啓恢復的時候，再使用全量的數據進行恢復。有了這個機制之後，Flink 便可以輕鬆處理數十 TB 的量級 State 數據。這個問題也是當時制約我們內部機器學習系統的最大因素，解決這一問題之後，Flink 流式應用的範圍變得更加廣泛。
3. 基於 credit 的流控機制
Flink 1.0 版本會在多個 Worker 之間共享一個 TCP channel。如果多個 Operator 在一個Task Manager 中，Operator 之間的網絡連接又是 TCP 共享，當其中一個 Operator 產生反壓，就會影響到同一個進程中其它 Operator 的處理效率，導致運行不穩定。因此在網絡層，阿里引入了基於信用的流控機制，每個 Operator 不能無限制的往 TCP channel 中發送數據。每個 Operator 有自己的信用，當它向下遊發送數據時需要減信用，當下遊真正消費數據後，這個信用分數纔會加回來，上游纔可以繼續往這個虛擬 Channel 中發送數據。Flink 引入精細的流控機制之後，作業的吞吐或延遲都變得更加穩定，不會因爲某一個算子的臨時抖動導致整個作業的不穩定。
4. Streaming SQL
阿里巴巴集團內部有大量的作業，作爲平臺維護方，如果用戶作業出現問題，需要第一時間查看用戶的代碼找出問題。但是用戶代碼數量不一，多則上萬行，少則上百行，使得維護成本非常高。所以阿里選擇統一的 Streaming SQL 作爲開發語言，通過查看用戶的 SQL 就能夠了解用戶的意圖。選擇 SQL 還有很多其他好處，比如 SQL 會集成一個優化器，讓系統和框架幫助用戶優化作業，提升用戶的執行效率。
這裏需要說明一下 Streaming SQL 的語義，這也是一些剛接觸 Streaming SQL 的用戶的典型問題。簡單來說，Streaming SQL和傳統的批處理 SQL 語義上是一致的，只是在執行模式和結果輸出方式上有所不同。比如下圖是一個用戶的分數表，需要做簡單的分數求和，同時計算結果的最後更新時間。在 SQL 語句中，SUM(Score) 計算分數，同時取 MAX（Time），與批處理不同之處在於，流式數據的實時性使 Streaming SQL 在運行時無法一下子看到所有數據，如在 12：01 時，Streaming SQL 會數出一個空記錄，以爲這時候系統連一條記錄都沒有看到。隨着記錄源源不斷的到來，在12：04時輸出第一次的結果，這是對12：04之前記錄的數據都進行了計算。在12：07時，可以看到當前表中所有的數據，對結果進行一次更新輸出。假設 USER_SCORES 表一開始就存在，那麼批處理運行的結果與流計算最終的結果是一樣的，這也就說明了流批一體的 SQL 語義的一致性。
5. Flink 在阿里的服務情況
在 2018 年雙 11，阿里巴巴服務規模已經超過萬臺集羣。單作業已經達到了數十 TB 的狀態數據，所有的作業加起來更是達到了 PB 級。每天需要處理超過十萬億的事件數據。在雙 11 的零點峯值時，數據處理量已經達到了 17 億條每秒。
在過去，Flink 基本上圍繞着 Continuous Processing 和 Streaming Analytics 領域展開，包括 DataStream API 和後來提出的 Streaming SQL。Flink 不僅在 Continuous Processing 和 Streaming Analytics 領域站穩了腳跟，並且成爲了當前領域的領先者。
三、Flink的現在
1. Flink 1.9的架構變化
目前 Flink 最新的版本是1.9，Flink 在這個版本上做了較大的架構調整。首先，Flink 之前版本的 Table API 和 SQL API 是構建於兩個底層的 API 之上，即 DataStream API 和 DataSet API。Flink 1.9 經歷了較大的架構調整之後，Table API 和 DataStream API 已成爲同級的 API。不同之處在於 DataStream API 提供的是更貼近物理執行計劃的 API，引擎完全基於用戶的描述能執行作業，不會過多的進行優化和干預。Table API 和 SQL 是關係表達式 API，用戶使用這個 API 描述想要做一件什麼事情，由框架在理解用戶意圖之後，配合優化器翻譯成高效的具體執行圖。這兩套 API 在未來都會同時提供流計算和批處理的支持，在此基礎之上，Flink 會共享統一的 DAG 層和 Stream Operator，Runtime 層則保留了分佈式的 Streaming DataFlow。
2. 統一 Operator 抽象
Flink 架構的改動引發了統一 Operator 抽象問題，因爲原來的 Operator 抽象只適用於Flink 的 Streaming 作業，Flink 的 DataSet API 並沒有使用原來的 Operator 抽象。Flink 早期的代碼參考了經典數據庫的方式，所有的算子都是以 pull 的模式執行。如下圖， Filter 算子嘗試找上游拉取數據，上游算子 HashJoin 會嘗試往兩端（Build 端和 Probe 端）拉取數據，做 Join。在低延遲和高吞吐要求的情況下，Flink 的 Streaming 作業通過推的方式執行，框架在讀取到數據之後會以 push 的方式推給所有需要的 Operator。爲了統一 Operator 抽象，讓 Streaming Operator 也能做到 HashJoin 的操作，阿里在協議上做了擴展，擴展的語義中算子可以通知框架想要的輸入順序。下圖中，HashJoin 通知 Framework 優先將 Build 端數據推給自己，在 HashJoin 處理完 Build 端，同時構建好 Hashtable 之後，再把Probe端的數據推給 HashJoin。以往開發人員支持流或批處理時很多算子需要寫兩套程序，統一 Operator 抽象之後，算子可以實現複用，幫助開發人員提高開發效率，達到事半功倍的效果。
3. Table API & SQL 1.9新特性
- 全新的 SQL 類型系統：Table API & SQL 1.9 引入了全新的 SQL 的類型系統。以往的Table 層的類型系統複用了 Runtime 的 TypeInformation，但在實際操作過程當中遇到較多的限制。引入全新的 SQL 類型系統可以更好的對齊 SQL 語義。
- DDL初步支持：這個版本中 Flink 還引入了 DDL 的初步支持，用戶可以使用 Create Table 或 Drop Table 等簡單的語法定義表格或刪除表。
- Table API增強：Table API 原來僅爲關係表達式的 API，Table API & SQL 1.9中現在加入了 Map，FlatMap 等更加靈活的 API。
- 統一的Catalog API：Table API & SQL 1.9 引入了統一的 Catalog API 之後，可以方便的和其它的 Catalog 對接。比如常見的 Hive，可以通過統一的 Catalog API，實現與 Hive.metastore 交互的插件，讓 Flink 可以直接讀取和處理 Hive 中的表。
- Blink planner：Table API 增加了 Blink planner 的支持，因爲在底層的 Runtime 做了較大的變化後，上層需要 SQL 的 Planner 與底層的 Runtime 進行對接。爲了確保原來的 Table API 用戶儘量不受影響，社區完整保留了原來的 Flink Planner。但同時又引入了新的 Blink planner，與新的 Runtime 設計進行對接。
Blink Planner Feature
Blink planner 增加了較多的新功能。首先，Blink planner 對數據結構進行了二進制化、增加了更豐富的內置函數、在聚合時引入了 Minibatch 優化、採取多種解熱點手段來解決聚合過程中碰到的熱點數據等。另外，流計算中的維表關聯的應用非常廣泛，開發者需要對數據流進行數據量維度的擴增，所以 Blink Planner 也支持了維表關聯。TopN 在電商領域應用非常廣泛，通過 Blink Planner 提供的 TopN 功能就可以輕鬆完成統計成交額排名前幾的商家這樣的功能。在對 TopN 功能進行簡單的擴展之後，Blink Planner 還支持了高效的流式去重。值得一提的是，Blink Planner 已經能夠完整的支持批處理，目前阿里內部版本已經可以跑通完整的 TPC-H 和 TPC-DS 這樣標準的 Benchmark 測試集。
4. 批處理優化
Flink 在 Runtime 層針對批處理實現了較多的優化。批處理中最經典問題便是錯誤處理的恢復。如下圖，Flink 在拓撲中可以比較靈活的調配每個邊的傳輸類型，在 A 跟 B 之間以網絡直連，B 跟 C 之間插入 Cache 層，在輸出端輸出 Cache 數據，減少 FailOver 傳播的代價。假設在 D 節點發生了錯誤，從 D 節點向上回溯到需要重新計算的範圍，當回溯到 Cache 層時，如果 B1 的結果已經存在於 DFS 裏或者 Cache 到了其它地方，錯誤的回溯則不需要再繼續進行。爲了確保一致性，到 Cache 層之後還需繼續向下回溯一遍，對下游還未執行或執行一半的作業進行簡單的重啓，如果沒有 Cache 支持，節點之間都是網絡連接，當 D 節點發生錯誤時，錯誤會蔓延到整張圖，而在有 Cache 支持的情況下只需重啓其中很小的子圖，可以大大提高 Flink 面對錯誤時的恢復效率。
插件化Shuffle Manager：Flink 1.9 版本增加了 Shuffle 插件，用戶自己可以實現中間的Shuffle 層，通過專門的 Service 接收中間的數據。當然也可以複用基於 Yarn 的 Shuffle Service。
5. 生態
Flink 1.9 版本在生態方面有較大的投入，比如增加了 Hive 的兼容性。在引入統一的Catelog API 之後，Flink 已經可以直接讀取 Hive Metastore。用戶可以通過 Flink SQL 處理 Hive 中的數據，同時處理完數據之後 Flink 能夠將數據寫回 Hive 表，寫回的方式可以兼容 Hive 的數據格式，若有後續的 Hive 作業，用戶可以在 Hive 表上繼續操作。另外，爲了給用戶提供更好的開發體驗，Flink 和 Zeppelin 進行了整合，用戶可以直接在 Notebook 中使用 Flink SQL，也可以使用 Python API 編寫 Flink 的作業。
6. 中文社區
Flink 社區對中文用戶非常重視。Flink 社區官網中已經增加了中文版文檔的支持。另外，社區開通了 Flink 中文用戶郵件列表，用戶訂閱郵件列表後，可以使用中文描述問題，社區中會有非常多的熱心愛好者幫助解答問題。
Flink 在實時計算和流計算領域的領先地位已毋庸置疑，後面對批處理支持將會重點關注。從 Flink 1.9 版本中可以看到，無論是推出更強大的 SQL 執行引擎，還是在 Runtime 層對錯誤恢復更友好的支持，都表明了 Flink 1.9 版本對於批處理的重視程度，而這僅僅是開始。
四、Flink 未來發展方向
1. Micro Services 案例
如下圖，電商系統中有訂單層、訂單交易系統、庫存系統、支付系統和物流系統。首先Micro services 之間以事件方式驅動系統之間的調用。用戶觸發一個訂單，訂單系統收到訂單做計算邏輯，再調用庫存系統，以上操作是典型的事件驅動模型。爲了保證性能和穩定性，在不同的 Micro Services 中需要使用 RPC Call，如果使用同步的 RPC Call，則需要解決線程數據量膨脹問題，所以需要在 Micro Services 之間會引入 Async Call。由於每個 Micro Service 的處理能力有限，比如當訂單跟庫存的 RPC 比例是 1:10 比例時，我們不能無限制的向下遊系發送 RPC 調用，因此需要引入一套流控的機制，適當放緩發送的 RPC 的量。但用戶流量難以預測，最佳解決方案是每個 Micro Service 都可以單獨的擴容和縮容。回到訂單系統，當訂單系統壓力較大時，對訂單層做擴容，或者當庫存處於流量低峯時，可以進行服務能力的縮減，所有的系統都需要數據的持久化，而系統背後都離不開 DB 的支持。
總結起來，Micro Service 需要幾點核心要素。第一，事件驅動，第二是系統間的異步傳輸，同時需要具備較好的流控機制，在節點之間和節點內做動態的擴縮容，最後需要有自己的 DB，可以理解爲 Micro Service 需要有對 State 的支持，能夠存儲歷史狀態。
不難發現，Micro Service 的需求 Flink 都能夠覆蓋。首先，Flink 是以消息爲驅動的系統，同時有非常精細的流控機制；因爲網絡之間天然的解耦，Flink 的數據傳輸都是異步進行；除此之外，Flink 還可以單獨爲每一個算子增加併發或者縮減併發，內置 State 的支持等等。Micro Services 的場景遠遠大於流計算和批處理的場景，相信在不遠的將來 Flink 的社區也會朝這個方向做更多的探索和嘗試，實現對 Event-driven Application 服務場景的支持。
Apache Flink 首屆極客挑戰賽
持續學習、和同行交流的機會，由賈揚清助陣，阿里雲計算平臺事業部、天池平臺、intel 聯合舉辦的首屆 Apache Flink 極客挑戰賽重磅來襲！
聚焦機器學習與計算性能兩大時下熱門領域，參與比賽，讓自己成爲技術多面手，還有機會贏得 10W 獎金。
大賽詳情瞭解：https://tianchi.aliyun.com/markets/tianchi/flink2019
本文作者：Ververica
本文爲雲棲社區原創內容，未經允許不得轉載。