下一个分布式存储系统，为万物互联的智能世界而发-InfoQ



 写点什么

如果说互联网和云计算使得对象存储在存储市场上与块存储、文件存储三分天下，相应的业务需求直接奠定了对象存储与块存储、文件存储并列存储江湖一哥的地位，那么接下来也许我们需要为下一场数据变革的大事做好准备 – 万物互联这样的商业场景将给数据存储带来极大的商业挑战和技术挑战。

万物互联下的数据

纵观人类历史，各种技术变革都是以人类活动为中心，然后发明各种工具。石器时代，原始人发明了石器以及用火从而提升了生活品质和社会文明。现代社会，人类为了解决各种寂寞空虚冷吃穿住用行、生理和心理上的各种需求从而发明了各种社交空间、社交工具、网络购物、生活服务 APP 等，为了更好的服务这些应用场景，挖掘这些场景所生产的数据的价值，从而有了今天的各种大数据技术。

在互联网时代，数据主要来源于网页、APP 以及一些相应的日志系统，而在万物互联的世界，数据还可以来源于有各种传感器、工业设备、监控设备、检测设备、智能家居、自动驾驶等。大数据的四个特征：数据量、时效性、多样性、价值密度在万物互联的场景下被进一步的深化，这就意味着商业成本以及技术成本的增加。

理论奠定技术的基础，业务驱使技术的变革。在万物互联的智能时代，我们有一个愿景：能够将万物互联下生成的海量原始数据转化为可用的信息以及行为决策，并且这个转换的时间差需要能够接近于零。 而需要实现这个愿景，从技术角度来看，需要有计算层面的解决方案也需要有存储层面的，如今在计算层面已经有 Flink、Spark 等这类成熟的分布式计算应用，然而在存储层面还没有。

流数据与流存储

在万物互联的场景下，各种传感器以及设备生成的数据有其原生的属性，这种数据自带时间戳、实时性要求高，而且是 “流数据” 。

首先流数据在百度百科里是这样被定义的：

流数据是一组顺序、大量、快速、连续到达的数据序列，一般情况下，数据流可被视为一个随时间延续而无限增长的动态数据集合。应用于网络监控、传感器网络、航空航天、气象测控和金融服务等领域。

从数据的生产与传输场景来看流数据具有几个与众不同的带有破坏性的特性：

数据随时间延续而无限增长，这意味着数据的无限性；
数据到达的速度有快有慢、负载有高有低，这意味着灵活又细粒度的资源弹性需求；
数据有序、无序、持久化以及复杂的传输环境而又要保证数据处理结果的唯一正确性。

这是三个特性转换成存储技术的语义对应着： 无限性、可伸缩性以及恰好一次：持久化、有序、一致性以及事务。

从 存储的视角 来说，每种类型的数据都有其原生的属性和需求，对应有最佳的适用场景以及最合适的存储系统。跑在数据库里的数据对实时性和可靠性要求非常的高，因此适合采用块存储系统。文件共享场景下需要向用户共享文件，多个用户可以共享读取一个文件，因此适合采用文件存储系统。而互联网网页与 APP 里的文件、图像、视频可以看作一个个的数据对象又需要租户隔离以及无限扩展，因此又非常适合采用对象存储系统。那么目前又有哪种存储系统最适合用于 “流数据” 呢？

正如当前技术条件下最适合 “流数据” 计算的是类似 Flink 这样的分布式流计算应用，最适合“流数据”的应当是 分布式流存储系统。

分布式流存储系统

产品定位

分布式流存储系统的产品定位是给万物互联这样的应用场景服务的，从技术角度来看它具有自身的特点，正如标题里提到的三个关键词： “分布式”、“流”、“存储” 。首先是分布式的，它具有分布式系统本身所具有的一切能力，接着表示是专门给流式数据设计和实现的，最后的存储表示的是一个原生的存储解决方案，它讲究数据的 可靠性、持久化、一致性、资源隔离等 ，它从 存储的视角 处理流数据。分布式流存储针对 “流数据” 的自身属性以及相应的特殊的业务需求场景做了专门的设计与实现，下面从 命名空间、业务场景、无限性、可伸缩性、恰好一次、字节流、数据管道、租户隔离、海量小文件、数据治理、流式架构 的角度依据 最佳实践原则 讲述了为什么需要专门设计和实现一个流式存储系统。

