Flink 版本 | Apache Flink 1.14.0 发布

Apache 软件基金会最近发布了年度报告，Apache Flink 再次跻身最活跃项目前 5 名！这一非凡的活动也体现在新的 1.14.0 版本中。200 多名贡献者再次致力于解决 1,000 多个问题。我们为这个社区如何持续推进项目而感到自豪。

此版本在 SQL API、更多连接器支持、检查点和 PyFlink 等领域带来了许多新功能和改进。此版本中的一个主要变化领域是集成的流和批处理体验。我们相信，在实践中，无界流处理在实践中与有界和批处理任务密切相关，因为许多用例需要处理来自各种来源的历史数据以及流数据。示例包括开发新应用程序时的数据探索、新应用程序的引导状态、要在流应用程序中应用的训练模型、修复/升级后重新处理数据等.

在 Flink 1.14 中，我们终于可以在应用程序中混合有界和无界流：Flink 现在支持获取部分运行和部分完成的应用程序的检查点（一些运算符到达有界输入的末尾）。此外，有界流现在在到达终点时采用最终检查点，以确保在接收器中顺利提交结果。

所述批处理执行模式现在支持使用DataStream API和SQL /Table API的混合程序（以前仅纯表/ SQL或的数据流中的程序）。

统一的 Source 和 Sink API 已经更新，我们开始围绕统一 API 整合连接器生态系统。我们添加了一个新的混合源，可以在多个存储系统之间架起桥梁。您现在可以执行一些操作，例如从 Amazon S3 读取旧数据，然后切换到 Apache Kafka。

此外，此版本进一步推动了我们的举措，使 Flink 更具自调性和更易于操作，而无需大量特定于流处理器的知识。我们在之前的版本中通过反应式扩展启动了这项计划， 现在正在添加自动网络内存调整（又名缓冲区去膨胀）。此功能可在高负载下加速检查点，同时保持高吞吐量且不增加检查点大小。该机制不断调整网络缓冲区，以确保最佳吞吐量，同时拥有最少的传输中数据。有关 更多详细信息，请参阅缓冲区去膨胀部分。

正如我们在下面讨论的那样，在各个组件中还有更多改进和新增功能。我们还不得不告别一些在最近的版本中被更新的功能所取代的功能，最突出的是我们正在删除旧的 SQL 执行引擎，并正在删除与 Apache Mesos 的主动集成。

我们希望您喜欢这个新版本，我们渴望了解您使用它的体验，它解决了哪些尚未解决的问题，它为您解锁了哪些新用例。

统一的批处理和流处理体验

Flink 的独特之处之一是它如何集成流处理和批处理，使用统一的 API 和支持多种执行范式的运行时。

正如介绍中的动机，我们相信流处理和批处理总是齐头并进。来自Facebook 流基础设施报告的这句话 很好地回应了这种情绪。

 流式处理与批处理不是一个非此即彼的决定。最初，Facebook 的所有数据仓库处理都是批处理。大约五年前，我们开始开发 Puma 和 Swift。正如我们在第 […] 节中所展示的，混合使用流处理和批处理可以将长管道加速数小时。

在同一引擎中同时进行实时计算和历史计算还可以确保语义之间的一致性并使结果具有很好的可比性。这是阿里巴巴的一篇 关于使用 Apache Flink 统一业务报告并以这种方式获得一致报告的文章。

虽然在早期版本中已经可以实现统一流和批处理，但此版本带来了一些解锁新用例的功能，以及一系列的生活质量改进。

检查点和有界流

Flink 的检查点机制最初只能在应用程序 DAG 中的所有任务都在运行时创建检查点。这意味着同时使用有界和无界数据源的应用程序实际上是不可能的。此外，当某些任务完成时，以流方式（而不是以批处理方式）执行的有界输入上的应用程序在处理结束时停止检查点。如果没有检查点，则不会提交最新的输出数据，从而导致恰好一次接收器的数据挥之不去。

使用FLIP-147， Flink 现在支持任务完成后的检查点，并在有界流的末尾获取最终检查点，确保在作业结束之前提交所有接收器数据（类似于stop-with-savepoint 的行为）。

要激活此功能，请添加execution.checkpointing.checkpoints-after-tasks-finish.enabled: true到您的配置中。与大功能和新功能的选择加入传统保持一致，这在 Flink 1.14 中默认不激活。我们希望它成为下一个版本的默认模式。

背景：虽然批处理执行模式通常是在有界流上运行应用程序的首选方式，但在有界流上使用流式执行模式有多种原因。例如，正在使用的接收器可能仅支持流执行（即 Kafka 接收器），或者您可能希望在应用程序中利用流固有的准按时间排序，例如受Kappa+ 架构的启发。

混合DataStream和Table/SQL 应用程序的批处理执行

