翻译 | 高赟

• 1.15 版本的一大看点是改进了运维 Apache Flink 的体验：包括明确 Checkpoint 和 Savepoint 在不同作业之间的所属权，简化 Checkpoint 和 Savepoint 生命周期管理；更加无缝支持完整的自动伸缩；通过 Watermark 对齐来消除多个数据源速率不同带来的问题等
• 1.15 版本中，Flink 进一步完善流批一体的体验：继续完善部分作业完成后的 Checkpoint 操作；支持批模式下的 Window table-valued 函数，并且使其在流批混合的场景下更加易用。
• Flink SQL 的进阶：包括能够在不丢失状态的情况下升级 SQL 作业；添加了对 JSON 相关函数的支持来简化数据的输入与输出操作。
• Flink 作为整个数据处理生态中的一环，1.15 版本进一步提升了与云服务的交互操作性，并且添加了更多的 Sink 连接器与数据格式。最后，我们在运行时中去除了对 Scala 的依赖^[2]。

Flink 容错策略的两个重要基础概念是 Checkpoint^[3] 与 Savepoint^[4] (参见比较^[5])。

Savepoint 的主要作用是支持作业修改、备份与升级等场景，它是由用户来完全控制的。而另一方面，Checkpoint 由 Flink 完全控制，用于通过支持快速恢复与重启来实现容错的能力。这两个概念十分相似，并且它们共享了很大一部分实现。

然而，由于遵循不同的功能要求，这两个概念逐渐变得不一致，使用户看起来没有完整的顶层设计。根据用户反馈，这两个概念应该被更好地对齐和协调，最重要的是，这两个概念应该被更清晰的定义。

在某些停止或重新启动作业的场景下，虽然逻辑上应该使用 Savepoint，但用户还是会选择使用持久化的 Checkpoint，因为 Savepoint 无法享受 Checkpoint 可以使用的一些优化而导致执行较为缓慢。但是在这种情况下，作业从持久化的 Checkpoint 重启时 (这种情况下 Checkpoint 实际上被当作 Savepoint 来使用)，对用户来说何时可以清理 Checkpoint 中的数据并不十分清楚。

因此，在 FLIP-193: 状态所属权^[6] 中，Flink 希望可以将 Savepoint 和 Checkpoint 抽像成唯一区别是所属权不同的两个概念。在 1.15 中，通过支持原生的增量 Savepoint^[7]，Flink 解决了 Savepoint 的一些不足：在过去的版本中，Savepoint 总是使用标准格式以及非增量的方式，这也是导致它性能较差的原因。在 1.15 中，如果用户选择使用原生格式并且同时使用了 RocksDB 状态存储，那么 Savepoint 将采用增量的方式来执行。我们也更新了相关文档来更好的概览与理解 Checkpoint 与 Savepoint 的差异。此外，关于从 Savepoint / 持久化的 Checkpoint 恢复^[8] 的语义，我们显式的引入了 CLAIM 与 NO_CLAIM 两种模式。对于 CLAIM 模式 Flink 将接管快照中数据的所属权，而对于 NO_CLAIM 模式，Flink 将创建它自己的副本，而由用户来负责管理与删除原始的数据。注意现在默认将采用 NO_CLAIM 模式，之前版本中从 Savepoint / 持久化的 Checkpoint 恢复的行为可以通过指定 LEGACY 模式来恢复。

基于 Reactive 模式与自适应调度器的弹性伸缩

由于越来越多的云服务基于 Apache Flink 构建 ，Flink 项目变得越来越云原生，这使得弹性伸缩也越来越重要。

此版本改进了 Reactive 模式^[9] 的指标。Reactive 模式是一个作业级别的模式，在这种模式下， JobManager 将尝试使用所有可用的 TaskManager 上的资源。我们在 1.15 中保证了作业级别的指标在 Reactive 模式下也可以正常的工作。

我们还为自适应调度器^[10] 添加了异常历史记录。自适应调度器是一个新的调度器，它首先声明了所需的资源并且根据根据资源情况在执行前决定资源的并行度。

此外，Flink 提高了缩减作业规模的速度：TaskManager 现在有一个专用代码路径来关闭自己，它会主动从集群中注销自己而不是依赖于心跳，从而给 JobManager 一个明确的缩减作业规模的信号。

自适应批调度器

