【翻譯】Apache Flink 1.12.0 Release Announcement

本文轉載自查看原文 2020-12-17 10:25 527 FLINK

本文來自官網： https://flink.apache.org/news/2020/12/10/release-1.12.0.html

2020年12月10日Marta Paes（@morsapaes）和Aljoscha Krettek（@aljoscha）

Apache Flink社區很高興地宣布 Flink 1.12.0 發布了！近 300 個 contributors 在1000個 threads 上工作，對可用性進行了重大改進，並提供了簡化（並統一）整個API堆棧的Flink處理的新功能。

發布要點

社區增加了對 DataStream API 中有效批處理執行的支持。這是實現批處理和流處理的真正統一運行時的下一個重要里程碑。
基於 Kubernetes 的高可用性（HA）作為高可用性生產設置的ZooKeeper的替代產品而實現。
Kafka SQL 連接器已擴展為可以在 upsert 模式下工作，並且能夠處理 SQL DDL 中的連接器元數據。現在，臨時表聯接也可以用 SQL 完全表示，而不再依賴於 Table API。
為支持在 PyFlink 的數據流中的 API 擴展了它的使用更復雜的情況，需要在 state 和 time 的細粒度控制，現在可以在 Kubernetes 上本地部署 PyFlink 任務。

這篇博客文章描述了所有主要的新功能和改進，需要注意的重要更改以及預期的發展。

新功能和改進
- DataStream API 中的批處理執行模式
- 新的 Data Sink API（測試版）
- Kubernetes 高可用性（HA）服務
- 其他改進
- Table API / SQL：SQL連接器中的元數據處理
- Table API / SQL：Upsert Kafka連接器
- Table API / SQL：在SQL中支持臨時表聯接
- Table API / SQL的其他改進
- PyFlink：Python DataStream API
- PyFlink的其他改進
重要變化
Release Notes
貢獻者名單

Apache Flink 1.12.0發行公告

2020年12月10日Marta Paes（@morsapaes）和Aljoscha Krettek（@aljoscha）

Apache Flink社區很高興宣布Flink 1.12.0的發布！近300個貢獻者在1000個線程上進行了工作，以顯着提高可用性以及新功能，這些功能簡化了（並統一了）整個API堆棧的Flink處理。

發布要點

社區增加了對DataStream API中有效批處理執行的支持。這是實現批處理和流處理的真正統一運行時的下一個重要里程碑。
基於Kubernetes的高可用性（HA）被實現為ZooKeeper的替代產品，以實現高可用性的生產設置。
Kafka SQL連接器已擴展為可以在upsert模式下工作，並且能夠處理SQL DDL中的連接器元數據。現在，臨時表聯接也可以用SQL完全表示，而不再依賴於Table API。
為支持在PyFlink的數據流中的API擴展了它的使用更復雜的情況，需要在國家和時間的細粒度控制，而且它現在可以在本地部署PyFlink工作Kubernetes。

這篇博客文章描述了所有主要的新功能和改進，需要注意的重要更改以及預期的發展。

現在，可以在Flink網站的更新的“下載”頁面上找到二進制發布包和源碼包，並且可以在 PyPI 上獲得最新的 PyFlink 發布包。請仔細閱讀 release notes，並查看完整的發行變更日志和更新文檔以獲取更多詳細信息。

我們鼓勵您下載這個發行版，並通過Flink郵件列表或JIRA與社區分享您的反饋。

新功能和改進

DataStream API 中的批處理執行模式

Flink 的核心 API 在項目的整個生命周期中都得到了有機開發，並且最初在設計時就考慮了特定的用例。盡管Table API / SQL已經具有統一的算子，但使用較低級別的抽象仍然需要您在批處理（DataSet API）和流式（DataStream API）的兩個語義上不同的API之間進行選擇。由於批處理是無限制流的子集，因此將它們合並到單個API中有一些明顯的優勢：

可重用性：在同一 API 下進行有效的批處理和流處理將使您可以輕松地在兩種執行模式之間切換，而無需重寫任何代碼。因此，可以輕松地重用作業來處理實時和歷史數據。
操作簡便性：提供統一的API將意味着使用同一組連接器，維護單個代碼庫並能夠輕松實現混合執行管道，例如用於回填之類的用例。

