來源?|?Apache Flink 官方博客翻譯?| 高赟(云騫)Apache Flink 社區(qū)很榮幸的宣布 Flink 1.11.0 版本正式發(fā)布！超過 200 名貢獻(xiàn)者參與了 Flink 1.11.0 的開發(fā)，提交了超過 1300 個(gè)修復(fù)或優(yōu)化。這些修改極大的提高了 Flink 的可用性，并且增強(qiáng)了各個(gè) API 棧的功能。其中一些比較重要的修改包括：

核心引擎部分引入了非對齊的 Checkpoint 機(jī)制。這一機(jī)制是對 Flink 容錯(cuò)機(jī)制的一個(gè)重要改進(jìn)，它可以提高嚴(yán)重反壓作業(yè)的 Checkpoint 速度。

實(shí)現(xiàn)了一套新的 Source 接口。通過統(tǒng)一流和批作業(yè) Source 的運(yùn)行機(jī)制，提供常用的內(nèi)部實(shí)現(xiàn)如事件時(shí)間處理，watermark 生成和空閑并發(fā)檢測，這套新的 Source 接口可以極大的降低實(shí)現(xiàn)新的 Source 時(shí)的開發(fā)復(fù)雜度。

Flink SQL 引入了對 CDC(Change Data Capture，變動(dòng)數(shù)據(jù)捕獲)的支持，它使 Flink 可以方便的通過像 Debezium 這類工具來翻譯和消費(fèi)數(shù)據(jù)庫的變動(dòng)日志。Table API 和 SQL 也擴(kuò)展了文件系統(tǒng)連接器對更多用戶場景和格式的支持，從而可以支持將流式數(shù)據(jù)從 Kafka 寫入 Hive 等場景。

PyFlink 優(yōu)化了多個(gè)部分的性能，包括對向量化的用戶自定義函數(shù)(Python UDF)的支持。這些改動(dòng)使 Flink Python 接口可以與常用的 Python 庫(如 Pandas 和 NumPy)進(jìn)行互操作，從而使 Flink 更適合數(shù)據(jù)處理與機(jī)器學(xué)習(xí)的場景。

Flink 1.11.0 的二進(jìn)制發(fā)布包和源代碼可以在 Flink 官網(wǎng)的下載頁面獲得，對應(yīng)的 PyFlink 發(fā)布包可以在 PyPI 網(wǎng)站下載。詳情可以參閱發(fā)布說明，發(fā)布功能更新與更新后的文檔。我們希望您下載試用這一版本后，可以通過 Flink 郵件列表和 JIRA 網(wǎng)站和我們分享您的反饋意見。▼ GitHub 下載地址?▼https://flink.apache.org/downloads.html#apache-flink-1110

新的功能和優(yōu)化

非對齊的 Checkpoints(Beta 版本)

當(dāng) Flink 發(fā)起一次 Checkpoint 時(shí)， Checkpoint Barrier 會(huì)從整個(gè)拓?fù)涞?Source 出發(fā)一直流動(dòng)到 Sink。對于超過一個(gè)輸入的算子，來自各個(gè)輸入的 Barrier 首先需要對齊，然后這個(gè)算子才能進(jìn)行 state 的快照操作以及將 Barrier 發(fā)布給后續(xù)的算子。一般情況下對齊可以在幾毫秒內(nèi)完成，但是當(dāng)反壓時(shí)，對齊可能成為一個(gè)瓶頸：

Checkpoint Barrier 在有反壓的輸入通道中傳播的速度非常慢(需要等待前面的數(shù)據(jù)處理完成)，這將會(huì)阻塞對其它輸入通道的數(shù)據(jù)處理并最終進(jìn)一步反壓上游的算子。

Checkpoint Barrier 傳播慢還會(huì)導(dǎo)致 Checkpoint 時(shí)間過長甚至超時(shí)，在最壞的情況下，這可能導(dǎo)致整個(gè)作業(yè)進(jìn)度無法更新。

為了提高 Checkpoint 在反壓情況下的性能，Flink 社區(qū)在 1.11.0 版本中初步實(shí)現(xiàn)了非對齊的 Checkpoint 機(jī)制(FLIP-76)。與對齊的 Checkpoint(圖1)相比，這種方式下算子不需要等待來自各個(gè)輸入通道的 Barrier 對齊，相反，這種方式允許 Barrier 越過前面的待處理的數(shù)據(jù)(即在輸出和輸入 Buffer 中的數(shù)據(jù))并且直接觸發(fā) Checkpoint 的同步階段。這一過程如圖2所示。

