Apache Flink 1.10.0 重磅發佈，年度最大規模版本升級！

時間 2020-02-14

標籤 apache flink 1.10.0 重磅發佈年度最大規模版本升級欄目 Apache 简体版

原文原文鏈接

Flink 1.10 同時還標誌着對 Blink[1] 的整合宣告完成，隨着對 Hive 的生產級別集成及對 TPC-DS 的全面覆蓋，Flink 在加強流式 SQL 處理能力的同時也具有了成熟的批處理能力。本篇博客將對這次版本升級中的主要新特性及優化、值得注意的重要變化以及使用新版本的預期效果逐一進行介紹。html

<p style="text-align:center"> 官網下載連接 sql

<p style="text-align:center">https://flink.apache.org/down...</p></p>express

新版本的二進制發佈包和源碼包已經能夠在最新的 Flink 官網下載頁面[2]找到。更多細節請參考完整的版本更新日誌[3]以及最新的用戶文檔[4]。歡迎您下載試用此版本，並將您的反饋意見經過 Flink 郵件列表[5]或 JIRA[6] 與社區分享。apache

新特性及優化

內存管理及配置優化

Flink 目前的 TaskExecutor 內存模型存在着一些缺陷，致使優化資源利用率比較困難，例如：編程

流和批處理內存佔用的配置模型不一樣；
流處理中的 RocksDB state backend 須要依賴用戶進行復雜的配置。

爲了讓內存配置變的對於用戶更加清晰、直觀，Flink 1.10 對 TaskExecutor 的內存模型和配置邏輯進行了較大的改動（FLIP-49 [7]）。這些改動使得 Flink 可以更好地適配全部部署環境（例如 Kubernetes, Yarn, Mesos），讓用戶可以更加嚴格的控制其內存開銷。網絡

■ Managed 內存擴展session

Managed 內存的範圍有所擴展，還涵蓋了 RocksDB state backend 使用的內存。儘管批處理做業既可使用堆內內存也可使用堆外內存，使用 RocksDB state backend 的流處理做業卻只能利用堆外內存。所以爲了讓用戶執行流和批處理做業時無需更改集羣的配置，咱們規定從如今起 managed 內存只能在堆外。數據結構

■ 簡化 RocksDB 配置框架

此前，配置像 RocksDB 這樣的堆外 state backend 須要進行大量的手動調試，例如減少 JVM 堆空間、設置 Flink 使用堆外內存等。如今，Flink 的開箱配置便可支持這一切，且只須要簡單地改變 managed 內存的大小便可調整 RocksDB state backend 的內存預算。 less

另外一個重要的優化是，Flink 如今能夠限制 RocksDB 的 native 內存佔用（FLINK-7289 [8]），以免超過總的內存預算——這對於 Kubernetes 等容器化部署環境尤其重要。關於如何開啓、調試該特性，請參考 RocksDB 調試[9]。

注：FLIP-49 改變了集羣的資源配置過程，所以從之前的 Flink 版本升級時可能須要對集羣配置進行調整。詳細的變動日誌及調試指南請參考文檔[10]。

統一的做業提交邏輯

在此以前，提交做業是由執行環境負責的，且與不一樣的部署目標（例如 Yarn, Kubernetes, Mesos）緊密相關。這致使用戶須要針對不一樣環境保留多套配置，增長了管理的成本。

在 Flink 1.10 中，做業提交邏輯被抽象到了通用的 Executor 接口（FLIP-73 [11]）。新增長的 ExecutorCLI （FLIP-81 [12]）引入了爲任意執行目標[13]指定配置參數的統一方法。此外，隨着引入 JobClient（FLINK-74 [14]）負責獲取 JobExecutionResult，獲取做業執行結果的邏輯也得以與做業提交解耦。

上述改變向用戶提供了統一的 Flink 入口，使得在 Apache Beam 或 Zeppelin notebooks 等下游框架中以編程方式使用 Flink 變的更加容易。對於須要在多種不一樣環境使用 Flink 的用戶而言，新的基於配置的執行過程一樣顯著下降了冗餘代碼量以及維護開銷。

原生 Kubernetes 集成（Beta）

對於想要在容器化環境中嘗試 Flink 的用戶來講，想要在 Kubernetes 上部署和管理一個 Flink standalone 集羣，首先須要對容器、算子及像 kubectl 這樣的環境工具備所瞭解。

