2019阿里云峰會·上海開發(fā)者大會于7月24日盛大開幕，本次峰會與未來世界的開發(fā)者們分享開源大數據、IT基礎設施云化、數據庫、云原生、物聯(lián)網等領域的技術干貨，共同探討前沿科技趨勢。本文整理自開源大數據專場中阿里巴巴高級技術專家楊克特（魯尼）先生的精彩演講，主要講解了Apache Flink過去和現在的發(fā)展情況，同時分享了對Apache Flink未來發(fā)展方向的理解。

《Apache Flink 的過去現在和未來》PPT下載

以下內容根據演講視頻以及PPT整理而成。

一、Flink的過去

1.Flink 的出現

Apache Flink項目在捐獻給Apache之前，是由柏林工業(yè)大學博士生發(fā)起的項目，當時的Flink系統(tǒng)還是一個基于流式Runtime的批處理引擎，主要解決的也是批處理的問題。2014年，Flink被捐獻給Apache，并迅速成為Apache 的頂級項目之一。2014年8月份，Apache發(fā)布了第一個Flink版本，Flink 0.6.0，在有了較好的流式引擎支持后，流計算的價值也隨之被挖掘和重視；同年12月，Flink發(fā)布了0.7版本，正式推出了DataStream API，這也是目前Flink應用的最廣泛的API。

2.Flink 0.9

State的支持和處理是流計算系統(tǒng)難以回避的存在，早期的流計算系統(tǒng)會將State的維護和管理交給用戶，如Storm和Spark Streaming。這種做法會帶來兩個問題，一方面提高了編寫流計算系統(tǒng)的門檻；另一方面，如果用戶自己維護State，容錯成本和系統(tǒng)提供Exactly Once 語義的成本將會提高。因此，2015年6月發(fā)布的Flink 0.9版本引入了內置State支持，并支持多種State 類型，如ValueState、MapState、ListState 等。

同時為了支持 Exactly Once 的一致性語義，還需要將本地的 State 組裝成一個全局的 Checkpoint。Flink 0.9中引入的Global Checkpoint機制是基于經典的Chandy-Lamport算法進行的改進。如圖，Flink 會在數據源中定期插入Barrier，框架在看到 Barrier 后會對本地的 State 做一個快照，然后再將 Barrier 往下游發(fā)送。我們可以近似的認為處理 Checkpoint 的Barrier只會引出一個消息處理的 overhead，這和正常的消息處理量相比幾乎可以忽略不計。在引入 Chandy-Lamport 算法以后，Flink 在保證 Exactly Once 的前提下，提供高吞吐和延遲便不再是一個 tradeoff，可以同時保證高吞吐和低延遲，而其它系統(tǒng)在做類似設計時，往往需要在吞吐和延遲之間做取舍，高一致性會影響吞吐量，反之在大的吞吐下無法保證一致性。

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 系統(tǒng)設計理念的先進性，看好其發(fā)展前景，因此阿里巴巴內部開始大量使用 Flink，同時也對 Flink 做了大刀闊斧的改進。

1. 重構分布式架構

在阿里和社區(qū)合作之后，考慮到阿里內部業(yè)務數據龐大、線上壓力非常大，因此第一個大刀闊斧的改進就是重構分布式架構。早期的Flink在各個角色之間沒有清晰的劃分，大部分職責集中在同一角色中，比如作業(yè)的調度，資源的申請、Task 的分配等內容，并且，這個角色還需要管理集群里的所有作業(yè)，在作業(yè)量非常大的阿里內部場景，很快就暴露了這樣的瓶頸。在重構分布式架構過程中，阿里有意識的將調度作業(yè)和申請資源的角色進行分離，設定了Job Manager和Resource Manager兩個職責，此后Resource Manager可以完全進行插件化處理，方便對接各種資源調度系統(tǒng)，如YARN和Kubernetes。以對接Kubernetes為例，只需寫一個插件，所有的作業(yè)便可以順暢的運營在整個環(huán)境中，大大簡化了流程。同時，這個架構還支持每一個作業(yè)使用獨立的 Job Manager 和 Resource Manager，這樣也大大提升了擴展性，一個集群可以輕松支持成千上萬的作業(yè)。

2. 增量 Checkpoint

為了解決數十 TB 量級 State 數據，阿里在 Flink 中引入了增量 Checkpoint 機制。在早期版本中，Flink 在執(zhí)行 Checkpoint 的時候，會將每個 Task 本地的 State 數據全量拷貝到可靠存儲上。當 State 的量級上到 TB 之后，每次都備份全量的數據顯然是一個無法接受的方案。增量 Checkpoint 機制也比較容易理解，就是在每一次 Checkpoint 時，不將所有 State 數據都刷新到可靠的存儲上，而只將這個 Checkpoint 周期內新增的 State 數據進行備份。而在作業(yè)碰到異常重啟恢復的時候，再使用全量的數據進行恢復。有了這個機制之后，Flink 便可以輕松處理數十 TB 的量級 State 數據。這個問題也是當時制約我們內部機器學習系統(tǒng)的最大因素，解決這一問題之后，Flink 流式應用的范圍變得更加廣泛。