圖1. 對齊的Checkpoint

圖2. 非對齊的Checkpoint由于被越過的傳播中的數(shù)據(jù)必須作為快照的一部分被持久化，非對齊的 Checkpoint 機(jī)制會(huì)增加 Checkpoint 的大小。但是，好的方面是它可以極大的減少 Checkpoint 需要的時(shí)間，因此即使在非穩(wěn)定的環(huán)境中，用戶也可以看到更多的作業(yè)進(jìn)度。這是由于非對齊的 Checkpoint 可以減少 Recovery 的負(fù)載。關(guān)于非對齊的 Checkpoint 更詳細(xì)的信息以及未來的開發(fā)計(jì)劃，可以分別參考相關(guān)文檔和 FLINK-14551。和其它 Beta 版本的特性一樣，我們非常期待和感謝您試用之后和社區(qū)分享您的感受。注意：開啟這一特征需要通過 Chekpoint 選項(xiàng)配置 enableUnalignedCheckpoints 參數(shù)。需要注意的是，非對齊的 Checkpoint 只有在 CheckpointMode 被設(shè)置為 CheckpointMode.EXACTLY_ONCE 的時(shí)候才有效。

統(tǒng)一的 Watermark 生成器

目前 Flink 的 Watermark 生成(也叫做分配)依賴于兩個(gè)接口：AssignerWithPunctuatedWatermarks 與 AssignerWithPeriodicWatermarks，這兩個(gè)接口與記錄時(shí)間戳提取的關(guān)系也比較混亂，從而使 Flink 難以實(shí)現(xiàn)一些用戶急需的功能，如支持空閑檢測；此外，這還會(huì)導(dǎo)致代碼重復(fù)且難以維護(hù)。通過?FLIP-126，現(xiàn)有的 watermark 生成接口被統(tǒng)一為一個(gè)單獨(dú)的接口，即 WatermarkGenerator，并且它和 TimestampAssigner 獨(dú)立。這一修改使用戶可以更好的控制 watermark 的發(fā)送邏輯，并且簡化實(shí)現(xiàn)支持watermark 生成和時(shí)間戳提取的 Source 的難度(可以參考新的 Source 接口)。基于這一接口，Flink 1.11 中還提供了許多內(nèi)置的 Watermark 生成策略(例如 forBoundedOutOfOrderness, forMonotonousTimestamps)，并且用戶可以使用自己的實(shí)現(xiàn)。

■ 支持 Watermark 空閑檢測

WatermarkStrategy.withIdleness()方法允許用戶在配置的時(shí)間內(nèi)(即超時(shí)時(shí)間內(nèi))沒有記錄到達(dá)時(shí)將一個(gè)流標(biāo)記為空閑，從而進(jìn)一步支持 Flink 正確處理多個(gè)并發(fā)之間的事件時(shí)間傾斜的問題，并且避免了空閑的并發(fā)延遲整個(gè)系統(tǒng)的事件時(shí)間。通過將 Kafka 連接器遷移至新的接口(FLINK-17669)，用戶可以受益于針對單個(gè)并發(fā)的空閑檢測。注意：這一 FLIP 的修改目前不會(huì)影響現(xiàn)有程序，但是我們推薦用戶后續(xù)盡量使用新的 Watermark 生成接口，避免后續(xù)版本禁用之前的 Watermark 生成器帶來的影響。

新的 Source 接口(Beta)

1.11 以編寫一個(gè)生產(chǎn)可用的 Flink Source 連接器并不是一個(gè)簡單的任務(wù)，它需要用戶對 Flink 內(nèi)部實(shí)現(xiàn)有一定的了解，并且需要在連接器中自行實(shí)現(xiàn)事件時(shí)間提取、Watermark 生成和空閑檢測等功能。針對這一問題，Flink 1.11 引入了一套新的Source 接口 FLIP-27 來解決上述問題，并且同時(shí)解決了需要為批作業(yè)和流作業(yè)編寫兩套 Source 實(shí)現(xiàn)的問題。

