关于后端:深入解读-Flink-117

摘要：本文整顿自阿里云技术专家，Apache Flink PMC Member & Committer、Flink CDC Maintainer 徐榜江(雪尽) 在深刻解读 Flink 1.17 的分享。内容次要分为四个局部：

1. Flink 1.17 Overview
2. Flink 1.17 Overall Story
3. Flink 1.17 Key Features
4. Summary

查看直播回放

一、Flink 1.17 Overview

Flink 1.17 版本实现了 7 个 FLIP，累计贡献者 170+，解决 600+Issue 以及 1100+Commits，整体来看是一个较大的版本。

从 Issue 散布来看，1.17 版本次要在 Runtime 层面以及 Table 层面做了较多改良，其中 Runtime 层面约 170+Issue，Table 层面约 120 个。另外，在 Checkpoint & State、API、Connector 层面也做了诸多晋升与改良。

1.17 版本实现的 FLIP 如上图所示，别离为：

• FLIP-256：扩大了 Rest API 反对提交作业时指定参数，与 Flink CLI 根本对齐。
• FLIP-265：将 Scala 的 API 反对标记为 deprecated, Flink 里的 API 有 Scala 与 Java 两套, 随着社区的一直倒退与演进，Scala API 呈现了各种问题，比方 Scala 版本升级艰难，在 Flink 1.15 里，从 Scala 2.12.7 降级到 2.12.15 必须做出兼容性毁坏的革新；另一方面，Java API 比 Scala API 在社区演进更快一些，前者的 Feature 会更多; 再加之社区比拟短少相熟 Scala 技术栈的 Contributor，因而社区决定将 Scala 的 API 缓缓移除，更专一于 Java API。
• FLIP-266：对 TM 的网络层配置做了很多简化，新增了多个外围个性，进步了 Runtime 层面网络的开箱即用，用户做更少的配置即可取得较好的作业优化成果。
• FLIP-280：在 SQL 层面引入了 PLAN ADVICE 性能，帮忙用户查看 PLAN 的正确性以及对 SQL 做优化，比方聚合是否应该拆分、非确定性的列导致不正确性的问题等，并提醒用户改写和优化 SQL。
• FLIP-281：Sink 对于 Batch 作业反对了预测执行。预测执行次要分为三个 FLIP 来逐渐实现，第一个 FLIP 反对作业链路中除 Source、Sink 之外的算子，第二个 FLIP 反对了 Source 算子，FLIP-281 是最初一个 FLIP，反对了 Sink 算子。Sink 算子比拟非凡，在 Flink 作业的拓扑里，它会 flush 数据到内部零碎，须要写入数据，多个 Task 协同内部零碎的执行对于数据的一致性会带来较大挑战。而 FLIP-281 反对了 Sink 的预测执行之后，Batch 作业的全链路都反对了预测执行。
• FLIP-282：引入了 Delete 和 Update API。在 Flink 从 Streaming Processing 到 Streaming Warehouse 的演进中，须要为 Streaming Warehouse 定制一些 API，比方行级数据的 Delete 与 Update API，不便与其余 Connector 的对接。
• FLIP-283：将自适应的 Batch 调度器作为默认调度器。之前的 1.16 版本曾经推出 Adaptive Batch Scheduler，但它不是默认调度器，而 1.17 版本将设置为默认调度器。

二、Flink 1.17 Overall Story

Flink 1.17 版本向 Streaming Warehouse 迈进了一大步。

如图所示，Flink 在从 Streaming Processing 到 Streaming Warehouse 迈进后，咱们不再须要批处理的链路，也不必拆分流解决的链路，批处理和流解决链路是对立的、流批一体的。

数据在数仓的每一层之间都通过 Flink 进行实时的流动，并且每一层数据实时可查，能够通过其余引擎查问湖存储里的数据，湖存储能够是 Paimon（从 Flink Table Store 子项目孵化出的 Apache 我的项目），也能够是 Hudi 等，提供了真正的流式服务。

