从 Apache Doris 3.0 版本开始，Apache Doris 开始支持存算分离模式，用户可以在集群部署时选择采用存算一体模式或存算分离模式。

全新存算分离模式对计算与存储进行了解耦，计算节点不再存储主数据，而是引入共享存储层（HDFS 与对象存储）作为统一的数据主存储空间，计算资源和存储资源可以独立扩缩容，为用户带来了多方面价值：

• 负载隔离：多个计算集群共享同一份数据，用户可以使用多计算集群对不同业务或者在离线的负载进行隔离；

• 存储成本大幅降低：全量数据存储到成本更低且极其可靠的共享存储中，热数据仅在本地 Cache，相比存算一体三副本，存储成本最高下降至原先的 1/10；

• 计算资源弹性：数据不保存在计算节点，计算资源可以按照负载需求实现灵活弹性扩缩容，比如单个计算集群的扩缩容或者加减计算集群，弹性带来了资源配置的灵活性以及成本的降低；

• 系统鲁棒性的提升：数据存储到共享存储，Doris 不再有多副本一致性的逻辑，会大幅度简化分布式存储带来的复杂度，从而会提升系统的鲁棒性。

• 数据共享和克隆的灵活性：存算分离架构的灵活性不止在一个 Doris 集群内部，在跨 Doris 集群时也应该体现出灵活性，比如 Doris 集群 A 中的库表可以轻量地在 Doris 集群 B 中完成克隆，即只做元数据级别的复制，不做数据的复制。

1-1. 从存算一体到存算分离

在存算一体模式中，Apache Doris 整体由 Frontend（FE）和 Backend（BE）两类进程组成，其中 FE 节点主要负责用户请求接入、查询解析规划、元数据管理和集群管理等相关工作，BE 节点主要负责数据存储和查询计划的执行，多 BE 节点间采取 MPP 分布式计算架构，通过多副本一致性协议来帮助服务的高可用和数据的高可靠。

新兴云计算基础设施的成熟，无论是公有云、私有云以及基于 K8s 的容器平台，云计算基础设施的革新催生了新的需求，越来越多用户期待 Apache Doris 针对云计算基础设施提供更加深度的适配，以便提供更加灵活强大的弹性能力，因此飞轮科技团队早在 2022 年基于 Apache Doris 设计并实现了云原生存算分离版本（SelectDB Cloud），在经过数百家企业近两年的大规模生产打磨后，将其贡献回 Apache Doris 社区，即当前 3.0 版本的存算分离模式。

在存算分离模式下，Apache Doris 整体架构演化成元数据层、计算层和共享存储层三层：

• 元数据层：新引入 Meta Service 模块来提供系统的元数据服务，例如库表、Schema、Rowset Meta、事务等信息，是一个可以横向扩展的无状态服务。目前 BE 的 Meta 已经全部进入了 Meta Service，FE 的部分 Meta 已进入 Meta Service，其它 Meta 在后续版本中也会全部进入 Meta Service。

• 计算层：负责执行查询规划，计算节点即无状态的 BE 节点，会缓存一部分 Tablet 元数据和数据到本地以提高查询性能。通过多个无状态的 BE 节点可以组成计算资源集合（即多计算集群），多个计算集群共享一份数据和元数据服务，计算集群支持随时弹性加减节点。

• 共享存储层：数据持久化到共享存储层，目前支持 HDFS 以及 S3、OSS、GCS、Azure Blob、COS、BOS、MinIO 等各类云上兼容 S3 协议的对象存储系统。

1-2 设计亮点

全新存算分离架构最大的设计亮点在于将 FE 全内存的元数据模式演变成共享的元数据服务，这一方案的优势在于，元数据服务提供了全局一致的状态视图，任何节点可以直接提交写入，不再需要经过 FE 做 Publish。写入时数据进入共享存储，元数据进入元数据服务，可以有效控制共享存储上的小文件数量，同时单表的实时写入性能和存算一体相差无几，整个系统的写入能力不再受限于单 FE 的处理能力。

基于全局一致的状态视图，在数据 GC 时，我们采用了设计上容易证明正确性和效率更高的正向数据删除。具体而言，将共享存储中的数据纳入到在共享元数据服务提供的全局一致视图中，数据生成时绑定一个事务，元数据删除时也绑定一个事务，以此可以实现删除和写入不能一起成功，视图中记录了哪些数据需要删除，异步删除过程只需要根据事务记录正向删除数据即可，不需要反向 GC。

未来随着 FE 中 Tablet 相关的 Meta 进入共享服务，Doris 集群规模也不再受限于单 FE 内存。基于共享的元数据服务和正向的数据删除技术，在此基础上可以便捷地扩展数据共享、轻量克隆等功能。

1-3 业界同类方案对比

业界还有另一种存算分离架构的设计方案，将数据和 BE 节点的 Meta 存放在共享对象存储或者 HDFS 中，该方案会有如下的问题：