通過將分區(qū)發(fā)現(xiàn)和實(shí)現(xiàn)消費(fèi)每一個(gè)分區(qū)的數(shù)據(jù)分成不同的組件(即 SplitEnumerator 和 SourceReader)，新的 Source 接口允許將不同的分區(qū)發(fā)現(xiàn)策略和分區(qū)消費(fèi)的具體實(shí)現(xiàn)任意組合。例如，現(xiàn)有的 Kafka 連接器提供了多種不同的分區(qū)發(fā)現(xiàn)策略，這些策略的實(shí)現(xiàn)和其實(shí)代碼的實(shí)現(xiàn)耦合在一起。如果遷移到新的接口，Kafka Source 將可以使用相同的分區(qū)消費(fèi)的實(shí)現(xiàn)(即 SourceReader)，并且針對不同的分區(qū)發(fā)現(xiàn)策略編寫單獨(dú)的 SplitEnumerator 的實(shí)現(xiàn)。

■ 流批統(tǒng)一

使用新版 Source 接口的 Source 連接器將可以同時(shí)用于有限數(shù)據(jù)(批)作業(yè)和無限數(shù)據(jù)(流)作業(yè)。這兩種場景僅有一個(gè)很小的區(qū)別：在有限數(shù)據(jù)的情況下，分區(qū)發(fā)現(xiàn)策略將返回一個(gè)固定大小的分區(qū)并且每一個(gè)分區(qū)的數(shù)據(jù)都是有限的；在無限數(shù)據(jù)的情況下，要么每個(gè)分區(qū)的數(shù)據(jù)量是無限的，要么分區(qū)發(fā)現(xiàn)策略可以不斷的產(chǎn)生新的分區(qū)。

■ 內(nèi)置的 Watermark 和事務(wù)時(shí)間處理

在新版 Source 接口中，TimestampAssigner 和 WatermarkGenerator 將透明的作為分區(qū)消費(fèi)具體實(shí)現(xiàn)(SourceReader)的一部分，因此用戶不需要實(shí)現(xiàn)任何時(shí)間戳提取和 Watermark 生成的代碼。注意：現(xiàn)有的 Source 連接器尚未基于新的 Source 接口重新實(shí)現(xiàn)，這將在后續(xù)版本中逐漸完成。如果想要基于新的 Source 接口實(shí)現(xiàn)自己的 Source，可以參考 Data Source 文檔和 Source 開發(fā)的一些建議。

Application 部署模式

在1.11之前，Flink 的作業(yè)有兩種部署模式，其中 Session 模式是將作業(yè)提交到一個(gè)長期運(yùn)行的 Flink Session 集群，Job 模式是為每個(gè)作業(yè)啟動(dòng)一個(gè)專門的 Flink 作業(yè)集群。這兩種模式下用戶作業(yè)的 main 方法都是客戶端執(zhí)行的，但是這種方式存在一定的問題：如果客戶端是更大程序的一部分的話，生成 JobGraph 容易成為系統(tǒng)的瓶頸；其次，這種方式也不能很好的適應(yīng)像 Docker 和 K8s 這樣的容器環(huán)境。Flink 1.11 引入了一種新的部署模式，即 Application 模式(FLIP-85)。這種模式下用戶程序的 main 方法將在集群中而不是客戶端運(yùn)行。這樣，作業(yè)提交就會(huì)變得非常簡單：用戶將程序邏輯和依賴打包進(jìn)一人可執(zhí)行的 jar 包里，集群的入口程序(ApplicationClusterEntryPoint)負(fù)責(zé)調(diào)用其中的 main 方法來生成 JobGraph。Flink 1.11 已經(jīng)可以支持基于 K8s 的 Application 模式(FLINK-10934)。

其它功能修改

■ 統(tǒng)一 JM 的內(nèi)存配置(FLIP-116)

在1.10中，Flink 統(tǒng)一了 TM 端的內(nèi)存管理和配置，相應(yīng)的在1.11中，Flink 進(jìn)一步對JM 端的內(nèi)存配置進(jìn)行了修改，使它的選項(xiàng)和配置方式與 FLIP-49 中引入的 TM 端的配置方式保持一致。這一修改影響所有的部署類型，包括 standalone，Yarn，Mesos 和新引入的 K8s。注意：復(fù)用之前的 Flink 配置將會(huì)得到不同的 JVM 參數(shù)，從而可能影響性能甚至導(dǎo)致異常。如果想要更新到 1.11 的話，請一定要參考遷移文檔。

