官宣｜Apache Flink 1.15 釋出公告

作者 | Joe Moser & 高贇
翻譯 | 高贇

Apache Flink，作為 Apache 社群最活躍的專案之一^[1]，一直秉承積極開放的態度不斷進行技術深耕。在此我們很榮幸的釋出 Flink 1.15 版本，並和大家分享這個版本令人振奮的一些功能和改進！

Apache Flink 核心概念之一是流 (無界資料) 批 (有界資料) 一體。流批一體極大的降低了流批融合作業的開發複雜度。在過去的幾個版本中，Flink 流批一體逐漸成熟，Flink 1.15 版本中流批一體更加完善，後面我們也將繼續推動這一方向的進展。目前大資料處理的一個趨勢是越來越多的業務和場景採用低程式碼的方式進行資料分析，而 Flink SQL則是這種低程式碼方式資料分析的典型代表。越來越多的使用者開始採用 Flink SQL 來實現他們的業務，這也是 Flink 使用者和生態快速增長的重要原因之一。Apache Flink 作為資料處理生態中的重要一環，可以與許多其他技術結合在一起支援各類使用者場景。在當下雲原生的背景下。我們也儘可能將 Flink 與這些系統以及各類雲基礎設施進行無縫整合。

在 1.15 版本中，Apache Flink 社群在上述這些方面都取得了重大進展：

1.15 版本的一大看點是改進了運維 Apache Flink 的體驗：包括明確 Checkpoint 和 Savepoint 在不同作業之間的所屬權，簡化 Checkpoint 和 Savepoint 生命週期管理；更加無縫支援完整的自動伸縮；通過 Watermark 對齊來消除多個資料來源速率不同帶來的問題等
1.15 版本中，Flink 進一步完善流批一體的體驗：繼續完善部分作業完成後的 Checkpoint 操作；支援批模式下的 Window table-valued 函式，並且使其在流批混合的場景下更加易用。
Flink SQL 的進階：包括能夠在不丟失狀態的情況下升級 SQL 作業；新增了對 JSON 相關函式的支援來簡化資料的輸入與輸出操作。
Flink 作為整個資料處理生態中的一環，1.15 版本進一步提升了與雲服務的互動操作性，並且新增了更多的 Sink 聯結器與資料格式。最後，我們在執行時中去除了對 Scala 的依賴^[2]。

輕鬆運維 Apache Flink

長期來看，即使是由最好的工程團隊來進行構建和調優，Flink 作業仍然依賴運維操作。 Flink 支援多種不同的部署模式、API、調優配置與用例，這意味著運維工作至關重要並且可能十分繁重。

在這個版本中，我們聽取了使用者的反饋，對 Flink 的運維操作進行了簡化，使使用者能夠更加輕鬆的進行運維。現在 Flink 明確了 Checkpoint 與 Savepoint 在不同作業之間的所屬權；更加無縫支援完整的自動伸縮；通過 Watermark 對齊消除多個資料來源產出速率不同帶來的問題，並且初步支援了在不丟失狀態的情況下升級 SQL 作業的能力。

澄清 Checkpoint 與 Savepoint 語義

Flink 容錯策略的兩個重要基礎概念是 Checkpoint^[3] 與 Savepoint^[4] (參見比較^[5])。

Savepoint 的主要作用是支援作業修改、備份與升級等場景，它是由使用者來完全控制的。而另一方面，Checkpoint 由 Flink 完全控制，用於通過支援快速恢復與重啟來實現容錯的能力。這兩個概念十分相似，並且它們共享了很大一部分實現。

然而，由於遵循不同的功能要求，這兩個概念逐漸變得不一致，使使用者看起來沒有完整的頂層設計。根據使用者反饋，這兩個概念應該被更好地對齊和協調，最重要的是，這兩個概念應該被更清晰的定義。

在某些停止或重新啟動作業的場景下，雖然邏輯上應該使用 Savepoint，但使用者還是會選擇使用持久化的 Checkpoint，因為 Savepoint 無法享受 Checkpoint 可以使用的一些優化而導致執行較為緩慢。但是在這種情況下，作業從持久化的 Checkpoint 重啟時 (這種情況下 Checkpoint 實際上被當作 Savepoint 來使用)，對使用者來說何時可以清理 Checkpoint 中的資料並不十分清楚。

