开源 Pravega 架构解析：如何通过分层解决流存储的三大挑战？

当前的大数据处理系统无论是何种架构都面临一个共同的问题，即：“计算是原生的流计算，而存储却不是原生的流存储” 。Pravega 团队重新思考了这一基本的数据处理和存储规则，为这一场景重新设计了一种新的存储类型，即原生的流存储，命名为”Pravega”，取梵语中“Good Speed”之意。本文是“分布式流存储 Pravega 系列文章”第二篇，第一篇文章回顾《 为什么你需要开源分布式流存储 Pravega？ 》。

流行大数据存储存在的三大问题

如图 1 是目前大数据处理平台最常见的 Lambda 架构，它的优势在于满足了实时处理与批处理需求，但是，正如前一篇文章 《实时流处理统一批处理的最后一块拼图：Pravega》 的观点，从存储的角度看其缺点也很明显，可以总结为如下三点：

1. 实时处理、批处理不统一，不同的处理路径采用了不同的存储组件，增加了系统的复杂度，导致了开发人员的额外学习成本和工作量。
2. 数据存储多组件化、多份化，如下图，同样的数据会被存储在 Elastic Search 、S3 对象存储系统、Kafka 等多种异构的系统中，而且考虑到数据的可靠性，数据还都是多份冗余的，这就极大的增加了用户的存储成本。而往往对于企业用户来说，0.1% 的存储冗余都意味着损失。
3. 系统里存储的组件太多太复杂，也增加了使用的运维成本。并且大部分现有的开源项目还处于“强运维”的产品阶段，对于企业用户来说又是很大的开销。

为了解决如上提出的三个问题： 降低开发成本、减少存储成本与减少运维成本 ，在这篇文章中，我们将从 Pravega 的架构角度出发，挖掘流存储的具体需求，并且通过架构的设计解决这三个问题。

第四种存储类型：流存储

从 存储的视角 来说，存储架构的设计需要首先明确存储的特点。每种类型的数据都有其原生的属性和常用访问模式，对应有最佳的适用场景以及最合适的存储系统。

在物联网、金融等实时应用场景中，所需要存储的数据一般被称之为“流数据”，流数据一般被定义为：

流数据是一组顺序、大量、快速、连续到达的数据序列，一般情况下，数据流可被视为一个随时间延续而无限增长的动态数据集合。

上图所示，我们将流数据定义为第四种数据类型。从左到右分布着四种最常见的的存储类型，依次从传统批数据转变成流数据。传统数据库这类基于事务的程序适合采用块存储系统。文件共享场景下需要在用户间共享文件进行读写操作，因此适合采用分布式文件 (NAS) 存储系统。而需要无限扩展并支持 REST 接口读写的非结构化的的图像 / 音视频文件则非常适合采用对象存储系统。

流数据存储针对流数据的应用场景需要满足以下需求：

• 低延时：在高并发条件下 <10ms 的读写延时。

• 仅处理一次：即使客户端、服务器或网络出现故障，也确保每个事件都被处理且只被处理一次。

• 顺序保证：可以提供严格有序的数据访问模式

• 检查点：确保每个读客户端 / 上层应用能保存和恢复原来的使用状态

从访问模式角度看，Pravega 需要统一传统批数据和流数据，因此不仅需要实时到达数据的低延时 (low latency) 读和写，还要满足对于历史数据的高吞吐 (high throughput) 的读。

技术在某种程度上一定是来自此前已有技术的新的组合。 --《技术的本质》，布莱恩·阿瑟

Pravega 也并不是凭空发明出来的，它是以前的成熟技术与新技术的组合。Pravega 团队拥有着基于日志存储的设计经验，也拥有 Apache ZooKeeper/BookKeeper 的项目历史，加之大量实时系统同样也采用日志存储的方式来完成实时应用的消息队列，想要满足这三种数据访问模式，自然想到了使用仅附加 (Append only) 的日志作为存储原语。

如图 3 所示：在 Pravega 里，日志是作为共享存储原语而存在的，数据以事件 (event) 的形式以仅附加的方式写入日志当中。

所有写入操作以及大部分读取操作都发生在日志的尾部 (tail read/write)。写操作将事件附加到日志中，而大量读客户端希望以到达日志的速度读取数据。这两种数据访问机制主要是需要低延迟。

