一、存储抽象的现状
在计算机软件设计中，有一个非常著名的观点：任何新的计算机问题都可以通过新加入的抽象层解决，对于存储也是一样。上图列出了三种大家主要使用的存储抽象，即块存储、文件存储和对象存储。块存储基本上和现代计算机工业同时期诞生；文件存储作为当今主流的存储抽象稍晚出现；对象存储更晚，其诞生于 1990 年代。而在实时计算的发展和云时代背景下，流式的数据有着越来越广泛的应用，我们认为需要一种新兴的存储抽象来应对这一种强调低延时、高并发流量的数据。而在文件存储中添加字节流可能是一个最直观的想法，但在实际需求上面临着一系列的挑战，实现反而更加复杂，如下图所示：
数据的写入大小对吞吐量的影响至关重要，为了平衡延时和吞吐量，在实现上需要引入 batching，并且需要预分配空间避免块分配造成的性能损耗，最后作为存储，持久化也必须保证。
本地文件系统本质上是不安全的。在现实世界中，每时每刻硬件节点，磁盘介质都可能会损坏。为了解决这些问题，就需要引入分布式存储系统，例如常见的多副本系统，但副本的拷贝费时费空间，分布式一致性协议的数据安全问题又会成为新的难题。
如果基于 shared-nothing 架构设计，完全并行不存在共享资源，例如上图中有三个副本分别存于三个独立的物理节点之上，那么单条流数据的存储大小就受限于单个物理界点的存储上限，所以这依然不是一个完备的解决方法。
由此可见，由于上述一系列的问题，基于文件系统构建流存储是相当复杂的。
于是，我们受到了开篇的观点的启示，尝试换个角度，使用分布式文件和对象存储的分层架构模式来解决这个问题。底层的可扩展存储可以作为一个数据湖，流的历史数据可以存入其中与其他非流的数据集共存，在节省了数据迁移、存储运维开销的同时可以解决数据孤岛的问题，批流结合的计算将会更加方便。
分层架构可以解决分散的多客户端。为了解决容错恢复的问题，我们在流存储的基础上增加了分布式 log 存储。
在真实应用实例中，实时应用程序的流量可能随着时间波动，为了应对数据的峰谷，我们引入了动态伸缩功能。
在左上角的图标中，横轴表示时间，纵轴表示应用程序的数据。它的波形图刚开始很平稳，到了特定点时数据量突然变大，这往往是一些跟时间有关的应用程序的特性，比如早晚高峰、双十一等场景，这个时候流量就会蜂拥而入。
一个完备的流存储系统应该能够感知到实时流量的变化进行资源的合理分配。当数据量变大时，底层会动态地分配更多的存储单元处理数据。在云原生时代的底层架构中，动态伸缩也是通用的存储系统中非常重要的一点。
二、Pravega 性能架构详解
Pravega 的设计宗旨是成为流的实时存储解决方案。
- 第一，应用程序将数据持久化存储到 Pravega 中，借助分层存储架构，Pravega Stream 实现了无上限的流存储；
- 第二，Pravega 支持端到端的仅一次语义，包括读端的 checkpoint 与事务性写功能，使得计算可以拆分为多个可靠的独立应用程序，实现了流式系统的微服务架构；
- 第三，Pravega 的动态伸缩机制，可以实现流量监控并自动在底层进行资源的分配，让开发和运维人员无需手动调度集群。
Pravega 独立的伸缩机制，让生产者和消费者互不影响，数据处理管道变得富有弹性，能对数据的实时变化做出适时的反应。
如图所示，Pravega 是从存储的视角看待流数据。Kafka 本身的定位是消息系统，所以它会从消息视角看待流数据。消息系统与存储系统的定位是不同的，消息系统是指消息传输系统，主要关注数据传输与生产消费的过程。Pravega 的定位是企业级的分布式流存储产品，不但满足流的属性还支持数据存储的持久化、安全可靠、隔离等属性。
视角的不同带来了设计架构上的差异性，由于消息系统无需处理长时间的数据存储，因此都会需要额外的任务和组件进行数据的搬运来完成持久化。而定位流存储的 Pravega 则在主存储中直接解决了数据 retention 问题。Pravega 的数据存储的核心引擎称之为 segment store，直接对接 HDFS 或 S3 的分布式存储组件用以进行长期、持久化的存储。依托底层存储组件的成熟架构与可扩展能力，Pravega 在存储端也就自然具备了大规模存储和可扩展的特性。
另一个架构上的差异则来自于客户端的小写优化。在典型的 IoT 场景中，边缘端的写入端数量通常比较大，而每次写入的数据量可能并不多。Pravega 的设计也充分考虑了这一场景，采用了在客户端和 segment store 两次 batching 的优化，将来自多个客户端的小写合并成对于底层磁盘友好的小批量写入，从而在保证低延时的基础上，大幅提升了高并发写入的性能。
这一设计也相应地对性能产生了影响。Pravega 测试了在同样的高并发负载下，与 Kafka 和 Pulsar 的性能对比，实验结果如下图所示。在我们的测试中使用高度并行的负载，每个 Stream/Topic 最多有 100 个写入端和 5000 个 segment。Pravega 可以在所有情况下都维持 250MBps 的速率，这也是测试云环境中磁盘的写入最大速率。而左右两图中可以看到，Kafka 和 Pulsar 在增加分区和生产者数量时，性能都会显著降低，在大规模的并发度下先后出现性能的降级。
这一实验过程和环境也完整地公开在这一篇博客之中，实验的代码也完全开源并贡献到了 openmessaging-benchmark 之中，有兴趣的同学可以尝试重现。
三、Pravega 流存储数据演示
从存储角度，我们已经介绍了 Pravega 对流存储的变化和架构特点。接下来，我们讲讲如何消费流存储数据。Pravega 如何跟 Flink 配合，构建端到端的大数据流水处理线。
我们提出的大数据架构，以 Apache Flink 作为计算引擎，通过统一的模型以及 API 来统一批处理和流处理；以 Pravega 作为存储引擎，为流式数据存储提供统一的抽象，使得对历史和实时数据有一致的访问方式。两者统一形成了从存储到计算的闭环，能够同时应对高吞吐的历史数据和低延时的实时数据。
更进一步，对于边缘计算的场景，Pravega 也兼容常用的消息通信协议，实现了相应的数据接收器，可以作为大数据流水处理的管道，从管道收集数据，把数据给到下游计算引擎应用程序，完成从边缘到数据中心的数据处理流水线。通过这样的方式，企业级用户可以很容易地搭建自己的大数据处理流水线。这也是我们开发流存储产品的目的。
我们认为在云原生时代，动态伸缩的功能是非常重要的，这样不但可以减轻应用程序开发的难度，而且可以更高效地利用底层的硬件资源。之前介绍了 Pravega 的动态伸缩，Flink 的新版本也支持了动态伸缩功能。那么我们将两个独立的伸缩联系起来，把动态伸缩功能推到整条流水线呢？
我们跟社区一起合作，完成了完整的伸缩链路，把端到端的 Auto-scaling 功能带给所有的客户。上图是端到端 Auto-scaling 概念的示意图。当数据注入变大时，Pravega 能够发生自动伸缩，分配更多的 segment 处理存储端的压力。而通过 metrics 以及 Kubernetes HPA 功能，Flink 也可以相应地分配更多并行计算的节点给到相应的计算任务中去，从而应对数据流量的变化。这是新一代对企业级用户非常关键的云原生能力。
四、展望未来
在 Flink Forward Asia 2021 大会上，Pravega 社区也跟 Flink 一起，共同发布了数据库同步方案的白皮书。Pravega 作为 CNCF 的项目也在不断发展，同时也会更坚定地拥抱开源。
随着技术的不断发展，越来越多的流式引擎和数据库引擎开始朝着融合的方向发展。展望未来，存储和计算，流和表的界限逐渐模糊。Pravega 批流一体的存储设计也暗合了 Flink 未来很重要的一个发展方向。Pravega 也会积极与包括 Flink 在内的数据湖仓相关的开源社区沟通合作，为企业级用户构建更友好、更强大的新一代数据流水线。
更多 Flink 相关技术问题，可扫码加入社区钉钉交流群
第一时间获取最新技术文章和社区动态，请关注公众号～