因此，在 FLIP-193: 狀態所屬權^[6] 中，Flink 希望可以將 Savepoint 和 Checkpoint 抽像成唯一區別是所屬權不同的兩個概念。在 1.15 中，通過支援原生的增量 Savepoint^[7]，Flink 解決了 Savepoint 的一些不足：在過去的版本中，Savepoint 總是使用標準格式以及非增量的方式，這也是導致它效能較差的原因。在 1.15 中，如果使用者選擇使用原生格式並且同時使用了 RocksDB 狀態儲存，那麼Savepoint 將採用增量的方式來執行。我們也更新了相關文件來更好的概覽與理解 Checkpoint 與 Savepoint 的差異。此外，關於從 Savepoint / 持久化的 Checkpoint 恢復^[8]的語義，我們顯式的引入了 CLAIM 與 NO_CLAIM 兩種模式。對於 CLAIM 模式 Flink 將接管快照中資料的所屬權，而對於 NO_CLAIM 模式，Flink 將建立它自己的副本，而由使用者來負責管理與刪除原始的資料。注意現在預設將採用 NO_CLAIM 模式，之前版本中從 Savepoint / 持久化的 Checkpoint 恢復的行為可以通過指定 LEGACY 模式來恢復。

基於 Reactive 模式與自適應排程器的彈性伸縮

由於越來越多的雲服務基於 Apache Flink 構建，Flink 專案變得越來越雲原生，這使得彈性伸縮也越來越重要。

此版本改進了 Reactive 模式^[9] 的指標。Reactive 模式是一個作業級別的模式，在這種模式下， JobManager 將嘗試使用所有可用的 TaskManager 上的資源。我們在 1.15 中保證了作業級別的指標在 Reactive 模式下也可以正常的工作。

我們還為自適應排程器^[10] 新增了異常歷史記錄。自適應排程器是一個新的排程器，它首先宣告瞭所需的資源並且根據根據資源情況在執行前決定資源的並行度。

此外，Flink 提高了縮減作業規模的速度：TaskManager 現在有一個專用程式碼路徑來關閉自己，它會主動從叢集中登出自己而不是依賴於心跳，從而給 JobManager 一個明確的縮減作業規模的訊號。

自適應批排程器

在 1.15 中，我們為 Apache Flink 引入了一個新的自適應批處理排程器^[11]。這一排程器可以自動根據每個節點需要處理的資料量的大小自動決定批處理作業中各節點的並行度。

此排程器的主要優點包括：

易用性：批處理作業的使用者不再需要手動調優並行度。
自適應：自動調整並行度可以更好地適應節點消費資料集隨時間發生變化的情況。
細粒度：每個作業節點的並行度可以單獨調整。這允許 SQL 批處理作業的節點自動為每個節點選擇單獨選擇最適合的並行度。

跨源節點的 Watermark 對齊

如果一個作業中使用了多個資料來源節點，並且這些資料來源以不同的節奏來增長 Watermark，這可能在下游節點中產生一些問題。例如，一些運算元可能需要快取非常大量的資料，從而導致巨大的運算元狀態。因此，我們在這一版本中引入了 Watermark 對齊的能力。

基於新的 Source 介面來實現的資料來源節點可以啟用 Watermark 對齊功能^[12]。使用者可以定義對齊組，如果其中某個源節點與其它節點相比Watermark領先過多，使用者可以暫停從該節點中消費資料。對齊 Watermark 的理想情況是有兩個或更多以不同速度產生 Watermark 的資料來源節點，並且資料來源節點併發與外部系統的分片數量相同的情況。

SQL 版本升級

SQL 查詢的執行計劃及其生成的拓撲是通過優化規則和一個基於成本的模型來得到的，這意味著即使最小的更改也可能會產生一個完全不同的拓撲。這種動態性使得在不同 Flink 版本間保證快照相容性非常具有挑戰性。在 1.15 中，社群首先通過保持拓撲不變的方式使相同的查詢在升級 Flink 版本後仍然可以啟動和執行。

SQL 升級的核心是 JSON 計劃 (即以 JSON 表達的查詢執行計劃，我們目前只有 JavaDocs 中的文件，並且仍在努力更新文件^[13] )，JSON Plan 可以讓 SQL 計劃以結構化資料的方式被匯入和匯出，之前這一功能是一個內部實現，現在它將被公開以提供給使用者使用。Table API 與 SQL 都會提供一種方式來編譯和執行一個保證在不同版本中保持不變的執行計劃。此功能將作為實驗性 MVP 功能釋出。想要嘗試的使用者已經可以建立一個 JSON 計劃，然後可以使用這一計劃在升級後基於舊的運算元結構恢復 Flink 作業。我們將在 1.16 中提供這一功能的完整支援。

從長遠來看，可靠的升級使 Flink SQL 可以線上上生產場景更加可靠的使用。

基於 Changelog 的狀態儲存