3. 基于 credit 的流控機制

Flink 1.0 版本會在多個 Worker 之間共享一個 TCP channel。如果多個 Operator 在一個Task Manager 中，Operator 之間的網絡連接又是 TCP 共享，當其中一個 Operator 產生反壓，就會影響到同一個進程中其它 Operator 的處理效率，導致運行不穩(wěn)定。因此在網絡層，阿里引入了基于信用的流控機制，每個 Operator 不能無限制的往 TCP channel 中發(fā)送數據。每個 Operator 有自己的信用，當它向下游發(fā)送數據時需要減信用，當下游真正消費數據后，這個信用分數才會加回來，上游才可以繼續(xù)往這個虛擬 Channel 中發(fā)送數據。Flink 引入精細的流控機制之后，作業(yè)的吞吐或延遲都變得更加穩(wěn)定，不會因為某一個算子的臨時抖動導致整個作業(yè)的不穩(wěn)定。

4. Streaming SQL

阿里巴巴集團內部有大量的作業(yè)，作為平臺維護方，如果用戶作業(yè)出現問題，需要第一時間查看用戶的代碼找出問題。但是用戶代碼數量不一，多則上萬行，少則上百行，使得維護成本非常高。所以阿里選擇統(tǒng)一的 Streaming SQL 作為開發(fā)語言，通過查看用戶的 SQL 就能夠了解用戶的意圖。選擇 SQL 還有很多其他好處，比如 SQL 會集成一個優(yōu)化器，讓系統(tǒng)和框架幫助用戶優(yōu)化作業(yè)，提升用戶的執(zhí)行效率。
這里需要說明一下 Streaming SQL 的語義，這也是一些剛接觸 Streaming SQL 的用戶的典型問題。簡單來說，Streaming SQL和傳統(tǒng)的批處理 SQL 語義上是一致的，只是在執(zhí)行模式和結果輸出方式上有所不同。比如下圖是一個用戶的分數表，需要做簡單的分數求和，同時計算結果的最后更新時間。在 SQL 語句中，SUM(Score) 計算分數，同時取 MAX（Time），與批處理不同之處在于，流式數據的實時性使 Streaming SQL 在運行時無法一下子看到所有數據，如在 12：01 時，Streaming SQL 會數出一個空記錄，以為這時候系統(tǒng)連一條記錄都沒有看到。隨著記錄源源不斷的到來，在12：04時輸出第一次的結果，這是對12：04之前記錄的數據都進行了計算。在12：07時，可以看到當前表中所有的數據，對結果進行一次更新輸出。假設 USER_SCORES 表一開始就存在，那么批處理運行的結果與流計算最終的結果是一樣的，這也就說明了流批一體的 SQL 語義的一致性。

5. Flink 在阿里的服務情況

在 2018 年雙 11，阿里巴巴服務規(guī)模已經超過萬臺集群。單作業(yè)已經達到了數十 TB 的狀態(tài)數據，所有的作業(yè)加起來更是達到了 PB 級。每天需要處理超過十萬億的事件數據。在雙 11 的零點峰值時，數據處理量已經達到了 17 億條每秒。

在過去，Flink 基本上圍繞著 Continuous Processing 和 Streaming Analytics 領域展開，包括 DataStream API 和后來提出的 Streaming SQL。Flink 不僅在 Continuous Processing 和 Streaming Analytics 領域站穩(wěn)了腳跟，并且成為了當前領域的領先者。

三、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 提供的是更貼近物理執(zhí)行計劃的 API，引擎完全基于用戶的描述能執(zhí)行作業(yè)，不會過多的進行優(yōu)化和干預。Table API 和 SQL 是關系表達式 API，用戶使用這個 API 描述想要做一件什么事情，由框架在理解用戶意圖之后，配合優(yōu)化器翻譯成高效的具體執(zhí)行圖。這兩套 API 在未來都會同時提供流計算和批處理的支持，在此基礎之上，Flink 會共享統(tǒng)一的 DAG 層和 Stream Operator，Runtime 層則保留了分布式的 Streaming DataFlow。

2. 統(tǒng)一 Operator 抽象

