作者 |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 打造得更加自調易用、無需大量流處理特定知識的目標又邁進了一步。作為向此目標邁出的第一步，我們在上個版本中引入了被動彈性伸縮模式 [1]。現在，我們又新增了對網絡內存的自動調整（即緩衝區去膨脹）。這一特性能在保持高吞吐、不增加 Checkpoint 大小的前提下，加速高負載時的Checkpoint。該機制通過不斷調整網絡緩衝區的大小，能夠以最少的緩衝數據達到最佳的吞吐效率。更多詳情請參考緩衝區去膨脹章節。
新版本中有許多來自各個組件的新特性與改進，我們將在下文介紹。與此同時，我們也告別了一些在最近的版本中逐漸被取代、廢棄的組件和功能。最具代表性的是，新版本中移除了舊版 SQL 查詢引擎和對 Apache Mesos 的集成。
我們希望你喜歡這個新版本，同時迫切地想了解你的使用體驗：這一版本解決了哪些此前尚未解決的問題，滿足了哪些新場景？
Flink 的一個獨特之處是其對流和批處理的統一：使用同一套 API、同一個可支持多種執行範式的運行時。
正如在前文中提到的，我們相信流處理和批處理是密不可分的。下面這段話來自一份關於 Facebook 流式數據處理的報告 [2]，很好地呼應了這一觀點。
流處理與批處理並不是非此即彼的選擇。最初，Facebook 所有數據倉庫的處理都是批處理。我們在大約 5 年前開始研發 Puma 和 Swift。正如我們在 […] 章節所展示的，混合使用流處理和批處理能夠為較長的處理流程節約數個小時。
利用同一引擎處理實時和歷史數據還可以確保語義的一致性，使結果具有更好的可比性。這裡有一篇關於阿里巴巴使用 Apache Flink 生成統一的、一致的業務報告的文章 [3]。此前的版本已經可以實現流批一體的數據處理。新版本在這方面增加了針對更多使用場景的新特性，以及一系列使用體驗的改進。有界流 Checkpoint 機制
Flink 的 Checkpoint 機制原本只支持在應用 DAG 中的所有任務都處於運行狀態時創建 Checkpoint。這意味着讓應用同時讀取有界和無界數據源在實質上是不可能的。此外，以流式（而非批式）處理有界輸入數據的應用，在數據將要處理完、部分任務結束時將不再做 Checkpoint。這使得最後一部分輸出數據無法被提交到要求精確一次語義的 Sink 中，造成業務延遲。
通過 FLIP-147 [4]，Flink 支持在部分任務結束後創建 Checkpoint，以及在有界流處理結束後觸發最終 Checkpoint 以確保在作業結束時將所有輸出結果提交到 Sink（與 stop-with-savepoint 類似）。
該特性可通過在配置中添加 execution.checkpointing.checkpoints-after-tasks-finish.enabled: true 啟用。出於讓用戶自主選擇並試用重大新特性的傳統，這一特性在 Flink 1.14 中沒有默認啟用。我們希望在下個版本中將其作為默認模式。
背景：處理有界數據時，儘管人們通常傾向於使用批處理模式，仍有一些情況需要用到流處理模式。例如，Sink 可能只支持流模式（即 Kafka Sink），或者應用希望儘量發揮流處理固有的近時間排序特性（例如 Kappa+ 架構 [5]）。
DataStream 和 Table/SQL 混合應用的批執行模式
SQL 和 Table API 正在成為新項目的默認起點，其天然的聲明式特點和豐富的內置類型與操作使應用開發變得簡單快速。然而，開發人員遇到一些特定的、事件驅動的業務邏輯，SQL 的表達能力無法滿足（或不適合強行用 SQL 來表達）的情況也並不罕見。
此時，自然的做法是插入一段有狀態的 DataStream API 描述的邏輯，再切換回 SQL。
在 Flink 1.14 中，有界的批執行模式的 SQL/Table 應用可將其中間數據錶轉換成數據流，經過由 DataStream API 定義的算子處理，再轉換回數據表。其內部原理是，Flink 構建了一個由優化的聲明式 SQL執行和 DataStream 批執行混合而成的數據流 DAG。詳見相關文檔 [6]。
混合 Source
全新的混合 Source [7] 能夠依次地從多個數據源讀取數據，在不同數據源之間無縫切換，產出一條由來自多個數據源的數據合併而成的數據流。
混合 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 的補充，甚至是替代選擇。關於如何啟用該特性，請參考文檔 [8]。
細粒度資源管理
細粒度資源管理是一項新的高級功能，用於提高大型共享集群的資源利用率。
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 的平台已經應用這種機制有一段時間了，在實踐中集群資源利用率有着顯著的提高。關於如何使用細粒度資源管理的更多細節，請參考文檔 [9]。連接器指標
此版本對連接器的指標進行了標準化（詳見 FLIP-33 [10]）。在接下來的幾個版本中，社區將在圍繞新的統一 API 逐步翻新所有連接器的同時，同步實現標準化指標對所有連接器的覆蓋。在 Flink 1.14 中，我們覆蓋了 Kafka 連接器和（部分的）文件系統連接器。
連接器在 Flink 作業中是數據的出入口。如果作業未按預期運行，連接器的指標是首先要檢查的部分之一。我們相信對於 Flink 應用的生產運維而言，這將是一個很好的改進。
Pulsar 連接器
此版本新增了 Apache Pulsar [11] 連接器。Pulsar 連接器支持以流和批兩種執行模式從 Pulsar 主題讀取數據。在 Pulsar 事務功能（自 Pulsar 2.8.0 引入）的支持下，Pulsar 連接器可以支持精確一次的數據傳遞語義，即使在生產者嘗試重傳消息時也能確保消息僅被傳遞給消費者一次。
為了滿足不同場景下對消息順序和規模的需求，Pulsar Source 連接器支持四種訂閱類型：獨占 [12]、共享 [13]、災備 [14]、鍵共享 [15]。
該連接器目前支持 DataStream API。SQL / Table API 預計將在後續版本中提供。關於如何使用 Pulsar 連接器，請參考文檔 [16]。
基於鏈接的性能提升
與 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 文檔 [17]。
維護一個開源項目也意味着有時要告別一些受人喜愛的功能特性。
在兩年前我們將 Blink SQL 引擎加入到 Flink 時，就已明確它終將取代原本的 SQL 引擎。Blink 速度更快，功能也更加完整。最近一年，Blink 已成為默認的 SQL 引擎。在 Flink 1.14，我們終於將舊版 SQL 引擎的所有代碼移除了。這讓我們得以移除許多過時的接口，避免用戶在實現自定義連接器和函數時產生不知該用哪個接口的困惑。這還有助於我們今後更加快速的迭代 SQL 引擎。
此版本還移除了對 Apache Mesos 的集成，因為我們發現幾乎沒有用戶仍對這一特性感興趣，同時也缺少足夠的貢獻者願意幫助維護這部分系統。Flink 1.14 將不再能夠在不依賴於像 Marathon 這樣的輔助項目的情況下運行在 Mesos 上，同時 Flink 的 ResourceManager 也不再支持根據工作負載的資源需求從 Mesos 動態申請、釋放資源。
我們已努力讓版本升級變得儘可能順利，但仍有一些改動需要用戶在升級 Flink 版本時對應用的一些部分做出調整。有關升級過程中可能需要做出的調整及確認，請參閱發版公告 [18]。原文連接：
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, 子揚, 莫辭
參考鏈接
[1] https://flink.apache.org/news/2021/05/03/release-1.13.0.html#reactive-scaling[2] https://research.fb.com/wp-content/uploads/2016/11/realtime_data_processing_at_facebook.pdf[3] https://www.ververica.com/blog/apache-flinks-stream-batch-unification-powers-alibabas-11.11-in-2020[4] https://cwiki.apache.org/confluence/display/FLINK/FLIP-147%3A+Support+Checkpoints+After+Tasks+Finished[5] https://www.youtube.com/watch?v=4qSlsYogALo&t=666s[6] https://nightlies.apache.org/flink/flink-docs-release-1.14/zh/docs/dev/table/data_stream_api/[7] https://nightlies.apache.org/flink/flink-docs-release-1.14/zh/docs/connectors/datastream/hybridsource/[8] https://nightlies.apache.org/flink/flink-docs-release-1.14/docs/deployment/memory/network_mem_tuning/#the-buffer-debloating-mechanism[9] https://nightlies.apache.org/flink/flink-docs-release-1.14/zh/docs/deployment/finegrained_resource/[10] https://cwiki.apache.org/confluence/display/FLINK/FLIP-33%3A+Standardize+Connector+Metrics[11] https://pulsar.apache.org/[12] https://pulsar.apache.org/docs/zh-CN/concepts-messaging/#exclusive[13] https://pulsar.apache.org/docs/zh-CN/concepts-messaging/#shared%E5%85%B1%E4%BA%AB[14] https://pulsar.apache.org/docs/zh-CN/concepts-messaging/#failover%E7%81%BE%E5%A4%87[15] https://pulsar.apache.org/docs/zh-CN/concepts-messaging/#key_shared[16] https://nightlies.apache.org/flink/flink-docs-release-1.14/zh/docs/connectors/datastream/pulsar/[17] https://nightlies.apache.org/flink/flink-docs-release-1.14/zh/docs/dev/python/overview/[18] https://nightlies.apache.org/flink/flink-docs-release-1.14/release-notes/flink-1.14/
▼ 關注「Flink 中文社區」，獲取更多技術乾貨▼
更多 Flink 相關技術問題，可掃碼加入社區釘釘交流群～
戳我，查看更多技術乾貨！
留言列表