摘要：本文根据戴尔科技集团软件工程师周玉敏在FlinkForwardAsia2020分享的话题《Pravega Flink Connector 的过去、现在和未来》整理而成，文章内容为：Pravega及Pravegaconnector简介PravegaconnectorFlink1.11经验分享高阶特性未来展望1.Pravega及Pravegaconnector简介Pravega项目名称来源于梵文，意为速度快。该项目起源于2016年，基于ApacheV2协议在Github上开源。它于2020年11月加入CNCF大家庭，成为CNCF沙箱项目。Pravega项目专为大规模数据流场景设计，是弥补传统消息队列存储不足的新型企业级存储系统。保持了流的无界、高性能读写，同时也增加了一些企业级的特性：比如弹性伸缩、分层存储，可以帮助企业用户降低使用和维护成本。同时我们在存储领域也有多年的技术积累，可以依托公司的商用存储产品为客户提供持久化存储。上面的架构图描述了Pravega的典型读写场景，并介绍了Pravega的术语，帮助您进一步了解系统架构。中间部分是一个Pravega集群，它是一个整体流的抽象系统。Stream可以认为是类似于Kafka的主题。同样，Pravega的Segment可以类比Kafka的Partition，作为数据分区的概念，同时提供动态缩放。Segment存储二进制数据流，根据数据流的大小，进行合并或拆分操作，释放或集中资源。这时候Segment会进行封操作，防止写入新的数据，然后新创建的Segment会接收到新的数据。图片左侧为数据写入场景，支持appendonly写入。用户可以为每个事件指定一个Routingkey来确定Segment的所有权。这可以与KafkaPartitioner进行比较。单个routingkey上的数据是保序的，保证读的顺序和写的顺序一致。右边是数据读取场景，多个reader会被一个ReaderGroup控制。ReaderGroup控制Reader之间的负载均衡，保证所有Segment在Reader之间均匀分布。同时，它还提供了检查点机制，形成一致的流分段，保证数据故障恢复。对于“读取”，我们同时支持批处理和流处理语义。对于流媒体场景，我们支持尾读；对于批处理场景，我们会考虑高并发来实现高吞吐量。2.PravegaFlinkconnector的过去PravegaFlinkconnector是Pravega最初支持的connector。这也是因为Pravega和Flink的设计理念非常一致。它们都是基于流的系统，集成了批和流，可以形成完整的存储和计算解决方案。计划。一、Pravega的发展历程connector从2017年开始就是一个独立的Github项目，2017年我们基于Flink1.3版本进行开发。当时包括StephanEwen在内的FlinkPMC成员加入我们，构建了最基本的Source/Sink功能，支持最基本的读写，也包括了PravegaCheckpoint的集成。这个后面会介绍。2018年最重要的亮点之一是对exactly-once语义的端到端支持。当时，团队与Flink社区进行了很多讨论。Pravega首先支持事务写客户端的特性，社区在此基础上进行合作。在Sink函数的基础上，使用了一套两阶段提交语义来实现基于checkpoint的分布式事务功能。后来，Flink进一步抽象出了二阶段提交API，也就是大家熟知的TwoPhaseCommitSinkFunction接口，也被Kafkaconnector所采用。社区有专门介绍此接口和端到端一次性语义的博客。在2019年，有更多的连接器来补充其他API，包括对批量读取和TableAPI的支持。2020年的重点是Flink1.11的集成，重点是FLIP-27和FLIP-95的新特性集成。2.Checkpoint集成实现以Kafka为例，可以先看看Kafka是如何实现FlinkCheckpoint集成的。上图展示了一个典型的Kafka“读取”架构。基于Chandy-Lamport算法的FlinkCheckpoint实现，当Jobmaster触发Checkpoint时，会向TaskExecutor发送RPC请求。收到后，它会将自己状态存储中的Kafkacommitoffset合并回JobManager，形成CheckpointMetadata。仔细考虑之后，其实可以发现一些小问题：扩缩容和动态平衡支持。在Partition调整的时候，或者对于Pravega来说，在Partition动态扩缩容的时候如何保证Merge的一致性。还有一点就是Task需要维护一个offset信息，整个设计会耦合Kafka内部的抽象offset。基于这些缺点，Pravega有自己内部设计的Checkpoint机制。我们来看看它是如何与Flink的Checkpoint集成的。另请阅读PravegaStream。从Checkpoint开始，这里就有区别了。Jobmaster不再向TaskExecutor发送RPC请求，而是通过ExternallyInducedSource接口向Pravega发送Checkpoint请求。同时，Pravega内部会使用StateSynchronizer组件来同步和协调所有阅读器，并会在所有阅读器之间发送Checkpoint事件。当TaskExecutor读取到CheckpointEvent时，整个Pravega会标记Checkpoint的完成，然后将返回的PravegaCheckpoint存入Jobmaster状态，完成Checkpoint。这种实现方式对于Flink来说其实更干净，因为它没有耦合外部系统的实现细节，整个checkpoint的工作都交给了Pravega去实现和完成。3、回顾Flink1.11high-levelfeatures的经验分享Flink1.11是2020年重要的发布版本，connector其实有很多挑战，主要集中在两个FLIP的实现上：FLIP-27和FLIP-95。对于这两个新功能，团队也花了很多时间进行整合，过程中也遇到了一些问题和挑战。跟大家分享一下我们是如何踩坑和填坑的。本文将以FLIP-95为例。1.FLIP-95集成FLIP-95是一个新的TableAPI。它的动机类似于FLIP-27。也是为了实现批流的集成接口，同时可以更好的支持CDC的集成。对于冗长的配置键，也提出了相应的FLIP-122来简化配置键的设置。1.1Pravega旧的TableAPI从上图中可以看到Flink1.10之前Pravega的一个TableAPI，从图中建表的DDL可以看出：使用update方式和append来区分batch和stream，以及batchstreams这样的数据区分并不直观。配置文件也很冗长复杂，读Stream需要通过connector.reader.stream-info.0这样很长的配置key来配置。在代码层面，也有很多与DataStreamAPI的耦合难以维护。针对这些问题，我们有很大的动力去实现这样一套新的API，让用户更好的使用表的抽象。整个框架如图所示。借助全新的框架，所有的配置项都通过ConfigOption接口定义，并在PravegaOptions类中集中管理。1.2Pravega新的TableAPI下图是最新的TableAPI建表的实现。相比上一款大大简化，功能上也有很多优化，比如企业级安全选项的配置，多流和启动。streamcut的指定函数。2.Flink-18641解决过程经验分享接下来我想在这里分享一个Flink1.11集成的小经验，是关于一个问题解决过程的分享。Flink-18641是我们在集成1.11.0版本时遇到的问题。升级过程中，单元测试会报CheckpointException。接下来就是我们完整的调试过程。首先我们自己去一步步调试。通过查看报错的错误日志，分析相关Pravega和Flink的源码，确定是FlinkCheckpointCoordinator相关的问题；然后我们也查看了社区的一些提交记录，发现在Flink1.10以后，CheckpointCoordinator线程模型，从原来的锁控制模型变成了Mailbox模型。这种模式导致我们原本的一些同步串行执行逻辑，被错误地并行运行，导致了这个错误；在进一步阅读此更改的拉取请求后，我们还通过电子邮件与一些相关的Committer取得了联系。最后在开发邮件列表上确认了这个问题并打开了这张JIRA票。我们也为开源社区的同胞们总结了以下几点：搜索邮件列表和JIRA，看看有没有其他人提出过类似的问题；完整描述问题，提供详细的版本信息、错误日志和回放当前步骤；在得到社区成员的反馈后，可以进一步召开会议，讨论解决方案；非中文环境要求英语。其实在国内作为开发者，还有邮件列表，JIRA之类的。我们还有DingTalk群组和视频，可以与很多Committer联系。其实更多的是一个沟通的过程。做开源就是多和社区交流，可以促进项目的共同成长。4.未来展望未来更大的工作是Pravegaschemaregistry的集成。Pravegaschemaregistry提供Pravega流的元数据管理，包括数据模式和序列化方法，并存储它们。此功能随Pravega0.8版本一起发布，这是该项目的第一个开源版本。我们会在后续的0.10版本基于该项目实现Pravega的Catalog，让FlinkTableAPI的使用更加简单；其次，我们也时刻关注Flink社区的新动向，积极整合社区的新版本和新功能，目前计划包括FLIP-143和FLIP-129；社区也在逐步完成基于docker容器的新测试框架的改造，我们也在关注和整合。最后，希望社区的小伙伴能够多多关注Pravega项目，促进Pravegaconnector与Flink的共同发展。