SQL 和 Table API 正在成为新项目的默认起点。内置类型和操作的声明性和丰富性使得快速开发应用程序变得容易。然而，对于某些类型的事件驱动的业务逻辑，开发人员最终会达到 SQL 表达能力的极限（或者当用 SQL 表达该逻辑变得怪诞时，这种情况并不少见）。

那时，自然的步骤是在再次切换回 SQL 之前融入一段有状态的 DataStream API 逻辑。

在 Flink 1.14 中，有界批处理执行的 SQL/Table 程序可以将它们的中间 Table 转换为 DataStream，应用一些 DataSteam API 操作，并将其转换回 Table。在幕后，Flink 构建了一个数据流 DAG，将声明式优化的 SQL 执行与批处理执行的 DataStream 逻辑混合在一起。查看文档了解详细信息。

混合Source

新的混合源 产生来自多个源的组合流，通过一个接一个地读取这些源，从一个源无缝切换到另一个源。

混合源的激励用例是从分层存储设置中读取流，就好像有一个跨所有层的流。例如，新数据可能会登陆 Kafa 并最终迁移到 S3（通常采用压缩柱状格式，以提高成本效率和性能）。混合源可以将其作为一个连续的逻辑流读取，从 S3 上的历史数据开始，过渡到 Kafka 中更新的数据。

 

我们相信这是实现日志和Kappa 架构的全部承诺的令人兴奋的一步。即使事件日志的旧部分被物理迁移到不同的存储（出于成本、更好的压缩、更快的读取等原因），您仍然可以将其视为一个连续的日志并将其处理。

Flink 1.14 增加了 Hybrid Source 的核心功能。在下一个版本中，我们希望为典型的切换策略添加更多实用程序和模式。

整合Source和Sink

随着新的统一（流/批处理）源和接收器 API 现在稳定，我们开始大力整合这些 API 周围的所有连接器。同时，我们更好地对齐 DataStream 和 SQL/Table API 之间的连接器。首先是用于 DataStream API的Kafka和文件源和接收器。

这项努力的结果（我们预计至少会发布 1-2 个后续版本）将为 Flink 用户在连接到外部系统时提供更流畅、更一致的体验。

缓冲消胀

Buffer Debloating是 Flink 中的一项新技术，可以最大限度地减少检查点延迟和成本。它通过自动调整网络内存的使用来确保高吞吐量，同时最大限度地减少传输中的数据量。

Apache Flink 在其网络堆栈中缓冲一定数量的数据，以便能够利用快速网络的带宽。以高吞吐量运行的 Flink 应用程序使用部分（或全部）内存。对齐的检查点与数据一起以毫秒为单位通过网络缓冲区。

当 Flink 应用程序变得（暂时）背压时（例如，当受到外部系统的背压时，或者当命中偏斜的记录时），这通常会导致网络缓冲区中的数据比使用应用程序当前所需的足够网络带宽所必需的多得多。吞吐量（由于背压而降低）。甚至还有一个不利的影响：更多的缓冲数据意味着检查点需要做更多的工作。对齐的检查点屏障需要等待更多的数据被处理，未对齐的检查点需要持久化更多的动态数据。

这就是Buffer Debloating发挥作用的地方：它将网络堆栈从保持最多 X 字节的数据更改为保持值得 X 毫秒的接收器计算时间的数据。默认设置为 1000 毫秒，这意味着网络堆栈将缓冲接收任务在 1000 毫秒内可以处理的数据。这些值会不断测量和调整，因此系统即使在变化的条件下也能保持这种特性。因此，Flink 现在可以为背压下的对齐检查点提供稳定且可预测的对齐时间，并且可以大大减少背压下未对齐检查点中存储的动态数据量。

 

Buffer Deloating 是未对齐检查点的补充功能，甚至是替代功能。查看文档 以了解如何激活此功能。

细粒度资源管理

细粒度资源管理是一项高级新功能，可提高大型共享集群的资源利用率。

Flink 集群执行各种数据处理工作负载。不同的数据处理步骤通常需要不同的资源，例如计算资源和内存。例如，大多数map()函数都相当轻量级，但是保留时间长的大窗口可以从大量内存中受益。默认情况下，Flink 以称为slot的粗粒度单元管理资源，这些单元是 TaskManager 资源的切片。流式管道用每个操作符的一个并行子任务填充一个槽，因此每个槽都持有一个子任务管道。通过“插槽共享组”，用户可以影响子任务如何分配给插槽。

通过细粒度的资源管理，TaskManager 插槽现在可以动态调整大小。转换和操作符指定他们想要的资源配置文件（CPU 大小、内存池、磁盘空间），并且 Flink 的资源管理器和任务管理器将任务管理器总资源的特定部分切掉。您可以将其视为 Flink 中最小的轻量级资源编排层。下图说明了共享固定大小插槽的当前默认模式与新的细粒度资源管理功能之间的区别。

您可能想知道为什么我们在 Flink 中实现这样的功能，同时我们还与 Kubernetes 或 YARN 等成熟的资源编排框架集成。Flink 内部额外的资源管理层显着提高资源利用率的情况有以下几种：

