Flink 1.11 究竟有哪些易用性上的改善

本篇文章給大家分享的是有關Flink 1.11 究竟有哪些易用性上的改善，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

• 首先在每個版本的規劃初期，會從志愿者中選出 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 讀?。簩崟r化的流式讀取 Hive，通過監控 Partition 生成增量讀取新 Partition，或者監控文件夾內新文件生成來增量讀取新文件。

• FLIP-123 通過 Hive Dialect 為用戶提供語法兼容，這樣用戶無需在 Flink 和 Hive 的 CLI 之間切換，可以直接遷移 Hive 腳本到 Flink 中執行。

• 提供 Hive 相關依賴的內置支持，避免用戶自己下載所需的相關依賴?，F在只需要單獨下載一個包，配置 HADOOP_CLASSPATH 就可以運行。

• 對用戶而言，在 Flink 中改造已有的 Source 或者重新實現一個生產級的 Source Connector 不是一件容易的事情，具體體現在沒有公共的代碼可以復用，而且需要理解很多 Flink 內部細節以及實現具體的 Event Time 分配、Watermark 產出、Idleness 監測、線程模型等。

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

• Partitions/Splits/Shards 概念在接口中沒有顯式表達，比如 Split 的發現邏輯和數據消費都耦合在 Source Sunction 的實現中，這樣在實現 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 引用，所以不會過多占用算子的計算時間而影響吞吐性能。

  

以上就是Flink 1.11 究竟有哪些易用性上的改善，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。