■?Web UI 功能增強(qiáng)

在1.11中，社區(qū)對 Flink Web UI 進(jìn)行了一系列的優(yōu)化。首要的修改是優(yōu)化了 TM 和 JM 的日志展示(FLIP-103)，其次，Flink Web UI 還引入了打印所有線程列表的工具(FLINK-14816)。在后續(xù)的版本中，Web UI 還將進(jìn)一步優(yōu)化，包括更好的反壓檢測，更靈活和可配置的異常展示以及對 Task 出錯(cuò)歷史的展示。

■?統(tǒng)一 Docker 鏡像

1.11 將所有 Docker 相關(guān)的資源都統(tǒng)一整理到了 apache/flink-docker項(xiàng)目中，并且擴(kuò)展了入口腳本從而允許用戶在不同模式下使用默認(rèn)的 docker 鏡像，避免了許多情況下用戶自己創(chuàng)建鏡像的麻煩。關(guān)于如何在不同環(huán)境和部署模式下使用和定制 Flink 官方 Docker 鏡像，請參考詳細(xì)文檔。

Table API/SQL：支持 CDC(Change Data Capture)

CDC 是數(shù)據(jù)庫中一種常用的模式，它捕獲數(shù)據(jù)庫提交的修改并且將這些修改廣播給其它的下游消費(fèi)者。CDC 可以用于像同步多個(gè)數(shù)據(jù)存儲(chǔ)和避免雙寫導(dǎo)致的問題等場景。長期以來 Flink 的用戶都希望能夠?qū)?CDC 數(shù)據(jù)通過 Table API/SQL 導(dǎo)入到作業(yè)中，而 Flink 1.11 實(shí)現(xiàn)了這一點(diǎn)。為了能夠在 Table API / SQL 中使用 CDC，Flink 1.11 更新了 Table Source 與 Sink 的接口來支持 changelog 模式(參考新的 Table Source 與 Sink 接口)并且支持了 Debezium 與 Canal 格式(FLIP-105)。這一改動(dòng)使動(dòng)態(tài) Table Source 不再只支持 append-only 的操作，而且可以導(dǎo)入外部的修改日志(插入事件)將它們翻譯為對應(yīng)的修改操作(插入，修改和刪除)并將這些操作與操作的類型發(fā)送到后續(xù)的流中。

為了消費(fèi) CDC 數(shù)據(jù)，用戶需要在使用 SQL DDL 創(chuàng)建表時(shí)指指定“format=debezium-json“或者“format=canal-json”： CREATE TABLE my_table ( ...) WITH ( 'connector'='...', -- e.g. 'kafka' 'format'='debezium-json', 'debezium-json.schema-include'='true' -- default: false (Debezium can be configured to include or exclude the message schema) 'debezium-json.ignore-parse-errors'='true' -- default: false);Flink 1.11 僅支持 Kafka 作為修改日志的數(shù)據(jù)源以及 JSON 編碼格式的修改日志；后續(xù) Flink 將進(jìn)一步支持 Avro(Debezium)和 Protobuf(Canal)格式。Flink 還計(jì)劃在未來支持 UDFMySQL 的 Binlog 以及 Kafka 的 Compact Topic 作為數(shù)據(jù)源，并且將對修改日志的支持?jǐn)U展到批作業(yè)。注意：目前有一個(gè)已知的 BUG(FLINK-18461)會(huì)導(dǎo)致使用修改日志的 Source 無法寫入到 Upsert Sink 中(例如，MySQL，HBase，ElasticSearch)。這個(gè)問題會(huì)在下一個(gè)版本(即 1.11.1)中修復(fù)。

Table API/SQL：支持 JDBC Catalog 和 Postgres Catalog

Flink 1.11 支持了一種通用的 JDBC Catalog 接口(FLIP-93)，這一接口允許 Table API/SQL 的用戶自動(dòng)的從通過 JDBC 連接的關(guān)系數(shù)據(jù)庫中導(dǎo)出表結(jié)構(gòu)。這一功能避免了之前用戶需要手動(dòng)復(fù)制表結(jié)構(gòu)以及進(jìn)行類型映射的麻煩，并且允許 Flink 在編譯時(shí)而不是運(yùn)行時(shí)對表結(jié)構(gòu)進(jìn)行檢查。首先在1.11中實(shí)現(xiàn)的是 Postgres Catalog。