在 Flink 1.10 中，咱們推出了初步的支持 session 模式的主動 Kubernetes 集成（FLINK-9953 [15]）。其中，「主動」指 Flink ResourceManager (K8sResMngr) 原生地與 Kubernetes 通訊，像 Flink 在 Yarn 和 Mesos 上同樣按需申請 pod。用戶能夠利用 namespace，在多租戶環境中以較少的資源開銷啓動 Flink。這須要用戶提早配置好 RBAC 角色和有足夠權限的服務帳號。

正如在統一的做業提交邏輯一節中提到的，Flink 1.10 將命令行參數映射到了統一的配置。所以，用戶能夠參閱 Kubernetes 配置選項，在命令行中使用如下命令向 Kubernetes 提交 Flink 做業。

./bin/flink run -d -e kubernetes-session -Dkubernetes.cluster-id=<ClusterId> examples/streaming/WindowJoin.jar

若是你但願第一時間嘗試這一特性，歡迎參考相關文檔[16]、試用並與社區分享你的反饋意見：

Table API/SQL: 生產可用的 Hive 集成

Flink 1.9 推出了預覽版的 Hive 集成。該版本容許用戶使用 SQL DDL 將 Flink 特有的元數據持久化到 Hive Metastore、調用 Hive 中定義的 UDF 以及讀、寫 Hive 中的表。Flink 1.10 進一步開發和完善了這一特性，帶來了全面兼容 Hive 主要版本[17]的生產可用的 Hive 集成。

■ Batch SQL 原生分區支持

此前，Flink 只支持寫入未分區的 Hive 表。在 Flink 1.10 中，Flink SQL 擴展支持了 INSERT OVERWRITE 和 PARTITION 的語法（FLIP-63 [18]），容許用戶寫入 Hive 中的靜態和動態分區。

寫入靜態分區

INSERT { INTO | OVERWRITE } TABLE tablename1 [PARTITION (partcol1=val1, partcol2=val2 ...)] select_statement1 FROM from_statement;

寫入動態分區

INSERT { INTO | OVERWRITE } TABLE tablename1 select_statement1 FROM from_statement;

對分區表的全面支持，使得用戶在讀取數據時可以受益於分區剪枝，減小了須要掃描的數據量，從而大幅提高了這些操做的性能。

■ 其餘優化

除了分區剪枝，Flink 1.10 的 Hive 集成還引入了許多數據讀取[19]方面的優化，例如：

投影下推：Flink 採用了投影下推技術，經過在掃描表時忽略沒必要要的域，最小化 Flink 和 Hive 表之間的數據傳輸量。這一優化在表的列數較多時尤其有效。
LIMIT 下推：對於包含 LIMIT 語句的查詢，Flink 在全部可能的地方限制返回的數據條數，以下降經過網絡傳輸的數據量。
讀取數據時的 ORC 向量化：爲了提升讀取 ORC 文件的性能，對於 Hive 2.0.0 及以上版本以及非複合數據類型的列，Flink 如今默認使用原生的 ORC 向量化讀取器。

■ 將可插拔模塊做爲 Flink 內置對象（Beta）

Flink 1.10 在 Flink table 核心引入了通用的可插拔模塊機制，目前主要應用於系統內置函數（FLIP-68 [20]）。經過模塊，用戶能夠擴展 Flink 的系統對象，例如像使用 Flink 系統函數同樣使用 Hive 內置函數。新版本中包含一個預先實現好的 HiveModule，可以支持多個 Hive 版本，固然用戶也能夠選擇編寫本身的可插拔模塊 [21]。

其餘 Table API/SQL 優化

■ SQL DDL 中的 watermark 和計算列

Flink 1.10 在 SQL DDL 中增長了針對流處理定義時間屬性及產生 watermark 的語法擴展（FLIP-66 [22]）。這使得用戶能夠在用 DDL 語句建立的表上進行基於時間的操做（例如窗口）以及定義 watermark 策略[23]。

CREATE TABLE table_name (

WATERMARK FOR columnName AS <watermark_strategy_expression>

) WITH (
...
)

■ 其餘 SQL DDL 擴展

Flink 如今嚴格區分臨時/持久、系統/目錄函數（FLIP-57 [24]）。這不只消除了函數引用中的歧義，還帶來了肯定的函數解析順序（例如，當存在命名衝突時，比起目錄函數、持久函數 Flink 會優先使用系統函數、臨時函數）。