在 Flink 1.15 中，我們引入了 MVP 特性：基於 Changelog 的狀態儲存^[14]。這一新的狀態儲存旨在支援更短、更可以預測的 Checkpoint 間隔。它具有以下優勢：

更短的端到端延遲：端到端延遲主要取決於 Checkpoint 機制，特別是使用了兩階段提交的支援端到端一致性的 Sink 節點的情況，這種情況下縮短 Checkpoint 週期意味著可以更快的提交資料。
更可預測的 Checkpoint 間隔：目前 Checkpoint 的完成時間很大程度上取決於需要儲存在 Checkpoint 中的資料的大小。通過使這一資料總是可以很小，Checkpoint 的完成時間變得更加可以預測。
恢復工作更少：Checkpoint 越頻繁，每次重啟後重新處理的資料也會越少。

基於 Changelog 的狀態儲存通過在後臺不斷向非易失性儲存上上傳狀態變化的記錄來實現上述目標。

可重複的清理

在以前的 Flink 版本中，Flink 在作業結束時只嘗試清理一次與作業相關的殘留資料，這可能會導致在發生錯誤時無法完成清理。在這個版本中，Flink 將嘗試重複執行清理以避免殘留資料。預設情況下，Flink 將不斷重試機制，直到執行成功為止。使用者可以通過配置相關引數^[15]來改變這種行為。禁用重試策略可以恢復 Flink 之前版本的行為。

清理 Checkpoint 的相關工作仍在進行中，包括 FLINK-26606^[16]。

Open API

Flink 現在提供遵循 Open API^[17] 標準的 REST API 規範。這允許 REST API 與遵循 Open API 標準的工具直接互動。您可以在 18 找到相應規範。

Application 模式的改進

在 Application 模式^[19] 下執行 Flink 時，如果使用者進行了相關配置^[20]，它現在可以保證作業在結束前能夠正常完成 stop-with-savepoint 操作。

在 Application 模式下執行的作業的恢復和清理也得到了改進。本地狀態的後設資料也可以儲存在工作目錄中，這使得從本地狀態恢復更容易 (例如將工作目錄設定在非易失的跨機器的儲存中的情況，之前本地狀態的後設資料儲存在記憶體中，因此在作業恢復時無法找回)。

流批一體的更多進展

在最新版本中，我們對流批一體的支援進行了進一步的完善。

作業結束前的 Checkpoint

在 Flink 1.14 中，新增了對作業結束前等待一次 Checkpoint 操作的支援，從而保證使用流模式處理有限資料可以保證所有被據被提交，但是在 1.14 中，該功能必須被手動啟用。自上次釋出以來，我們聽取了使用者反饋並決定預設啟用它。關於這一功能的更多資訊以及如何禁用此功能，請參閱 21。需要指出的是，這一預設配置的變化可能延長使用流模式處理有界資料時的執行時間，因為作業必須在結束前等待下一個 Checkpoint 完成。

Window table-valued 函式

Window table-valued 函式^[22] 之前僅可用於流模式下。在 1.15 中，它們現在也可以在批模式下使用。此外，通過實現一個專門的運算元，我們現在不再要求這些 Window 函式必須定義一個聚合器，從而進一步增強了 Window table-valued 函式。

Flink SQL

社群指標表明 Flink SQL 被廣泛使用並且變得越來越流行。在 1.15 中社群對 Flink SQL 也做了許多改進，下文將更加詳細地討論其中兩個改進。

CAST / 型別系統增強

資料以各種形式出現，但是並不是所有情況下都是使用者需要的型別，因此 CAST^[23] 是 SQL 中最常見的操作之一。在 Flink 1.15 中，失敗的 CAST 的預設行為已從返回 null 更改為返回錯誤，從而使它更符合 SQL 標準。之前的行為可以通過呼叫新引入的 TRY_CAST 函式或通過在恢復時配置相應引數來實現。

此外，Flink 1.15 也修正了許多 CAST 的錯誤並對它的功能進行了改進，從而保證結果的正確性。

JSON 函式

JSON 是最流行的資料格式之一，越來越多的 SQL 使用者需要生成或讀取 JSON 型別的資料。Flink 1.15 根據 SQL 2016 標準引入了多個 JSON 處理函式^[24]。這些函式允許使用者來使用 Flink SQL 方言檢查、建立和修改 JSON 字串。

社群支援

Flink 的一個重要目標是使使用者能夠構建流資料管道來解決他們的用例。一般來說，Apache Flink 不會單獨使用，而是作為更大的資料分析平臺中的重要一環。因此，簡化 Flink 在雲環境下的使用與維護、支援無縫連線到其他系統並繼續支援 Java 和 Python 等程式語言對完善 Flink 生態十分重要。