考慮到這些優點，社區已朝着統一DataStream API邁出了第一步：支持高效的批處理執行（FLIP-134）。從長遠來看，這意味着 DataSet API 將被 DataStream API 和 Table API / SQL（FLIP-131）棄用和包含。對於統一工作的概述，請參閱這次最近的 Flink Forward 大會。

批處理流

您已經可以使用DataStream API來處理有界的流（例如文件），其限制是運行時不“知道”作業是有界的。為了優化有界輸入的 runtime ，新 BATCH 模式執行使用基於排序的 shuffles （具有純內存的聚合）和改進的調度策略（請參見流水線區域調度）。結果，BATCH DataStream API 中的模式執行已經非常接近 Flink 1.12 中DataSet API 的性能。有關性能基准的更多詳細信息，請查看原始提案（FLIP-140）。

在 Flink 1.12 中，默認執行模式為 STREAMING。要配置作業以 BATCH 模式運行，您可以在提交作業時設置配置：

bin/flink run -Dexecution.runtime-mode=BATCH examples/streaming/WordCount.jar

，或以編程方式執行：

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

env.setRuntimeMode(RuntimeMode.BATCH);

注意：盡管尚未棄用 DataSet API，但我們建議用戶優先使用具有 BATCH 執行模式的 DataStream API 來執行新的批處理作業，並考慮遷移現有的 DataSet 作業。

新的 Data Sink API（Beta）

在以前的版本中，已經確保 Data Source 連接器可以同時在兩種執行模式下工作，因此在Flink 1.12中，社區專注於實現統一的 Data Sink API（FLIP-143）。新的抽象引入了 write/commit protocol 和一個更加模塊化的接口，其中各個組件透明地暴露給框架。

一個 Data Sink 實現必須提供 what 和 How：SinkWriter 寫入哪些需要提交的數據和輸出（即 committables ）; 以及封裝了如何處理提交表的Committer和GlobalCommitter。該框架負責 when 和 where：在什么時間和在 which 機器或程序提交。

這種更加模塊化的抽象允許為 BATCH 和 STREAMING 模式執行不同的 runtime 實現，這些 runtime 實現了預期的目的，但是僅使用一個統一的 data sink 實現。在Flink 1.12中，FileSink 連接器是 StreamingFileSink（FLINK-19758）的統一替代品。其余的連接器將在未來的版本中移植到新接口。

Kubernetes高可用性（HA）服務

Kubernetes 提供了Flink可以用於 JobManager 故障轉移的內置功能，而不是依賴 ZooKeeper。為了啟用 “ ZooKeeperless” HA 設置，社區在 Flink 1.12（FLIP-144）中實現了 Kubernetes HA 服務。該服務與 ZooKeeper 實現基於相同的基本接口構建，並使用 Kubernetes 的 ConfigMap 對象處理從 JobManager 故障中恢復所需的所有元數據。有關如何配置高可用性 Kubernetes 集群的更多詳細信息和示例，請參閱文檔。

注意：這並不意味着將刪除 ZooKeeper 依賴，而只是在 Kubernetes 上為 Flink 用戶提供了替代方法。

其他改進

將現有的 connector 遷移到新的 Data Source API

先前版本引入了新的 Data Source API（FLIP-27），允許實現既可以作為有界（批處理）源也可以作為無界（流式）源使用的 connector。在 Flink 1.12 中，社區開始從 FileSystem 連接器（FLINK-19161）開始將現有 source 連接器移植到新接口。

注意：統一的 source 實現將是完全獨立的連接器，與舊版本不兼容。

Pipelined Region 調度（FLIP-119）

Flink 的調度程序在很大程度上是分別為批處理和流處理工作負載而設計的。此版本引入了統一的調度策略，該策略可識別 blocking 的數據交換，以將執行圖分解為 Pipelined Region。這樣，僅當有數據可以執行工作時才調度每個區域，並且僅在所有必需的資源都可用時才部署它。以及獨立重啟失敗的區域。特別是對於批處理作業，新策略可提高資源利用率，並消除死鎖。

