摘要：Apache Flink是一個面向分散式資料流處理和批次資料處理的開源計算平臺，它能夠基於同一個Flink執行時，提供支援流處理和批處理兩種型別應用的功能。目前，Apache Flink 1.9.0版本已經正式釋出，該版本有什麼樣的里程碑意義，又具有哪些重點改動和新功能呢？本文中，阿里巴巴高階技術專家伍翀就為大家帶來了對於Apache Flink 1.9.0版本的介紹。

演講嘉賓介紹：

本次分享主要分為以下三個方面：

1. Flink 1.9.0的里程碑意義
2. Flink 1.9.0的重點改動和新功能
3. 總結

一、Flink 1.9.0的里程碑意義

下圖展示的是在2019年中阿里技術微信公眾號發表的兩篇新聞，一篇為“阿里正式向Apache Flink貢獻Blink程式碼”介紹的是在2019年1月Blink開源並且貢獻給Apache Flink，另外一篇為“修改程式碼150萬行！Apache Flink 1.9.0做了這些重大修改！”介紹的是2019年8月Bink合併入Flink之後首次發版。之所以將這兩篇新聞放在一起，是因為無論是對於Blink還是Flink而言，Flink 1.9.0的發版都是具有里程碑意義的。

在2019年年初，Blink開源貢獻給Apache Flink的時候，一個要點就是Blink會以Flink的一個分支來支援開源，Blink會將其主要的最佳化點都Merge到Flink裡面，一起將Flink做的更好。如今，都已經過去了半年的時間，隨著Flink1.9.0版本的釋出，阿里巴巴的Blink團隊可以驕傲地宣佈自己已經兌現了之前的承諾。因此，當我們結合這兩篇報導來看的時候，能夠發現當初Blink的一些新功能如今已經能夠在Flink1.9.0版本里面看到了，也能看出Flink社群的效率和執行力都是非常高的。

二、Flink 1.9.0的重點改動和新功能

這部分將為大家介紹Flink 1.9.0的重點改動和新功能。

架構升級
整體而言，如果一個軟體系統產生了較大改動，那基本上就是架構升級帶來的，對於Flink而言也不例外。想必熟悉Flink的同學對於下圖中左側的架構圖一定不會陌生，在Flink的分散式流式執行引擎之上有一整套相對獨立的DataStream API和DataSet API，它們分別負責流計算作業和批處理作業。在此基礎之上Flink還提供了一個流批統一的Table API和SQL，使用者可以使用相同的Table API或者SQL來描述流計算作業和批處理作業，只需要在執行時告訴Flink引擎以流模式執行還是以批模式執行即可，Table層將會把作業最佳化成為DataStream作業或者DataSet作業。但是Flink 1.8版本的架構在底層存在一些弊端，那就是DataStream和DataSet在底層共享的程式碼並不多。其次，兩者的API也完全不同，因此就會導致上層重複開發的工作量比較大，長期來看就會使得Flink的開發和維護成本越來越大。

基於上述問題，Blink在架構上進行了一些新型的探索，經過和社群密切的討論之後確定了Flink未來的架構路線。也就是在Flink未來的版本中，DataSet的API會被完全移除掉，SteamTransformation會作為底層的API來描述批作業和流作業，Table API和SQL會將流作業都翻譯到SteamTransformation上，所以在Flink 1.9中為了不影響使用之前版本使用者的體驗，還需要一種能夠讓新舊架構並存的方案。基於這個目的，Flink的社群開發人員也做了一系列努力，提出了上圖中右側的Flink 1.9架構設計，將API和實現部分做了模組的拆分，並且提出了一個Planner介面，能夠支援不同的Planner具體實現。Planner的具體工作就是最佳化和翻譯成物理執行圖等，也就是Flink Query Processor所做的工作。Flink將原本的實現全部移動到了Flink Query Processor中，將從Blink Merge過來的功能都放到了Blink Query Processor。這樣就能夠實現一舉兩得，不僅能夠使得Table模組拆分之後變得更加清晰，更重要的是也不會影響老版本使用者的體驗，同時能夠使得使用者享受到Blink的新功能和最佳化。