• 对于很多小槽来说，专用TaskManagers的开销非常高（JVM开销，Flink控制数据结构）。时隙共享通过在所有运算符类型之间共享时隙来隐式地解决这个问题，这意味着在轻量级运算符（需要小时隙）和重量级运算符（需要大时隙）之间共享资源。然而，这仅在所有操作符共享相同的并行性时才有效，这并非最佳。此外，某些算子在单独运行时效果更好（例如需要专用 GPU 资源的 ML 训练算子）。

• Kubernetes 和 YARN 通常需要相当长的时间来满足请求，尤其是在负载集群上。对于许多批处理作业，在等待请求完成时效率会下降。

那么什么时候应该使用这个功能呢？对于大多数流和批处理作业，默认资源管理机制非常适合。如果您有长时间运行的流作业或快速批处理作业，其中不同阶段具有不同的资源需求，并且您可能已经将不同算子的并行度调整为不同的值，那么细粒度的资源管理可以帮助您提高资源效率。阿里巴巴内部基于Flink的平台已经使用这种机制有一段时间了，集群的资源利用率显着提高。有关如何使用此功能的详细信息，请参阅细粒度资源管理文档。

连接器

• 连接器指标

此版本中已对连接器的度量标准进行了标准化（请参阅FLIP-33）。社区将逐渐通过所有连接器提取指标，因为我们会在下一个版本中将它们重新设计到新的统一 API 上。在 Flink 1.14 中，我们介绍了 Kafka 连接器和（部分）文件系统连接器。

连接器是 Flink 作业中数据的入口和出口点。如果作业未按预期运行，则连接器遥测是首先要检查的部分之一。我们相信在生产中运行 Flink 应用程序时，这将成为一个很好的改进。

• Pulsar连接器

在这个版本中，Flink 添加了Apache Pulsar连接器。Pulsar 连接器从 Pulsar 主题读取数据，并支持流和批处理两种执行模式。在事务功能的支持下（在 Pulsar 2.8.0 中引入），Pulsar 连接器提供了一次性传递语义，以确保消息只传递给消费者一次，即使生产者重试发送消息。

为了支持不同用例的不同消息排序和扩展需求，Pulsar 源连接器公开了四种订阅类型：-独占  -共享  -故障转移  -密钥共享

连接器当前支持 DataStream API。表 API/SQL 绑定预计将在未来版本中提供。有关如何使用 Pulsar 连接器的详细信息，请参阅 Apache Pulsar 连接器。

PyFlink

• 通过Chaining提高性能

类似于 Java API 如何在任务中链接转换函数/操作符以避免序列化开销，PyFlink 现在链接 Python 函数。在 PyFlink 的情况下，链接不仅消除了序列化开销，还减少了 Java 和 Python 进程之间的 RPC 往返。这极大地提高了 PyFlink 的整体性能。

Python 函数链已经可用于 Table API 和 SQL 中使用的 Python UDF。在 Flink 1.14 中，Python DataStream API 中的 cPython 函数也使用了链接。

• 用于调试的环回模式

Python 函数通常在 Flink 的 JVM 旁边的一个单独的 Python 进程中执行。这种架构使得调试 Python 代码变得困难。

PyFlink 1.14 引入了环回模式，默认情况下为本地部署激活。在这种模式下，用户自定义的Python函数将在客户端的Python进程中执行，该进程是启动PyFlink程序的入口点进程，包含构建数据流DAG的DataStream API和Table API代码。用户现在可以通过在本地启动 PyFlink 作业时在其 IDE 中设置断点来轻松调试其 Python 函数。

• 其他改进

PyFlink 还有许多其他改进，例如支持在 YARN 应用程序模式下执行作业以及支持将压缩的 tgz 文件作为 Python 存档。查看Python API 文档 以获取更多详细信息。

告别旧版 SQL 引擎和 Mesos 支持

维护一个开源项目有时也意味着要告别一些心爱的功能。

当我们在两年多前将 Blink SQL Engine 添加到 Flink 时，很明显它最终会取代之前的 SQL 引擎。Blink 速度更快，功能更完整。一年来，Blink 一直是默认的 SQL 引擎。在 Flink 1.14 中，我们最终从之前的 SQL 引擎中删除了所有代码。这使我们能够删除许多过时的接口，并减少用户在实现自定义连接器或功能时使用哪些接口的困惑。它也将帮助我们在未来对 SQL 引擎进行更快的更改。

与 Apache Mesos 的主动集成也被删除了，因为我们发现用户对此功能兴趣不大，而且我们无法聚集足够的贡献者来帮助维护系统的这一部分。如果没有 Marathon 等项目的帮助，Flink 1.14 无法再在 Mesos 上运行，并且 Flink 资源管理器无法再从 Mesos 请求和释放资源，以应对不断变化的资源需求的工作负载。