支持 Sort-Merge Shuffles（FLIP-148）

為了提高大規模批處理作業的穩定性，性能和資源利用率，社區引入了 sort-merge shuffle，以替代 Flink 已經使用的原始 shuffle 實現。這種方法可以顯着減少 shuffle 時間，並使用更少的文件句柄和文件寫入緩沖區（這對於大規模作業是有問題的）。后續版本（FLINK-19614）中將實現進一步的優化。

注意：此功能是實驗性的，默認情況下未啟用。要啟用 sort-merge shuffle，您可以在 TaskManager 網絡配置選項中配置合理的最小並行度閾值。

對Flink WebUI（FLIP-75）的改進

作為對 Flink WebUI 的一系列改進的延續，該社區致力於在 WebUI（FLIP-104）上公開 JobManager 的內存相關指標和配置參數。TaskManager 的指標頁面也已更新，以反映對 Flink 1.10（FLIP-102）中引入的 TaskManager 內存模型的更改，並為托管內存，網絡內存和元空間添加了新的指標。

Table API / SQL：SQL 連接器中的元數據處理

某些 Source（和 Format）將其他字段公開為元數據，這些字段對於用戶與記錄數據一起處理是很有價值的。一個常見的例子是 kafka，你可能要如訪問 offset，partition 或 topic 的信息，讀/寫記錄 key 或使用嵌入的元數據的 timestamp 基於時間的操作。在新版本中，Flink SQL支持元數據列以讀取和寫入表每一行的特定於連接器和格式的字段（FLIP-107）。這些列在CREATE TABLE語句中使用METADATA（保留）關鍵字聲明。

CREATE TABLE kafka_table (
  id BIGINT,
  name STRING,
  event_time TIMESTAMP(3) METADATA FROM 'timestamp', -- access Kafka 'timestamp' metadata
  headers MAP<STRING, BYTES> METADATA  -- access Kafka 'headers' metadata
) WITH (
  'connector' = 'kafka',
  'topic' = 'test-topic', 
  'format' = 'avro'
);

在 Flink 1.12 中，公開了 Kafka 和 Kinesis 連接器的元數據，並且已經計划在 FileSystem 連接器上支持（FLINK-19903）。由於 Kafka 記錄的結構更為復雜，因此還專門為 Kafka 連接器實現了新屬性，以控制如何處理鍵/值對。有關 Flink SQL 中元數據支持的完整概述，請查看每個連接器的文檔以及原始提案中的用例。

Table API / SQL：Upsert Kafka 連接器

對於某些用例，例如 interpreting compacted topics 或寫出（更新）匯總結果，有必要將 Kafka 記錄鍵作為真正的主鍵來處理，以確定可以插入，刪除或更新的內容。為了實現這一點，社區創建了一個專用的 upsert 連接器（upsert-kafka），用於擴展基本實現以在upsert 模式（FLIP-149）中工作。

新的 upsert-kafka 連接器可用於 Source 和 Sink ，並提供與現有 Kafka 連接器相同的基本功能和持久性保證，因為它下重用了大部分代碼。要使用 upsert-kafka connector，您必須在創建表時定義一個主鍵約束，並為鍵（key.format）和值（value.format）指定（反序列化）格式。

Table API / SQL：在SQL中支持 Temporal Table Joins

現在，您無需創建臨時表函數來在某個特定時間點查詢表，而只需使用標准 SQL 子句 FOR SYSTEM_TIME AS OF（SQL：2011）來表示臨時表聯接。此外，現在支持對具有時間屬性和主鍵的任何類型的表進行時態聯接，而不僅僅是 append-only table。這可以解鎖一組新的用例，例如直接針對 Kafka compacted 的主題或數據庫變更日志（例如，來自Debezium）執行臨時聯接。

-- Table backed by a Kafka topic
CREATE TABLE orders (
    order_id STRING,
    currency STRING,
    amount INT,
    order_time TIMESTAMP(3),
    WATERMARK FOR order_time AS order_time - INTERVAL '30' SECOND
) WITH (
    'connector' = 'kafka',
    ...
);