Table API & SQL 重構和新功能

在Table API & SQL 重構和新功能部分，Flink在1.9.0版本中也Merge了大量從Blink中增加的SQL功能。這些新功能都是在阿里巴巴內部經過千錘百煉而沉澱出來的，相信能夠使得Flink更上一層臺階。這裡挑選了一些比較重要的成果為大家介紹，比如對於SQL DDL的支援，重構了型別系統，高效流式的TopN，高效流式去重，社群關注已久的維表關聯，對於MinBatch以及多種解熱點手段的支援，完整的批處理支援，Python Table API以及Hive的整合。接下來也會簡單介紹下這些新功能。

SQL DDL：在以前如果要註冊一個Source或者Table Sink，必須要透過Java、Scala等程式碼或者配置檔案進行註冊，而在Flink 1.9版本中則支援了SQL DDL的語法直接去註冊或者刪除表。

重構型別系統：在Flink 1.9版本中實現了一套全新的資料型別系統，這套全新的型別系統與SQL標準進行了完全對齊，能夠支援更加豐富的型別。這套全新的型別系統也為未來Flink SQL能夠支援更加完備和完善的功能打下了堅實的基礎。

TopN：在Flink 1.9版本提供強大的流處理能力以及社群期待已久的TopN來實時計算排行榜，能夠實時計算排名靠前的店鋪或者進行實時流資料的過濾。

高效流式去重：在現實的生產系統中，很多ETL作業或者任務沒有做到端到端的一致性，這就導致明細層可能存在重複資料，這些資料交給彙總層做彙總時就會造成指標偏大，進而多計算了一些值，因此在進入彙總層之前往往都會做一個去重，這裡引入了一個流計算中比較高效的去重功能，能夠以比較低的代價來過濾重複的資料。

維表關聯：能夠實時地關聯MySQL、HBase、Hive表中資料。

MinBatch&多種解熱點手段：在效能最佳化方面，Flink 1.9版本也提供了一些效能最佳化的手段，比如提升吞吐的MinBatch的最佳化以及多種解熱點手段。

完整的批處理支援：Flink 1.9版本具有完整的批處理支援，在下一個版本中也會繼續投入力量來支援TBDS達到開箱即用的高效能。

Python Table API：在Flink 1.9版本中也引入了Python Table API，這也是Flink在多語言方向的有一個重大進步。能夠使得Python使用者能夠輕鬆地玩轉Flink SQL這樣的功能。

Hive整合：Hive是Hadoop生態圈中不可忽視的重要力量，為了更好地去推廣Flink批處理的功能，與Hive進行整合也是必不可少的。很高興，在Flink 1.9版本的貢獻者中也有兩位Hive的PMC來推動整合工作。而首先需要解決的就是Flink如何讀取Hive資料的問題，目前Flink已經完整打通了對於Hive MetaStore的訪問，Flink可以直接去訪問Hive MetaStore中的資料，同時反過來Flink也可以將其表資料中的元資訊直接儲存到Hive MetaStore裡面供Hive訪問，同時我們也增加了Hive的Connector支援CSV等格式，使用者只需要配置Hive的MetaStore就能夠在Flink直接讀取。在此基礎之上，Flink 1.9版本還增加了Hive自定義函式的相容，Hive的自定義函式都能夠在Flink SQL裡面直接執行。

批處理改進：細粒度批作業恢復（FLIP-1）