雲環境互操作性

許多使用者在不同雲服務提供商所提供的雲基礎設施中部署與使用 Flink，同時也有一些服務可以幫助使用者管理部署在他們的平臺上的 Flink 叢集。

在 Flink 1.15 中，我們新增了寫入 Google Cloud Storage 的支援。我們還整理了 Flink 生態中的聯結器並把精力放在支援 AWS 相關的生態上 (即 KDS^[25] 與 Firehose^[26] )。

Elasticsearch Sink

我們在 Flink 的整個聯結器生態上進行了大量工作，但我們想強調 Elasticsearch Sink^[27]：它是基於最新的 Sink API 來實現的，因此可以提供非同步輸出與端到端一致性的能力。它可以作為未來更多 Sink 實現的模板。

Scala-free 的 Flink

博文^[28] 已經解釋了為什麼 Scala 使用者現在可以結合任何 Scala 版本 (包括 Scala 3) 使用 Flink的 Java API。

最後，刪除 Scala 依賴只是清理和更新來自 Flink 生態系統的各種技術的更大工作的一部分。

從 Flink 1.14 開始，我們移除了 Mesos 整合，隔離了 Akka，廢棄了 DataSet Java API，並將 Table API 隱藏在一個抽象後面。社群的這些努力也吸引了許多使用者與貢獻者的關注。

PyFlink

在 Flink 1.15 之前，Python API 中使用者定義的函式是在單獨的 Python 程式中執行的，這將導致額外的序列化/反序列化和程式通訊開銷。在資料較大的場景中，例如影像處理等，這個開銷變得不可忽視。此外，由於它涉及程式間通訊，這一處理延遲也是不可忽略的。這些問題在延遲至關重要的場景是不可接受的，例如量化交易等。因此，在 Flink 1.15 中，我們引入了一種 “執行緒” 模式的新執行模式：使用者自定義的函式將在 JVM 中作為執行緒執行，而不是在單獨的 Python 程式中執行。基準測試表明在 JSON 處理等常見場景中吞吐量可以增加 2 倍，處理延遲也從幾秒到微秒。需要指出的是，由於這仍然是 “執行緒” 模式的第一個版本，此前它僅支援 Python Table API 與 SQL 中的標量函式。我們計劃在下一版本中將其擴充套件到 Python API 中其他型別的自定義函式。

其它

Flink 1.15 進一步完善了對於聯結器測試框架^[29] 的支援，如果你想貢獻一個聯結器或改進一個聯結器，你絕對應該看一下這部分工作。

Flink 1.15 也新增了一些期待已久的功能，包括 CSV 格式^[30] 與小檔案壓縮^[31]。

同時，Sink API 被升級到版本 2^[32]。我們鼓勵每個聯結器的維護者升級到這個版本。

總結

Apache Flink 簡化了運維操作，在對齊流批處理功能取得進一步進展，改進了 SQL 元件使其變得更易於使用，並且現在可以更好地與其他系統進行整合。

