Apache Flink 1.15详解
问题导读：
1、Apache Flink 1.15 有哪些新特性？
2、Apache Flink 1.15 怎样实现弹性扩展？
3、Apache Flink 1.15 在检查点方面有哪些改进？
得益于我们组织良好且开放的社区，Apache Flink 作为一项技术不断 发展壮大，并且仍然是 Apache 社区中最活跃的项目之一。随着 Flink 1.15 的发布，我们很自豪地宣布了一些令人兴奋的变化。
使 Apache Flink 脱颖而出的主要概念之一是批处理（又名有界）和流（又名无界）数据处理的统一，这有助于降低开发的复杂性。在之前的版本中，我们在这个统一方面付出了很多努力，您可以期待在这个方向上做出更多努力。
Apache Flink 不仅在贡献和用户方面不断增长，而且在原始用例之外也有所增长。我们看到了以低代码/无代码实现更多业务/分析用例的趋势。Flink SQL 是 Flink 生态系统中支持此类用例的功能，这也是其受欢迎程度持续增长的原因。
Apache Flink 是数据管道/架构中必不可少的构建块，并与许多其他技术一起使用以驱动各种用例。尽管该领域可能会出现新的想法/产品，但现有技术继续将自己确立为解决关键任务问题的标准。知道我们拥有如此广泛的影响力并在许多项目的成功中发挥了作用，因此将 Apache Flink 与云基础设施和现有系统集成的体验尽可能无缝和容易是很重要的。
在 1.15 版本中，Apache Flink 社区在所有这些领域都取得了重大进展。尽管如此，这些并不是使其成为 1.15 的唯一因素。贡献者改进了操作 Apache Flink 的体验，使处理检查点和保存点及其所有权变得更加容易和透明，通过消除不同数据源产生不同数量数据，以及 - 最后 - 在不丢失状态的情况下升级 SQL 作业的能力。通过在任务完成后继续支持检查点并在批处理模式下添加窗口表值函数，统一流和批处理的体验再次得到改善，使混合用例变得更加容易。在 SQL 空间中，不仅增加了版本升级的第一步，还增加了 JSON 函数，以便更轻松地导入和导出 SQL 中的结构化数据。从长远来看，两者都将允许用户更好地依赖 Flink SQL 进行生产用例。为了将 Apache Flink 建立为数据处理生态系统的一部分，我们改进了云互操作性并添加了更多sink连接器和格式。是的，我们启用了Scala-free的 运行时。
轻松操作 Apache Flink
即使是由最好的工程团队构建和调优的 Flink 作业仍然需要维护，通常是长期的。Apache Flink 涵盖的许多部署模式、API、可调配置和用例意味着维护支持至关重要，而且可能很繁重。
在这个版本中，我们听取了用户的反馈，现在操作 Flink 变得更加容易。它现在在处理检查点和保存点及其所有权方面更加透明，这使得自动缩放更加无缝和完整（通过消除不同数据源产生不同数据量的用例的副作用）并能够
升级 SQL在不丢失状态的情况下工作。
澄清检查点和保存点语义
Flink 容错策略的一个重要基石是基于 检查点和 保存点（参见比较）。保存点的目的一直是将 Flink 作业的转换、备份和升级置于用户的控制之下。另一方面，检查点旨在完全由 Flink 控制，并通过快速恢复、故障转移等来保证容错。这两个概念非常相似，底层实现也有相同的想法。
然而，这两个概念通过遵循特定的功能要求并有时忽略了总体思想和策略而分开了。根据用户反馈，很明显这应该更好地对齐和协调，最重要的是，要更清楚！
在某些情况下，用户依赖检查点来停止/重新启动作业，而保存点本来是正确的选择。还不清楚保存点是否较慢，因为它们不包含使获取检查点如此之快的某些功能。在某些情况下，例如从保留的检查点恢复 - 其中检查点以某种方式被视为保存点 - 用户不清楚他们何时可以实际清理它。
通过FLIP-193（快照所有权） ，社区旨在使所有权成为保存点和检查点之间的唯一区别。在 1.15 版本中，社区通过支持原生和增量保存点修复了其中的一些缺点 。保存点总是使用使它们变慢的规范格式。同样，编写完整的保存点肯定比以增量方式编写要花费更长的时间。在 1.15 中，如果用户使用原生格式来获取保存点以及 RocksDB 状态后端，则会以增量方式自动获取保存点。文档也进行了澄清，以便更好地概述和理解检查点和保存点之间的差异。语义为 从保存点/保留的检查点恢复 也已明确介绍了 CLAIM 和 NO_CLAIM 模式。在 CLAIM 模式下，Flink 接管现有快照的所有权，在 NO_CLAIM 模式下，它创建自己的副本并将现有的副本留给用户。请注意 NO_CLAIM 模式是新的默认行为。从保存点/保留检查点恢复的旧语义仍然可以访问，但必须通过选择 LEGACY 模式手动选择。
使用Reactive模式和自适应调度程序进行弹性缩放
在越来越多的基于 Apache Flink 构建的云服务的推动下，该项目变得越来越云原生，这使得弹性扩展变得更加重要。
此版本改进了响应模式的指标，这是一种作业范围模式，JobManager 将尝试使用所有可用的 TaskManager 资源。为此，我们让 Job 范围内的所有指标在启用响应模式时都能正常工作。
我们还为自适应调度器添加了异常历史记录，这是一个新的调度器，它首先声明所需的资源并等待它们，然后再决定执行作业的并行度。
此外，缩减规模显着加快。TaskManager 现在有一个专用的关闭代码路径，它会主动从集群中注销自己，而不是依赖心跳，从而为 JobManager 提供一个明确的缩减信号。
自适应批处理调度器
在 1.15 中，我们为 Apache Flink 引入了一个新的调度器：Adaptive Batch Scheduler。新的调度器可以根据每个顶点需要处理的数据量的大小，自动决定批处理作业的作业顶点的并行度。
此调度程序的主要优点包括：
[*]易用性：
批处理作业用户可以从并行度调优中解脱出来。
[*]自适应：
自动调整的并行性可以更好地适应每天具有不同卷大小的消费数据集。
[*]细粒度：
每个作业顶点的并行度将单独调整。
这允许自动为 SQL 批处理作业的顶点分配不同的适当并行度。
跨数据源的Watermark对齐
拥有以不同速度增加Watermark的数据源可能会导致下游Operator出现问题。例如，一些算子可能需要缓冲过多的数据，这可能会导致大量的算子状态。这就是我们在此版本中引入 Watermark 对齐的原因。
对于基于新源界面的源， 可以激活Watermark对齐。用户可以定义对齐组以暂停从其他来源太远的来源消费。对齐Watermark的理想场景是当有两个或多个源以不同的速度产生Watermark并且源具有与拆分/分片/分区相同的并行度时。
SQL 版本升级
SQL 查询的执行计划及其生成的拓扑基于优化规则和成本模型。这意味着即使是最小的更改也可能会引入完全不同的拓扑。这种动态性使得在不同 Flink 版本之间保证快照兼容性非常具有挑战性。在 1.15 的努力中，社区专注于保持相同的查询（通过相同的拓扑）即使在升级后也能正常运行。
SQL 升级的核心是 JSON 计划（请注意，目前我们的 JavaDocs 中只有文档，并且仍在努力更新文档），这是 JSON 函数，可以更轻松地在 SQL 中导入和导出结构化数据。这已在以前的版本中引入供内部使用，现在将对外公开。Table API 和 SQL 都将提供一种编译和执行计划的方法，该计划保证在不同版本中具有相同的拓扑。此功能将作为实验性 MVP 发布。想要尝试的用户已经可以创建一个 JSON 计划，然后可以用于基于旧的 operator 结构恢复 Flink 作业。在 Flink 1.16 中可以期待完整的功能。
从长远来看，可靠的升级使 Flink SQL 对于生产用例更加可靠。
更改日志状态后端
在 Flink 1.15 中，我们引入了 changelog state backend的 MVP 特性，旨在使检查点间隔更短、更可预测，具有以下优点：
[*]更短的端到端延迟：
端到端延迟主要取决于检查点机制，尤其是对于事务接收器。
事务接收器在检查点上提交，因此更快的检查点意味着更频繁的提交。
[*]更可预测的检查点间隔：
目前检查点时间很大程度上取决于需要在检查点存储上持久化的工件的大小。
通过始终保持较小的大小，检查点时间变得更加可预测。
[*]恢复工作量减少：
检查点越频繁，每次恢复后需要重新处理的数据就越少。
更改日志状态后端通过在非易失性存储上持续保持状态更改同时在后台执行状态实现来帮助实现上述目标。
可重复的清理
在以前的 Flink 版本中，清理与作业相关的工件只进行一次，这可能会导致在发生错误时放弃工件。在这个版本中，Flink 将尝试再次运行清理以避免留下工件。默认情况下，此重试机制一直运行到成功为止。用户可以通过配置可重复的清理选项来更改此行为。禁用重试策略将导致 Flink 的行为与以前版本一样。
FLINK-26606涵盖了清理检查点的工作仍在进行中 。
开放API
Flink 现在提供了一个遵循 OpenAPI标准的实验性 REST API 规范。这允许 REST API 与实现 OpenAPI 标准的标准工具一起使用。您可以在此处找到规范。
应用模式的改进
在应用程序模式下运行 Flink 时，现在可以保证作业在完成后会获取一个保存点，如果它们已配置为这样做（请参阅 execution.shutdown-on-application-finish）。
在应用程序模式下运行的作业的恢复和清理也得到了改进。本地状态可以保存在工作目录中，这使得从本地存储中恢复更容易。
流和批处理的统一更多进展
在最新版本中，我们在统一流处理和批处理的目标上进行了新的努力并延续了之前的一些努力。
最终检查点
在 Flink 1.14 中，添加了最终检查点作为必须手动启用的功能。自上次发布以来，我们听取了用户反馈并决定默认启用它。有关更多信息以及如何禁用此功能，请参阅 文档。这种配置更改可能会延长有界流作业的关闭顺序，因为作业必须等待最终检查点才能完成。
窗口Table-Valued函数
窗口表值函数 仅可用于无界数据流。在此版本中，它们也可以在 BATCH 模式下使用。在处理这个问题的同时，更改窗口表值函数也通过实现一个不再需要这些窗口函数与聚合器一起使用的专用运算符得到了总体改进。
Flink SQL
社区指标表明 Flink SQL 被广泛使用并且每天都变得越来越流行。社区进行了一些改进，但我们想更详细地讨论两个。
CAST/类型系统增强
数据以各种形式出现，但通常不是您需要的类型，这就是为什么 转换 是 SQL 中最常见的操作之一。在 Flink 1.15 中，失败的 CAST 的默认行为已经从返回 null 更改为返回错误，这使其更加符合 SQL 标准。仍然可以通过调用新引入的 TRY_CAST 函数或通过配置标志恢复旧的强制转换行为。
此外，还修复了许多错误并改进了投射功能，以确保正确的结果。
JSON 函数
JSON 是最流行的数据格式之一，SQL 用户越来越需要构建和读取这些数据结构。根据 SQL 2016 标准，在 Flink SQL 中添加了多个 JSON函数。它允许用户使用 Flink SQL 方言检查、创建和修改 JSON 字符串。
社区赋能
使人们能够构建流数据管道来解决他们的用例是我们的目标。社区很清楚，像 Apache Flink 这样的技术永远不会单独使用，并且永远是更大架构的一部分。因此，重要的是 Flink 在云端运行良好，与其他系统无缝连接，并继续支持 Java 和 Python 等编程语言。
云互操作性
有用户在来自各种云提供商的云基础设施中操作 Flink 部署。还有一些服务可以在他们的平台上为用户管理 Flink 部署。
在 Flink 1.15 中，为 Google Cloud Storage 添加了一个可恢复的 writer。我们还组织了 Flink 生态系统中的连接器，并重点关注 AWS 生态系统的连接器（即 KDS、 Firehose）。
Elasticsearch Sink
在 Flink 的整个连接器生态系统上进行了大量工作，但我们想强调 Elasticsearch Sink，因为它是使用新的连接器接口实现的，它提供了异步功能和端到端语义。该sink将在未来充当模板。
无 Scala 的 Flink
一篇详细的博客文章已经解释了为什么 Scala 用户现在可以将 Flink Java API 与任何 Scala 版本（包括 Scala 3）一起使用。
最后，移除 Scala 只是从 Flink 生态系统中清理和更新各种技术的更大努力的一部分。
从 Flink 1.14 开始，我们移除了 Mesos 集成，隔离了 Akka，弃用了 DataSet Java API，并将 Table API 隐藏在一个抽象之后。社区已经对这些努力产生了很大的吸引力。
PyFlink
在 Flink 1.15 之前，Python 用户定义的函数在单独的 Python 进程中执行，这导致了额外的序列化/反序列化和通信开销。在具有大量数据的场景中，例如图像处理等，这种开销变得不可忽略。此外，由于涉及到进程间通信，处理延迟也是不可忽略的，这在延迟很关键的场景中是无法接受的，例如量化事务等。在 Flink 1.15 中，我们引入了一种新的执行模式，称为“线程” ' 模式，对于这种模式，Python 用户定义的函数将在 JVM 中作为线程而不是单独的 Python 进程执行。基准测试表明，在 JSON 处理等常见场景中，吞吐量可以提高 2 倍。处理延迟也从几秒减少到微秒。需要注意的是，由于这仍然是'thread'模式的第一个版本，它目前只支持Python Table API & SQL中使用的Python ScalarFunction。我们计划将其扩展到可以在下一版本中使用 Python 用户定义函数的其他领域。
其他
在连接器测试框架上已经完成了进一步的工作 。如果你想贡献一个连接器或改进一个连接器，你绝对应该看看。
添加了一些期待已久的功能，包括 CSV 格式 和统一接收器界面中的小文件压缩 。
sink API 已经升级到版本 2 ，我们鼓励每个连接器维护者升级到这个版本。
概括
Apache Flink 现在更易于操作，在对齐流和批处理方面取得了更大的进展，通过改进 SQL 组件变得更易于访问，并且现在与其他技术更好地集成。
还值得一提的是，社区已经为CDC 连接器建立了一个新家，连接器存储库 将被外部化（以 Elasticsearch sink 作为第一个示例），并且现在有一个 Kubernetes 操作器 （ 社区维护的公告博文） .
展望未来，社区将继续致力于使 Apache Flink 成为真正的统一流和批处理处理器，并致力于将 Flink 更好地集成到云原生生态系统中。
升级说明
虽然我们的目标是使升级尽可能顺利，但有些更改需要用户在升级到 Apache Flink 1.15 时调整程序的某些部分。请查看 发行说明 ，了解升级期间适用的调整和问题列表。升级时值得一提的一件大事是没有 Scala 版本的更新依赖项。在这里获取详细信息。
最新经典文章，欢迎关注公众号http://www.aboutyun.com/data/attachment/forum/201903/18/215536lzpn7n3u7m7u90vm.jpg
---------------------
作者：Flink
来源：weixin
原文：Apache Flink 1.15 重磅发布！
页:
[1]