本篇内容整理自 Pravega 我国社区创始人、戴尔科技集团软件工程技术总监滕昱在 Flink Forward Asia 2021 主会场的讲演。主要内容包含：

1. 存储笼统的现状
2. Pravega 功用架构详解
3. Pravega 流存储数据演示
4. 展望未来

FFA 2021 直播回放 & 讲演 PDF 下载

一、存储笼统的现状

在核算机软件规划中，有一个十分闻名的观念：任何新的核算机问题都能够经过新加入的笼统层处理，关于存储也是一样。上图列出了三种咱们主要运用的存储笼统，即块存储、文件存储和目标存储。块存储基本上和现代核算机工业一同期诞生；文件存储作为当今干流的存储笼统稍晚呈现；目标存储更晚，其诞生于 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 在内的数据湖仓相关的开源社区沟通合作，为企业级用户构建更友爱、更强壮的新一代数据流水线。