命名空间

通常，块存储系统以 分区、目录、文件 ，文件存储系统以 目录、文件 ，以及对象存储以 租户、桶、对象 来定义数据的存储路径以及命名空间，而流存储系统则以 范围(scope)、流(stream)、段(segment)、事件(event) 来描述数据的存储路径以及命名空间。

类型	命名空间
块存储	分区、目录、文件
文件存储	目录、文件
对象存储	租户、桶、对象
流存储	范围、流、段、事件

在流存储系统里，如下图所示，数据的组织形式被抽象成范围、流、段和事件，范围由流组成，流由段组成，段由事件组成，事件由字节(bytes)组成。

流的组成

业务场景

可穿戴设备、自动驾驶与工业厂房

可以想象一下这样的业务场景：某个商家销售了几千万个智能手表，这些智能手表可以记录每个用户每天走了多少步，同时还可以分析过往的历史数据，用柱状图给用户展示历史数据，如下图所示：

步数分析

考虑到信息安全，用户 A 是不能看到用户 B 的数据的，那么就需要按智能手表为单位进行租户隔离，这种的场景下就有几千万个租户，同时每个租户还有自己的存储空间配额，比如给每个智能手表分配 5GB 存储空间。光是这样的租户隔离场景，依据 最佳实践 的系统设计原则，不管是块存储系统、文件存储系统、对象存储系统还是 Kafka 这样的消息系统，按他们本身的隔离特性以及支持的租户规模都是难以在单个系统里支持这样的租户隔离场景。但是用流存储来实现就很方便，比如以智能手表的业务场景为例：

默认分配 5GB 存储空间给一个智能手表，然后定义一个智能手表类型的命名空间用于与其他智能设备进行隔离，给每个智能手表分配一个流，每个智能手表上报的字节数据以事件为单位存储在流内的段里。
也可以这样来定义：给每个智能手表分配一个 5GB 存储空间的命名空间，手表里的每个传感器都对应一个流，每个传感器以事件为单位上报字节数据存储到流的段里。

还可以想象一下这样的业务场景：自动驾驶。采用分布式流存储的话，我们可以这样处理自动驾驶的数据：给每一辆无人车定义一个 1TB 存储空间的范围，车上的每个传感器都归属于一个流，传感器上报的事件都在段内持久化。再假设每辆车都有 1000 个传感器（实际情况只多不少），那么 10 万辆车就需要定义 1 亿个流，可以想象要进行这种规模的隔离也就只有这种专门针对流数据而设计的流存储系统能够支持。

在工业互联网的场景下，还可以这样定义工业设备的数据：给一个厂房里的每台设备定义一个范围，每台设备里的每个传感器都对应一个流，传感器上传的事件数据保存在流内的段里，这样就很方便的对工业设备进行了大规模的租户数据隔离。

因此，以 “范围、流、段、事件” 的方式很方便的进行了大规模的租户隔离保证了用户信息安全同时又进行了存储资源配额的隔离。

大数据处理平台

万物互联场景下无限量的数据给数据处理技术带来巨大的挑战与压力，不同的应用场景意味着不同的数据处理要求与复杂度，要把这些不同的甚至矛盾的数据处理要求都很好的综合在一个大数据处理系统里，对现有的大数据处理技术来说是个非常大的挑战，比如无人车的处理要求毫秒甚至纳秒级的数据处理实时性、而有些工业设备数据只需要分析历史数据，要让一个大数据处理系统既能能处理历史数据又能提供毫秒级甚至纳秒级的实时性处理能力还能应对各种不同格式不同传输场景的数据，而且每种数据处理都能达到这些应用场景原生指标的处理需求。相信这样的场景对工程技术人员来说是个很大的挑战。为了解决上述问题，按照现有的成熟的技术能力，通常开发人员采用类似 Lambda 架构（如下图）这样的大数据处理平台来处理大数据。

