Flink 1.5重磅发布：处理模型重构，延迟更低！

Posted 2021-04-13 AI前线

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Flink 1.5重磅发布：处理模型重构，延迟更低！相关的知识，希望对你有一定的参考价值。

策划编辑 | Natalie

译者 | 无明

编辑 | Natalie

AI 前线导读：Apache Flink 1.5.0 于昨天晚上正式发布！在过去的五个月，Flink 社区努力解决了 780 多个问题，新版本主要包含以下几项重大特性更新：重新设计并实现了 Flink 的大部分处理模型、广受开发者期待的广播状态支持、更快的保存点恢复、改进网络栈带来吞吐量提升和低延迟、添加了用于流式 SQL 查询的 SQL CLI 等。

更多优质内容请关注微信公众号“AI 前线”，（ID：ai-front）

Flink 1.5.0 是 1.x.y 系列的第六个主要版本。与往常一样，它兼容之前 1.x.y 版本中使用 @Public 注解标注过的 API。

最新版本已经可以下载，开发者可以通过 Flink 邮件列表或 JIRA 进行反馈。以下将列出最新版本的主要特性和改进。

流式处理进一步演化

Flink 正在给流式处理领域带来另一次重大飞跃。流式处理不仅意味着更加快速的分析，更是一种构建快速连续数据处理管道的原则性方法。流式处理正在成为构建数据驱动型和数据密集型应用程序的典范——它将数据处理逻辑和应用程序及业务逻辑汇集在了一起。

新版本对底层的一些基础组件进行了改进，包括：

重新设计并实现了 Flink 的大部分处理模型（FLIP-6）。尽管此项工作尚未全部完工，但 Flink 1.5 已经可以支持更为顺畅的 Kubernetes 部署，并可以将与外部系统的通信（与外部服务代理的交互）切换到 HTTP/REST。同时，Flink 1.5 简化了在常见集群管理器（如 YARN、Mesos）上进行的部署，并提供动态资源分配功能。
流式广播状态（FLINK-4940）可以将广播流（如上下文数据、机器学习模型、规则 / 模式、触发器等）与可能带有键控状态（keyed state）的流（如特征向量、状态机等）连接在一起。而在 Flink 1.5 之前，很难做到这一点。
为了改善对实时应用程序的支持，Flink 团队对 Flink 的网络栈（FLINK-7315）进行了重大改进。Flink 1.5 在保持高吞吐量的同时实现了更低的延迟。另外，新版本还改进了回压情况下检查点的稳定性。
流式 SQL 越来越被认为是一种简单而强大的方式，用于执行流式分析、构建数据管道、进行特征工程或基于变更数据增量更新应用程序状态。新版本添加了用于流式 SQL 查询的 SQL CLI（FLIP-24），让流式 SQL 更易于使用。

新特性和改进

重写 Flink 部署和处理模型

重写 Flink 部署和处理模型的工作已经进行了一年多，来自多个组织的贡献者（如 Artisans、阿里巴巴和 Dell EMC）合作设计和实现了该特性，这是 Flink 项目启动以来对核心组件做出的最重大的一项改进。

简单地说，这些改进增加了对 YARN 和 Mesos 调度器动态资源分配和动态资源释放的支持，以更好的利用资源、进行故障恢复和动态扩展。此外，新版本还简化了在容器管理基础设施（如 Kubernetes）上进行的部署，所有对 JobManager 的请求都通过 REST 发起，包括提交和取消作业、请求作业状态，获取保存点等。

此次改进也为 Flink 将来与 Kubernetes 更好的集成奠定了基础。在稍后的版本中，有可能在不先启动 Flink 集群的情况下，将作业塞进 Docker，并作为容器部署的一部分。此外，此次改进向支持应用程序的并行性自动调整卖出了一大步。

需要注意的是，这些改进对 Flink API 没有任何影响。

广播状态

