导读 本文将讲解 StarRocks 3.0 版本带来的存算分离架构，分享关于存算分离的一些思考和实现中的技术细节。

主要包括以下三大部分：

1. 业界案例

2. StarRocks 存算分离设计和实现解析

3. StarRocks 存算分离测评

分享嘉宾｜丁凯 镜舟 技术专家，主导构建 StarRocks 存算分离架构

编辑整理｜陈振

内容校对｜李瑶

出品社区｜DataFun

01业界案例

首先来分享一些业界存算分离方案的实例。

1. 案例一

这个案例是利用 AWS S3 来做共享存储，同时涉及多副本的写入和跨 AZ 的数据同步。这个案例的亮点在于数据持久化是以日志的形式去写的，需要通过跨 AZ 的数据同步实现快速的数据更新，基于底层的日志即数据、主从复制、多副本复制、共享存储，实现了快速的数据共享和弹性能力。不足是底层的日志和存储都需要与这种架构相绑定，是高度定制化的，架构难以复制。

2. 案例二

案例二是 Snowflake 架构，是典型的 SaaS 架构。它分为三层，Service 层、Virtual Warehouse 层和 Data Storage 层。Service 层主要提供 SaaS 服务，包括安全、接入、管理、租户等。数据分析所依赖的核心是下面两层，即 Virtual Warehouse 层和 Data Storage 层。Virtual Warehouse 层实现了计算的硬隔离能力，可以利用共享存储的同一份数据做不同的计算。这个案例的亮点在于完全的存算分离架构，以 SaaS 服务的形式去提供分析型数据库服务，并且使用了S3对象存储作为实际存储，成本较低。使用 Local Disck 作为热数据 Cache，兼顾性能，但一定程度上限制了弹性。不足是完全依赖 SaaS 服务设计，在国内做一些定制化部署时很难做一些裁剪和适配。

3. 案例三

案例三是一个 AWS 的 Redshift 案例。Redshift 同样是存算分离架构，而且可以利用 AQUA 将算子下推到硬件中实现查询加速，还可以利用 CaaS 进行查询加速。包括定制化的 Redshift Managed Storage，这些都是 Redshift 的亮点。但不足仍是架构定制化程度过高，难以复制。

4. 小结

上述案例中的存算分离架构，存储部分的实现各有不同。针对特定应用场景进行架构设计，难以扩展。针对 SaaS 服务设计，难以适应灵活的部署模式。架构上比较标准化，缺乏创新，想象空间有限。

StarRocks 希望在自己的存算分离设计中解决上述问题。

02StarRocks 存算分离设计和实现解析

1. StarOS 云原生平台

通过对上述案例的思考，StarRocks 在做存算分离时不仅考虑如何做到存算分离，还会考虑在云原生架构下是否可以做一个操作系统的能力。所以经过内部讨论产生了 StarOS 云原生操作系统，包括计算部分、存储部分，甚至外部的分布式存储以及私有云的部署。尤其是在分布式存储方面，将分库、分表、分片都包含在内，并做好存储划分和分布式计算调度，使用者只需关注数据在哪，将计算任务调度到数据所在的存储上即可。StarOS 可以很容易地部署到公有云、私有云上，并具备很好的弹性能力。

2. StarRocks 存算分离整体架构

StarRocks 存算分离架构如下图所示。

StarRocks 在存算一体架构下是 FE + BE 架构，而在存算分离架构下将 BE 升级为了 CN（Compute Node）。CN 和 BE 的最大区别是可以做到无状态，因为在存算分离架构下数据已经存到分布式存储上了。CN 就完全变为了一个计算引擎，并借助本地 Cache 实现数据加速。StarManager 又整合了 Shard Manager、Service Manager、Worker Manager、FileStore Manager、LogStore Manager 的能力，来更好地管理 tablet。

3. 存算分离实现解析

StarRocks存算一体架构下，FE 会存储 table 和 partition 的信息，BE 会存储 tablet 信息，包含 segment data 和 metadata 等。这是 3.0 版本之前的方案。在做存算分离时对界限的划分进行了深入思考，并不是按照 FE 和 BE 来进行切割划分，比如是否可以从 tablet metadata 和 segment data 之间划分，因为 tablet metadata 数据量不大，大量的实际数据是存放在 segment data 中的。是不是可以依赖 KV 存储来存放 tablet metadata，或者将这部分元数据再归给 FE。考虑到不增加 FE 存储元数据的压力，还能让 BE 无状态化，最终将 BE 中的 tablet metadata 和 segment data 都存储到了外部存储。

在这种架构选型下会面临以下一些挑战：

