Flink 1.11.0 釋出，有哪些值得關注的新特性？

阿里妹導讀：7 月 7 日，Flink 1.11.0 正式釋出。歷時近 4 個月，Flink 在生態、易用性、生產可用性、穩定性等方面都進行了增強和改善。Apache Flink PMC、阿里巴巴高階技術專家王治江，同時也是這個版本的 release manager 之一，將和大家一一分享，並深度剖析 Flink 1.11.0 帶來了哪些讓大家期待已久的特性，對一些有代表性的 feature 從不同維度解讀。

首先在每個版本的規劃初期，會從志願者中選出 1-2 名作為 release manager。1.11.0 版本我作為中國這邊的 release manager，同時還有一名來自 Ververica 的 Piotr Nowojski 作為德國方的 release manager，這在某種程度上也說明中國的開發者和貢獻度在整個社群的佔比很重要。

接下來會進行這個版本的 feature kickoff。在一些大的方向上，社群的規劃週期可能比較久，會分階段、分步驟跨越多個版本完成，確保質量。每個版本的側重點也會有所不同，比如前兩個版本側重於批處理的加強，而這個版本更側重於流處理易用性的提升。社群規劃的 feature 列表會在郵件列表中發起討論，以收集更多的使用者/開發者意見和反饋。

一般的開發週期為 2-3 個月時間，提前會明確規劃出大概的 feature freeze 時間，之後進行 release candidate 的釋出和測試、以及 bug fix。一般經過幾輪的迭代週期後會正式投票透過一個相對穩定的 candidate 版本，然後基於這個版本正式釋出。

CREATE TABLE my_table (  ...) WITH (  'connector'='...', -- e.g. 'kafka'  'format'='debezium-json',  'debezium-json.schema-include'='true' -- default: false (Debezium can be configured to include or exclude the message schema)  'debezium-json.ignore-parse-errors'='true' -- default: false);

• Hive 寫入：FLIP-115 完善擴充套件了 FileSystem connector 的基礎能力和實現，Table/SQL 層的 sink 可以支援各種格式（CSV、Json、Avro、Parquet、ORC），而且支援 Hive table 的所有格式。

• Partition 支援：資料匯入 Hive 引入 partition 提交機制來控制可見性，透過sink.partition-commit.trigger 控制 partition 提交的時機，透過 sink.partition-commit.policy.kind 選擇提交策略，支援 SUCCESS 檔案和 metastore 提交。

• Hive 讀取：實時化的流式讀取 Hive，透過監控 partition 生成增量讀取新 partition，或者監控資料夾內新檔案生成來增量讀取新檔案。

• FLIP-123 透過 Hive Dialect 為使用者提供語法相容，這樣使用者無需在 Flink 和 Hive 的 CLI 之間切換，可以直接遷移 Hive 指令碼到 Flink 中執行。

• 提供 Hive 相關依賴的內建支援，避免使用者自己下載所需的相關依賴。現在只需要單獨下載一個包，配置 HADOOP_CLASSPATH 就可以執行。

• 對使用者而言，在 Flink 中改造已有的 source 或者重新實現一個生產級的 source connector 不是一件容易的事情，具體體現在沒有公共的程式碼可以複用，而且需要理解很多 Flink 內部細節以及實現具體的 event time 分配、watermark 產出、idleness 監測、執行緒模型等。

• 批和流的場景需要實現不同的 source。

• partitions/splits/shards 概念在介面中沒有顯式表達，比如 split 的發現邏輯和資料消費都耦合在 source function 的實現中，這樣在實現 Kafka 或 Kinesis 型別的 source 時增加了複雜性。

• 在 runtime 執行層，checkpoint 鎖被 source function 搶佔會帶來一系列問題，框架很難進行最佳化。

• 首先在 Job Manager 和 Task Manager 中分別引入兩種不同的元件 Split Enumerator 和 Source reader，解耦 split 發現和對應的消費處理，同時方便隨意組合不同的策略。比如現有的 Kafka connector 中有多種不同的 partition 發現策略和實現耦合在一起，在新的架構下，我們只需要實現一種 source reader，就可以適配多種 split enumerator 的實現來對應不同的 partition 發現策略。