该架构的劣势在于，不再须要两套零碎，架构更简洁。同时，将离线与实时整合在一起，只需一份存储，老本更低，通过 Flink SQL 流批一体的引擎做加工，语义和数据均可保持一致。垂直方向上，每一层数据实时可查，架构通明凋谢。

为了更好地向流式数仓迈进，咱们在 Batch 方面做了很多加强。

• Streaming Warehouse：引入了 Delete 与 Update API，同时提供了 add/modify/drop 列，主键以及 Watermark 语法。
• Batch 性能优化块：预测执行、自适应 Batch 调度器、混合 Shuffle 模式以及 Join-reorder 算法。
• 提交工具：SQL Client 反对了 Gateway 模式，反对通过 SQL 语句治理 Flink 作业。

Streaming 性能也在一直演进。

• Streaming SQL 语义加强：修复了非确定性操作导致的 PLAN 谬误，引入了 PLAN ADVICE 提供 SQL 的优化倡议以及谬误的 warning，欠缺了 Watermark 对齐。
• Checkpoint 改良：提出通用的增量 Checkpoint，次要实现了速度以及稳定性的晋升。同时，Unaligned Checkpoint 实现了生产可用。
• Statebackend 降级：将 FRocksDB 的版本做了降级，带来了更多 Feature，反对 Apple 的芯片组，比方 Mac M1。

三、Flink 1.17 Key Features

咱们对 Batch 做了端到端的性能优化，涵盖了 SQL 的 PLAN、Runtime 算子、调度全流程。

• Runtime 的预测执行：反对了 Sink 算子，同时改良了慢工作的检测，之前只思考慢工作的执行工夫，当初还思考数据量。
• 自适应 Batch 调度器：将自适应调度器作为默认调度器。调度器能够依据每个 Job 和节点解决的数据量主动设置并发，更智能。另外，做了配置简化，晋升整体的易用性。
• 混合 Shuffle：混合 Shuffle 是一种联合了 blocking 与 pipeline 长处提出的新的 Shuffle 模式。在 1.17 版本里反对了自定义 Batch 调度器、预测执行，同时反对重用两头数据，晋升性能。另外，混合 Shuffle 模式在大规模生产环境下的稳定性失去进一步晋升。
• SQL 层面的优化：Planner 引入了动静布局的的 Join-reorder 算法，之前的 Join-reorder 算法优化出的 PLAN 树相当于是一棵偏左树，并发解决往往只有两路；而动静布局的 Join-reorder 算会使得 PLAN 树更均衡，并发也更高。在算子层面做了动静 local hash 聚合优化，通过 code 键实现，比方 count 聚合时，数据比拟稠密处能够间接跳过聚合，晋升性能。同时，在算子上打消了局部虚函数的调用，使得性能进一步晋升。

通过上述各层的优化，Flink 1.17 整体相比 Flink 1.16 的 TPC-DS 性能晋升 26%。

Flink 1.16 耗时靠近 7000 秒，1.17 降为 5000+ 秒。上图可见，局部 Query 的性能晋升非常显著，比方 Q58 从 150+ 秒升高至几十秒。

另外，咱们对 Checkpoint 和 State 也做了很多改良。

比方通用增量 Checkpoint（GIC）速度方面有了很大晋升，在开启通用增量 Checkpoint 后，WordCount 与 Window 作业性能晋升了 4.23 倍与 38.39 倍，WordCount 实现工夫有靠近 90% 的缩小，Window 作业的 Checkpoint 耗时从 130s 降至 1.58s。

对于流作业而言，开启通用增量 Checkpoint 后，速度和稳定性都失去了质的晋升。

另外，咱们对 GIC 的稳定性也做了晋升。如上图所示，红线代表开启了通用增量 Checkpoint 的耗时，耗时更短，毛刺更少，这阐明 WordCount 与 Window 作业的稳定性均有显著晋升。而如果不开启通用增量 Checkpoint，Window 的作业耗时可高达 400s，且极不稳固。