Flink 1.9版本在批處理部分也做了較多的改進，首要的就是細粒度批作業的恢復。這個最佳化點在很早之前就被提出來了，而在1.9版本里終於將未完成的功能實現了收尾。在Flink 1.9版本中，如果批處理的作業有錯誤發生，Flink會首先計算這個錯誤影響的範圍，這稱為Fault Region，因為在批處理作業中有一些節點需要透過Pipeline的資料進行傳輸，而其他的節點可以透過Blocking的方式先把資料儲存下來，下游再去讀取儲存下來的資料，如果運算元的輸出已經進行了完整的儲存，那就沒有必要將這個運算元重新拉起來執行了，這樣就使得錯誤恢復被控制在一個相對較小的範圍裡面。如果再極端一點，在每個資料Shuffle的地方都進行資料落盤，這就和MapReduce的Map行為比較類似了，不過Flink支援更加高階的用法，使用者可以自行控制每個Shuffle的地方透過網路進行直連還是透過檔案落盤的方式進行傳輸，這也是Flink的一個核心不同點。

有了檔案Shuffle之後，大家也會想是否能夠將這個功能外掛化，使其能夠將檔案Shuffle到其他地方，目前社群也在針對於這個方向做相應的努力，比如可以用Yarn做Shuffle的實現或者做一個分散式服務對於檔案進行Shuffle。在阿里內部已經實現了這種架構，實現了單作業處理百TB級別的作業。當Flink具備這種外掛化機制以後，就能夠輕鬆地對接更加高效和靈活的Shuffle，讓Shuffle這個批處理裡面老大難的問題得到較好的解決。

流處理改進：State Processor API(FLIP-43)

流處理一直都是Flink的核心，所以在Flink 1.9版本里面也在流處理方面提出了很多改進，增加了一個非常實用的功能叫做Sate Processor API，其能夠幫助使用者直接訪問Flink中儲存的State，API能夠幫助使用者非常方便地讀取、修改甚至重建整個State。這個功能的強大之處在於幾個方面，第一個就是靈活地讀取外部的資料，比如從一個資料庫中讀取自主地構建Savepoint，解決作業冷啟動問題，這樣就不用從N天前開始重跑整個資料。

此外，藉助State Processor API，使用者可以直接分析State中的資料，因為這部分資料在之前一直屬於黑盒，這裡面儲存的資料是對是錯，是否存在異常都用都無從得知，當有了State Processor API之後，使用者就可以像分析普通資料一樣來分析State資料，進而檢測異常和分析故障。第三點就是對於髒資料的訂正，比如有一條髒資料汙染了State，就可以用State Processor API對於狀態進行修復和訂正。最後一點就是狀態遷移，但使用者修改了作業邏輯，還想要複用原來作業中大部分的State，或者想要升級這個State的結構就可以用這個API來完成相應的工作。在流處理面很多常見的工作和問題都可以透過Flink 1.9版本里面提供的State Processor API解決，因此也可以看出這個API的應用前景是非常廣泛的。

重構的Web UI

除了上述功能的改進之外，Flink 1.9.0還提供瞭如下圖所示的煥然一新的Web UI。這個最新的前端UI由專業Web前端工程師操刀，採用了最新的AngularJS進行重構。可以看出最新的Web UI非常的清新和現代化，也算是Apache開源軟體裡面自帶UI的一股清流。

三、總結

經過緊鑼密鼓的開發，Flink 1.9.0不僅迎來了眾多的中國開發者，貢獻了海量的程式碼，也帶來了很多的使用者。從下圖可以看出，無論是從解決issue數量還是從程式碼commit數量上來看，Flink 1.9.0版本超過了之前兩個版本的總和。從程式碼修改行數來看，Flink 1.9.0達到了150萬行，是之前版本的程式碼修改行數的大約6倍，可以說Flink 1.9.0是Flink開源以來開發者最為活躍的一個版本。從Contributor數量上也可以看出，Flink也吸引了越來越多的貢獻者，並且其中很多的貢獻者都來自於中國。此外，根據Apache官方所釋出的開源專案活躍指標來看，Flink的各項指標也都名列前茅。

從這一切都能夠看出，Flink 1.9.0是一個開始，在未來無論是Flink的功能還是生態都會變得越來越好。我們也由衷地希望更多的開發者能夠加入Flink開發社群，一起將Flink做的越來越好。

本文作者：jark

原文連結

本文為雲棲社群原創內容，未經允許不得轉載。