• 在新架構下實現的 source connector 可以做到批流統一，唯一的小區別是對批場景的有限輸入，split enumerator 會產出固定數量的 split 集合並且每個 split 都是有限資料集；對於流場景的無限輸入，split enumerator 要麼產出無限多的 split 或者 split 自身是無限資料集。

• 複雜的 timestamp assigner 以及 watermark generator 透明的內建在 source reader 模組內執行，對使用者來說是無感知的。這樣使用者如果想實現新的 source connector，一般不再需要重複實現這部分功能。

• 每次呼叫可以處理 N 條資料。

• 資料格式基於 Apache Arrow，大大降低了 Java、Python 程式之間的序列化/反序列化開銷。

• 方便 Python 使用者基於 Numpy 和 Pandas 等資料分析領域常用的 Python 庫，開發高效能的 Python UDF。

• PyFlink table 和 Pandas DataFrame 之間無縫切換（FLIP-120），增強 Pandas 生態的易用性和相容性。

• Table & SQL 中可以定義和使用 Python UDTF（FLINK-14500），不再必需 Java/Scala UDTF。

• Cython 最佳化 Python UDF 的效能（FLIP-121），對比 1.10.0 可以提升 30 倍。

• Python UDF 中使用者自定義 metric（FLIP-112），方便監控和除錯 UDF 的執行。

• Session 模式：提前啟動一個叢集，所有作業都共享這個叢集的資源執行。優勢是避免每個作業單獨啟動叢集帶來的額外開銷，缺點是隔離性稍差。如果一個作業把某個 Task Manager（TM）容器搞掛，會導致這個容器內的所有作業都跟著重啟。雖然每個作業有自己獨立的 Job Manager（JM）來管理，但是這些 JM 都執行在一個程式中，容易帶來負載上的瓶頸。

• Per-job 模式：為了解決 session 模式隔離性差的問題，每個作業根據資源需求啟動獨立的叢集，每個作業的 JM 也是執行在獨立的程式中，負載相對小很多。

• 上游輸出端控制單個 sub partition 堆積 buffer 的最大閾值（backlog），避免負載不均場景下單個鏈路上堆積大量 buffer。

• 在不影響網路吞吐效能的情況下合理修改上下游預設的 buffer 配置。

• 上下游資料傳輸的基礎協議進行了調整，允許單個資料鏈路可以配置 0 個獨佔 buffer 而不死鎖，這樣總的 buffer 數量和作業併發規模解耦。根據實際需求在吞吐效能和 checkpoint 速度兩者之間權衡，自定義 buffer 配比。

• Checkpoint barrier 跨資料 buffer 傳輸，不在輸入輸出佇列排隊等待處理，這樣就和運算元的計算能力解耦，barrier 在節點之間的傳輸只有網路延時，可以忽略不計。

• 每個運算元多個輸入鏈路之間不需要等待 barrier 對齊來執行 checkpoint，第一個到的 barrier 就可以提前觸發 checkpoint，這樣可以進一步提速 checkpoint，不會因為個別鏈路的延遲而影響整體。

• 為了和之前 aligned checkpoint 的語義保持一致，所有未被處理的輸入輸出資料 buffer 都將作為 channel state 在 checkpoint 執行時進行快照持久化，在 failover 時連同 operator state 一同進行恢復。換句話說，aligned 機制保證的是 barrier 前面所有資料必須被處理完，狀態實時體現到 operator state 中；而 unaligned 機制把 barrier 前面的未處理資料所反映的 operator state 延後到 failover restart 時透過 channel state 回放進行體現，從狀態恢復的角度來說最終都是一致的。注意這裡雖然引入了額外的 in-flight buffer 的持久化，但是這個過程實際是在 checkpoint 的非同步階段完成的，同步階段只是進行了輕量級的 buffer 引用，所以不會過多佔用運算元的計算時間而影響吞吐效能。