翻譯 | 高赟

• 1.15 版本的一大看點(diǎn)是改進(jìn)了運(yùn)維 Apache Flink 的體驗(yàn)：包括明確 Checkpoint 和 Savepoint 在不同作業(yè)之間的所屬權(quán)，簡(jiǎn)化 Checkpoint 和 Savepoint 生命周期管理；更加無縫支持完整的自動(dòng)伸縮；通過 Watermark 對(duì)齊來消除多個(gè)數(shù)據(jù)源速率不同帶來的問題等
  
  
• 1.15 版本中，F(xiàn)link 進(jìn)一步完善流批一體的體驗(yàn)：繼續(xù)完善部分作業(yè)完成后的 Checkpoint 操作；支持批模式下的 Window table-valued 函數(shù)，并且使其在流批混合的場(chǎng)景下更加易用。
  
  
• Flink SQL 的進(jìn)階：包括能夠在不丟失狀態(tài)的情況下升級(jí) SQL 作業(yè)；添加了對(duì) JSON 相關(guān)函數(shù)的支持來簡(jiǎn)化數(shù)據(jù)的輸入與輸出操作。
  
  
• Flink 作為整個(gè)數(shù)據(jù)處理生態(tài)中的一環(huán)，1.15 版本進(jìn)一步提升了與云服務(wù)的交互操作性，并且添加了更多的 Sink 連接器與數(shù)據(jù)格式。最后，我們在運(yùn)行時(shí)中去除了對(duì) Scala 的依賴^[2]。

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

Savepoint 的主要作用是支持作業(yè)修改、備份與升級(jí)等場(chǎng)景，它是由用戶來完全控制的。而另一方面，Checkpoint 由 Flink 完全控制，用于通過支持快速恢復(fù)與重啟來實(shí)現(xiàn)容錯(cuò)的能力。這兩個(gè)概念十分相似，并且它們共享了很大一部分實(shí)現(xiàn)。

然而，由于遵循不同的功能要求，這兩個(gè)概念逐漸變得不一致，使用戶看起來沒有完整的頂層設(shè)計(jì)。根據(jù)用戶反饋，這兩個(gè)概念應(yīng)該被更好地對(duì)齊和協(xié)調(diào)，最重要的是，這兩個(gè)概念應(yīng)該被更清晰的定義。

在某些停止或重新啟動(dòng)作業(yè)的場(chǎng)景下，雖然邏輯上應(yīng)該使用 Savepoint，但用戶還是會(huì)選擇使用持久化的 Checkpoint，因?yàn)?Savepoint 無法享受 Checkpoint 可以使用的一些優(yōu)化而導(dǎo)致執(zhí)行較為緩慢。但是在這種情況下，作業(yè)從持久化的 Checkpoint 重啟時(shí) (這種情況下 Checkpoint 實(shí)際上被當(dāng)作 Savepoint 來使用)，對(duì)用戶來說何時(shí)可以清理 Checkpoint 中的數(shù)據(jù)并不十分清楚。

因此，在 FLIP-193: 狀態(tài)所屬權(quán)^[6]?中，F(xiàn)link 希望可以將 Savepoint 和 Checkpoint 抽像成唯一區(qū)別是所屬權(quán)不同的兩個(gè)概念。在 1.15 中，通過支持原生的增量 Savepoint^[7]，F(xiàn)link 解決了 Savepoint 的一些不足：在過去的版本中，Savepoint 總是使用標(biāo)準(zhǔn)格式以及非增量的方式，這也是導(dǎo)致它性能較差的原因。在 1.15 中，如果用戶選擇使用原生格式并且同時(shí)使用了 RocksDB?狀態(tài)存儲(chǔ)，那么 Savepoint 將采用增量的方式來執(zhí)行。我們也更新了相關(guān)文檔來更好的概覽與理解 Checkpoint 與 Savepoint 的差異。此外，關(guān)于從 Savepoint / 持久化的 Checkpoint 恢復(fù)^[8]?的語義，我們顯式的引入了 CLAIM 與 NO_CLAIM 兩種模式。對(duì)于 CLAIM 模式 Flink 將接管快照中數(shù)據(jù)的所屬權(quán)，而對(duì)于 NO_CLAIM 模式，F(xiàn)link 將創(chuàng)建它自己的副本，而由用戶來負(fù)責(zé)管理與刪除原始的數(shù)據(jù)。注意現(xiàn)在默認(rèn)將采用 NO_CLAIM 模式，之前版本中從 Savepoint / 持久化的 Checkpoint 恢復(fù)的行為可以通過指定 LEGACY 模式來恢復(fù)。

