解构“存算分离”

一、计算与存储为何要分离

        在计算机中，我们所说的计算其实指的是由CPU和内存组成的算力单元，存储指的是持久化的数据存放单元。从单体计算机的角度来讲，计算存储分离其实并不现实。我试想一下，如果将计算机的计算和存储单元分开，指令都需要通过网络来传输，以目前网络的速度是很难与CPU计算速度相匹配的，所以从单体计算机的角度来讲，计算与存储分离是一个伪概念。

        不管我们承认与否，其实是网络一直在制约基础IT架构的演进和发展，过去由于网络带宽的限制， 我们习惯性的把计算和存储偶合在一起，以减少网络传输的压力，比较典型的就是MapReduce和 Hadoop，就是用本地IO代替网络传输，是计算和存储耦合在一起的典型场景。但是随着网络技术 的发展，网络带宽和网络质量已经不再是瓶颈，磁盘IO反而没有明显的增长，计算和存储耦合在架 构上的缺点也逐渐暴露出来：

         1、耦合带来资源浪费：作为底层的资源平台，基础IT环境的资源总是有限的，站在业务的角度是计算先达到瓶颈，还是存储先达到瓶颈，他们的时间点是不一样的。由于计算和存储的耦合设计，无论扩计算还是扩存储，都会造成资源的浪费；

         2、服务器款型繁杂，维护难度大：从运维的角度来讲，降低服务器的款型是降低运维难度和工作量的有效手段。但是由于计算和存储的耦合设计，随着业务复杂度的增加和新业务线上的加快，对服务器资源配比的要求也会随之增加，维护一个繁杂的服务器款型表可以是一件好玩的事情；

        3、耦合造成扩容不便：计算和存储耦合在一起还有另外一个坏处，那就是每次扩容都需要考虑数据的迁移，给本来简单的扩容工作带来很多风险和不可控因素。 从上面的分析来看，架构不是一成不变的，会根据技术的发展和业务的发展进行演进和升级，计算和存储的分离设计，就是在这样一个背景下进入大家视野的。

二、计算与存储分离的应用场景

        计算和存储分离主要应用在哪些方面呢，主要是数据库和消息队列：

        1、数据库

         以传统的主从结构的数据库系统为例，主库接收数据变更，从库读取binlog，通过重放binlog以实现数据复制。在这种架构下，当主库负载较大的时候，由于复制的是binlog，需要走完相关事务， 所以主从复制就会变得很慢。当主库数据量比较大的时候，我们增加从库的速度也会变慢，同时数据库备份也会变慢，我们的扩容成本也随之增加。因此我们也逐渐开始接受走计算和存储分离的道路，让所有的节点都共享一个存储。也许我们对这样的场景习以为常，其实这就是典型的计算和存储分离设计，现在很多的数据库都在逐渐向“计算和存储分离”靠拢，包括现在的PolarDB、 OceanBase ，TiDB等等。所以“计算和存储分离”应该是未来数据库的主要发展方向。

         2、消息队列

        消息队列不论是Kafka还是RocketMQ其设计思想都是利用本地机器的磁盘来进行保存消息队列， 这样其实是由一定的弊端的。首先容量有限，本地空间毕竟容量有限很容易造成消息堆积，会导致我们要追溯一些历史数据的时候就会导致无法查询，然后在扩容的时候只能扩容新节点，扩展成本也比较高。针对这些问题ApachePulsar出现了。 在Pulsar的架构中，数据计算和数据存储是单独的两个结构。数据计算也就是Broker，其作用和 Kafka的Broker类似，用于负载均衡，处理consumer和producer等，如果业务上consumer和 producer特别的多，我们可以单独扩展这一层。数据存储也就是Bookie，pulsar使用了Apache Bookkeeper存储系统，并没有过多的关心存储细节。这样做的好处就是，只需要关系计算层的细 节和逻辑，存储部分采用成熟的方案和系统。 其实Kafka也在向这些方面靠拢，比如也在讨论是否支持分层存储，但是是否会实现存储节点的单 独设置也不一定，但“计算和存储分离”的方向应该是消息队列未来发展的主要方向。