Flink 架構的改動引發(fā)了統(tǒng)一 Operator 抽象問題，因為原來的 Operator 抽象只適用于Flink 的 Streaming 作業(yè)，Flink 的 DataSet API 并沒有使用原來的 Operator 抽象。Flink 早期的代碼參考了經典數據庫的方式，所有的算子都是以 pull 的模式執(zhí)行。如下圖， Filter 算子嘗試找上游拉取數據，上游算子 HashJoin 會嘗試往兩端（Build 端和 Probe 端）拉取數據，做 Join。在低延遲和高吞吐要求的情況下，Flink 的 Streaming 作業(yè)通過推的方式執(zhí)行，框架在讀取到數據之后會以 push 的方式推給所有需要的 Operator。為了統(tǒng)一 Operator 抽象，讓 Streaming Operator 也能做到 HashJoin 的操作，阿里在協(xié)議上做了擴展，擴展的語義中算子可以通知框架想要的輸入順序。下圖中，HashJoin 通知 Framework 優(yōu)先將 Build 端數據推給自己，在 HashJoin 處理完 Build 端，同時構建好 Hashtable 之后，再把Probe端的數據推給 HashJoin。以往開發(fā)人員支持流或批處理時很多算子需要寫兩套程序，統(tǒng)一 Operator 抽象之后，算子可以實現復用，幫助開發(fā)人員提高開發(fā)效率，達到事半功倍的效果。

3. Table API & SQL 1.9新特性

• 全新的 SQL 類型系統(tǒng)：Table API & SQL 1.9 引入了全新的 SQL 的類型系統(tǒng)。以往的Table 層的類型系統(tǒng)復用了 Runtime 的 TypeInformation，但在實際操作過程當中遇到較多的限制。引入全新的 SQL 類型系統(tǒng)可以更好的對齊 SQL 語義。
• DDL初步支持：這個版本中 Flink 還引入了 DDL 的初步支持，用戶可以使用 Create Table 或 Drop Table 等簡單的語法定義表格或刪除表。
• Table API增強：Table API 原來僅為關系表達式的 API，Table API & SQL 1.9中現在加入了 Map，FlatMap 等更加靈活的 API。
• 統(tǒng)一的Catalog API：Table API & SQL 1.9 引入了統(tǒng)一的 Catalog API 之后，可以方便的和其它的 Catalog 對接。比如常見的 Hive，可以通過統(tǒng)一的 Catalog API，實現與 Hive.metastore 交互的插件，讓 Flink 可以直接讀取和處理 Hive 中的表。
• Blink planner：Table API 增加了 Blink planner 的支持，因為在底層的 Runtime 做了較大的變化后，上層需要 SQL 的 Planner 與底層的 Runtime 進行對接。為了確保原來的 Table API 用戶盡量不受影響，社區(qū)完整保留了原來的 Flink Planner。但同時又引入了新的 Blink planner，與新的 Runtime 設計進行對接。

Blink Planner Feature

Blink planner 增加了較多的新功能。首先，Blink planner 對數據結構進行了二進制化、增加了更豐富的內置函數、在聚合時引入了 Minibatch 優(yōu)化、采取多種解熱點手段來解決聚合過程中碰到的熱點數據等。另外，流計算中的維表關聯(lián)的應用非常廣泛，開發(fā)者需要對數據流進行數據量維度的擴增，所以 Blink Planner 也支持了維表關聯(lián)。TopN 在電商領域應用非常廣泛，通過 Blink Planner 提供的 TopN 功能就可以輕松完成統(tǒng)計成交額排名前幾的商家這樣的功能。在對 TopN 功能進行簡單的擴展之后，Blink Planner 還支持了高效的流式去重。值得一提的是，Blink Planner 已經能夠完整的支持批處理，目前阿里內部版本已經可以跑通完整的 TPC-H 和 TPC-DS 這樣標準的 Benchmark 測試集。

4. 批處理優(yōu)化

Flink 在 Runtime 層針對批處理實現了較多的優(yōu)化。批處理中最經典問題便是錯誤處理的恢復。如下圖，Flink 在拓撲中可以比較靈活的調配每個邊的傳輸類型，在 A 跟 B 之間以網絡直連，B 跟 C 之間插入 Cache 層，在輸出端輸出 Cache 數據，減少 FailOver 傳播的代價。假設在 D 節(jié)點發(fā)生了錯誤，從 D 節(jié)點向上回溯到需要重新計算的范圍，當回溯到 Cache 層時，如果 B1 的結果已經存在于 DFS 里或者 Cache 到了其它地方，錯誤的回溯則不需要再繼續(xù)進行。為了確保一致性，到 Cache 層之后還需繼續(xù)向下回溯一遍，對下游還未執(zhí)行或執(zhí)行一半的作業(yè)進行簡單的重啟，如果沒有 Cache 支持，節(jié)點之間都是網絡連接，當 D 節(jié)點發(fā)生錯誤時，錯誤會蔓延到整張圖，而在有 Cache 支持的情況下只需重啟其中很小的子圖，可以大大提高 Flink 面對錯誤時的恢復效率。

