共计 3418 个字符，预计需要花费 9 分钟才能阅读完成。
本篇内容整顿自 Pravega 中国社区创始人、戴尔科技团体软件工程技术总监滕昱在 Flink Forward Asia 2021 主会场的演讲。次要内容包含：
- 存储形象的现状
- Pravega 性能架构详解
- Pravega 流存储数据演示
- 展望未来
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 在内的数据湖仓相干的开源社区沟通单干，为企业级用户构建更敌对、更弱小的新一代数据流水线。
FFA 2021 直播回放 & 演讲 PDF 下载
更多 Flink 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～
