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

　　Pravega 以及 Pravega connector 简介

　　Pravega connector 的过去

　　回顾 Flink 1.11 高阶特性心得

　　未来展望

　　Pravega 创客大赛介绍

　　Tips：

　　- 原文视频链接：https://www.bilibili.com/video/BV1ga4y1n7Hr?p=3

　　- 文末扫码关注 Pravega 创客大赛

　　一、Pravega 以及 Pravega connector 简介

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

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

　　以上的架构图描述的是 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 的过去

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

　　1. Pravega 发展历程

　　 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 集成实现

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

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

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