同值得一提的是社群為 CDC 聯結器^[33] 建立了一個新家。同時，聯結器相關程式碼^[34] 將被移動到 Flink 外一個單獨的倉庫中 (以 Elasticsearch Sink 作業第一個例子^[35] ）。此外，現在社群新增了一個由社群維護的關於 K8s Operator^[36] 的公告部落格^[37]。

展望未來，社群將繼續專注於使 Apache Flink 成為真正的流批一體處理系統，並致力於將 Flink 更好地整合到雲原生生態系統中。

升級說明

雖然我們的目標是儘可能支援平穩升級，但是一些改動仍然需要使用者在升級到 1.15 的時候對它們的程式進行調整。請參考 Release Notes^[38] 來獲得在升級時需要進行的改動與可能的問題列表。其中最值得一提的是由於去除 Scala 依賴的努力，現在許多依賴項中不再需要新增 Scala 版本字尾。關於更多資訊可以參考^[39]。

原文連結：
https://flink.apache.org/news...

貢獻者列表

Apache Flink 社群感謝對此版本做出貢獻的每一位貢獻者：

Ada Wong, Ahmed Hamdy, Aitozi, Alexander Fedulov, Alexander Preuß, Alexander Trushev, Ali Bahadir Zeybek, Anton Kalashnikov, Arvid Heise, Bernard Joseph Jean Bruno, Bo Cui, Brian Zhou, Camile, ChangLi, Chengkai Yang, Chesnay Schepler, Daisy T, Danny Cranmer, David Anderson, David Moravek, David N Perkins, Dawid Wysakowicz, Denis-Cosmin Nutiu, Dian Fu, Dong Lin, Eelis Kostiainen, Etienne Chauchot, Fabian Paul, Francesco Guardiani, Gabor Somogyi, Galen Warren, Gao Yun, Gen Luo, GitHub, Gyula Fora, Hang Ruan, Hangxiang Yu, Honnix, Horace Lee, Ingo Bürk, JIN FENG, Jack, Jane Chan, Jark Wu, JianZhangYang, Jiangjie (Becket) Qin, JianzhangYang, Jiayi Liao, Jing, Jing Ge, Jing Zhang, Jingsong Lee, JingsongLi, Jinzhong Li, Joao Boto, Joey Lee, John Karp, Jon Gillham, Jun Qin, Junfan Zhang, Juntao Hu, Kexin, Kexin Hui, Kirill Listopad, Konstantin Knauf, LB-Yu, Leonard Xu, Lijie Wang, Liu Jiangang, Maciej Bryński, Marios Trivyzas, MartijnVisser, Mason Chen, Matthias Pohl, Michal Ciesielczyk, Mika, Mika Naylor, Mrart, Mulavar, Nick Burkard, Nico Kruber, Nicolas Raga, Nicolaus Weidner, Niklas Semmler, Nikolay, Nuno Afonso, Oleg Smirnov, Paul Lin, Paul Zhang, PengFei Li, Piotr Nowojski, Px, Qingsheng Ren, Robert Metzger, Roc Marshal, Roman, Roman Khachatryan, Ruanshubin, Rudi Kershaw, Rui Li, Ryan Scudellari, Ryan Skraba, Sebastian Mattheis, Sergey, Sergey Nuyanzin, Shen Zhu, Shengkai, Shuo Cheng, Sike Bai, SteNicholas, Steffen Hausmann, Stephan Ewen, Tartarus0zm, Thesharing, Thomas Weise, Till Rohrmann, Timo Walther, Tony Wei, Victor Xu, Wenhao Ji, X-czh, Xianxun Ye, Xin Yu, Xinbin Huang, Xintong Song, Xuannan, Yang Wang, Yangze Guo, Yao Zhang, Yi Tang, Yibo Wen, Yuan Mei, Yuanhao Tian, Yubin Li, Yuepeng Pan, Yufan Sheng, Yufei Zhang, Yuhao Bi, Yun Gao, Yun Tang, Yuval Itzchakov, Yuxin Tan, Zakelly, Zhu Zhu, Zichen Liu, Zongwen Li, atptour2017, baisike, bgeng777, camilesing, chenxyz707, chenzihao, chuixue, dengziming, dijkwxyz, fanrui, fengli, fenyi, fornaix, gaurav726, godfrey he, godfreyhe, gongzhongqiang, haochenhao, hapihu, hehuiyuan, hongshuboy, huangxingbo, huweihua, iyupeng, jiaoqingbo, jinfeng, jxjgsylsg, kevin.cyj, kylewang, lbb, liliwei, liming.1018, lincoln lee, liufangqi, liujiangang, liushouwei, liuyongvs, lixiaobao14, lmagic233, lovewin99, lujiefsi, luoyuxia, lz, mans2singh, martijnvisser, mayue.fight, nanmu42, oogetyboogety, paul8263, pusheng.li01, qianchutao, realdengziqi, ruanhang1993, sammieliu, shammon, shihong90, shitou, shouweikun, shouzuo1, shuo.cs, siavash119, simenliuxing, sjwiesman, slankka, slinkydeveloper, snailHumming, snuyanzin, sujun, sujun1, syhily, tsreaper, txdong-sz, unknown, vahmed-hamdy, wangfeifan, wangpengcheng, wangyang0918, wangzhiwu, wangzhuo, wgzhao, wsz94, xiangqiao123, xmarker, xuyang, xuyu, xuzifu666, yangjunhan, yangze.gyz, ysymi, yuxia Luo, zhang chaoming, zhangchaoming, zhangjiaogg, zhangjingcun, zhangjun02, zhangmang, zlzhang0122, zoucao, zp, zzccctv, 周平, 子揚, 李銳, 蔣龍, 龍三, 莊天翼

參考連結

[1] https://www.apache.org/founda...

[2] https://flink.apache.org/2022...

[3] https://nightlies.apache.org/...

[4] https://nightlies.apache.org/...

[5] https://nightlies.apache.org/...

[6] https://cwiki.apache.org/conf...

[7] https://nightlies.apache.org/...

[8] https://nightlies.apache.org/...

[9] https://nightlies.apache.org/...

[10] https://cwiki.apache.org/conf...

[11] https://nightlies.apache.org/...