共计 6696 个字符，预计需要花费 17 分钟才能阅读完成。
简介： 随着 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
版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。
