简介：随着5G 网络、容器云、高性能存储硬件程度的一直进步，流解决正在领有越来越宽泛的市场前景。

作者 | 滕昱（戴尔科技团体 软件开发总监）

随着5G 网络、容器云、高性能存储硬件程度的一直进步，流解决正在领有越来越宽泛的市场前景。

各种各样的设施传感器、监控摄像头、挪动终端设备等等无时无刻不在产生着大量的流式数据。针对不同的场景，流式数据兴许会有各式各样不同的特点，然而对于这些流式数据的解决，往往都有实时或者靠近于实时的、无边界连续不断的、低延时的共性要求。而这些要求，恰好就是流解决的根本特点。

仅仅从这些根本特点看，如同流解决早曾经被实现了。不论是70年代开始衰亡的规定引擎，还是基于传统的关系型数据库的简单海量数据处理，貌似都符合要求，甚至在编程语言里都既有了对这些解决零碎的反对。然而Stonebraker，Çetintemel和Zdonik在2005年的论文《The 8 Requirements of Real-Time Stream Processing》中指出，现有的这些零碎其实还不能真正满足流解决的要求，流解决技术还须要进一步的倒退。

这也是为什么现阶段蕴含Flink在内的流批一体的大数据技术栈继续在不停倒退的起因。IDC报告指出，将来的3~5年整个实时数据会以惊人的速度增长。那么不论是针对实时数据的流解决，还是针对历史数据的批处理，也都须要同步的倒退来满足时代的要求。

这些流批一体的大数据技术栈的倒退，不光蕴含Flink等解决引擎的进化，也包含存储畛域。那么在存储畛域，针对古代流解决，又有哪些进化和倒退呢？

传统来说，数据往往以文件的模式组织，用文件系统加以治理。

然而，文件接口形象真的能很好的解决流式的间断数据么？让咱们来看一看。

首先，假如咱们用文件和文件系统来做一个流存储。把传感器、用户日志、用户输出这些数据注入一个文件中，貌似并没有什么问题。然而被写入文件的数据必须被继续一直的读取进去。也就是说，继续一直被写入文件的数据，必须不停的被读取进去用以解决，这是文件接口和针对间断数据流解决最基本的区别。

其次，当数据质变大的时候，并发是必须的。咱们当然能够利用多个文件实现并发写。但这也意味着读端的应用程序必须追踪多文件读。为减少并发而带来的多文件读取的协调和追踪并没有蕴含在文件接口的形象里，所以这对读应用程序来说，并不是通明的。

第三，如果进一步思考动静扩大呢？动静扩大意味着在程序读取的过程中再动静生成新的文件或者合并已有文件以适应新的并发度。在这种状况下，读端应用程序须要本人监测在读文件的新增和缩小，这是除应用程序自身业务逻辑之外额定的工作。

第四，数据是间断无边界的，须要一种标记来记录以后数据的读取地位。横跨多个文件去设计逻辑上全局统一的地位点，进一步减少了应用程序的复杂性。

第五，IOT场景往往须要保护针对同一设施号的数据序列。如果把设施数据当作文件，把设施号当作key，那么注入端须要key到文件的映射解决并保护在同一key命名空间下的per-key order。同时，读取端还得做到多文件读取的负载平衡。这些都是文件和文件系统形象不能实现，所有的工作都推向了下层应用程序。

第六，对于流解决来说，数据的革除往往是从流数据的头开始删除，先写入的先删。文件接口形象并不能很好的解决这点。

近些年来，业界其实是广泛应用了一个两头解决方案，通过messaging零碎（比方Kafka）+文件系统的混合形象计划注入。这解决了局部问题，比如说动静扩大、注入端的并行问题。然而这不是一个残缺的端到端解决方案。实时流计算是走了messaging接口躲避了文件接口的一些问题，然而针对历史数据的批处理还是须要文件接口，这实际上是针对同一数据的两种零碎。

所以，对于间断的流式数据的存储层形象，咱们须要的既不是原来的基于传统数据库的实现，也不是基于messaging零碎的转化，而是从头设计一个残缺的流存储系统。

那么，这种流存储的形象能给下层的计算单元带来什么样的益处呢？让咱们来具体看一下。

首先，对于之前提到的messaging零碎+文件系统，数据须要用stream接口进入messaging零碎，然而可能以文件接口方式读出，在接口形象上并不统一。咱们须要的流存储形象，不论是注入端还是读取端，都是stream接口，给应用程序对立的形象。

其次，流存储形象须要提供动静扩大性能。在应用程序看来，它只须要往一个stream里写入数据。至于这个stream形象怎么基于注入量进行动静扩大，或者在多路并发下怎么保障per-key的order，由形象层外部解决，对应用程序齐全通明。

第三，在所有状况下，哪怕是动静扩大过程中，从流存储形象层读出的数据，具备per-key的order保障。