Lambda 架构

Lambda 架构即支持批处理也支持实时处理，能应对数据的多样性、具有容错功能、复杂性分离、能处理流式数据也能处理历史数据等优点，但是缺点也很明显：批处理一套独立的数据处理路径，实时处理又一套数据处理路径，然后还要合并结果再输出展示，同时系统里同样的数据存在存储多份的问题，比如同样的数据在 Elasticsearch 里有、HDFS 里有、ceph 里有、Kafka 里也有，除了这些甚至还存在其他一些复杂的存储组件，而且同样的数据还都是多份冗余的，因此存储成本太高太过于复杂。Lambda 架构里为了提供一个功能却引入一个组件，在复杂之上堆积复杂，存储成本、开发与运维成本都太过于复杂。

那么应当如何解决 Lambda 架构带来的这些缺点？ 以数据流向为核心 重构大数据处理平台是一个比较好的方案，它具体包括数据的采集、聚合、传输、缓存、持久化、处理、展示等。依据这种设计理念我们可以推出一个端到端的原生的流式大数据处理平台：原生的流式计算加上一个原生的流式存储并且可以平衡商业成本与技术成本。

流式计算可以采用 Flink，然而并没有发现当前有合适的流式存储可以使用，如果采用 Flink 加上传统的文件存储或者块存储、对象存储的方式，也只能认为是半原生的大数据处理平台： 计算是原生的流式计算而存储却不是原生的流式存储 。

因此，综合思考万物互联场景下的数据处理场景也需要一个原生的分布式流存储系统， 重构 Lambda 架构里的存储栈 ，使得分布式流计算加上分布式流存储即为原生的流式大数据处理系统，同时还能很好的平衡商业成本与技术成本之间的关系。

数据无限性

无限性是分布式流存储最为重要的设计原则。从流数据的角度来看，数据是大量、快速、连续而又无限的，这就给流存储系统的设计与实现带来极大的困难，无限的数据使得存储系统必须能支持连续且无限规模的数据流，光这一点就对存储系统的可扩展性要求非常的高，同时还要求存储系统能够根据到达的数据量动态而又优雅地进行扩容与缩容。从技术与成本的角度来看，数据无限性意味着冷热数据分离，长期不用的数据淘汰到长期存储系统里，热点数据需要缓存，同时还需要能支持历史数据的读取与实时数据的读取与写入。

可伸缩性

可伸缩性也是分布式流存储最为重要的设计原则之一，而且流存储里的可伸缩性要求还是自动化的资源细粒度的可伸缩。通常，在云原生的场景下，资源的缩放是以主机、虚机或容器为单位的，这样的缩放对流存储来说粒度太大。在流存储的场景下需要能够以数据的 “流段” 为单位，比如一个流段 2MB，那么就需要能支持一次自动扩容或缩容 2MB 的存储空间。另外在流存储里还要求写入与读取对数据子集的操作是解耦分离的，并且写入与读取二者之间跟数据流段还要有一个合理的平衡。

恰好一次

恰好一次也是分布式流存储最为重要的设计原则之一，恰好一次意味着数据的可持久化、有序、一致性以及事务性的支持。持久性意味着一旦得到确认，即使存储组件发生故障，写入的数据也不会丢失。有序意味着读客户端将严格按照写入的顺序处理数据。一致性意味着所有的读客户端即使面对存储故障、网络故障也都会看到相同的有序数据视图。事务性写入对于保证 Flink 这样的计算应用处理结果的完全正确是非常必要的。

字节流

分布式流存储里采用字节流的格式组织数据而不是像消息系统里采用消息报文的方式，这意味着接口的通用性。二进制的字节流是与数据格式无关的，字节流可以组成事件封装在分布式存储的流段里。而消息系统里数据是消息头消息体的格式封装的，在兼容性上不如字节流。