插件化Shuffle Manager：Flink 1.9 版本增加了 Shuffle 插件，用戶自己可以實現中間的Shuffle 層，通過專門的 Service 接收中間的數據。當然也可以復用基于 Yarn 的 Shuffle Service。

5. 生態(tài)

Flink 1.9 版本在生態(tài)方面有較大的投入，比如增加了 Hive 的兼容性。在引入統(tǒng)一的Catelog API 之后，Flink 已經可以直接讀取 Hive Metastore。用戶可以通過 Flink SQL 處理 Hive 中的數據，同時處理完數據之后 Flink 能夠將數據寫回 Hive 表，寫回的方式可以兼容 Hive 的數據格式，若有后續(xù)的 Hive 作業(yè)，用戶可以在 Hive 表上繼續(xù)操作。另外，為了給用戶提供更好的開發(fā)體驗，Flink 和 Zeppelin 進行了整合，用戶可以直接在 Notebook 中使用 Flink SQL，也可以使用 Python API 編寫 Flink 的作業(yè)。

6. 中文社區(qū)

Flink 社區(qū)對中文用戶非常重視。Flink 社區(qū)官網中已經增加了中文版文檔的支持。另外，社區(qū)開通了 Flink 中文用戶郵件列表，用戶訂閱郵件列表后，可以使用中文描述問題，社區(qū)中會有非常多的熱心愛好者幫助解答問題。

Flink 在實時計算和流計算領域的領先地位已毋庸置疑，后面對批處理支持將會重點關注。從 Flink 1.9 版本中可以看到，無論是推出更強大的 SQL 執(zhí)行引擎，還是在 Runtime 層對錯誤恢復更友好的支持，都表明了 Flink 1.9 版本對于批處理的重視程度，而這僅僅是開始。

四、Flink 未來發(fā)展方向

1. Micro Services 案例

如下圖，電商系統(tǒng)中有訂單層、訂單交易系統(tǒng)、庫存系統(tǒng)、支付系統(tǒng)和物流系統(tǒng)。首先Micro services 之間以事件方式驅動系統(tǒng)之間的調用。用戶觸發(fā)一個訂單，訂單系統(tǒng)收到訂單做計算邏輯，再調用庫存系統(tǒng)，以上操作是典型的事件驅動模型。為了保證性能和穩(wěn)定性，在不同的 Micro Services 中需要使用 RPC Call，如果使用同步的 RPC Call，則需要解決線程數據量膨脹問題，所以需要在 Micro Services 之間會引入 Async Call。由于每個 Micro Service 的處理能力有限，比如當訂單跟庫存的 RPC 比例是 1:10 比例時，我們不能無限制的向下游系發(fā)送 RPC 調用，因此需要引入一套流控的機制，適當放緩發(fā)送的 RPC 的量。但用戶流量難以預測，最佳解決方案是每個 Micro Service 都可以單獨的擴容和縮容。回到訂單系統(tǒng)，當訂單系統(tǒng)壓力較大時，對訂單層做擴容，或者當庫存處于流量低峰時，可以進行服務能力的縮減，所有的系統(tǒng)都需要數據的持久化，而系統(tǒng)背后都離不開 DB 的支持。

總結起來，Micro Service 需要幾點核心要素。第一，事件驅動，第二是系統(tǒng)間的異步傳輸，同時需要具備較好的流控機制，在節(jié)點之間和節(jié)點內做動態(tài)的擴縮容，最后需要有自己的 DB，可以理解為 Micro Service 需要有對 State 的支持，能夠存儲歷史狀態(tài)。

不難發(fā)現，Micro Service 的需求 Flink 都能夠覆蓋。首先，Flink 是以消息為驅動的系統(tǒng)，同時有非常精細的流控機制；因為網絡之間天然的解耦，Flink 的數據傳輸都是異步進行；除此之外，Flink 還可以單獨為每一個算子增加并發(fā)或者縮減并發(fā)，內置 State 的支持等等。Micro Services 的場景遠遠大于流計算和批處理的場景，相信在不遠的將來 Flink 的社區(qū)也會朝這個方向做更多的探索和嘗試，實現對 Event-driven Application 服務場景的支持。

Apache Flink 首屆極客挑戰(zhàn)賽

持續(xù)學習、和同行交流的機會，由賈揚清助陣，阿里云計算平臺事業(yè)部、天池平臺、intel 聯(lián)合舉辦的首屆 Apache Flink 極客挑戰(zhàn)賽重磅來襲！

聚焦機器學習與計算性能兩大時下熱門領域，參與比賽，讓自己成為技術多面手，還有機會贏得 10W 獎金。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的即将发版！Apache Flink 1.9 版本有哪些新特性？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。