第四，流存储形象可能在逻辑上提供基于工夫的全局统一的地位点，咱们称之为Stream Cut。应用程序依赖于此可能回放到任意一个地位点，回放或重试业务逻辑。

计算引擎例如Flink可能利用流存储形象提供的Stream Cut，基于流存储系统解决的checkpointing性能，实现端到端的exactly-once保障。这在文件形象接口上，是很难做到的。

除此之外，还有很多其余针对streaming典型场景的的益处，例如原子读写，低延时的tail read、事务反对、历史数据truncation等等。

那么，假如有了这个很好的流存储形象呈现，它能做什么？

咱们可能基于这层形象，建造更简略、更分明的大数据的流水线。

海量的间断流式数据注入这个流水线，被保留到流存储中。以Flink为代表的流批一体的处理单元用流存储提供的对立接口，包含针对流解决的低提早的tail read，以及针对批处理的高吞吐的historical read，针对同一份数据，提供反对exactly-once语义的数据处理。一种形象一套解决，简化流程。

当然理论中流水线会更加简单一些。数据往往是被写入Edge端，进行on-the-fly的实时计算解决，比方监控摄像头拍下的图片图像的预处理。同时，数据也能够被发送到数据中心的公有云或者是私有云上，作更大规模的准实时的一个计算。这样的形式，让大数据流水线的开发变得十分的分明和简洁。

Pravega（梵语：high speed）就是在流存储形象的需要背景下应运而生的零碎，具备后面提到的流存储形象的所有特点。Pravega是2016年创立开源我的项目Apache2 License，近期已被退出CNCF。

上面咱们就来看看，Pravega是怎么提供以上提到的流存储形象的这些属性的。

首先，对于近期写入的数据，Pravega提供低提早的tail read。同时，Pravega底层由可扩大的软件定义存储实现，能够反对有限历史数据存储。并且这些历史数据同样通过streaming接口读取，以实现针对历史数据的流解决。其次，Pravega反对动静扩大。依据前端流量的大小，Pravega可能动静调整partition的数量以适应前端流量，对客户端通明。再次，Pravega提供StreamCut不便客户获取基于工夫的数据分片，用来实现数据会放解决性能等。当然，Pravega还反对以streaming接口truncate数据，从头读取历史数据等等。基本上之前提到的相干特点在Pravega里都能找到相应的性能反对。

那Pravega具体是怎么实现的呢？

当创立一个stream的时候，和其余可扩大零碎不同，用户并不需要指定并发的个数。在Pravega外部，segment是真正的数据存储单元。一个stream能够领有一个或多个segment(s)。Pravega通过动静调整segment的个数实现动静扩大。

所有写入stream的数据都被当作是一串append only的bytes最终写入segment中。能够是一行log，能够是一张图片，通过serializer/deserializer决定语义，没有格局的限度，也没有必须是小文件的限度。

当stream领有多个segment的时候，数据会并发写入这多个segment中。这多个segment将namespace分成等同数量的key space，写入的数据能够通过绑定routing key，决定本人写入哪个key space（segment）中。雷同routing key的数据会被写入同一个segment中，取得order保障。比方，传感器产生的间断数据都能够应用传感器的设施号作为routing key，以保障同一传感器产生的数据领有雷同的routing key而被写入同一个segment，以保障读取时的时序性。实际上，Pravega的transaction，exactly-once等个性正是基于此实现的。

讲了那么多动静扩大，上面给大家一个具体的例子看看它的实现。假如零碎中创立了一个stream，开始的时候他只有两个segment。

当注入流量翻倍的时候，Pravega可能检测到这点，并且将segment的个数从2个扩大成4个。这点不须要用户的任何干涉，不须要扭转配置、扩大节点、起停服务等等，所有的都无缝产生在Pravega外部，对用户通明。

同样，当注入流量缩小时，Pravega也能相应的合并segment，去除不必要的并发节俭资源应用。

Pravega的这种动静扩大机制，联合container化的部署形式，让Pravega真正实现了cloud-native的分布式可扩大的流存储系统。

上面是Pravega的架构图。右边是一个十分形象的stream，用户通过Event Stream Writer/Reader通过streaming接口读写数据。左边能够分成两局部，控制面板和数据面板。控制面板负责管理和保护stream和segment，比方stream的创立， segment的调配部署，以及segment的动静扩大等。数据面板以segment为单位治理数据。写入segment的数据首先会被写入Durable Log实现数据的长久化爱护。同时数据也会缓存在Streaming Cache中，提供高性能的读取。所有写入的数据在积攒后会通过优化算法打包写入底层可扩大的Long-term Storage，通过分级存储保留历史数据。这层Storage只做数据存储性能，对于历史数据的读取仍然通过Pravega的streaming接口提供。数据面板除了通过segment来治理用户数据外，也通过Table segment治理本人的metadata数据。它同样反对动静扩大，防止了很多零碎用zookeeper寄存metadata是遇到的扩大问题。