在 1.15 中，我们为 Apache Flink 引入了一个新的自适应批处理调度器^[11]。这一调度器可以自动根据每个节点需要处理的数据量的大小自动决定批处理作业中各节点的并行度。

此调度器的主要优点包括：

1. 易用性：批处理作业的用户不再需要手动调优并行度。
2. 自适应：自动调整并行度可以更好地适应节点消费数据集随时间发生变化的情况。
3. 细粒度：每个作业节点的并行度可以单独调整。这允许 SQL 批处理作业的节点自动为每个节点选择单独选择最适合的并行度。

跨源节点的 Watermark 对齐

SQL 版本升级

SQL 查询的执行计划及其生成的拓扑是通过优化规则和一个基于成本的模型来得到的，这意味着即使最小的更改也可能会产生一个完全不同的拓扑。这种动态性使得在不同 Flink 版本间保证快照兼容性非常具有挑战性。在 1.15 中，社区首先通过保持拓扑不变的方式使相同的查询在升级 Flink 版本后仍然可以启动和执行。

在 Flink 1.15 中，我们引入了 MVP 特性：基于 Changelog 的状态存储^[14]。这一新的状态存储旨在支持更短、更可以预测的 Checkpoint 间隔。它具有以下优势：

1. 更短的端到端延迟：端到端延迟主要取决于 Checkpoint 机制，特别是使用了两阶段提交的支持端到端一致性的 Sink 节点的情况，这种情况下缩短 Checkpoint 周期意味着可以更快的提交数据。
2. 更可预测的 Checkpoint 间隔：目前 Checkpoint 的完成时间很大程度上取决于需要保存在 Checkpoint 中的数据的大小。通过使这一数据总是可以很小，Checkpoint 的完成时间变得更加可以预测。
3. 恢复工作更少：Checkpoint 越频繁，每次重启后重新处理的数据也会越少。

在以前的 Flink 版本中，Flink 在作业结束时只尝试清理一次与作业相关的残留数据，这可能会导致在发生错误时无法完成清理。在这个版本中，Flink 将尝试重复运行清理以避免残留数据。默认情况下，Flink 将不断重试机制，直到运行成功为止。用户可以通过配置相关参数^[15] 来改变这种行为。禁用重试策略可以恢复 Flink 之前版本的行为。

Flink 现在提供遵循 Open API^[17] 标准的 REST API 规范。这允许 REST API 与遵循 Open API 标准的工具直接交互。您可以在 [18] 找到相应规范。

在 Application 模式^[19] 下运行 Flink 时，如果用户进行了相关配置^[20]，它现在可以保证作业在结束前能够正常完成 stop-with-savepoint 操作。

在最新版本中，我们对流批一体的支持进行了进一步的完善。

在 Flink 1.14 中，添加了对作业结束前等待一次 Checkpoint 操作的支持，从而保证使用流模式处理有限数据可以保证所有被据被提交，但是在 1.14 中，该功能必须被手动启用。自上次发布以来，我们听取了用户反馈并决定默认启用它。关于这一功能的更多信息以及如何禁用此功能，请参阅 [21]。需要指出的是，这一默认配置的变化可能延长使用流模式处理有界数据时的执行时间，因为作业必须在结束前等待下一个 Checkpoint 完成。

Window table-valued 函数^[22] 之前仅可用于流模式下。在 1.15 中，它们现在也可以在批模式下使用。此外，通过实现一个专门的算子，我们现在不再要求这些 Window 函数必须定义一个聚合器，从而进一步增强了 Window table-valued 函数。

社区指标表明 Flink SQL 被广泛使用并且变得越来越流行。在 1.15 中社区对 Flink SQL 也做了许多改进，下文将更加详细地讨论其中两个改进。

Flink 的一个重要目标是使用户能够构建流数据管道来解决他们的用例。一般来说，Apache Flink 不会单独使用，而是作为更大的数据分析平台中的重要一环。因此，简化 Flink 在云环境下的使用与维护、支持无缝连接到其他系统并继续支持 Java 和 Python 等编程语言对完善 Flink 生态十分重要。

Flink 1.15 进一步完善了对于连接器测试框架^[29] 的支持，如果你想贡献一个连接器或改进一个连接器，你绝对应该看一下这部分工作。

原文链接：

https://flink.apache.org/news/2022/05/05/1.15-announcement.html

贡献者列表