Pravega Flink connector 的过去、现在和未来

本文整理自戴尔科技集团软件工程师周煜敏在 Flink Forward Asia 2020 分享的议题《Pravega Flink Connector 的过去、现在和未来》，文章内容为：

1. Pravega 以及 Pravega connector 简介

2. Pravega connector 的过去

3. 回顾 Flink 1.11 高阶特性心得分享

4. 未来展望

一、Pravega 以及 Pravega connector 简介

img

Pravega 项目的名字来源于梵语，意思是 good speed。项目起源于 2016 年，基于 Apache V2 协议在 Github 上开源，并且于 2020 年 11 月加入了 CNCF 的大家庭，成为了 CNCF 的 sandbox 项目。

Pravega 项目是为大规模数据流场景而设计的，弥补传统消息队列存储短板的一个新的企业级存储系统。它在保持对于流的无边界、高性能的读写上，也增加了企业级的一些特性：例如弹性伸缩以及分层存储，可以帮助企业用户降低使用和维护的成本。同时我们也在存储领域有着多年的技术沉淀，可以依托公司商用存储产品为客户提供持久化的存储。

img

以上的架构图描述的是 Pravega 典型的读写场景，借此进行 Pravega 术语介绍以帮助大家进一步了解系统架构。

• 中间部分是一个 Pravega 的集群 ，它整体是以 stream 抽象的系统。stream 可以认为是类比 Kafka 的 topic。同样，Pravega 的 Segment 可以类比 Kafka 的 Partition，作为数据分区的概念，同时提供动态伸缩的功能。

  Segment 存储二进制数据数据流，并且根据数据流量的大小，发生 merge 或者 split 的操作，以释放或者集中资源。此时 Segment 会进行 seal 操作禁止新数据写入，然后由新建的 Segment 进行新数据的接收。

• 图片左侧是数据写入的场景，支持 append only 的写入。用户可以对于每一个 event 指定 Routing key 来决定 Segment 的归属。这一点可以类比 Kafka Partitioner。单一的 Routing key 上的数据具有保序性，确保读出的顺序与写入相同。

• 图片右侧是数据读取的场景，多个 reader 会有一个 Reader Group 进行管控。Reader Group 控制着 reader 之间的负载均衡的，来保证所有的 Segment 能在 reader 之间均匀分布。同时也提供 Checkpoint 机制形成一致的 stream 切分来保证数据的故障恢复。对于 "读"，我们支持批和流两种语义。对于流的场景，我们支持尾读；对于批的场景，我们会更多的考虑高并发来达到高吞吐。

二、Pravega Flink connector 的过去

img

Pravega Flink connector 是 Pravega 最初支持的 connector，这也是因为 Pravega 与 Flink 的设计理念非常一致，都是以流为基础的批流一体的系统，能够组成存储加计算的完整解决方案。

1. Pravega 发展历程

img

• connector 从 2017 年开始成为独立的 Github 项目。2017 年，我们基于 Flink 1.3 版本进行开发，当时有包括 Stephan Ewen 在内的 Flink PMC 成员加入，合作构建了最基础的 Source / Sink function，支持最基础的读写，同时也包括 Pravega Checkpoint 的集成，这点会在后面进行介绍。

• 2018 年最重要的一个亮点功能就是端到端的精确一次性语义支持。当时团队和 Flink 社区有非常多的讨论，Pravega 首先支持了事务性写客户端的特性，社区在此基础上合作，以 Sink function 为基础，通过一套两阶段提交的语义实现了基于 checkpoint 的分布式事务功能。后来，Flink 也进一步抽象出了两阶段提交的 API，也就是为大家熟知的 TwoPhaseCommitSinkFunction 接口，并且也被 Kafka connector 采用。社区有博客来专门介绍这一接口，以及端到端的一次性语义。

• 2019 年更多的是 connector 对其它 API 的一些补完，包括对批的读取以及 Table API 都有了支持。

• 2020 年的主要关注点是对 Flink 1.11 的集成，其中的重点是 FLIP-27 以及 FLIP-95 的新特性集成。

2. Checkpoint 集成实现

img

以 Kafka 为例，可以首先来看一下 Kafka 是如何做到 Flink Checkpoint 的集成的。

上图所示是一个典型的 Kafka "读" 的架构。基于 Chandy-Lamport 算法的 Flink checkpoint 实现，当 Job master Trigger 一个 Checkpoint 时，会往 Task Executor 发送 RPC 请求。其接收到之后会把自身状态存储中的 Kafka commit offset 合并回 Job Manager 形成一个 Checkpoint Metadata。

仔细思考后，其实可以发现其中的一些小问题：

• 扩缩容以及动态的平衡支持。当 Partition 进行调整的时候，或者说对 Pravega 而言，在 Partition 动态扩容和缩容的时候，如何进行 Merge 一致性的保证。

• 还有一点就是 Task 需要维护一个 offset 的信息，整个设计会与 Kafka 的内部抽象 offset 耦合。

img