好，到此为止，咱们应该理解到Pravega的确是合乎流存储形象的实现。那么随后的一个问题是，反对了这么多灵便的性能，实现应该很简单吧。这样的一个流存储系统，运行起来到底性能会怎么样呢？毕竟对于实时性要求比拟高的流解决来说，性能是至关重要的。

为了验证这点，咱们把Pravega 0.8部署在AWS规范服务商，用业界规范的OpenMessaging Benchmark零碎，对Pravega的性能进行了测试和取样。残缺的后果在《When speeding makes sense — Fast, consistent, durable and scalable streaming data with Pravega》（https://blog.pravega.io/2020/10/01/when-speeding-makes-sense-fast-consistent-durable-and-scalable-streaming-data-with-pravega/）这篇博客上能够找到。

这里咱们截取了其中的一些对Pravega的性能进行一些介绍。

上面这张图显示了Pravega在1个segment和16个segment下，随着注入量的一直减少，Pravega的性能体现。咱们能够看到，Pravega性能针对不同segment并没有太大区别，都可能做到低延时高吞吐。随着注入量的增大，性能成稳固线性变动。足以阐明Pravega在性能方面的亮眼稳固体现。

此外，咱们还和messaging零碎（Pulsar）比照了分级存储的性能。测试中，对于同样部署在AWS上Pravega和Pulsar，咱们用OpenMessaging对两套零碎用雷同的注入速度继续写入15分钟，以使两套零碎上有大概100GB的历史数据。而后同时关上读端读取数据，考验两套零碎对于历史数据读取的体现。从图上咱们能够看到，Pravega在短短几分钟内就可能读取并消化掉之前的历史数据，追赶上前端新的写入。而Pulsar破费80分钟仍然没有做到。这也正是Pravega作为一个流存储系统而不是messaging零碎必须具备的劣势，对历史数据的存储和读写同样重要。

对于Pravega引以为傲的动静扩大机制，咱们也给出了相干测试。在上面的图示中，测试stream刚开始只有1个segment。在高注入量的继续注入下，图示能够看到stream的segment每隔大概10分钟主动扩大一次，随着每次扩大，零碎提早升高一次。整个过程齐全主动，最终零碎会针对注入的数据量，达到最佳性能均衡。完满的设计！

那是不是segment越多越好呢？咱们都有相似的教训，segment越多，资源竞争越强烈，零碎会呈现超负载的状况，性能反而会更糟。那Pravega是这样的状况么？

咱们也做了和Kafka的比照图。当segment个数从1涨到10的时候，的确，对于两套零碎来说，segment个数越多，吞吐率越高。然而显然，10是峰值，超过当前Kafka如教训意料的一样，性能开始有了显著降落。然而Pravega仍旧可能维持峰值的高性能不变。足以阐明Pravega的性能在扩大时的稳定性。

由上所有的架构介绍和性能剖析，咱们能够看到，Pravega的确是一个合格的企业级的cloud-native分布式可扩大流式存储系统。

有了这样一个零碎，建造企业级的流解决零碎变得绝对简略。咱们就基于Pravega建造了一个可扩大的流批一体的流式搜寻零碎：Pravega Search。

能够把Pravega Search看作是相似于Elasticsearch或者Splunk产品相似的搜寻零碎。它同样能够针对注入数据创立索引，通过索引查问提供搜寻后果。然而，Pravega Search思考流解决的特点，反对针对流数据的continuous query。在间断数据的一直注入时，同时给出实时的计算结果。这是Elasticsearch所没有的。

这就是基于流存储系统Pravega构建流解决利用的便捷和劣势。在批流一体的流水线上，Pravega stream作为数据管道，把下层一个个的计算单元耦合起来。比方图中所示，用户数据流入Pravega stream后，流入continuous query进行计算，计算结果数据又从新流回Pravega stream一直套接。同时，不论是针对流解决的continuous query还是基于历史数据的传统批处理，数据只存储了一份，防止了当初批流一体的大数据处理流水线上数据在多个不同集群之间反复复置存储的问题。

综上所述，随着流解决的一直倒退，流存储系统也从晚期的基于传统数据库，到当初的新型架构体系一直倒退，并且仍然领有广大的发展前景。

在将来流存储系统的倒退蓝图里，message零碎曾经不能齐全满足技术倒退对于流存储系统的所有空想。Pravega应流存储系统需要而生，提供纯正的流存储形象，旨在促成批流一体的大数据流解决零碎的倒退。

作为CNCF的大数据流解决生态中的一员，Pravega和其余开源流解决零碎例如Flink，必将给大数据流解决畛域倒退带来新的色调，让咱们刮目相待！

流动举荐：

仅需99元即可体验阿里云基于 Apache Flink 构建的企业级产品-实时计算 Flink 版！点击下方链接理解流动详情：https://www.aliyun.com/product/bigdata/sc?utm\_content=g\_1000250506

版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。