在 FLIP-57 的基礎上，咱們擴展了 SQL DDL 的語法，支持建立目錄函數、臨時函數以及臨時系統函數（FLIP-79 [25]）：

CREATE [TEMPORARY|TEMPORARY SYSTEM] FUNCTION

[IF NOT EXISTS] [catalog_name.][db_name.]function_name

AS identifier [LANGUAGE JAVA|SCALA]

關於目前完整的 Flink SQL DDL 支持，請參考最新的文檔[26]。

注：爲了從此正確地處理和保證元對象（表、視圖、函數）上的行爲一致性，Flink 廢棄了 Table API 中的部分對象申明方法，以使留下的方法更加接近標準的 SQL DDL（FLIP-64 [27]）。

■ 批處理完整的 TPC-DS 覆蓋

TPC-DS 是普遍使用的業界標準決策支持 benchmark，用於衡量基於 SQL 的數據處理引擎性能。Flink 1.10 端到端地支持全部 TPC-DS 查詢（FLINK-11491 [28]），標誌着 Flink SQL 引擎已經具有知足現代數據倉庫及其餘相似的處理需求的能力。

PyFlink: 支持原生用戶自定義函數（UDF）

做爲 Flink 全面支持 Python 的第一步，在以前版本中咱們發佈了預覽版的 PyFlink。在新版本中，咱們專一於讓用戶在 Table API/SQL 中註冊並使用自定義函數（UDF，另 UDTF / UDAF 規劃中）（FLIP-58 [29]）。

若是你對這一特性的底層實現（基於 Apache Beam 的可移植框架 [30]）感興趣，請參考 FLIP-58 的 Architecture 章節以及 FLIP-78 [31]。這些數據結構爲支持 Pandas 以及從此將 PyFlink 引入到 DataStream API 奠基了基礎。

從 Flink 1.10 開始，用戶只要執行如下命令就能夠輕鬆地經過 pip 安裝 PyFlink：

pip install apache-flink

更多 PyFlink 規劃中的優化，請參考 FLINK-14500[32]，同時歡迎加入有關用戶需求的討論[33]。

重要變動

FLINK-10725[34]：Flink 如今可使用 Java 11 編譯和運行。
FLINK-15495[35]：SQL 客戶端如今默認使用 Blink planner，向用戶提供最新的特性及優化。Table API 一樣計劃在下個版本中從舊的 planner 切換到 Blink planner，咱們建議用戶如今就開始嘗試和熟悉 Blink planner。
FLINK-13025[36]：新的 Elasticsearch sink connector[37] 全面支持 Elasticsearch 7.x 版本。
FLINK-15115[38]：Kafka 0.8 和 0.9 的 connector 已被標記爲廢棄並再也不主動支持。若是你還在使用這些版本或有其餘相關問題，請經過 @dev 郵件列表聯繫咱們。
FLINK-14516[39]：非基於信用的網絡流控制已被移除，同時移除的還有配置項「taskmanager.network.credit.model」。從此，Flink 將老是使用基於信用的網絡流控制。
FLINK-12122[40]：在 Flink 1.5.0 中，FLIP-6[41] 改變了 slot 在 TaskManager 之間的分佈方式。要想使用此前的調度策略，既儘量將負載分散到全部當前可用的 TaskManager，用戶能夠在 flink-conf.yaml 中設置「cluster.evenly-spread-out-slots: true」。
FLINK-11956[42]：
s3-hadoop 和 s3-presto 文件系統再也不使用類重定位加載方式，而是使用插件方式加載，同時無縫集成全部認證提供者。咱們強烈建議其餘文件系統也只使用插件加載方式，並將陸續移除重定位加載方式。
Flink 1.9 推出了新的 Web UI，同時保留了原來的 Web UI 以備不時之需。截至目前，咱們沒有收到關於新的 UI 存在問題的反饋，所以社區投票決定[43]在 Flink 1.10 中移除舊的 Web UI。

發行說明

準備升級到 Flink 1.10 的用戶，請參考發行說明[44]中的詳細變動及新特性列表。對於標註爲 @Public 的 API，此版本與此前的 1.x 版本 API 兼容。

貢獻者列表