用户写了一个 SQL Query 之后，可能在这个 Query 里有双流 Join，有聚合，有维表关联等等。那么，如何判断一个 Query 是否有问题呢？

为此，咱们提供了 PLAN ADVICE 性能，在执行 Explain 语句时候反对 PLAN_ADVICE 选项。比方，在执行 Query 之前能够先做一次 Explain，失去一些倡议。

如上图，告警信息提醒 current_timestamp 是一个非确定性函数，源表的数据是 Changelog 流，因为源表和后果表的主键不统一，会生成一个 SinkUpsertMaterializer 算子来在 state 中物化输出并输入正确的后果给 Sink，但 SinkUpsertMaterializer 节点要求输出不能有非确定性更新，用户应用 PLAN_ADVIC 就会取得对应的倡议，防止这类正确性问题。此外，社区也在打算让 SinkUpsertMaterializer 反对 upsertKey 模式，在后续的版本中能够在框架侧解决这个问题。

除了 PLAN 正确性倡议，PLAN_ADVIC 也会提供 SQL 优化倡议。如上图所示，PLAN_ADVIC 倡议开启 local global 两阶段聚合来晋升 SQL 的性能。

作业监控方面，Flink 1.17 将火焰图细化至 Task 级别，这对线上作业调优、问题定位提供了更多帮忙，比方能够查看每个 Task 线程的耗时散布明细等。

四、Summary

总体来说，Flink 1.17 的工作次要蕴含以下五个方面：

1. 为了更好地迈向 Streaming Warehouse，陆续提出了相干 Streaming Warehouse API。
2. 对 Batch 重点优化了性能以及晋升稳定性。
3. 对 Streaming SQL 的语义做了加强与欠缺。
4. Checkpoint 的速度与稳定性都有了进一步晋升。
5. 对 SQL Client 以及 Gateway 工具做了进一步扩大。

Flink 1.18 的工作曾经开启，Feature Freeze 预计在 7 月 11 号，Release 预计在 9 月底。用户能够点击此处，关注具体的 Feature 与 FLIP 停顿。

Flink 1.18 的重点工作将会从以下四个方向开展：

1. Streaming Warehouse API 补齐。
2. Batch 性能的优化以及生态的扩大。
3. Streaming SQL 的语义以及易用性改良。
4. 存算拆散的 Checkpoint 的架构演进。

Q&A

Q：Flink CDC 反对 Delta Lake 吗?

A：Flink CDC 次要是 Source，Delta Lake 是 Sink 写入，CDC 捕捉的数据能够写入到 Flink 反对的上游，Delta Lake 也是能够的。

Q：新版本在批处理性能上的优化，场景利用上能够有哪些晋升？

A：都是普适的性能优化，可能晋升 Batch 作业的性能和稳定性。

Q：实时大宽表实现有办法吗？比方十个流的 Join，无工夫窗口。

A：能够做多流 Join 配合各个流的更新策略配置不同的 State TTL。

Q：Flink 反对 es 跟 clickhouse 嘛？

A：反对这两种数据源的。

Q：事实表 Left Join 多个维度表的时候，有没有什么无效的优化能够缩小 State 大小和升高 Latency？

A：SQL 优化比方过滤前移，设置算子级别的 State TTL（1.18 会反对）。

Q：codegen 都用在哪些场景的优化上了？

A：一些 SQL 算子，UDF，SQL 表达式都用到了 codegen 技术

Q：Flink 资源动静扩缩能够用嘛？比方顶峰多用资源，低峰主动把资源还 yarn。

A：能够理解下 Flink 的 K8s operator。

查看直播回放

更多内容

流动举荐
阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：0 元试用 
实时计算 Flink 版（5000CU* 小时，3 个月内）理解流动详情：https://click.aliyun.com/m/1000372333/