Table API/SQL：支持 Avro，ORC 和 Parquet 格式的文件系統(tǒng)連接器

為了提高用戶使用 Flink 進(jìn)行端到端的流式 ETL 的體驗(yàn)，Flink 1.11 在 Table API/SQL 中引入了新的文件系統(tǒng)連接器。它基于 Flink 自己的文件系統(tǒng)抽象和 StreamingFileSink 來實(shí)現(xiàn)，從而保證和 DataStream API 有相同的能力和一致的行為。

這也意味著 Table API/SQL 的用戶可以使用 StreamingFileSink 現(xiàn)在已經(jīng)支持的文件格式，例如 (Avro) Parquet，以及在這1.11中新增加的文件格式，例如 Avro 和 ORC。

CREATE TABLE my_table ( column_name1 INT, column_name2 STRING, ... part_name1 INT, part_name2 STRING) PARTITIONED BY (part_name1, part_name2) WITH ( 'connector' = 'filesystem', 'path' = 'file:///path/to/file, 'format' = '...', -- supported formats: Avro, ORC, Parquet, CSV, JSON ...);新的全能的文件系統(tǒng)連接器可以透明的支持流作業(yè)和批作業(yè)，提供 Exactly-once 語義并且提供了完整的分區(qū)的支持，從而相對于之前的 Connector 極大的擴(kuò)展了可以支持的場景。例如，用戶可以容易的實(shí)現(xiàn)將流式數(shù)據(jù)從 Kafka 寫入 Hive 的場景。后續(xù)的文件系統(tǒng)連接器的優(yōu)化可以參考 FLINK-17778。

Table API/SQL：支持 Python UDF

在1.11之前 Table API/SQL 的用戶只能通過 Java 或 Scala 來實(shí)現(xiàn) UDF。在1.11中，Flink 擴(kuò)展了 Python 語言的應(yīng)用范圍，除了 PyFlink 外，Flink 1.11 還在 SQL DDL 語法(FLIP-106)和 SQL Client(FLIP-114)中支持了 Python UDF。用戶還可以在系統(tǒng) Catalog 中通過 SQL DDL 或者 Java Catalog API 來注冊 Python UDF，這樣這些 UDF 可以在作業(yè)中共享。

其它的 Table API/SQL 優(yōu)化

■ Hive Connect 兼容 Hive DDL 和 DML(FLIP-123)

從1.11開始，用戶可以在 Table API/SQL 和 SQL Client 中使用 Hive 語法(HiveQL)來編寫 SQL 語句。為了支持這一特性，Flink 引入了一種新的 SQL 方言，用戶可以動(dòng)態(tài)的為每一條語句選擇使用Flink(default)或Hive(hive)方法。對于所支持的 DDL 和 DML 的完整列表，請參考 Hive 方言的文檔。

■?Flink SQL 語法的擴(kuò)展和優(yōu)化

• Flink 1.11 引入了主鍵約束的概念，從而可以在 Flink SQL DDL 的運(yùn)行時(shí)優(yōu)化中使用(FLIP-87)。
• 視圖對象已經(jīng)在 SQL DDL 中完整支持，可以通過 CREATE/ALTER/DROP VIEW 等語句使用(FLIP-71)。
• 用戶可以在 DQL 和 DML 中使用動(dòng)態(tài)表屬性動(dòng)態(tài)指定或覆蓋 Table 的選項(xiàng)(FLIP-113)。
• 為了簡化 connector 參數(shù)的配置，提高異常處理的能力，Table API/SQL 修改了一些配置項(xiàng)的名稱(FLIP-122)。這一改動(dòng)不會(huì)破壞兼容性，用戶仍然可以使用老的名稱。

■?新的 Table Source 和 Sink 接口(FLIP-95)

Flink 1.11 引入了新的 Table Source 和 Sink 接口(即 DynamicTableSource 和 DynamicTableSink)，這一接口可以統(tǒng)一批作業(yè)和流作業(yè)，在使用 Blink Planner 時(shí)提供更高效的數(shù)據(jù)處理并且可以支持修改日志的處理(參考支持修改日志)。新的接口簡化了用戶實(shí)現(xiàn)新的自定義的連接器和修改現(xiàn)有連接器的復(fù)雜度。一個(gè)基于支持修改日志語義的數(shù)據(jù)解析格式來實(shí)現(xiàn)定制表掃描的Source的案例請參考這一文檔。注意：盡管這一修改不會(huì)破壞兼容性，但是我們推薦 Table API/SQL 的用戶盡快將現(xiàn)有的Source和Sink升級到新的接口上。

■?重構(gòu) Table Env 接口(FLIP-84)

1.11之前 TableEnvironment 和 Table 上相似的接口的行為并不完全相同，這導(dǎo)致了接口的不一致并使用戶感到困惑。為了解決這一問題并使基于 Table API/SQL 的編寫程序更加流暢，Flink 1.11 引入了新的方法來統(tǒng)一這些不一致的行為，例如執(zhí)行觸發(fā)的時(shí)機(jī)(即executeSql())，結(jié)果展示(即 print()，collecto())并且為后續(xù)版本的重要功能(如多語句執(zhí)行)打下了基礎(chǔ)。注意：在 FLIP-84 中被標(biāo)記為過期的方法不會(huì)被立刻刪掉，但是我們建議用戶采用新的方法。對于新的方法和過期方法的完整列表，可以查看 FLIP-84 的總結(jié)部分。

■?新的類型推斷和 Table API UDF(FLIP-65)

在 Flink 1.9 中，社區(qū)開始在 Table API 中支持一種新的類型系統(tǒng)來提高與標(biāo)準(zhǔn) SQL 的一致性(FLIP-37)。在1.11中這一工作接近完成，通過支持在 Table API UDF 中使用新的類型系統(tǒng)(目前支持 scalar 函數(shù)與 table 函數(shù)，計(jì)劃下一版本也支持 aggregate 函數(shù))。

PyFlink：支持 Pandas UDF

在1.11之前，PyFlink 中的 Python UDF 僅支持標(biāo)準(zhǔn)的 Python 標(biāo)量類型。這帶來了一些限制：

在 JVM 和 Python 進(jìn)程之間傳遞數(shù)據(jù)會(huì)導(dǎo)致較大序列化、反序列化開銷。

難以集成常用的高性能 Python 數(shù)值計(jì)算框架，例如 Pandas 和 NumPy。

為了克服這些限制，社區(qū)引入了對基于 Pandas 的(標(biāo)量)向量 Python UDF 的支持(FLIP-97)。由于可以通過利用 Apache Arrow 來最小化序列化/反序列化的開銷，向量 UDF 的性能一般會(huì)非常好；此外，將 pandas.Series 作為輸入輸出的類型可以充分復(fù)用 Pandas 和 NumPy 庫。這些特點(diǎn)使 Pandas UDF 特別適合并行機(jī)器學(xué)習(xí)和其它大規(guī)模、分布式的數(shù)據(jù)科學(xué)的計(jì)算作業(yè)(例如特征提取或分布式模式服務(wù))。@udf(input_types=[DataTypes.BIGINT(),DataTypes.BIGINT()],result_type=DataTypes.BIGINT(),udf_type="pandas")defadd(i,j):??returni+j為了使 UDF 變?yōu)?Pandas UDF，需要在 udf 的裝飾器中添加額外的參數(shù) udf_type=”pandas”，如文檔所示。