-- Table backed by a Kafka compacted topic
CREATE TABLE latest_rates ( 
    currency STRING,
    currency_rate DECIMAL(38, 10),
    currency_time TIMESTAMP(3),
    WATERMARK FOR currency_time AS currency_time - INTERVAL '5' SECOND,
    PRIMARY KEY (currency) NOT ENFORCED      
) WITH (
  'connector' = 'upsert-kafka',
  ...
);

-- Event-time temporal table join
SELECT 
    o.order_id,
    o.order_time, 
    o.amount * r.currency_rate AS amount,
    r.currency
FROM orders AS o, latest_rates FOR SYSTEM_TIME AS OF o.order_time r
ON o.currency = r.currency;

前面的示例還顯示了如何在 temporal table joins 的上下文中利用新的 upsert-kafka 連接器。

Hive Tables in Temporal Table Joins

您還可以通過自動讀取最新的表分區作為 temporal table（FLINK-19644）或整個表作為在執行時跟蹤最新版本的有界流來對 Hive 表執行 temporal table join。有關在臨時表聯接中使用Hive表的示例，請參考文檔。

Table API / SQL的其他改進

Kinesis Flink SQL 連接器（FLINK-18858）

從 Flink 1.12開始，Table API / SQL 本身也支持將 Amazon Kinesis Data Streams（KDS）作為 source/sink 。新的 Kinesis SQL 連接器隨附對增強的扇出（EFO）和 sink 分區的支持。有關支持的功能，配置選項和公開的元數據的完整概述，請查看更新的文檔。

FileSystem / Hive 連接器中的 streaming sink 壓縮（FLINK-19345）

當寫為大文件時，許多批量格式（例如Parquet）是最有效的。當啟用頻繁 checkpoint 時，這是一個挑戰，因為創建的小文件太多（需要在檢查點上滾動）。在 Flink 1.12中，fink sink 支持文件壓縮，從而允許作業保留較小的 checkpoint 間隔，而不會生成大量文件。要啟用文件壓縮，您可以按照文檔中的說明設置 FileSystem 連接器的屬性 auto-compaction=true。

Kafka 連接器中的水印下推（FLINK-20041）

為了確保從 Kafka 消費時的正確性，通常最好在每個分區的基礎上生成水印，因為分區中的亂序通常比所有分區中的亂序性要低。Flink 現在將下推水印策略，以從 Kafka 內部發出分區的水印。source 的輸出水印將由其讀取的分區上的最小水印確定，從而產生更好（即更接近實時）的水印。通過水印下推功能，您還可以配置分區的空閑狀態檢測，以防止空閑分區阻止整個應用程序的事件時間進度。

新支持的格式

Format	Description	Supported Connectors
Avro Schema Registry	讀寫 Confluent Schema Registry KafkaAvroSerializer 序列化的數據。	Kafka, Upsert Kafka
Debezium Avro	讀取和寫入使用Confluent Schema Registry KafkaAvroSerializer序列化的Debezium記錄。	Kafka
Maxwell (CDC)	讀寫 Maxwell JSON 記錄.	Kafka FileSystem
Raw	讀寫 raw (byte-based) 值做為一列值.	Kafka, Upsert Kafka Kinesis FileSystem

用於聯接優化的多輸入運算符（FLINK-19621）

為了消除不必要的序列化和數據溢出並提高批處理和流表API / SQL作業的性能，default planner 現在利用最新版本（FLIP-92）中引入的 N-ary stream operator 來實現運算符的“鏈接”通過前邊緣連接。

Table API UDAF的類型推斷（FLIP-65）

此版本結束了 Flink 1.9 中針對 Table API 的新數據類型系統上的工作，並向該新類型系統公開了聚合函數（UDAF）。從 Flink 1.12 開始，UDAF 的行為類似於標量和表函數，並支持所有數據類型。

PyFlink：Python DataStream API

為了擴展 PyFlink 的可用性，此版本引入了 Python DataStream API（FLIP-130）的第一個版本，該版本支持無狀態操作（例如Map，FlatMap，Filter，KeyBy）。

from pyflink.common.typeinfo import Types
from pyflink.datastream import MapFunction, StreamExecutionEnvironment