基于 Reactive 模式與自適應(yīng)調(diào)度器的彈性伸縮

由于越來越多的云服務(wù)基于 Apache Flink 構(gòu)建 ，F(xiàn)link 項(xiàng)目變得越來越云原生，這使得彈性伸縮也越來越重要。

此版本改進(jìn)了?Reactive 模式^[9]?的指標(biāo)。Reactive 模式是一個(gè)作業(yè)級(jí)別的模式，在這種模式下， JobManager 將嘗試使用所有可用的 TaskManager 上的資源。我們?cè)?1.15 中保證了作業(yè)級(jí)別的指標(biāo)在 Reactive 模式下也可以正常的工作。

我們還為自適應(yīng)調(diào)度器^[10]?添加了異常歷史記錄。自適應(yīng)調(diào)度器是一個(gè)新的調(diào)度器，它首先聲明了所需的資源并且根據(jù)根據(jù)資源情況在執(zhí)行前決定資源的并行度。

此外，F(xiàn)link 提高了縮減作業(yè)規(guī)模的速度：TaskManager 現(xiàn)在有一個(gè)專用代碼路徑來關(guān)閉自己，它會(huì)主動(dòng)從集群中注銷自己而不是依賴于心跳，從而給 JobManager 一個(gè)明確的縮減作業(yè)規(guī)模的信號(hào)。

自適應(yīng)批調(diào)度器

在 1.15 中，我們?yōu)?Apache Flink 引入了一個(gè)新的自適應(yīng)批處理調(diào)度器^[11]。這一調(diào)度器可以自動(dòng)根據(jù)每個(gè)節(jié)點(diǎn)需要處理的數(shù)據(jù)量的大小自動(dòng)決定批處理作業(yè)中各節(jié)點(diǎn)的并行度。

此調(diào)度器的主要優(yōu)點(diǎn)包括：

1. 易用性：批處理作業(yè)的用戶不再需要手動(dòng)調(diào)優(yōu)并行度。
   
   
2. 自適應(yīng)：自動(dòng)調(diào)整并行度可以更好地適應(yīng)節(jié)點(diǎn)消費(fèi)數(shù)據(jù)集隨時(shí)間發(fā)生變化的情況。
   
   
3. 細(xì)粒度：每個(gè)作業(yè)節(jié)點(diǎn)的并行度可以單獨(dú)調(diào)整。這允許 SQL 批處理作業(yè)的節(jié)點(diǎn)自動(dòng)為每個(gè)節(jié)點(diǎn)選擇單獨(dú)選擇最適合的并行度。

跨源節(jié)點(diǎn)的 Watermark 對(duì)齊

SQL 版本升級(jí)

SQL 查詢的執(zhí)行計(jì)劃及其生成的拓?fù)涫峭ㄟ^優(yōu)化規(guī)則和一個(gè)基于成本的模型來得到的，這意味著即使最小的更改也可能會(huì)產(chǎn)生一個(gè)完全不同的拓?fù)洹?/span>這種動(dòng)態(tài)性使得在不同 Flink 版本間保證快照兼容性非常具有挑戰(zhàn)性。在 1.15 中，社區(qū)首先通過保持拓?fù)洳蛔兊姆绞绞瓜嗤牟樵冊(cè)谏?jí) Flink 版本后仍然可以啟動(dòng)和執(zhí)行。

在 Flink 1.15 中，我們引入了 MVP 特性：基于 Changelog 的狀態(tài)存儲(chǔ)^[14]。這一新的狀態(tài)存儲(chǔ)旨在支持更短、更可以預(yù)測(cè)的 Checkpoint 間隔。它具有以下優(yōu)勢(shì)：

