长按二维码关注
大数据领域必关注的公众号
By大数据研习社
概要：Flink1.15重大功能进展：
1.Flink1.15 使Apache Flink运维更简单。
2.Flink1.15使流批一体更完善。
3.Flink1.15使Flink SQL功能更强大。
4.Flink1.15使Apache Flink与云服务交互性更友好。
Apache Flink 的核心概念之一是流批集成。流批融合大大降低了流批融合作业的开发复杂度。在过去的几个版本中，Flink 的流批集成已经逐渐成熟。在 Flink 1.15 中，流批集成更加完善。未来，我们将继续推动这方面的进展。目前大数据处理的趋势之一是越来越多的业务和场景使用低代码的方式进行数据分析，而Flink SQL就是这种低代码的数据分析方式的典型代表。越来越多的用户正在采用 Flink SQL 来实现业务，这也是 Flink 用户和生态快速增长的重要原因之一。作为数据处理生态系统的重要组成部分，Apache Flink 可以与许多其他技术相结合，以支持各种用户场景。在当前的云原生环境中。我们还尽可能将 Flink 与这些系统和各种云基础设施无缝集成。
Flink 1.15让Apache Flink运维更简单：包括不同作业之间Checkpoint和Savepoint的归属清晰，简化Checkpoint和Savepoint生命周期管理；更无缝地支持完全自动缩放；水印对齐，以消除因数据源速率不同等导致的多个问题。
Flink 1.15 使得流和批处理的整合更加完善：在部分作业完成后继续完善Checkpoint操作；支持批处理模式下的Window表值函数，在流-批混合的场景下使用更方便。
Flink 1.15 让Flink SQL 更加强大：包括升级SQL 作业而不丢失状态的能力；添加对 JSON 相关函数的支持，以简化数据输入和输出操作。
Flink 1.15 使 Apache Flink 与云服务的交互性更强：Flink 作为整个数据处理生态系统的一部分，1.15 版本进一步提高了与云服务的互操作性，并增加了更多的 sink 连接器和数据格式。最后，我们在运行时移除了对 Scala 的依赖。
1.使Apache Flink运维更简单
长期来看，即使是由最好的工程团队来进行构建和调优，Flink 作业仍然依赖运维操作。Flink 支持多种不同的部署模式、API、调优配置与用例，这意味着运维工作至关重要并且可能十分繁重。
在这个版本中，我们听取了用户的反馈，对 Flink 的运维操作进行了简化，使用户能够更加轻松的进行运维。现在 Flink 明确了 Checkpoint 与 Savepoint 在不同作业之间的所属权；更加无缝支持完整的自动伸缩；通过 Watermark 对齐消除多个数据源产出速率不同带来的问题，并且初步支持了在不丢失状态的情况下升级 SQL 作业的能力。
1.1 明确 Checkpoint 与 Savepoint 语义
Flink 容错策略的两个重要的基本概念是 Checkpoint 和 Savepoint。
Savepoint的主要功能是支持作业修改、备份、升级等场景，完全由用户控制。另一方面，检查点完全由 Flink 控制，用于通过支持快速恢复和重启来实现容错。这两个概念非常相似，它们共享很大一部分实现。
但是，由于遵循不同的功能需求，这两个概念逐渐变得不一致，让用户觉得没有完整的顶层设计。 根据用户反馈，这两个概念应该更好地对齐和协调，最重要的是，这两个概念应该更清晰地定义。
在一些作业停止或重启的场景下，虽然在逻辑上应该使用 Savepoints，但用户仍然选择使用持久化 Checkpoints，因为 Savepoints 无法享受到 Checkpoints 可以使用的一些优化，导致执行缓慢。但是在这种情况下，当作业从一个持久的 Checkpoint 重新启动时（在这种情况下，Checkpoint 实际上是作为 Savepoint 使用的），用户不太清楚 Checkpoint 中的数据何时可以被清理。
因此，在 FLIP-193：State Ownership 中，Flink 希望将 Savepoint 和 Checkpoint 抽象为两个概念，唯一的区别是所有权。在 1.15 中，通过支持原生的增量保存点，Flink 解决了保存点的一些缺点：在过去的版本中，保存点总是使用标准格式和非增量方式，这也是其性能不佳的原因。在 1.15 中，如果用户选择使用原生格式并且还使用 RocksDB 状态存储，则将增量执行保存点。我们还更新了相关文档，以更好地概述和理解 Checkpoint 和 Savepoint 之间的区别。此外，我们明确介绍了两种模式，CLAIM 和 NO_CLAIM，关于从 Savepoint/Persistent Checkpoint 恢复的语义。对于 CLAIM 模式，Flink 将接管快照中数据的所有权，而对于 NO_CLAIM 模式，Flink 将创建自己的副本，由用户负责管理和删除原始数据。请注意，现在将默认使用 NO_CLAIM 模式，可以通过指定 LEGACY 模式来恢复以前版本中从 Savepoint Persistent Checkpoint 恢复的行为。
1.2 提高Flink作业的弹性伸缩
随着越来越多的云服务建立在 Apache Flink 之上，Flink 项目也越来越云原生，这使得弹性伸缩变得越来越重要。
此版本改进了反应模式的指标。 Reactive 模式是 JobManager 将尝试使用 TaskManager 上所有可用资源的作业级模式。在 1.15 中，我们确保作业级指标在反应模式下也能正常工作。
我们还向自适应调度程序添加了异常历史记录。 自适应调度器是一种新的调度器，它首先声明需要的资源，并在执行前根据资源条件确定资源的并行度。
此外，Flink 还提高了缩减作业的速度：TaskManager 现在有一个专门的代码路径来关闭自己，它会主动从集群中注销自己而不是依赖心跳，给 JobManager 一个明确的缩减作业的信号。
1.3 引入Watermark 对齐的能力
如果在一个作业中使用多个数据源节点，并且这些数据源以不同的节奏增长 Watermark，这可能会在下游节点中产生一些问题。例如，一些算子可能需要缓存非常大量的数据，导致算子状态巨大。因此，我们在此版本中引入了对齐水印的功能。
基于新的 Source 接口实现的数据源节点可以启用 Watermark 对齐。用户可以定义对齐组，并且如果与其他节点相比，其中一个源节点距离水印太远，用户可以暂停使用来自该节点的数据。对齐水印的理想情况是当有两个或多个数据源节点以不同的速率产生水印，并且数据源节点与外部系统同时具有相同数量的分片时。
1.4 降低作业恢复复杂度
在 Application 模式下运行 Flink 时，如果用户进行了配置，现在可以保证作业在结束前可以正常完成 stop-with-savepoint 操作。
在应用程序模式下运行的作业的恢复和清理也得到了改进。 本地状态元数据也可以保存在工作目录中，这样更容易从本地状态恢复（例如在非易失性跨机存储中设置工作目录的情况下，之前的本地状态元数据在 保存在内存中），因此在工作恢复时无法检索）。
1.5 提高SQL 版本升级的兼容性
SQL 查询的执行计划及其生成的拓扑是通过优化规则和基于成本的模型得出的，这意味着即使是最小的更改也可能导致完全不同的拓扑。这种动态使得确保跨 Flink 版本的快照兼容性变得非常具有挑战性。在 1.15 中，社区首先在 Flink 版本升级后，保持拓扑不变，启动和执行相同的查询。
SQL升级的核心是JSON计划（即用JSON表示的查询执行计划，我们目前只有JavaDocs的文档，还在努力更新文档），JSON Plan允许导入SQL计划 并以结构化数据的形式导出，之前这个功能是内部实现，现在会暴露给用户。 Table API 和 SQL 都提供了一种编译和执行执行计划的方法，该执行计划保证跨版本保持不变。此功能将作为实验性 MVP 功能发布。想要尝试它的用户已经可以创建一个 JSON 计划，然后可以用于在升级后基于旧的 operator 结构恢复 Flink 作业。我们将在 1.16 中对该功能提供全面支持。
从长远来看，可靠的升级让 Flink SQL 在在线生产场景中的使用更加可靠。
1.6 提供REST API规范
Flink 现在提供遵循 Open API标准的 REST API 规范。这允许 REST API 与遵循 Open API 标准的工具直接交互。
1.7 引入自适应批调度器
在 1.15 中，我们为 Apache Flink 引入了一个新的自适应批处理调度器。这个调度器可以根据每个节点需要处理的数据量，自动确定批处理作业中每个节点的并行度。
该调度程序的主要优点包括：
易用性：批处理作业的用户不再需要手动调优并行度。
自适应：自动调整并行度，可以更好地适应节点消费数据集随时间的变化。
细粒度：每个作业节点的并行度可以单独调整。 这允许 SQL 批处理作业的节点自动为每个节点单独选择最合适的并行度。
1.8 引入基于Changelog的状态存储
l 更短的端到端延迟：端到端延迟主要取决于Checkpoint机制，特别是在使用支持端到端一致性的两阶段提交的sink节点的情况下。在这种情况下，缩短检查点周期意味着快速提交数据。
l 更可预测的Checkpoint间隔：目前Checkpoint的完成时间很大程度上取决于Checkpoint需要保存的数据大小。通过保持这些数据较小，检查点完成时间变得更加可预测。
l 恢复工作少：检查点越频繁，每次重启后重新处理的数据就越少。
l 基于Changelog的状态存储通过在后台不断上传状态变化的记录到非易失性存储来实现上述目标。
1.9 允许重复清理残留数据
在之前的 Flink 版本中，Flink 仅在作业结束时尝试清理一次残留的作业相关数据，这样可能会在发生错误时阻止清理完成。在此版本中，Flink 将尝试重复运行清理以避免残留数据。默认情况下，Flink 会不断重试该机制，直到运行成功。用户可以通过配置相关参数来改变这种行为。禁用重试策略会恢复 Flink 之前版本的行为。
清理检查点的工作仍在进行中，包括 FLINK-26606。
2.使Apache Flink流批一体更完善
在Flink1.15版本中，我们对流批一体的支持进行了进一步的完善。
2.1 增加Window table-valued 函数对批处理支持
窗口表值函数以前仅在流模式下可用。 在 1.15 中，它们现在也可以在批处理模式下使用。此外，通过实现专门的运算符，我们现在不再需要这些 Window 函数必须定义聚合器，从而进一步增强了 Window 表值函数。
2.2 默认开启作业结束前的Checkpoint
在 Flink 1.14 中，增加了在作业结束前等待 Checkpoint 操作的支持，以确保使用流模式处理有限的数据确保所有数据都提交，但在 1.14 中，必须手动启用此功能。自上次发布以来，我们听取了用户反馈并决定默认启用它。需要注意的是，在使用流模式处理有界数据时，此默认配置更改可能会延长执行时间，因为作业必须等待下一个检查点完成才能结束。
3.使Flink SQL的功能进一步改进
社区指标显示 Flink SQL 被广泛使用并变得越来越流行。社区还在 1.15 中对 Flink SQL 进行了许多改进，其中两个将在下面更详细地讨论。
3.1 丰富了JSON 处理函数
JSON 是最流行的数据格式之一，越来越多的 SQL 用户需要生成或读取 JSON 类型的数据。 Flink 1.15 根据 SQL 2016 标准引入了几个 JSON 处理函数。这些函数允许用户使用 Flink SQL 方言检查、创建和修改 JSON 字符串。
3.2 CAST的错误修正与功能改进
数据有多种形式，但并非在所有情况下都是用户需要的类型，因此 CAST 是 SQL 中最常见的操作之一。在 Flink 1.15 中，失败的 CAST 的默认行为已从返回 null 更改为返回错误，使其更加符合 SQL。之前的行为可以通过调用新引入的TRY_CAST函数或者恢复时配置相应的参数来实现。
此外，Flink 1.15 还修复了许多 CAST 的 bug，并改进了其功能，以确保结果的正确性。
4.使Apache Flink社区支持更强大
Flink 的一个重要目标是让用户能够构建流数据管道来解决他们的用例。一般来说，Apache Flink 并不是单独使用的，而是作为一个更大的数据分析平台的重要组成部分。因此，简化 Flink 在云环境中的使用和维护，支持与其他系统的无缝连接，持续支持 Java、Python 等编程语言，对于完善 Flink 生态非常重要。
4.1 Elasticsearch Sink提供异步输出与端到端一致性
我们在 Flink 的整个连接器生态系统上做了很多工作，但是我们想强调一下 Elasticsearch Sink：它是基于最新的 Sink API 实现的，因此它可以提供异步输出和端到端的一致性。它可以用作将来更多接收器实现的模板。
4.2 PyFlink引入线程模式
在 Flink 1.15 之前，Python API 中的用户定义函数在单独的 Python 进程中执行，这会产生额外的序列化/反序列化和进程通信开销。在具有大数据的场景中，例如图像处理，这种开销变得不可忽略。此外，由于它涉及进程间通信，因此这种处理延迟也是不可忽略的。这些问题在延迟至关重要的场景中是不可接受的，例如量化交易。因此，在 Flink 1.15 中，我们引入了“线程”模式的新执行模式：用户定义的函数将在 JVM 中作为线程执行，而不是在单独的 Python 进程中执行。基准测试表明，在 JSON 处理等常见场景中，吞吐量可以提高 2 倍，处理延迟范围从秒到微秒。需要指出的是，由于这仍然是“线程”模式的第一个版本，之前它只支持 Python Table API 和 SQL 中的标量函数。我们计划在下一个版本中将其扩展到 Python API 中的其他类型的自定义函数。
4.3 删除Scala版本依赖
官网解释了为什么 Scala 用户现在可以在任何 Scala 版本（包括 Scala 3）上使用 Flink 的 Java API。最后，移除 Scala 依赖只是从 Flink 生态系统中清理和更新各种技术的更大努力的一部分。从 Flink 1.14 开始，我们移除了 Mesos 集成，隔离了 Akka，弃用了 DataSet Java API，并将 Table API 隐藏在抽象之后。这些社区的努力也引起了许多用户和贡献者的关注。
4.4 增加云环境互操作性
许多用户在不同云服务提供商提供的云基础设施中部署和使用 Flink，也有一些服务可以帮助用户管理部署在其平台上的 Flink 集群。
在 Flink 1.15 中，我们添加了对写入 Google Cloud Storage 的支持。我们还整理了 Flink 生态中的连接器，重点支持 AWS 相关的生态。
5.Apache Flink其他功能完善与改进
Flink 1.15 进一步完善了对连接器测试框架的支持，如果你想贡献一个连接器或改进一个连接器，你一定要看看这部分工作。 Flink 1.15 还增加了一些期待已久的功能，包括 CSV 格式和小文件压缩。同时，Sink API 升级到第 2 版。我们鼓励每个连接器的维护者升级到此版本。
欢迎点赞 + 收藏 + 在看 素质三连 完
▼ 往期精彩回顾 ▼ 程序员，如何避免内卷 Apache 架构师总结的 30 条架构原则 【全网首发】Hadoop 3.0分布式集群安装 大数据运维工程师经典面试题汇总(附带答案) 大数据面试130题 某集团大数据平台整体架构及实施方案完整目录 大数据凉凉了？Apache将一众大数据开源项目束之高阁！ 实战企业数据湖，抢先数仓新玩法 Superset制作智慧数据大屏，看它就够了 Apache Flink 在快手的过去、现在和未来 华为云-基于Ambari构建大数据平台（上） 华为云-基于Ambari构建大数据平台（下） 【HBase调优】Hbase万亿级存储性能优化总结 【Python精华】100个Python练手小程序 【HBase企业应用开发】工作中自己总结的Hbase笔记，非常全面！ 【剑指Offer】近50个常见算法面试题的Java实现代码