PyFlink 的其它優(yōu)化

■?支持轉(zhuǎn)換器 fromPandas/toPandas(FLIP-120)

Arrow 還被用來優(yōu)化 PyFlink Table 和 pandas.DataFrame 之間的轉(zhuǎn)換，從而使用戶可以在不同的處理引擎之間無縫切換，而不需要編寫特殊的連接器進(jìn)行中轉(zhuǎn)。使用 fromPandas()和toPandas() 方法的安例，可以參考相關(guān)文檔。

■?支持用戶自定義的 Table Function(User-defined Table Function,UDTF)(FLINK-14500)

從1.11開始，用戶可以在 PyFlink 定義和注冊自定義的 UDTF。與 Python UDF 類似，UDTF 可以接受0個(gè)，一個(gè)或多個(gè)標(biāo)量值作為參數(shù)，但是可以返回任意多行數(shù)據(jù)作為輸出而不是只能返回單個(gè)值。

■?基于 Cython 對 UDF 的性能進(jìn)行優(yōu)化(FLIP-121)

Cython 是一個(gè) Python 語言預(yù)編譯的超集，它經(jīng)常被用來提高大規(guī)模數(shù)據(jù)計(jì)算函數(shù)的性能，因?yàn)樗梢詫⒋a執(zhí)行速度優(yōu)化到機(jī)器指令級別，并且可以很好的與常用的基于 C 語言實(shí)現(xiàn)的庫配合，例如 NumPy。從 Flink 1.11 開始，用戶可以構(gòu)造包括 Cython支持的 PyFlink[60]并且可以通過 Cython 來優(yōu)化 Python UDF。這種優(yōu)化可以極大的提升代碼的性能(與 1.10 的 Python UDF 相比最高能有 30 倍的提升)。

