谈谈计算与存储分离架构

字数 2594阅读 737评论 0赞 4

内容摘要：

计算与存储分离是一种新的架构潮流，适用于数据库和消息队列等场景，也在大数据架构中得到应用。分离设计可以降低资源浪费、减少服务器款型、方便扩容和实现混合云等优点。

当前摘要为AI生成

存算分离，作为一种架构潮流，在架构设计和项目规划的时候经常被提及。现如今， 数字化转型已经从选择题变成了必修课， 企业IT架构的重塑也势在必行，所以我们有必要把这些所谓潮流的东西解构清楚。翻阅了不少资料，也参考了网上一些文章，我们简单来分析一下。 
 
  一、计算与存储为何要分离

在计算机中，我们所说的计算其实指的是由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计算集群，连接共享存储和云存储。

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

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

存算分离

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

谈谈计算与存储分离架构

添加新评论0 条评论

文章目录展开目录

作者其他文章

相关文章

相关问题

相关资料