GitHub 位址 https://github.com/apache/flink
歡迎大家給 Flink 點贊送 star~
作者 | Stephan Ewen & Johannes Moser
翻譯 | 宋辛童
在 Apache 軟體基金會近期釋出的年度報告中，Apache Flink 再次跻身最活躍項目前 5 名！該項目最新釋出的 1.14.0 版本同樣展現了其非凡的活躍力，囊括了來自超過 200 名貢獻者的 1000 餘項貢獻。整個社群為項目的推進付出了持之以恒的努力，我們引以為傲。
新版本在 SQL API、更多連接配接器支援、Checkpoint 機制、PyFlink 等多個方面帶來了大量的新特性與改進。其中一個主要的改進是針對流批一體的使用體驗。我們相信，在實踐中，對無界的資料流的處理與對有界的批資料的處理是密不可分的，因為很多場景都需要在處理實時資料流的同時處理來自各種資料源的曆史資料。例如開發新應用時的資料探索、新應用的狀态初始化、用于流式應用的訓練模型、更新或修複後的資料重處理等。
在 Flink 1.14 中，我們終于可以在同一個應用當中混合使用有界流和無界流：Flink 現在支援對部分運作、部分結束的應用（部分算子已處理到有界輸入資料流的末端）做 Checkpoint。此外，Flink 在處理到有界資料流末端時會觸發最終 Checkpoint，以確定所有計算結果順利送出到 Sink。
批執行模式現在支援在同一應用中混合使用 DataStream API 和 SQL/Table API（此前僅支援單獨使用 DataStream API 或 SQL/Table API）。
我們更新了統一的 Source 和 Sink API，并已開始圍繞統一的 API 整合連接配接器生态。我們新增了混合 Source 可在多個存儲系統間過渡。你現在可以實作諸如先從 Amazon S3 中讀取舊的資料再無縫切換到 Apache Kafka 這樣的處理。
此外，這一版本朝着我們将 Flink 打造得更加自調易用、無需大量流處理特定知識的目标又邁進了一步。作為向此目标邁出的第一步，我們在上個版本中引入了
被動彈性伸縮模式。現在，我們又新增了對網絡記憶體的自動調整（即緩沖區去膨脹）。這一特性能在保持高吞吐、不增加 Checkpoint 大小的前提下，加速高負載時的Checkpoint。該機制通過不斷調整網絡緩沖區的大小，能夠以最少的緩沖資料達到最佳的吞吐效率。更多詳情請參考緩沖區去膨脹章節。
新版本中有許多來自各個元件的新特性與改進，我們将在下文介紹。與此同時，我們也告别了一些在最近的版本中逐漸被取代、廢棄的元件和功能。最具代表性的是，新版本中移除了舊版 SQL 查詢引擎和對 Apache Mesos 的內建。
我們希望你喜歡這個新版本，同時迫切地想了解你的使用體驗：這一版本解決了哪些此前尚未解決的問題，滿足了哪些新場景？
一、流批一體的處理體驗
Flink 的一個獨特之處是其對流和批處理的統一：使用同一套 API、同一個可支援多種執行範式的運作時。
正如在前文中提到的，我們相信流處理和批處理是密不可分的。下面這段話來自一份
關于 Facebook 流式資料處理的報告，很好地呼應了這一觀點。
流處理與批處理并不是非此即彼的選擇。最初，Facebook 所有資料倉庫的處理都是批處理。我們在大約 5 年前開始研發 Puma 和 Swift。正如我們在 […] 章節所展示的，混合使用流處理和批處理能夠為較長的處理流程節約數個小時。
利用同一引擎處理實時和曆史資料還可以確定語義的一緻性，使結果具有更好的可比性。這裡有一篇
關于阿裡巴巴使用 Apache Flink 生成統一的、一緻的業務報告的文章。
此前的版本已經可以實作流批一體的資料處理。新版本在這方面增加了針對更多使用場景的新特性，以及一系列使用體驗的改進。
有界流 Checkpoint 機制
Flink 的 Checkpoint 機制原本隻支援在應用 DAG 中的所有任務都處于運作狀态時建立 Checkpoint。這意味着讓應用同時讀取有界和無界資料源在實質上是不可能的。此外，以流式（而非批式）處理有界輸入資料的應用，在資料将要處理完、部分任務結束時将不再做 Checkpoint。這使得最後一部分輸出資料無法被送出到要求精确一次語義的 Sink 中，造成業務延遲。
通過
FLIP-147，Flink 支援在部分任務結束後建立 Checkpoint，以及在有界流處理結束後觸發最終 Checkpoint 以確定在作業結束時将所有輸出結果送出到 Sink（與 stop-with-savepoint 類似）。
該特性可通過在配置中添加 execution.checkpointing.checkpoints-after-tasks-finish.enabled: true 啟用。出于讓使用者自主選擇并試用重大新特性的傳統，這一特性在 Flink 1.14 中沒有預設啟用。我們希望在下個版本中将其作為預設模式。
背景：處理有界資料時，盡管人們通常傾向于使用批處理模式，仍有一些情況需要用到流處理模式。例如，Sink 可能隻支援流模式（即 Kafka Sink），或者應用希望盡量發揮流處理固有的近時間排序特性（例如
Kappa+ 架構）。
DataStream 和 Table/SQL 混合應用的批執行模式
SQL 和 Table API 正在成為新項目的預設起點，其天然的聲明式特點和豐富的内置類型與操作使應用開發變得簡單快速。然而，開發人員遇到一些特定的、事件驅動的業務邏輯，SQL 的表達能力無法滿足（或不适合強行用 SQL 來表達）的情況也并不罕見。
此時，自然的做法是插入一段有狀态的 DataStream API 描述的邏輯，再切換回 SQL。
在 Flink 1.14 中，有界的批執行模式的 SQL/Table 應用可将其中間資料表轉換成資料流，經過由 DataStream API 定義的算子處理，再轉換回資料表。其内部原理是，Flink 建構了一個由優化的聲明式 SQL執行和 DataStream 批執行混合而成的資料流 DAG。詳見
相關文檔混合 Source
全新的
能夠依次地從多個資料源讀取資料，在不同資料源之間無縫切換，産出一條由來自多個資料源的資料合并而成的資料流。
混合 Source 針對的是從分層存儲中讀取資料的場景，相當于從一條跨越所有層級的資料流讀取資料。例如，将新資料灌入 Kafka，并最終遷移至 S3（出于成本與效率的考量這通常是壓縮的列存格式）。混合 Source 可以像讀取一條連續的邏輯資料流一樣，先從 S3 讀取曆史資料，然後轉換到 Kafka 讀取最新的資料。
我們相信這是向着實作日志與 Kappa 架構完整前景的令人興奮的一步。即使事件日志的陳舊部分在實體上被遷移到了不同的存儲（出于成本、壓縮效率、讀取速度等原因），你仍可以将其視作連續的日志處理。
Flink 1.14 加入了混合 Source 的核心功能。在後續的版本中，我們希望加入更多針對典型切換政策的工具與模式。
整合 Source 和 Sink
随着新的流批統一的 Source 和 Sink API 變得穩定，我們開始了圍繞這些 API 整合所有連接配接器的巨大努力。與此同時，我們也會讓 DataStream 和 SQL / Table API 上的連接配接器更好地對齊，首先是DataStream API 上的 Kafka 和檔案 Source、Sink。
伴随着這一努力（預計仍将持續 1-2 個版本），Flink 使用者在連接配接外部系統時将獲得更加流暢、一緻的體驗。
二、運維改進
緩沖區去膨脹
緩沖區去膨脹是 Flink 中的一項新技術，可以最小化 Checkpoint 的延遲和開銷。它通過自動調整網絡記憶體的用量，在確定高吞吐的同時最小化緩沖區中的資料量。
Apache Flink 在其網絡棧中緩沖了一定量的資料，以便有效利用快速網絡的高帶寬。Flink 應用以高吞吐運作時，會使用部分（或全部）網絡緩沖記憶體。對齊的 Checkpoint 随着資料在毫秒級的時間内流過網絡緩沖區。
當 Flink 應用出現（暫時的）反壓時（例如外部系統反壓或遇到資料傾斜），往往會導緻網絡緩沖區中存放了相對應用目前吞吐（因反壓而降低）所需的帶寬過多的資料。更加不利的是，緩沖的資料越多意味着 Checkpoint 機制需要做越多的工作。對齊的 Checkpoint 需要等待更多的資料得到處理，非對齊的 Checkpoint 則需要持久化更多排隊中的資料。
這就輪到緩沖區去膨脹登場了。它将網絡棧從持有最多 X 位元組的資料改為持有需要接收端 X 毫秒計算時間處理的資料。預設值是 1000 毫秒，意味着網絡棧會緩沖下遊任務 1000 毫秒所能處理的資料量。通過持續的測量和調整，系統能夠在不斷變化的情況下保持這一特性。是以，Flink 對齊式 Checkpoint 具備了穩定的、可預測的對齊時間，反壓時存放在非對齊式 Checkpoint中的資料量也極大程度減少了。
緩沖區去膨脹可以作為非對齊式 Checkpoint 的補充，甚至是替代選擇。關于如何啟用該特性，請參考
文檔細粒度資源管理
細粒度資源管理是一項新的進階功能，用于提高大型共享叢集的資源使用率。
Flink 叢集執行多種多樣的資料處理工作負載。不同的資料處理步驟通常需要不同的資源，如計算資源、記憶體等。例如，大多數映射函數都比較輕量，而較大的、保留時間較長的視窗函數往往受益于大量記憶體。預設情況下，Flink 以粗粒度的 Slot 管理資源，一個 Slot 代表 TaskManager 的一個資源切片。一個 Slot 可以存放流式處理流程中每個算子的一個并發子任務執行個體，即一個 Slot 可持有一整條處理流程的并發子任務執行個體。通過 Slot Sharing Group，使用者可以影響子任務在 Slot 上的分布。
有了細粒度資源管理，TaskManager 上的 Slot 可以動态改變大小。轉換和算子指定所需的資源配置（CPU、記憶體、磁盤等），由 Flink 的 ResourceManager 和 TaskManager 負責從 TaskManager 的總資源中劃分出指定大小的資源切片。你可以将這看做是 Flink 中的一層最小化、輕量化的資源編排。下圖展示了細粒度資源管理與目前預設的共享固定大小 Slot 資源管理方式的差別。
你可能會問，Flink 已經內建了 Kubernetes、Yarn 等成熟的資源編排架構，為什麼還要增加這樣一個新特性？有幾種情況，在 Flink 内部增加一層資源管理可以顯著提高資源使用率：
- 當 Slot 比較小時，為每個 Slot 專門申請 TaskManager 的代價是非常高的（JVM 開銷、Flink 架構開銷等）。Slot Sharing 通過讓不同類型的算子共享 Slot，即在輕量的算子（需要較小的 Slot）和重量的算子（需要較大的 Slot）間共享資源，在一定程度上解決了這個問題。然而，這僅在所有算子的并發度相同時有較好的效果，并非總是最優的。此外，有些算子更适合單獨運作（例如機器學習中負責訓練的算子需要專用的 GPU資源）。
- Kubernetes 和 Yarn 往往需要花費一段時間來滿足資源請求，特别是在叢集負載較高時。對于一些批處理作業，等待資源的時間會降低作業的執行效率。
那麼什麼時候應該啟用這一特性呢？預設的資源管理機制适用于大多數流處理和批處理作業。如果你的作業是長時間運作的流作業或快速的批作業，其不同處理階段需要的資源差異明顯，且你已經為不同算子設定了不同的并發度，那麼你可以嘗試用細粒度資源管理提高資源效率。
阿裡巴巴内部基于 Flink 的平台已經應用這種機制有一段時間了，在實踐中叢集資源使用率有着顯著的提高。
關于如何使用細粒度資源管理的更多細節，請參考
三、連接配接器
連接配接器名額
此版本對連接配接器的名額進行了标準化（詳見
FLIP-33）。在接下來的幾個版本中，社群将在圍繞新的統一 API 逐漸翻新所有連接配接器的同時，同步實作标準化名額對所有連接配接器的覆寫。在 Flink 1.14 中，我們覆寫了 Kafka 連接配接器和（部分的）檔案系統連接配接器。
連接配接器在 Flink 作業中是資料的出入口。如果作業未按預期運作，連接配接器的名額是首先要檢查的部分之一。我們相信對于 Flink 應用的生産運維而言，這将是一個很好的改進。
Pulsar 連接配接器
此版本新增了
Apache Pulsar連接配接器。Pulsar 連接配接器支援以流和批兩種執行模式從 Pulsar 主題讀取資料。在 Pulsar 事務功能（自 Pulsar 2.8.0 引入）的支援下，Pulsar 連接配接器可以支援精确一次的資料傳遞語義，即使在生産者嘗試重傳消息時也能確定消息僅被傳遞給消費者一次。
為了滿足不同場景下對消息順序和規模的需求，Pulsar Source 連接配接器支援四種訂閱類型：
獨占、
共享 災備 鍵共享該連接配接器目前支援 DataStream API。SQL / Table API 預計将在後續版本中提供。關于如何使用 Pulsar 連接配接器，請參考
四、PyFlink
基于連結的性能提升
與 Java API 将任務中的轉換函數、算子連結起來以避免序列化開銷類似，PyFlink 現在也會将 Python 函數連結起來。對于 PyFlink，連結不僅能消除序列化開銷，還能減少 Java 和 Python 程序間的 RPC 通信。這大幅提高了 PyFlink 的整體性能。
此前版本中，SQL / Table API 已經可以将 Python 函數連結起來。在 Flink 1.14中，這一優化進一步覆寫了 Python DataStream API 中的 cPython 函數。
環回調試模式
通常情況下，Python 函數是由獨立于 Flink JVM 之外的 Python 程序執行的。這一架構導緻對 Python 代碼的調試比較困難。
PyFlink 1.14 引入了環回模式，在本地部署模式下自動啟用。該模式下，使用者自定義 Python 函數将由運作用戶端的 Python 程序執行，該程序是啟動 PyFlink 應用的入口，負責執行用于建構資料流 DAG 的所有 DataStream API 和 Table API 代碼。使用者現在本地運作 PyFlink 作業時，可以通過在 IDE 中設定斷點的方式友善地調試 Python 函數。
其他改進
PyFlink 還有很多其他改進，例如支援用 Yarn Application 模式執行作業、支援使用 tgz 壓縮格式的 Python 歸檔檔案等。更多詳情請參考
Python API 文檔五、告别舊版 SQL 引擎和 Mesos 支援
維護一個開源項目也意味着有時要告别一些受人喜愛的功能特性。
在兩年前我們将 Blink SQL 引擎加入到 Flink 時，就已明确它終将取代原本的 SQL 引擎。Blink 速度更快，功能也更加完整。最近一年，Blink 已成為預設的 SQL 引擎。在 Flink 1.14，我們終于将舊版 SQL 引擎的所有代碼移除了。這讓我們得以移除許多過時的接口，避免使用者在實作自定義連接配接器和函數時産生不知該用哪個接口的困惑。這還有助于我們今後更加快速的疊代 SQL 引擎。
此版本還移除了對 Apache Mesos 的內建，因為我們發現幾乎沒有使用者仍對這一特性感興趣，同時也缺少足夠的貢獻者願意幫助維護這部分系統。Flink 1.14 将不再能夠在不依賴于像 Marathon 這樣的輔助項目的情況下運作在 Mesos 上，同時 Flink 的 ResourceManager 也不再支援根據工作負載的資源需求從 Mesos 動态申請、釋放資源。
六、更新說明
我們已努力讓版本更新變得盡可能順利，但仍有一些改動需要使用者在更新 Flink 版本時對應用的一些部分做出調整。有關更新過程中可能需要做出的調整及确認，請參閱
發版公告原文連接配接： https://flink.apache.org/news/2021/09/29/release-1.14.0.html
貢獻者清單
Apache Flink 社群感謝對此版本做出貢獻的每一位貢獻者：
adavis9592, Ada Wong, aidenma, Aitozi, Ankush Khanna, anton, Anton Kalashnikov, Arvid Heise, Ashwin Kolhatkar, Authuir, bgeng777, Brian Zhou, camile.sing, caoyingjie, Cemre Mengu, chennuo, Chesnay Schepler, chuixue, CodeCooker17, comsir, Daisy T, Danny Cranmer, David Anderson, David Moravek, Dawid Wysakowicz, dbgp2021, Dian Fu, Dong Lin, Edmondsky, Elphas Toringepi, Emre Kartoglu, ericliuk, Eron Wright, est08zw, Etienne Chauchot, Fabian Paul, fangliang, fangyue1, fengli, Francesco Guardiani, FuyaoLi2017, fuyli, Gabor Somogyi, gaoyajun02, Gen Luo, gentlewangyu, GitHub, godfrey he, godfreyhe, gongzhongqiang, Guokuai Huang, GuoWei Ma, Gyula Fora, hackergin, hameizi, Hang Ruan, Han Wei, hapihu, hehuiyuan, hstdream, Huachao Mao, HuangXiao, huangxingbo, huxixiang, Ingo Bürk, Jacklee, Jan Brusch, Jane, Jane Chan, Jark Wu, JasonLee, Jiajie Zhong, Jiangjie (Becket) Qin, Jianzhang Chen, Jiayi Liao, Jing, Jingsong Lee, JingsongLi, Jing Zhang, jinxing64, junfan.zhang, Jun Qin, Jun Zhang, kanata163, Kevin Bohinski, kevin.cyj, Kevin Fan, Kurt Young, kylewang, Lars Bachmann, lbb, LB Yu, LB-Yu, LeeJiangchuan, Leeviiii, leiyanfei, Leonard Xu, LightGHLi, Lijie Wang, liliwei, lincoln lee, Linyu, liuyanpunk, lixiaobao14, luoyuxia, Lyn Zhang, lys0716, MaChengLong, mans2singh, Marios Trivyzas, martijnvisser, Matthias Pohl, Mayi, mayue.fight, Michael Li, Michal Ciesielczyk, Mika, Mika Naylor, MikuSugar, movesan, Mulan, Nico Kruber, Nicolas Raga, Nicolaus Weidner, paul8263, Paul Lin, pierre xiong, Piotr Nowojski, Qingsheng Ren, Rainie Li, Robert Metzger, Roc Marshal, Roman, Roman Khachatryan, Rui Li, sammieliu, sasukerui, Senbin Lin, Senhong Liu, Serhat Soydan, Seth Wiesman, sharkdtu, Shengkai, Shen Zhu, shizhengchao, Shuo Cheng, shuo.cs, simenliuxing, sjwiesman, Srinivasulu Punuru, Stefan Gloutnikov, SteNicholas, Stephan Ewen, sujun, sv3ndk, Svend Vanderveken, syhily, Tartarus0zm, Terry Wang, Thesharing, Thomas Weise, tiegen, Till Rohrmann, Timo Walther, tison, Tony Wei, trushev, tsreaper, TsReaper, Tzu-Li (Gordon) Tai, wangfeifan, wangwei1025, wangxianghu, wangyang0918, weizheng92, Wenhao Ji, Wenlong Lyu, wenqiao, WilliamSong11, wuren, wysstartgo, Xintong Song, yanchenyun, yangminghua, yangqu, Yang Wang, Yangyang ZHANG, Yangze Guo, Yao Zhang, yfhanfei, yiksanchan, Yik San Chan, Yi Tang, yljee, Youngwoo Kim, Yuan Mei, Yubin Li, Yufan Sheng, yulei0824, Yun Gao, Yun Tang, yuxia Luo, Zakelly, zhang chaoming, zhangjunfan, zhangmang, zhangzhengqi3, zhao_wei_nan, zhaown, zhaoxing, ZhiJie Yang, Zhilong Hong, Zhiwen Sun, Zhu Zhu, zlzhang0122, zoran, Zor X. LIU, zoucao, Zsombor Chikan, 子揚, 莫辭
更多 Flink 相關技術問題，可掃碼加入社群釘釘交流群
第一時間擷取最新技術文章和社群動态，請關注公衆号～
活動推薦
阿裡雲基于 Apache Flink 建構的企業級産品-實時計算Flink版現開啟活動：
99 元試用
實時計算Flink版（包年包月、10CU）即有機會獲得 Flink 獨家定制T恤；另包 3 個月及以上還有 85 折優惠！
了解活動詳情：
https://www.aliyun.com/product/bigdata/sc