• 异构存储系统的支持。主要是对对象存储的支持，同时也支持 HDFS、Google Stoarge、Azure Blob 等。因为不同的存储特性也不尽相同，比如写入的数据是否可以修改、文件的创建和写入是否是原子性的等等。如何做到对各种存储最大限度的兼容是一大挑战。
• 如何降低 IO 延迟。在分布式存储场景下，会比本地盘慢很多，正常 Nvme SSD 的 IO 延迟可达到100 us 以内，HDD 的延迟也可以保持在 5 ms 以内，但是 Distributed Storage 的 IO 延迟大多数是在 1～100 ms，甚至想保持在 10 ms 都很不容易。因为 Distributed Storage 是要走网络的，而且还与其本身内部的 IO 链路有关。如何做到低延迟是个挑战点。
• 存储元数据的一致性如何保障。元数据层面，比如使用对象存储和 HDFS 时，create 和 list 操作的表现就不一致。这时就要考虑数据写入后是否能立刻读到，还有写入的文件是否能立刻 list 出来。这对于 NAS 或本地文件系统来说都是很正常的能力，但是分布式条件下多半难以达到。
• 计算与存储缓存调度。存算分离场景下引入缓存，缓存和计算的调度需要考量。
• Compaction 和 GC。在存算一体架构下，数据在哪个节点就会由哪个节点负责 Compaction，而在存算分离架构下，每个节点都可以做 Compaction，需要考虑由哪个节点去做。做完 Compaction 之后，远程存储上的垃圾由哪个节点去做删除也需要考虑。所以数据版本和实效性方面又是一个挑战点。

下面介绍 StarRocks 存算分离的一些关键技术点。

（1）缓存

在存算分离架构下，一直访问远程存储，IO 延迟是非常大的，远超本地存储。虽然节点是无状态的，但是可以利用本地盘和内存将远程存储拉回的数据缓存下来，加速后续查询，虽然首次查询会比较慢，但是后续查询如果还会使用缓存下来的数据就会实现查询效率的提升。

（2）不可更改文件

统一对远程存储做不可更改的限制，即认为文件写入后是不可更改的，比如像 HDFS 这种可以更改的远程存储，也对其做限制，认为其不可更改。这样也可以更好地做到多版本控制。比如 tablet 信息需要更改，会生成一个新的文件，并且用版本号来标识，并通过多版本管理能力来维护 tablet 信息。

（3）写幂等

在某个节点操作 tablet 的时候可能丢失和 FE的心跳，处于假死状态，FE 会将任务交给另外一个节点，就会发生多个节点同时操作同一个 tablet，导致数据损毁。通过写幂等性就可以保证数据的正确性，即文件在多次完全替换情况下还能保证是正确的。

（4）多版本管理

可以保证在存算分离情况下，数据和元数据的一致性。

4. 存算分离的价值

（1）降成本

主要体现在两个方面：

• 副本的减少。在存算一体架构下，数据通常是 3 副本，但是在存算分离场景下，数据可以变为 1 副本。再比如云上使用的 EBS，EBS 本身就是 3 副本，数据再 3 副本就是 9 份数据。
• 存储介质单位成本的降低。EBS 单位存储就会比 S3 要贵很多，在改为存算分离后，EBS 到 S3 可以降低 4-10 倍的成本。

（2）提升可靠性和可用性

可用性方面，存算一体架构下，如果 BE 挂了，存储也就不可用了，但是在存算分离架构下，计算节点挂掉，再启动一个计算节点就可以了，因为数据都在远程存储上。

可靠性方面，存算一体架构下，一般数据做 3 副本，可靠性可以达到 3 个 9 或 5 个 9，但在存算分离架构下，依赖的云厂商的存储都可以达到 9 个 9 甚至 11 个 9。

（3）弹性与资源隔离

类似 Snowflake 架构，利用 Warehouse 实现计算资源的隔离，但可以共享同一份数据。目前社区版本只支持单 Warehouse，在 3.2 版本时将提供多 Warehouse 能力。每个 Warehouse 就是一个资源池，Warehouse 之间就有物理隔离能力。

03StarRocks 存算分离测评

1. 导入数据吞吐能力测试：StreamLoad

通过 StreamLoad 来测试存算分离架构下集群的导入和吞吐能力。配置和测试结果如下图。在导入时间上，1 并发和 4 并发并没有太大区别，但在 16 并发下存算分离的导入时间约为存算一体的一半。在吞吐上也类似，1 并发和 4 并发并没有太大区别，在 16 并发下存算分离的吞吐约为存算一体的两倍。在存算分离架构下，可以持续提升写入和吞吐能力，直至最终打满节点的带宽。

2. 查询性能测试：TPCDS 1TB

这里做了三种对比测试，如下图。第一行是存算一体的测试结果，第二行是存算分离在缓存充分预热的下测试结果，第三行是存算分离在无缓存场景下的测试结果，可以发现缓存重复预热的测试结果基本和存算一体的测试结果一致。在没有缓存情况下，数据依然可查，并且性能衰退只有 50% 左右。

3. 用户测评

以下两个案例是 5、6 月份存算分离活动的用户案例。

（1）案例一

用户的需求是使用存算分离实现降本，并且能够按需扩容，解决资源潮汐利用率的问题。用户使用了 SSB 和 TPCH 两种测试集，在性能方面，Local Cache 可以命中的情况下，查询延时与存算一体架构持平，后续会尝试替换现有的存算一体架构。

（2）案例二

用户的首要需求同样还是降本，因为有很多的历史数据要存储，将历史数据有效归档，会使存储成本有效降低。第二点需求是历史数据能查而且能更新。经测试，在写入性能方面，异步写入参数对写入性能有较大影响，关闭后可对写入性能有 7 倍左右的提升。关闭本地缓存后，直接写入 OSS，写入瓶颈有 OSS 控制。存算分离开启本地缓存和存算一体写入基本持平。在查询方面，对于单 SQL 查询，开启本地缓存后有明显优化，性能和存算一体基本持平。

以上就是本次分享的内容，谢谢大家。