1. 更短的端到端延遲：端到端延遲主要取決于 Checkpoint 機(jī)制，特別是使用了兩階段提交的支持端到端一致性的 Sink 節(jié)點(diǎn)的情況，這種情況下縮短 Checkpoint 周期意味著可以更快的提交數(shù)據(jù)。
   
   
2. 更可預(yù)測(cè)的 Checkpoint 間隔：目前 Checkpoint 的完成時(shí)間很大程度上取決于需要保存在 Checkpoint 中的數(shù)據(jù)的大小。通過使這一數(shù)據(jù)總是可以很小，Checkpoint 的完成時(shí)間變得更加可以預(yù)測(cè)。
   
   
3. 恢復(fù)工作更少：Checkpoint 越頻繁，每次重啟后重新處理的數(shù)據(jù)也會(huì)越少。

在以前的 Flink 版本中，F(xiàn)link 在作業(yè)結(jié)束時(shí)只嘗試清理一次與作業(yè)相關(guān)的殘留數(shù)據(jù)，這可能會(huì)導(dǎo)致在發(fā)生錯(cuò)誤時(shí)無法完成清理。在這個(gè)版本中，F(xiàn)link 將嘗試重復(fù)運(yùn)行清理以避免殘留數(shù)據(jù)。默認(rèn)情況下，F(xiàn)link 將不斷重試機(jī)制，直到運(yùn)行成功為止。用戶可以通過配置相關(guān)參數(shù)^[15]?來改變這種行為。禁用重試策略可以恢復(fù) Flink 之前版本的行為。

Flink 現(xiàn)在提供遵循 Open API^[17]?標(biāo)準(zhǔn)的 REST API 規(guī)范。這允許 REST API 與遵循 Open API 標(biāo)準(zhǔn)的工具直接交互。您可以在 [18] 找到相應(yīng)規(guī)范。

在 Application 模式^[19]?下運(yùn)行 Flink 時(shí)，如果用戶進(jìn)行了相關(guān)配置^[20]，它現(xiàn)在可以保證作業(yè)在結(jié)束前能夠正常完成 stop-with-savepoint 操作。

在最新版本中，我們對(duì)流批一體的支持進(jìn)行了進(jìn)一步的完善。

在 Flink 1.14 中，添加了對(duì)作業(yè)結(jié)束前等待一次 Checkpoint 操作的支持，從而保證使用流模式處理有限數(shù)據(jù)可以保證所有被據(jù)被提交，但是在 1.14 中，該功能必須被手動(dòng)啟用。自上次發(fā)布以來，我們聽取了用戶反饋并決定默認(rèn)啟用它。關(guān)于這一功能的更多信息以及如何禁用此功能，請(qǐng)參閱 [21]。需要指出的是，這一默認(rèn)配置的變化可能延長(zhǎng)使用流模式處理有界數(shù)據(jù)時(shí)的執(zhí)行時(shí)間，因?yàn)樽鳂I(yè)必須在結(jié)束前等待下一個(gè) Checkpoint 完成。

Window table-valued 函數(shù)^[22]?之前僅可用于流模式下。在 1.15 中，它們現(xiàn)在也可以在批模式下使用。此外，通過實(shí)現(xiàn)一個(gè)專門的算子，我們現(xiàn)在不再要求這些 Window 函數(shù)必須定義一個(gè)聚合器，從而進(jìn)一步增強(qiáng)了 Window table-valued 函數(shù)。

社區(qū)指標(biāo)表明 Flink SQL 被廣泛使用并且變得越來越流行。在 1.15 中社區(qū)對(duì) Flink SQL 也做了許多改進(jìn)，下文將更加詳細(xì)地討論其中兩個(gè)改進(jìn)。

Flink 的一個(gè)重要目標(biāo)是使用戶能夠構(gòu)建流數(shù)據(jù)管道來解決他們的用例。一般來說，Apache Flink 不會(huì)單獨(dú)使用，而是作為更大的數(shù)據(jù)分析平臺(tái)中的重要一環(huán)。因此，簡(jiǎn)化 Flink 在云環(huán)境下的使用與維護(hù)、支持無縫連接到其他系統(tǒng)并繼續(xù)支持 Java 和 Python 等編程語言對(duì)完善 Flink 生態(tài)十分重要。

Flink 1.15 進(jìn)一步完善了對(duì)于連接器測(cè)試框架^[29]?的支持，如果你想貢獻(xiàn)一個(gè)連接器或改進(jìn)一個(gè)連接器，你絕對(duì)應(yīng)該看一下這部分工作。

原文鏈接：

https://flink.apache.org/news/2022/05/05/1.15-announcement.html

貢獻(xiàn)者列表

???點(diǎn)擊查看更多技術(shù)內(nèi)容～