对广播状态的支持（即在某个函数的所有并行实例中复制状态）是一直广受开发者期待的特性。广播状态的典型应用场景包括两个流，一个是控制或配置流，负责管理规则、模式或其他配置消息，另一个是常规的数据流。常规数据流的处理是通过控制流的消息来配置的，规则或模式被广播到函数的所有并行实例中，并应用于常规流的所有事件上。

当然，广播状态也可以有保存点或进行保存点恢复，就像 Flink 的其他状态一样，也具有一次性（exactly once）状态一致性保证。此外，广播状态为实现 Flink CEP 库的“动态模式”特性带来了可能性。

Flink 网络栈的改进

分布式流式应用程序的性能在很大程度上取决于通过网络连接传输事件的组件。在流式处理环境中，延迟和吞吐量是最为重要的两个性能指标。

Flink 1.5 从两个方面对 Flink 的网络栈进行了改进，即使用基于信用（credit based）的流量控制和改善传输延迟。基于信用的流量控制在最大程度上减少“线上”数据量，同时保持了高吞吐量。这显著减少了在回压情况下用于完成检查点的时间。此外，Flink 现在能够在不降低吞吐量的情况下实现更低的延迟。

任务本地状态恢复

Flink 的检查点机制将应用程序状态的副本写入到远程的持久化存储中，并在发生故障时将其加载回去。这种机制确保应用程序在发生失效时不会丢失状态。不过如果真的发生故障，可能需要一段时间才能从远程存储中加载状态以恢复应用程序。

Flink 社区正在不断努力提高检查点和恢复效率。以前版本使用了异步和增量检查点，在新版本中，主要提高了故障恢复的效率。

任务本地状态恢复主要利用了这样的一个事实——作业的失败通常是由单个操作、任务管理器或机器失效引起的。在将操作状态写入远程存储时，Flink 也会在每台机器的本地磁盘上保留一份副本。在进行失效备援时，调度程序会尝试将任务重新分配给以前的机器，并从本地磁盘而不是远程存储加载状态，从而加快恢复速度。

扩展对 SQL 和 Table API 的 Join 支持

在 1.5.0 版本中，Flink 增加对基于窗口的外连接的支持。如下查询允许对有限时间范围内的基于事件时间或处理时间的表进行连接。

Flink 1.5重磅发布：处理模型重构，延迟更低！

对于不应该在有限时间间隔内连接两个流式表的情况，Flink SQL 提供了非窗口内部连接支持。这样可以实现完全匹配，而这在许多标准 SQL 语句中是很常见的。

Flink 1.5重磅发布：处理模型重构，延迟更低！

SQL CLI 客户端

几个月前，Flink 社区开始致力于添加一项服务，用于执行流和批处理 SQL 查询（FLIP-24）。新的 SQL CLI 客户端就是这项工作的第一个成果，并提供了一个 SQL shell 用于查询数据流。

Flink 1.5重磅发布：处理模型重构，延迟更低！

其他特性和改进

OpenStack 提供了用于在资源池上创建公共和私有云的软件。Flink 现在支持 OpenStack 的类 S3 文件系统 Swift，用于保存检查点和保存点。Swift 可以在没有 Hadoop 依赖的情况下使用。
改进从连接器读取或向连接器写入 JSON 消息。现在可以通过解析一个标准的 JSON 模式来配置序列化器和反序列化器。SQL CLI 客户端能够读取来自 Kafka 的 JSON 记录。
应用程序可以在无需手动触发保存点的情况下进行伸缩。实际上，Flink 仍然会保存一个保存点，然后停止应用程序并重新调整并行度。
改进了 watermark 和延迟的度量标准，Flink 现在捕获所有操作器（包括数据源在内）的最小化 watermark。此外，为了更好地与常用指标系统集成，延迟度量指标进行了重新设计。
FileInputFormat（和其他多种输入格式）现在支持从多个路径读取文件。
BucketingSink 支持自定义扩展规范。
CassandraOutputFormat 可用于发送 Row 对象。
Kinesis 消费者客户端允许更大程度的定制化。