■?Python UDF 支持用戶自定義的 Metrics(FLIP-112)

為了使用戶可以更容易的監(jiān)控和調(diào)試 Python UDF 的執(zhí)行，PyFlink 現(xiàn)在支持收集和輸出 Metric 的值到外部系統(tǒng)中，并且支持自定義域和變量。用戶可以在 UDF 的 open 方法中通過調(diào)用 function_context.get_metric_group() 來訪問一個(gè) Metric 系統(tǒng)，如文檔所示。

其它重要優(yōu)化

• [FLINK-17339] 從1.11開始，Blink Planner 將變?yōu)?Table API/SQL 的默認(rèn) Planner。實(shí)際上，在1.10中 SQL Client 的默認(rèn) Planner 已經(jīng)變?yōu)?Blink Planner。老的 Planner 仍然將會(huì)支持，但是后續(xù)不會(huì)再有大的變更。
• [FLINK-5763] Savepoints 將所有的狀態(tài)寫入到單個(gè)目錄下(包括元數(shù)據(jù)和程序狀態(tài))。這使得用戶可以容易的看出每個(gè) Savepoint 的 State 包含哪些文件，并且允許用戶直接通過移動(dòng)目錄來實(shí)現(xiàn) Savepoint 的重定位。
• [FLINK-16408] 為了減少 JVM 元數(shù)據(jù)空間的壓力，Flink 1.11 中對于單個(gè) TaskExecutor 只要上面還有某個(gè)作業(yè)的 Slot，該作業(yè)的 ClassLoader 就會(huì)被復(fù)用。這一改動(dòng)會(huì)改變 Flink 錯(cuò)誤恢復(fù)的行為，因?yàn)?static 字段不會(huì)被重新初始化。
• [FLINK-11086] Flink 現(xiàn)在可以支持 Hadoop 3.0.0 以上的版本。注意 Flink 項(xiàng)目并未提供任何更新的“flink-shaded-hadoop-*”的 jar 包，而是需要用戶自己將相應(yīng)的 Hadoop 依賴加入 HADOOP_CLASSPATH 環(huán)境變量(推薦的方式)或者將 Hadoop 依賴加入到 lib/目錄下。
• [FLINK-16963] 所有 Flink 內(nèi)置的 Metric Report 現(xiàn)在被修改為 Flink 的插件。如果要使用它們，不應(yīng)該放置到 lib/目錄下(會(huì)導(dǎo)致類沖突)，而是要放置到 plugins/目錄下。
• [FLINK-12639] 社區(qū)正在對 Flink 文檔進(jìn)行重構(gòu)，從1.11開始，您可能會(huì)注意到文檔的導(dǎo)航和內(nèi)容組織發(fā)生了一些變化。

詳細(xì)發(fā)布說明

如果你想要升級到1.11的話，請?jiān)敿?xì)閱讀詳細(xì)發(fā)布說明。與之前所有1.x版本相比，1.11可以保證所有標(biāo)記為@Public的接口的兼容。猜你喜歡

1、Spark 背后的商業(yè)公司收購的 Redash 是個(gè)啥？

2、馬鐵大神的 Apache Spark 十年回顧

3、YARN 在字節(jié)跳動(dòng)的優(yōu)化與實(shí)踐

4、Apache Spark 3.0.0 正式版終于發(fā)布了，重要特性全面解析

過往記憶大數(shù)據(jù)微信群，請?zhí)砑游⑿?#xff1a;fangzhen0219,備注【進(jìn)群】

點(diǎn)擊「閱讀原文」即可查看原版官方博客～

總結(jié)

以上是生活随笔為你收集整理的1.1.1.1校园网_Apache Flink 1.11.0 重要功能全面解析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。