数据管道

在存储界通常喜欢用跑车、卡车、渡轮来比喻块存储、文件存储以及对象存储，打个比方来说块存储类似跑车：极快、极稳、装的人少、成本高；文件存储类似卡车：快、稳、装的人比跑车多，但是没跑车那么快；对象存储类似渡轮：可以装非常多的货，讲究量大、成本低；那么分布式流存储像什么呢？在我们的定义里它就像管道： 数据如同流水一般流过管道，又快又稳源源不断而又永无止境 。

租户隔离

分布式流存储从一开始设计的时候就将”租户隔离“作为其基本特性进行实现，”隔离“是分布式流存储的最基本的特性之一，在分布式流存储里租户隔离不只是租户 B 绝对不能看的到租户 A 的任何信息这样的信息安全层面的隔离，它支持范围、流、段、事件层面的隔离还将支持的租户规模作为设计的目标之一，在分布式流存储里单集群需要能支持千万量级起的租户数，另外还有资源、命名、可视空间、权限以及服务质量层面的隔离。

海量小文件

对巨量小文件的支持是分布式流存储的设计原则之一。正如前面提到的，万物互联下的海量数据来源于传感器，而传感器上传的数据都是类似温度、地理位置、告警信息这样的几个字节几个字节的小数据，这就意味着在万物互联的场景下会有巨量的小数据上传，而且 90%以上的数据操作行为都是写入。为了保证数据写入的性能以及可靠性、正确性、持久性以及保证介质的使用寿命降低成本，这也需要存储系统针对这种业务场景进行专门的设计。

在分布式流存储里每个事件第一步是被仅附加写入一个缓存的段内进行封装的，在段达到一定的尺寸（比如 64MB）后会被封闭不再写入，这时再将整个段写入下一级的持久化存储里。通过这样的设计，实现小数据在缓存里封装成大块的数据，再将大块数据写入持久化存储设备的方式保证了存储系统整体的性能。

数据治理

当前的大数据处理平台，不管是 Kappa 架构还是 lambda 架构，数据的存储都是多组件化、多份化的。比如同样的数据在 Kafka 里有、在 HDFS 里有、在 Elasticsearch 里又有，有些用户还使用了更多的存储中间件，而且这些数据还是多份冗余的。这一方面增加了数据的存储成本，另一方面也降低了数据的可信性、可靠性、合规性，给数据标准化以及数据的重复利用带来了困难，不利于数据的分享、合规、降低成本以及安全可靠地支持业务和决策。数据治理也是分布式流存储的基本设计原则之一，通过使用分布式流存储，大数据处理平台的架构可以进化成 ”分布式流计算+ 分布式流存储“ 这样的原生流式数据处理平台架构。

流式架构

下图体现了 ”分布式流计算+ 分布式流存储“ 这样的原生流式大数据处理平台的架构理念。

流式架构

这个架构体现了 “流原生”(stream native)式 的设计哲学，“流原生”的计算加上“流原生”的存储管道组成了“流原生”的大数据处理平台。数据从分布式流存储输入经过 map 算子计算，输出中间计算结果到分布式流存储里，数据又从分布式流存储里读入到 Filter 算子里，再经过计算，中间结果放到了分布式流存储里，再最后的计算结果经过聚合算子的计算放到了目的地的分布式流存储里。这个过程体现了算子编排和管道式编程的设计哲学，在这里分布式流存储起了大数据处理平台里的管道的作用。

同时，在分布式流存储里数据的存储单位是流段，当输入的数据速率或者负载增加时，流段就会自动扩容，通过流协议联动，流计算应用的算子也相应扩容。相应的，如果输入的数据速率或负载降低，流段就自动收缩，通过流协议联动，流计算应用的算子也相应的缩容，所有这些行为都是自动完成的，无需人工干预，这种行为体现了分布式流存储的细粒度可伸缩性。