对于历史数据的处理，读客户端不从日志的尾部读取，而是从日志中的任意位置开始读。这些读取称为追赶读 (catch-up read)。我们可以采用和尾部数据一样的高性能存储（例如 SSD）来存储历史数据，但这会非常昂贵并迫使用户通过删除历史数据来节省成本。这就需要 Pravega 架构提供一种机制，允许客户在日志的历史部分使用经济高效，高度可扩展的高吞吐量存储，这样他们就能够保留所有的历史数据，来完成对一个完整数据集的读取。

Pravega 逻辑架构

为了实现上述的三种访问模式的性能需求，Pravega 采用了如上图所示的分层存储架构。事件可以存储在低延迟 / 高 IOPS 的存储（第一层存储）和更高吞吐量的存储（第二层存储）中。通过这种方式，冷热数据分离有效降低了数据存储成本。上层使用 Apache ZooKeeper 作为分布式协调器，并提供统一的 Stream 抽象。

第一层存储用于快速持久地将数据写入 stream，并确保从 stream 的尾读尽可能快。第一层存储基于开源 Apache BookKeeper 项目。BookKeeper 是一种底层的日志服务，具有高扩展、强容错、低延迟等特性。许多 Apache 开源项目，例如 Apache Pulsar，Apache DistributedLog 都是基于这一项目实现。BookKeeper 对于复制、持久性、一致性、可用性、低延时的承诺也正是 Pravega 所需要的第一层存储的需求。为达到高性能的读写延迟需求，我们建议第一层存储通常在更快的 SSD 或甚至非易失性存储 (non-volatile RAM) 上实现。

第二层存储考虑到经济效益，选用高度可扩展，高吞吐量的云存储，目前 Pravega 支持 HDFS，NFS 和 S3 协议的二级存储，用户可以选用支持这些协议的大规模存储进行扩展。Pravega 提供了两种数据降层 (retention) 的模式，一种基于数据在 stream 中保留的时间，另一种基于数据在 stream 中存储的容量大小。Pravega 会异步将事件从第一层迁移到第二层，而读写客户端将不会感知到数据存储层级的变化，依然使用同样的 Stream 抽象操作数据的读写。

正是基于这样的分层模型，文章开头提到的三大问题被一次性解决。

1. 对于开发者而言，只需要关心 Stream 抽象的读写客户端的操作。实时处理和批处理不再区分对数据访问方式。
2. 数据仅在第一层存储有三份拷贝，在第二层存储则可以通过商业分布式 / 云存储自身拥有的高可用、分布式数据恢复机制（如 Erasure Coding）进一步降低存储系数，达到比公有云存储更便宜的总拥有成本 (TCO)。
3. 所有的存储组件归结为统一的 Pravega，组件仅包括 Apache ZooKeeper，Apache BookKeeper 以及可托管的第二层存储，运维复杂程度大大降低。Pravega 还提供了额外的“零运维”自动弹性伸缩特性，进一步减轻了数据高峰期的运维压力。

Pravega 的基本概念

本章节将简要介绍一些 Pravega 的基本概念。

Stream：Pravega 存储的抽象，类似于 Kafka 的 topic，是一种可持久化、可伸缩、仅附加、字节大小无限制的序列，具有高性能和强一致性的特性。在同一个 scope 内 stream 具有命名唯一性，stream 由一个或多个 segment 组成。用户可以在创建 stream 时配置降层策略 ( RetentionPolicy ) 和伸缩策略 ( ScalingPolicy )。

Scope：scope 是 stream 的命名空间，将 stream 进行分类和隔离。在多租户场景下，每一个租户拥有一个 scope。例如，具体应用、商业部门等可以划分 scope。

Segment：Pravega 最底层的存储单元，对应 BookKeeper 中的 ledger。stream 由 segment 组成，segment 是 stream 的分片，类似但不局限于 Kafka 的 partition。事件 (event) 存储在 segment 里。一个 stream 的 segment 的数量可以根据到达数据量和伸缩策略改变，同时也是该 stream 读取时的最大并行度。

