解构“存算分离”

郑金辉
过去由于网络带宽的限制,我们习惯性的把计算和存储偶合在一起,以减少网络传输的压力,但随着网络技术的发展,网络带宽和网络质量已经不再是瓶颈,磁盘IO反而没有明显的增长,计算和存储耦合在架构上的缺点也逐渐暴露出来……本文解读了存算分离的原因、应用场景,以及大数据架构中的存算分离应用。

本文来自微信公众号“twt企业IT社区”,作者/郑金辉。

存算分离,作为一种架构潮流,在架构设计和项目规划的时候经常被提及。现如今,数字化转型已经从选择题变成了必修课,企业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计算集群,连接共享存储和云存储。

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

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

原题:谈谈计算与存储分离架构;作者个人公众号:向云而生

THEEND

最新评论(评论仅代表用户观点)

更多
暂无评论