三、大数据架构中的存算分离应用

        传统的大数据架构中，数据计算和存储的资源都是共用的，比如CDH的集群配置，每个节点既是 YARN计算节点又是HDFS存储节点，其实这种设计也是源于Google的GFS。在Hadoop面世之初，网络带宽很低，为了减少大数据量的网络传输，Hadoop采用了尽量使用节点本地存储的设 计，这就形成了计算和存储耦合的架构。

        近年来CPU算力和网络速度增速远快于存储，数据中心有足够的带宽来传输数据，随着数据量的增长，多副本的设计和考虑也造成了成本的飙升，计算和存储绑定的设计实用性开始变差。随着 Spark和Flink等框架逐渐代替MapReduce，批处理和流处理同时共存，也改变了旧有的业务模型，这些都需要新的大数据架构去适配。计算和存储分离的大数据架构开始进入视野。

        现在很多新的大数据引擎都支持计算存储分离，可以通过外部存储引用的方式进行数据对接，而不是通过ETL加载到本地。Hadoop生态圈也开始拥抱计算与存储分离，Hadoop除了HDFS之外还支 持S3，用户可以在私有云或者是公有云上运行Hadoop计算集群，连接共享存储和云存储。

        这样做的好处也是显而易见的，首先是可以实现计算和存储资源的单独扩容，然后原本分散的数据 实现集中存储，打造统一数据湖。更重要的一点，可以真正实现大数据混合云，数据存储保留在本地，机器学习等计算资源部署在公有云，既考虑了安全性，又实现了计算的敏捷。计算存储的分离，也可以方便实现软件版本的灵活管理，存储部分求稳，要保持软件版本的稳定，计算部分求快，可以通过数据沙盒和容器技术，实现不同算力模型的快速交付，各部分独立升级互不影响。这样我们积极可以，构建以企业数据湖为核心的稳态数据资源服务，构建以数据计算为核心的敏态数据能力服务，在实现数据治理的基础上实现数据运营。

        其实计算与存储分离这个提法，多少有点噱头的意思，没有那么复杂，当然也没那么简单。还是那句话：没有一成不变的架构，只有不变的以业务为核心的架构意识。

四、观点

  ①  纵观过去的20年，我们在算力、网络、存储方向的发展上都有了质的飞跃，然而横向对比却又不难发现三者并不是等效发展。网络，从此前主流 100Mb 到如今10GbE就绪，甚至迈进25 GbE、40 GbE，赶超了100多倍；存储，HDD 硬盘的性能提升虽然没有网络的大飞跃，但得益于SDD制程和工艺的迭代，存储领域也有了相当显著的进步，NVME的应用已经炉火纯青；而回到算力上，即便是处理器工艺已经迈入7nm，算力的提升也远不及前两者的跨越。非平衡的三元演进趋势，加之数字化转型中不同阶段衍生出的差异性需求，迫切的期待创造一个更加随心的架构形态。

        存算分离架构（Disaggregated Storage and Compute Architecture）似乎更像是当下的众望所归，充分契合如今的信息技术格局与各行业务境况，其得天独厚的优势也相得益彰：

• 更灵活的选择。计算资源与存储空间的配置互不制约，即使身处在形态各异的业务场景，都可以因地制宜构建个性化的配比，充分匹配业务的每一项资源要求。

• 更高效的扩容。计算资源先达到瓶颈？存储空间先达到瓶颈？都能够进行独立、按需扩容，持续保障存算资源的高效使用，杜绝存算一体扩容时带来的资源浪费。

• 更安全的隔离。存、算各司其职，形成逻辑隔离。计算节点不再承担数据存储，计算节点动态增减甚至是故障宕机，无需大量数据的迁移，丝毫不影响数据存储的可靠性与完整性 

② 从性能角度讲，存储计算分离的架构有利于发挥性能优势，各自发挥自己的优势。从很多技术发展的趋势来看，最终都会走向专业细分化的趋势，毕竟没有任何技术架构或者平台是万能的，都是针对某种场景才能发挥最大的优势，没有万能钥匙，技术发展的最终目标就是把合适的技术应用在合适的场景当中。

③ 从安全角度讲，存储计算分离的架构有利于企业更有针对性地应用不同的安全策略来进行管控。数据才是企业的资源，计算只不过是对资源进行加工的工具而已，两者在安全上面的要求和管控策略完全不同。

④ 一般来说，存算一体的计算和存储是强耦合的，不能分别扩展。在小规模的系统下，存算一体占主流。但是当用户需要的计算资源比较多，需要的存储资源也比较多了以后，需要计算和存储分别按需扩展、弹性计算，这样的话必定会演进到存算分离。因此可以认为存算分离是趋势。