即將發版！Apache Flink 1.9 版本有哪些新特性？

時間 2019-11-05

標籤即將 apache flink 1.9 版本哪些特性欄目 Apache 简体版

原文原文鏈接

2019阿里雲峯會·上海開發者大會於7月24日盛大開幕，本次峯會與將來世界的開發者們分享開源大數據、IT基礎設施雲化、數據庫、雲原生、物聯網等領域的技術乾貨，共同探討前沿科技趨勢。本文整理自開源大數據專場中阿里巴巴高級技術專家楊克特（魯尼）先生的精彩演講，主要講解了Apache Flink過去和如今的發展狀況，同時分享了對Apache Flink將來發展方向的理解。算法

《Apache Flink 的過去如今和將來》PPT下載數據庫

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

1、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 版本的基石。框架

2、阿里巴巴與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 領域站穩了腳跟，而且成爲了當前領域的領先者。

3、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 版本對於批處理的重視程度，而這僅僅是開始。

4、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 服務場景的支持。