潮流下的存算分离，到底能解决什么问题？

PowerData

以下文章来源于Apache Doris 补习班 ，作者苏奕嘉

[

Apache Doris 补习班 .

Apache Doris Active Contributor 和 SelectDB SA 来做的不定时更新，主打 Apache Doris 系列学习文章和相关信息、原理解析或者新特性使用教程，争取 All In 原创，欢迎投稿~

](#)

前言

诚如最近一些技术公众号描述所言，大数据体系在当前这个阶段，随着不断演进又出现了各种新兴的名词。

有些名词是新瓶装老酒，为了赚钱赚眼球和噱头；

有些名词是技术创新项，为了实实在在提升技术创新力。

那在往后，会单独开一个系列，站在我的角度和以 Apache Doris 为基准参照对象，谈谈最近的这些让诸多技术老爷们挠头的那些名词。

看看这些新兴名词是真否解决了什么问题？本质上是噱头还是真技术？

词条释义

存算分离顾名思义，就是存储资源和计算资源分离开来的一种技术架构（Share-Storage），对应的即为存算一体架构（Share-Nothing）。

我们以 Doris 软件架构为例，先从以下两个简图大致感受一下两者架构的不同点：

存算一体

存算分离

两者的基础架构可以一目了然的对照出差异点：存储介质和耦合形态的改变。

原本作为 Share-Nothing 架构的软件而言，不同节点之间资源互相隔离，行为互不影响。可以在单个节点资源确定的情况下，尽可能充分的利用资源完成计算。

而存算分离体系下，计算资源（CPU和内存）虽然依旧隔离，但是参与计算中的数据读取 IO 却成为共享资源，看到这里大家反应肯定是：

1. 1. 会不会引发共享资源争抢导致计算变慢？
2. 2. 既然有弊端为什么还要做存算分离？
3. 3. 架构改变下的收益是否大于弊端？
4. 4. 什么情况下存算分离收益会比较明显？
5. 5. ……

我们一一来解答。

架构收益

计算弹性

存算分离带来最大的优势点，就是可以更灵活的配备计算资源的大小，举个例子：

若作为 OLAP 平台，要高并发低延迟的对业务提供查询解析能力。应对日常流量，在低负载的时候，可能仅需要3台计算节点完成计算，每天早晨 9:00 - 11:00 和下午 14:00 - 16:00 ，由于业务都上班了，流量突增，需要 10 台节点才能应对处理完所有请求。

在存算一体的架构中，一般我们需要根据业务流量的峰值，再加一些冗余值来计算出整体资源大小，故此无论流量负载多低，都需要常备对应资源来应对，若短期内有非预期的查询流量突增情况，那大概率会影响线上的业务查询时延和查询成功率。

若要进行计算资源的弹性扩缩容，存算一体还需要数据重分布（Rebalance）的过程，从 OLAP 这个场景角度而言，弹性拓展时效性跟不上流量激增的时效性，所以很难满足这种计算资源贴合业务流量极速弹性的场景需求。

在存算分离的架构中，根据不同软件的实现方案，大多都可以做到分钟级、秒级的弹性扩缩容能力，其主要原因是免除了数据重分布的过程，可从共享数据介质（S3/HDFS/OSS……）来预热加载查询所需的部分数据，即计算节点只需要在内存或者计算节点的 LocalDisk 上进行临时缓存就可以。

这种无疑极大的提升了算力可弹性的能力，只要预备的机器资源池足够，理论上可以很轻松的应对流量的高低起伏。

资源利用率

在上一小节，以一个例子阐述了存算分离在弹性能力上的优势，那相应带来的，就是在整体资源利用率上的提升。

如案例所述，低负载时 3 台节点，高负载时 10 台节点，换而言之使用存算分离可带来每天 20个小时 * 7 台的资源空闲，如果是云服务，那这 7 台在闲置后可以使用虚机停机不收费策略，以此降低计算资源购置成本；如果是 IDC 机房部署，这 7 台在闲置时期可以交由其他无状态计算服务来使用，比如 Spark 节点在这段时间内处理大规模模型特征计算等任务。

这种架构对于计算成本而言，就有比较明显的节省，或者资源利用率而言，会有比较大的提升。

但是这样就真的完美无缺了么？这个疑问留在弊端章节讨论。

存储副本

存算一体架构下，为保证数据可靠性和可用性，往往都需要3副本来存储，3副本可以满足多数派写入机制，对数据的一致性写入、自动化修复等能力都提供了很好的基础条件保证。

同样由于数据存储都是 On LocalDisk，所以数据存储成本随着时间的推移，会逐步成为平台成本中比重最大的一块。为解决存储成本问题，若丢弃保证数据可靠性，采用副本数较低的数据存储方案，往往会导致数据丢失等重大隐患。

存算分离架构下，数据存储只需要存储一份，交由数据共享存储基座来保证数据可靠性。

如对象存储（S3/OSS/COS/BOS）、HDFS 等，依靠多副本或纠删码等特性就可保证数据可靠性，上层计算应用无需再关注，只需要结合基座完成计算即可。

所以在存储副本数上，存算分离只需要存储一份（实质上这个存储成本嫁接至数据共享存储基座之上），那看起来似乎也没有成本降低？且让我们讨论下一环节来配合说明。

单位存储成本

LocalDisk 与 HDFS 或 对象存储 的单位存储成本是完全不一样的。

以阿里云 OSS 和虚机磁盘 ESSD 为例，前者每 GB 存储成本折合后仅有后者的 1/10 左右。

1TB 数据 3副本 存储1年 ESSD

1TB 数据 1副本 存储1年 OSS

这个比例是基于对象存储保证了多副本可靠性基础上的价格对比，故此整体存储成本相较于 LocalDisk 的话，有极大的降低，若采用 HDFS 基座的话，可能降幅会进一步增加。

所以结合存储副本降低以及单位存储成本降低的综合性价比而言，存算分离架构在存储这一块成本节省是会有较大比例的。

灾备能力

在大多存算分离的场景里，有经验的架构师会提出公共计算这一概念，什么叫公共计算，即使用公共开放的文件格式，如 CSV、Parquet、ORC 等格式做为数据存储的基准格式，再利用 Share-Storage 的架构特性，以达到一份数据多份计算集群甚至不同计算引擎共享的能力。

同样这一概念在单个组件上还可以做更强大的灾备能力，诸如云商的对象存储，可以利用快照等快速备份机制，满足出问题以后迅速以快照形态恢复，避免长时间业务数据宕机导致的严重后果。

同时还可以满足跑批用 A 组件，流式用 B 组件，即席用 C 组件，模型计算用 D 组件这样的上层任意切换使用，而不关注底层数据位置的好处，但是这样又真的是完美无缺的么？

资源隔离能力

存算分离以后，可以将不同的计算资源按组别划分，不同的计算资源组之间可以做到互相之间完全的物理隔离。

不单计算资源分组，分组以后使用的还是同一份数据，这样就极大的降低了数据的冗余性和孤岛效应。

在存算一体的资源分组下，可以比较好的限制 CPU 和内存，但是对网络 IO 以及磁盘 IO 限制起来是非常具备挑战性的，那在存算分离的架构下，不同的虚机或者物理机去完成不同的计算任务，之间直接物理隔离，就不用挑战 IO 这一项资源的限制能力了。

架构弊端

说实话，存算分离这个架构并不是很新的一种理论概念。

从上述小节可以看出，的确在一些场景里有其独到的优势和好处，但任何技术都做不到全是好处没有弊端。

下面就来讲讲这种架构下相较于存算一体，又有哪些弊端？

峰谷流量应对能力

先来看看最具价值的弹性扩展能力。

在上一章节，我们讲到存算分离的弹性扩缩容就是为了满足弹性应对流量算力这个诉求，但是在实际实践和物理资源配比时会发现，由于不同软件的弹性机制和保障机制实现的程度不一样，往往导致理想很丰满，现实很骨感：

非预期流量暴增时，计算资源滞后响应；

暴增流量回落后，资源滞后回落；

在回落过程中流量再次突增，计算资源依旧无法迅速弹起响应

……

有经验的老架构师都知道这意味着什么（自信点，文章读完就已经晋升为有经验的老架构师了）。

两个字：灾难

一个 OLAP 贴上层应用的系统，对延迟是极其敏感的，这“流量来了接不住，流量走了资源上”的二货行为，对架构而言属实是极其糟糕的一件事。

所以这一环节特别考验应用程序在存算分离架构上的实现了，比如应用启动速度、数据预热速度等各方面的设计，如果设计足够好，那么就可以做到 Auto 级别的弹性扩缩容，如果设计不够好，那就需要业务策略制的完成定时扩缩容，以此尽可能保证算力和流量的匹配度。

换而言之，当前也没有哪一个软件架构在实际生产上，可以做到精准控制完全避免突增流量带来的影响。这个影响分为成本影响和业务敏感度影响，就是要么增大资源成本，预留足够充足的资源应对突发流量，要么牺牲一定的业务敏感度来换取整体成本的下降。

当然这也于每家公司实际的业务场景息息相关，比如有些业务场景就是很固定，如跑批任务、报表任务等，那弹性扩缩容能力的确是有价值和意义的。

存储基座IOPS

说到存储，就不得不提 IO 相关的指标了，包括吞吐量、顺序读写、随机读写等各项指标。

无论是 ESSD、NVME、HDD 这些 LocalDisk 存储介质类型，还是 S3、HDFS 这些对象存储产品和文件存储系统，除去上一章节讲的价格之外，也依旧得关注性能上的各项指标是否满足系统应用的诉求。

众所周知，对象存储在当前主流产品类型中，IOPS 一直是一个令人头疼的问题，也是没法直接拿来做系统存储的原因，一旦高频的读写改，那对对象存储而言就是比较灾难的一件事。

当然前段时间 InfoQ 发了一篇说对象存储的 IOPS 将大幅度提升，同时随机查询时延等关键性指标会大幅度下降，可将至十几毫秒内。在没有真正大规模落地的实践中来之前，我认为那都还是一个实验品功能，不具备生产实践的参考价值。

所以综合以上的描述，一个存算分离的产品架构，若根据存算分离 Share-Storage 的理论直接架于诸如对象存储这样的存储基座上，不做任何其他架构和策略上的优化和调整的话，那一定是有比较多的坑在里面等用户慢慢去发现和挖掘的。

存储基座稳定性

除去指标类的关注以外，既然要做数据存储的基座，那难免会被问到可靠性怎样。

云商的可靠性，由于研发时间已经比较长了，同时也是专门的一批人在做运维，再加之买的服务是可以有 SLA 的保障体系的，所以综合的可靠性和可用性都还可以，真出了问题就得找云商赔付了。

这里想聊的其实是自建的基座。

若公司想自建对象存储这样的基础设施，那可靠性这里就得打一个比较大的问号了，不是说我不信任各位运维大佬的能力，而是当前真的没有特别成熟的开源稳定的产品。

除非自己买服务器然后再吆喝云商私有化团队做私有化部署，那成本可能相较于云上直接用会更加高一些，同时如果真的出现了存储介质损坏等问题，能否短时间内修复不影响对外提供的服务，这也需要打一个问号。

数据一致性问题

一份数据由多个计算资源组或者不同的计算引擎来使用带来的一致性问题，也是整体设计实现上需要考虑和关注的事项。

有些计算组是在读、有些组是在写，那这时候要不要学习 TP 库做加锁，加什么粒度的锁，加了锁是不是会影响整体查询和写入效率？如果不加锁是否可以通过Compaction机制完成数据版本合并从而保证一致性？如果通过 Compaction 那又如何解决不同计算组之间的元数据信息同步？

高频读写能力

在 IOPS 小节我们也提到了如果是基于对象存储这样的产品来做基座，那么高频的读写会对其造成比较灾难性的后果，那有大佬就会说：我做攒批低频写不可以么？

可以，只是一定要考虑元数据信息存储和数据块存储到底如何去划分。

诸如当前已知的一些产品，元数据也是放到了对象存储这样的远端做管理，那像这样的设计里，就会牺牲实时更新写入能力，在诸如实时数据仓库，或者数据可见性要求比较高的场景里而言，这样的设计其实是不可容忍的。

命中率

描述了上述的很多问题以后，有经验的老架构师此刻漏出了笑容，因为你已经想到了一些解决办法对不对？

比如在计算节点上挂载 ESSD 这样的 LocalDisk，然后预热加载对象存储的部分数据，一方面可以无视低成本数据基座 IOPS 和时延的影响，另一方面虽然成本会增加一些，但是对外提供服务的能力大幅度增强了，是不是属于一个合理解？

是的，这也是包括 SnowFlake、SelectDB-Cloud 等云原生 MPP 实时数仓仓库深入实践的架构，兼顾了弹性能力和成本下降的性价比，但是也还有一个问题：命中率几何？

如果所有数据全部预热到 ESSD，那若没有弹性扩缩容的诉求的话，成本其实没什么变化；

如果预热了其中一部分数据，若数据没有在 LocalDisk 或者内存中命中的话，就要从远端进行冷查询，若此类查询过多，穿透的查询流量产生的 IOPS 依旧会把存储基座给打满，那还是影响到了业务上的查询时延甚至成功率。

这时候就得再靠优化 LRU、Cache 等机制来尽可能保证数据命中率了，所以这相较于存算一体也是一个比较明显的弊端。

资源利用场景

上个章节我们讲了在弹性扩缩容以后的冗余资源，可以做有效利用。

但是在一个中小型企业中，其实并没有很大的一个资源池子来做这样的弹性动作，如果是 IDC 机房，那基本就几台到十几台物理机就能解决算力资源问题。

那思考一下这样的一个场景。

使用 MPP 数据库做 OLAP 应用，高峰流量过了以后释放了部分机器资源，这时候你的 Spark 模型跑批任务启动了，需要跑 2 小时才能跑完，当跑了 1.5 个小时的时候，OLAP 应用流量上涨，需要扩容计算节点，你将会面临两个选择：

1. 1. Kill 跑了大半的 Spark 任务，资源返还，交由 OLAP
2. 2. 就不给，都跑一多半了，业务线再忍忍就行了

那这种选择题其实是非常恶心人的一件事，因为可能导致的就是跑批任务的时效性永远不可控，带来的就是对上层业务的应用支持更新频次也没法保证。

适用场景

一个架构一定是有优势也有劣势的，所以存算分离还是有比较明确的适用场景的：

1. 1. 云厂商的基座平台，比如国内外的各大云商，他们有非常大的资源池子，虚机的分配速度也非常快，所以天然适合这样的解决思路，无论是采用虚机作为单元，还是 Pod 作为单元，都是完全 OK 的。
2. 2. 集团级的基础设施平台，比如工商银行这样的金融界巨无霸，本身就具备私有化资源池的能力，那基于大规模的计算池子完成存算分离的设计，也是能切实有降本增效之用。
3. 3. 基于 K8S 的企业级基座，也可以尝试使用这样的架构，但是这时候就得综合评估收益和运维成本了，毕竟将单体数据库这种有状态的服务丢进容器化编排工具中的行为，看起来也不是特别优雅的一种选择。

除去以上三种，本人并不推荐中小企业考虑这种架构模式，存算一体在中小规模的场景里还是首选的稳定可靠的最佳选择。

如果想考虑存储降本，那可以考虑冷热分层；如果考虑资源隔离，那可以研究 Resource Group 和 WorkLoad Group，在存算一体场景里每种问题都有专项高分的解，不必在架构层面反复折腾引入新问题。

尾声

存算分离是在特定场景下具备价值的一种架构模式，这类架构模式的确能解决一些在企业内比较挠头的问题，但是还是那句话，没有绝对好的架构，一劳永逸的解决所有问题的那种，也没有完全不堪的架构，什么问题都解决不了（或许有）。

所以在做整体架构设计时，还是得辩证的去看，取长补短来达到一个全盘设计的极致性价比。

本来这篇里要加入 Apache Doris 在 2024 Q1 新 Merge 回来的存算分离架构设计和应用解决场景来着，但是篇幅过于长了，为减少看官老爷的阅读压力就不在这里一并讨论了，等年后会写一篇《Apache Doris 存算一体架构下如何降低成本》。

本篇是今年技术篇章的最后一篇了，提前预祝各位看官老爷除夕夜都可以回家吃到团圆年夜饭，也希望看春晚无聊了可以打开补习班公众号看看我的年度总结 ^\_^

我们除夕夜见~