class MyMapFunction(MapFunction):

    def map(self, value):
        return value + 1


env = StreamExecutionEnvironment.get_execution_environment()
data_stream = env.from_collection([1, 2, 3, 4, 5], type_info=Types.INT())
mapped_stream = data_stream.map(MyMapFunction(), output_type=Types.INT())
mapped_stream.print()
env.execute("datastream job")

PyFlink 的其他改進

Kubernetes 上的 PyFlink作業（FLINK-17480）

除了獨立部署和 YARN 部署之外，PyFlink 作業現在還可以本地部署在 Kubernetes 上。該部署文檔都有詳細的關於如何啟動一個指令會話或應用 Kubernetes 集群。

用戶定義的匯總函數（UDAF）

在 Flink 1.12中，您可以在 PyFlink（FLIP-139）中定義和注冊 UDAF 。與不處理狀態並且一次只處理一行的普通 UDF 相比，UDAF 是有狀態的，可用於計算多個輸入行上的自定義聚合。要從矢量化中受益，您還可以使用Pandas UDAF（FLIP-137）（最快10倍）。

注意：常規UDAF僅在 group aggregations and in streaming mode 下受支持。對於批處理模式或窗口聚合，請使用Pandas UDAF。

重要變化

[ FLINK-19319 ]默認流時間特征已更改為 EventTime，因此您不再需要調用 StreamExecutionEnvironment.setStreamTimeCharacteristic() 以啟用事件時間支持。
[ FLINK-19278 ] Flink現在依賴於 Scala Macros 2.1.1，因此不再支持<2.11.11的Scala版本。
[ FLINK-19152 ]此版本中已刪除了 Kafka 0.10.x 和 0.11.x 連接器。如果您仍在使用這些版本，請參閱文檔以了解如何升級到通用 Kafka 連接器。
[ FLINK-18795 ] HBase 連接器已升級到最新的穩定版本（2.2.3）。
[ FLINK-17877 ] PyFlink 現在支持Python 3.8。
[ FLINK-18738 ]為了與 FLIP-53 保持一致，托管內存現在也是 Python worker 的默認設置。配置 python.fn-execution.buffer.memory.size 和 python.fn-execution.framework.memory.size 已被刪除，將不再生效。

發行說明

如果您打算將安裝程序升級到Flink 1.12（注：官網寫的是 1.11，寫錯了），請仔細查看發行說明，以獲取詳細的更改和新功能列表。此版本與使用@Public批注進行批注的API的1.x早期版本兼容。

貢獻者名單

Apache Flink社區要感謝使該版本成為可能的300位貢獻者中的每一位