基于这些不足之处，Pravega 有自己内部设计的 Checkpoint 机制，我们来看一下它是怎么和 Flink 的 Checkpoint 进行集成的。

同样读取 Pravega Stream。开始 Checkpoint 这里就有不同，Job master 不再向 Task Executor 发送 RPC 请求，转而以 ExternallyInducedSource 的接口，向 Pravega 发送一个 Checkpoint 的请求。

同时，Pravega 内部会利用 StateSynchronizer 组件来同步和协调所有的 reader，并且会在所有的 reader 之间，发送 Checkpoint 的 event。当 Task Executor 读到 Checkpoint Event 之后，整个 Pravega 会标志着这个 Checkpoint 完成，然后返回的 Pravega Checkpoint 会存到 Job master state 当中，从而完成 Checkpoint。

这样的实现其实对于 Flink 来说是更干净的，因为它没有耦合外部系统的实现细节，整个 Checkpoint 的工作是交给 Pravega 来实现并完成的。

三、回顾 Flink 1.11 高阶特性心得分享

Flink 1.11 是 2020 年的一个重要发布版本，对 connector 而言其实也有非常多的挑战，主要集中在两个 FLIP 的实现：FLIP-27 以及 FLIP-95。对于这两个全新功能，团队也花了很多时间去集成，在过程中也遇到了一些问题和挑战。下面我们来向大家分享一下我们是如何踩坑和填坑的。本文会以 FLIP-95 为例展开。

1. FLIP-95 集成

img

FLIP-95 是新的 Table API，其动机和 FLIP-27 类似，也是为了实现批流一体的接口，同时也能更好地支持 CDC 的集成。针对冗长的配置键，也提出了相应的 FLIP-122 来简化配置键的设定。

1.1 Pravega 旧的 Table API

img

从上图可以看到 Pravega 在 Flink 1.10 之前的一个 Table API，并且从图中建表的 DDL 可以看到：

• 以 update mode 和 append 去进行区分批和流，而且批流的数据这样的区分并不直观。

• 配置件也非常的冗长和复杂，读取的 Stream 需要通过 connector.reader.stream-info.0 这样非常长的配置键来配置。

• 在代码层面，和 DataStream API 也有非常多的耦合难以维护。

针对这些问题，我们也就有了非常大的动力去实现这样一套新的 API，让用户更好的去使用表的抽象。整个框架如图所示，借由整个新框架的帮助，所有的配置项通过 ConfigOption 接口定义，并且都集中在 PravegaOptions 类管理。

img

1.2 Pravega 全新 Table API

下图是最新 Table API 建表的实现，和之前的相比有非常大的简化，同时在功能上也有了不少优化，例如企业级安全选项的配置，多 stream 以及起始 streamcut 的指定功能。

img

2. Flink-18641 解决过程心得分享

img

接下来，我想在此分享 Flink 1.11 集成的一个小的心得，是关于一个 issue 解决过程的分享。Flink-18641 是我们在集成 1.11.0 版本时碰到的问题。升级的过程中，在单元测试中会报 CheckpointException。接下来是我们完整的 debug 过程。

• 首先会自己去逐步断点调试，通过查看 error 的报错日志，分析相关的 Pravega 以及 Flink 的源码，确定它是 Flink CheckpointCoordinator 相关的一些问题；

• 然后我们也查看了社区的一些提交记录，发现 Flink 1.10 之后， CheckpointCoordinator 线程模型，由原来锁控制的模型变成了 Mailbox 模型。这个模型导致了我们原来同步串型化执行的一些逻辑，错误的被并行化运行了，于是导致该错误；

• 进一步看了这一个改动的 pull request，也通过邮件和相关的一些 Committer 取得了联系。最后在 dev 邮件列表上确认问题，并且开了这个 JIRA ticket。

我们也总结了以下一些注意事项给到在做开源社区的同胞们：

• 在邮件列表和 JIRA 中搜索是否有其他人已经提出了类似问题；

• 完整的描述问题，提供详细的版本信息，报错日志和重现步骤；

• 得到社区成员反馈之后，可以进一步会议沟通商讨解决方案；

• 在非中文环境需要使用英语。

其实作为中国的开发人员，有除了像 mailing list 和 JIRA 之外。我们也有钉钉群以及视频的方式可以联系到非常多的 Committer。其实更多的就是一个交流的过程，做开源就是要和社区多交流，可以促进项目之间的共同成长。

四、未来展望

img

• 在未来比较大的工作就是 Pravega schema registry 集成。Pravega schema registry 提供了对 Pravega stream 的元数据的管理，包括数据 schema 以及序列化方式，并进行存储。这个功能伴随着 Pravega 0.8 版本发布了该项目的第一个开源版本。我们将在之后的 0.10 版本中基于这一项目实现 Pravega 的 Catalog，使得 Flink table API 的使用更加简单；

• 其次，我们也时刻关注 Flink 社区的新动向，对于社区的新版本、新功能也会积极集成，目前的计划包括 FLIP-143 和 FLIP-129；

• 社区也在逐步完成基于 docker 容器的新的 Test Framework 的转换，我们也在关注并进行集成。