Fink 社區對這次新版本的全部貢獻者表示感謝：

Achyuth Samudrala, Aitozi, Alberto Romero, Alec.Ch, Aleksey Pak, Alexander Fedulov, Alice Yan, Aljoscha Krettek, Aloys, Andrey Zagrebin, Arvid Heise, Benchao Li, Benoit Hanotte, Benoît Paris, Bhagavan Das, Biao Liu, Chesnay Schepler, Congxian Qiu, Cyrille Chépélov, César Soto Valero, David Anderson, David Hrbacek, David Moravek, Dawid Wysakowicz, Dezhi Cai, Dian Fu, Dyana Rose, Eamon Taaffe, Fabian Hueske, Fawad Halim, Fokko Driesprong, Frey Gao, Gabor Gevay, Gao Yun, Gary Yao, GatsbyNewton, GitHub, Grebennikov Roman, GuoWei Ma, Gyula Fora, Haibo Sun, Hao Dang, Henvealf, Hongtao Zhang, HuangXingBo, Hwanju Kim, Igal Shilman, Jacob Sevart, Jark Wu, Jeff Martin, Jeff Yang, Jeff Zhang, Jiangjie (Becket) Qin, Jiayi, Jiayi Liao, Jincheng Sun, Jing Zhang, Jingsong Lee, JingsongLi, Joao Boto, John Lonergan, Kaibo Zhou, Konstantin Knauf, Kostas Kloudas, Kurt Young, Leonard Xu, Ling Wang, Lining Jing, Liupengcheng, LouisXu, Mads Chr. Olesen, Marco Zühlke, Marcos Klein, Matyas Orhidi, Maximilian Bode, Maximilian Michels, Nick Pavlakis, Nico Kruber, Nicolas Deslandes, Pablo Valtuille, Paul Lam, Paul Lin, PengFei Li, Piotr Nowojski, Piotr Przybylski, Piyush Narang, Ricco Chen, Richard Deurwaarder, Robert Metzger, Roman, Roman Grebennikov, Roman Khachatryan, Rong Rong, Rui Li, Ryan Tao, Scott Kidder, Seth Wiesman, Shannon Carey, Shaobin.Ou, Shuo Cheng, Stefan Richter, Stephan Ewen, Steve OU, Steven Wu, Terry Wang, Thesharing, Thomas Weise, Till Rohrmann, Timo Walther, Tony Wei, TsReaper, Tzu-Li (Gordon) Tai, Victor Wong, WangHengwei, Wei Zhong, WeiZhong94, Wind (Jiayi Liao), Xintong Song, XuQianJin-Stars, Xuefu Zhang, Xupingyong, Yadong Xie, Yang Wang, Yangze Guo, Yikun Jiang, Ying, YngwieWang, Yu Li, Yuan Mei, Yun Gao, Yun Tang, Zhanchun Zhang, Zhenghua Gao, Zhijiang, Zhu Zhu, a-suiniaev, azagrebin, beyond1920, biao.liub, blueszheng, bowen.li, caoyingjie, catkint, chendonglin, chenqi, chunpinghe, cyq89051127, danrtsey.wy, dengziming, dianfu, eskabetxe, fanrui, forideal, gentlewang, godfrey he, godfreyhe, haodang, hehuiyuan, hequn8128, hpeter, huangxingbo, huzheng, ifndef-SleePy, jiemotongxue, joe, jrthe42, kevin.cyj, klion26, lamber-ken, libenchao, liketic, lincoln-lil, lining, liuyongvs, liyafan82, lz, mans2singh, mojo, openinx, ouyangwulin, shining-huang, shuai-xu, shuo.cs, stayhsfLee, sunhaibotb, sunjincheng121, tianboxiu, tianchen, tianchen92, tison, tszkitlo40, unknown, vinoyang, vthinkxie, wangpeibin, wangxiaowei, wangxiyuan, wangxlong, wangyang0918, whlwanghailong, xuchao0903, xuyang1706, yanghua, yangjf2019, yongqiang chai, yuzhao.cyz, zentol, zhangzhanchum, zhengcanbin, zhijiang, zhongyong jin, zhuzhu.zz, zjuwangg, zoudaokoulife, 硯田, 謝磊, 張志豪, 曹建華。

參考連接：

原文連接：https://flink.apache.org/news...

相關標籤/搜索