Abhijit Shandilya, Aditya Agarwal, Alan Su, Alexander Alexandrov, Alexander Fedulov, Alexey Trenikhin, Aljoscha Krettek, Allen Madsen, Andrei Bulgakov, Andrey Zagrebin, Arvid Heise, Authuir, Bairos, Bartosz Krasinski, Benchao Li, Brandon, Brian Zhou, C08061, Canbin Zheng, Cedric Chen, Chesnay Schepler, Chris Nix, Congxian Qiu, DG-Wangtao, Da(Dash)Shen, Dan Hill, Daniel Magyar, Danish Amjad, Danny Chan, Danny Cranmer, David Anderson, Dawid Wysakowicz, Devin Thomson, Dian Fu, Dongxu Wang, Dylan Forciea, Echo Lee, Etienne Chauchot, Fabian Paul, Felipe Lolas, Fin-Chan, Fin-chan, Flavio Pompermaier, Flora Tao, Fokko Driesprong, Gao Yun, Gary Yao, Ghildiyal, GitHub, Grebennikov Roman, GuoWei Ma, Gyula Fora, Hequn Cheng, Herman, Hong Teoh, HuangXiao, HuangXingBo, Husky Zeng, Hyeonseop Lee, I. Raleigh, Ivan, Jacky Lau, Jark Wu, Jaskaran Bindra, Jeff Yang, Jeff Zhang, Jiangjie (Becket) Qin, Jiatao Tao, Jiayi Liao, Jiayi-Liao, Jiezhi.G, Jimmy.Zhou, Jindrich Vimr, Jingsong Lee, JingsongLi, Joey Echeverria, Juha Mynttinen, Jun Qin, Jörn Kottmann, Karim Mansour, Kevin Bohinski, Kezhu Wang, Konstantin Knauf, Kostas Kloudas, Kurt Young, Lee Do-Kyeong, Leonard Xu, Lijie Wang, Liu Jiangang, Lorenzo Nicora, LululuAlu, Luxios22, Marta Paes Moreira, Mateusz Sabat, Matthias Pohl, Maximilian Michels, Miklos Gergely, Milan Nikl, Nico Kruber, Niel Hu, Niels Basjes, Oleksandr Nitavskyi, Paul Lam, Peng, PengFei Li, PengchengLiu, Peter Huang, Piotr Nowojski, PoojaChandak, Qingsheng Ren, Qishang Zhong, Richard Deurwaarder, Richard Moorhead, Robert Metzger, Roc Marshal, Roey Shem Tov, Roman, Roman Khachatryan, Rong Rong, Rui Li, Seth Wiesman, Shawn Huang, ShawnHx, Shengkai, Shuiqiang Chen, Shuo Cheng, SteNicholas, Stephan Ewen, Steve Whelan, Steven Wu, Tartarus0zm, Terry Wang, Thesharing, Thomas Weise, Till Rohrmann, Timo Walther, TsReaper, Tzu-Li (Gordon) Tai, Ufuk Celebi, V1ncentzzZ, Vladimirs Kotovs, Wei Zhong, Weike DONG, XBaith, Xiaogang Zhou, Xiaoguang Sun, Xingcan Cui, Xintong Song, Xuannan, Yang Liu, Yangze Guo, Yichao Yang, Yikun Jiang, Yu Li, Yuan Mei, Yubin Li, Yun Gao, Yun Tang, Yun Wang, Zhenhua Yang, Zhijiang, Zhu Zhu, acesine, acqua.csq, austin ce, bigdata-ny, billyrrr, caozhen, caozhen1937, chaojianok, chenkai, chris, cpugputpu, dalong01.liu, darionyaphet, dijie, diohabara, dufeng1010, fangliang, felixzheng, gkrishna, gm7y8, godfrey he, godfreyhe, gsralex, haseeb1431, hequn.chq, hequn8128, houmaozheng, huangxiao, huangxingbo, huzekang, jPrest, jasonlee, jinfeng, jinhai, johnm, jxeditor, kecheng, kevin.cyj, kevinzwx, klion26, leiqiang, libenchao, lijiewang.wlj, liufangliang, liujiangang, liuyongvs, liuyufei9527, lsy, lzy3261944, mans2singh, molsionmo, openopen2, pengweibo, rinkako, sanshi@wwdz.onaliyun.com, secondChoice, seunjjs, shaokan.cao, shizhengchao, shizk233, shouweikun, spurthi chaganti, sujun, sunjincheng121, sxnan, tison, totorooo, venn, vthinkxie, wangsong2, wangtong, wangxiyuan, wangxlong, wangyang0918, wangzzu, weizheng92, whlwanghailong, wineandcheeze, wooplevip, wtog, wudi28, wxp, xcomp, xiaoHoly, xiaolong.wang, yangyichao-mango, yingshin, yushengnan, yushujun, yuzhao.cyz, zhangap, zhangmang, zhangzhanchum, zhangzhanchun, zhangzhanhua, zhangzp, zheyu, zhijiang, zhushang, zhuxiaoshang, zlzhang0122, zodo, zoudan, zouzhiye

歡迎關注Flink菜鳥公眾號，會不定期更新Flink（開發技術）相關的推文

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 編譯 flink 1.12.0 Flink1.12.0依賴 Apache Flink 1.12.0 正式發布，DataSet API 將被棄用，真正的流批一體 WeihanLi.Npoi 1.11.0/1.12.0 Release Notes Flink 1.12.0 sql 任務指定 job name Apache Flink flink-1.12.0 upsert-kafka connector demo CDH6.3.2 Cloudera Manager 集成Flink1.12.0 【翻譯】Flink window 《從0到1學習Flink》—— Apache Flink 介紹