• 无法承载实时写：在写入数据时，数据会根据分区分桶规则映射到 Tablet 中并生成 Segment 文件以及 Rowset Meta。在写入阶段会通过 FE 进行两阶段提交（即 Publish），在 BE 节点接到 Publish 请求后再将 Rowset 设置为可见，Publish 是不允许失败的。如果将 Rowset Meta 保存在共享存储中，实时写入过程中的小文件数据是数据文件的三倍，一次写入数据结束后生成 Rowset Meta、一次 Publish 时更改 Rowset Meta 状态。Publish 是由 FE 节点单点驱动的，不论单个表或整个系统的写入能力都受限于 FE 节点。

  

  在 Apache Doris 3.0 版本正式发版后，我们对该方案实时数据写入性能与 Apache Doris 进行了对比。在此我们在相同计算资源下分别模拟 500 并发任务写入 10000 个 500 行的数据文件和 50 并发任务写入 250 个 20000 行的数据文件，可以看到在 50 并发下 Apache Doris 存算分离和存算一体模式的微批写入性能基本相当，而该方案写入性能与 Apache Doris 差距达到 100 倍。在 500 并发下，Apache Doris 存算分离模式性能稍有损耗，但对比该方案仍有超过 11 倍的巨大优势。为了保证测试公平性，Apache Doris 并未开启 Group Commit 服务端攒批的能力（该方案不具备此能力），而在开启 Group Commit 后实时写入能力还将进一步增强。

  

  此外该方案在实时写入方面还存在稳定性和成本问题：

  • 稳定性隐患：小文件数目多会给共享存储特别是 HDFS 带来更大的压力和不稳定隐患。

  • 对象存储请求费用高：部分公有云对象存储的 Put 和 Delete 收费是 Get 的 10 倍，小文件数目多会导致对象存储请求费用大幅上升，甚至超过存储费用。

• 扩展性受限：FE 的 Meta 是全内存的，存算分离模式下往往会面对更大规模的数据存储，因此当 Tablet 数量超大时（例如超过千万级别），FE 内存的压力较大；整个系统的写入能力受到 FE 单点瓶颈的限制。

• 数据删除逻辑隐患：存算分离架构下数据只有一份，因此数据删除逻辑对于系统的可靠性至关重要。常规的跨系统数据删除做法是对比计算出差集，对于写入过程中的数据依赖超时时间，没办法从机制上 100% 避免删除和写入一起成功，删除和写入一起成功就会丢数据。另外在存储系统有异常时，用于计算差集的输入可能错误，这就可能导致误删除数据。

• 数据共享与轻量级克隆：存算分离架构未来可以借助于架构的灵活性实现数据共享和轻量级数据克隆，降低企业数据管理的负担。如若每个集群是单独的 FE，跨集群克隆数据之后，很难计算出哪些数据没有被引用可以被删除，跨多个集群计算很容易误删数据。

与之相比，Doris 3.0 版本将 FE 全内存的元数据模式演变成共享的元数据服务有效地克服了以上问题。

1-4 查询性能对比

由于存算分离模式下数据需要从远端共享存储系统中读取，因此数据传输的主要瓶颈，从存算一体模式下的磁盘 IO 转变为存算分离模式下的网络带宽，在一定程度上会造成性能损耗。

为了加速数据访问，Apache Doris 实现了基于本地磁盘的高速缓存机制，并提供 LRU 和 TTL 两种高效的缓存管理策略，并对索引相关的数据进行了优化，旨在最大程度上缓存用户常用数据、提升查询性能。新导入的数据将异步写入缓存中，以加速最新数据的首次访问。如果查询所需数据不在缓存中，系统将从远端存储中读取该数据进内存并同步写入缓存中，以便于后续查询。在涉及多计算集群的应用场景中，Apache Doris 提供缓存预热功能，当新计算集群建立时，用户可以选择对特定的数据（如表或分区）进行预热，以进一步提高查询效率。

在此我们分别对存算一体模式和存算分离模式进行了不同缓存下的性能测试，以 TPC-DS 1TB 测试集为例，主要结果如下：

• 完全命中缓存时（即查询的所有数据均被加载进缓存中）存算分离模式与存算一体模式查询性能完全持平；

• 部分命中缓存时（即测试开始前清空所有缓存，初始状态下缓存中无任何数据，在测试过程中数据被逐渐加载进缓存中，性能随之持续提升）存算分离模式与存算一体模式查询性能基本相当，总体性能损耗约 10% ，这一测试场景也与用户实际应用中最为类似。

• 完全未命中任何缓存时（每次执行 SQL 前均清理所有缓存，模拟极端情况）性能损耗约 35%。即使在冷数据读取时存在一定性能损耗，但相较于业内其他同类系统，存算分离模式下的 Apache Doris 仍有着极为明显的性能优势。

1-5 写入性能对比

在写入性能方面，我们在相同计算资源下分别模拟了批量导入和高并发实时导入两大场景，存算一体模式和存算分离模式的写入性能对比结论如下：

• 在批量数据导入场景，导入 TPC-H 1TB 和 TPC-DS 1TB 测试数据集，在存算一体模式采用单副本的情况下，存算分离模式写入性能较存算一体模式分别提升了 20.05% 和 27.98%。批量导入时 Segment 文件大小一般会在几十 MB 到上百 MB，存算分离模式会将 Segment 文件切分成多个小文件并发上传到对象存储，因而会带来比写本地磁盘更高的吞吐。实际部署中存算一体模式一般会采用三副本，此时存算分离模式的写入性能优势会更加明显。

• 高并发实时导入场景在前文中已介绍，在此不在赘述。

1-6 生产运行经验

• 性能：实时数据场景下可以指定 TTL 的 Cache 以及写入时数据进入 Cache，使查询性能达到与存算一体。Compaction 和 Schema Change 后台任务生成的数据根据热度进入 Cache 可以避免查询抖动。

• 负载隔离：多计算集群提供了物理层资源隔离，比如不同业务单元适合使用多计算集群隔离。单个计算集群内依然需要使用 Workload Group 对不同的查询做资源的限制和隔离。