事件（event）：Pravega IO 操作的最小单位，类似于 Kafka 的 message。事件是 stream 中的可以表示为一组字节的任何事物。例如：来自温度传感器的读数，网站点击和日志数据等。

Stream，segment 和事件的关系如下图所示。

路由键（Routing key）：事件所拥有的属性，路由键会通过一致性散列算法（consistent hashing）将事件读写到对应的 segment，因此相同的路由键会将事件路由到相同的 segment，由相同的读客户端读取。路由键是 Pravega 许多读写语义特性的基础。

写客户端（Writer）：写客户端是一个可以创建事件并将事件写入一个或多个 stream 中的应用，所有的事件数据都通过附加到 stream 的尾部来写入。

读客户端（Reader）：读客户端是一个可以从一个或多个 stream 中读取事件的应用。Pravega 会以负载均衡方式分配 stream 中的 segment 给指定的 Reader。读客户端可以从 stream 中的任何一点读取，比如头部、尾部、中间任何一点。

读者组（Reader Group）：读者组由读客户端组成，读者组本质上是为了实现同一个组内读客户端的并行化以及不同组的 stream 读取扇出，类似于 Kafka 的 Consumer Group。同一个读者组内的读客户端可以一起并行读取给定的一组 segment 内的事件。读者组由 name 字符串唯一标识。

Pravega 产品定位和与 kafka 的对比

前面我们已经提到过 Pravega 是从 存储的视角 来看待流数据，而 Kafka 本身的定位是消息系统而不是存储系统，它是从 消息的视角 来看待流数据。消息系统与存储系统的定位是不同的，简单来说，消息系统是消息的传输系统，关注的是数据传输与生产消费的过程。Pravega 的定位就是企业级的分布式流存储产品，除了满足流的属性之外，还需要满足数据存储的持久化、安全、可靠性、一致性、隔离等属性，关注数据的生产、传输、存放、访问等整个数据的生命周期。作为企业级的产品，一些额外的特性也有支持，例如：数据安全、多租户、自动扩缩容、状态同步器、事务支持等，部分特性将在后续文章详述。

这里我们把 Pravega 与 Kafka 做了对比，大体在功能上的差异如下表所示。功能上的差异也只是说明各个产品针对的业务场景不同，看待数据的视角不同，并不是说明这个产品不好，另外每个产品自身也在演进，因此本对比仅供参考。

总结

本文从商业痛点出发，分析了分布式流存储 Pravega 的需求，重点介绍了 Pravega 的关键架构以及关键特性，另外还与 Kafka 做了简要对比。有关 Pravega 的更多详细信息，请参阅官方网站以及关注我们的后续文章。

Pravega 系列文章计划

Pravega 根据 Apache 2.0 许可证开源，我们欢迎对流式存储感兴趣的大咖们加入 Pravega 社区，与 Pravega 共同成长。下一篇文章将会从 Pravega 的应用实例出发，阐述如何使用 Pravega。本篇文章为 Pravega 系列第二篇，后面的文章标题如下（标题根据需求可能会有更新）：

1. 实时流处理 (Streaming) 统一批处理 (Batch) 的最后一块拼图：Pravega
2. Pravega 设计原理与基本架构介绍
3. Pravega 应用实例
4. Pravega 动态弹性伸缩特性
5. Pravega 的仅一次语义及事务支持
6. 分布式一致性解决方案：状态同步器
7. 与 Apache Flink 集成使用

作者简介

• 滕昱：就职于 DellEMC 非结构化数据存储部门 (Unstructured Data Storage) 团队并担任软件开发总监。2007 年加入 DellEMC 以后一直专注于分布式存储领域。参加并领导了中国研发团队参与两代 DellEMC 对象存储产品的研发工作并取得商业上成功。从 2017 年开始，兼任 Streaming 存储和实时计算系统的设计开发与领导工作。

• 吴长平，现就职于 DellEMC，10 年 + 存储、分布式、云计算开发以及架构设计经验，现从事流存储和实时计算系统的设计与开发工作；

• 周煜敏，复旦大学计算机专业研究生，从本科起就参与 DellEMC 分布式对象存储的实习工作。现参与 Flink 相关领域研发工作。

参考链接

1. https://www.pravega.io