Day 27｜Apache Doris 存算分离：Compute Group、File Cache 与弹性计算

课程阶段：第六阶段——湖仓与 AI
建议学习时长：4～6 小时
实验基线：Apache Doris 4.0.8 Stable / 4.1.3 Latest
本文核验日期：2026-08-18

Day 26 介绍了 Multi-Catalog，让 Doris 可以直接访问 Hive、Iceberg、Hudi、Paimon 和 JDBC 数据源。Day 27 把视角拉回 Doris 内部表，重点学习另一种云原生架构：数据持久化到 S3、HDFS、OSS 等共享存储，BE 节点主要承担计算和本地缓存，多个 Compute Group 可以共享同一份数据，并根据业务负载独立扩缩。

这套架构会改变容量规划、故障恢复和性能治理的思路。存算一体关注本地副本、Rebalance 和数据盘容量；存算分离关注共享存储、元数据服务、计算组、File Cache、缓存预热和远端访问成本。查询延迟也会呈现两类状态：缓存命中时接近本地盘路径，缓存未命中时需要访问远端存储。

你原有培训材料在湖仓章节中介绍过 Compute Node 和 File Cache：Compute Node 用于隔离繁重的数据湖查询，File Cache 用于缓存远端文件。今天需要进一步区分两个概念：

存算一体中的 Compute Node / Resource Group，常用于外表计算隔离或物理资源分组；
存算分离中的 Compute Group，由一个或多个 BE 组成，访问共享 Storage Vault 中的 Doris 内部表数据。

名称接近，部署模式、数据路径和治理方式各有自己的边界。

一、今天要掌握什么

完成本篇后，学习者应具备以下能力：

能够画出存算分离模式下 FE、Meta Service、FoundationDB、Recycler、Storage Vault 和 Compute Group 的关系；
能够解释存算一体与存算分离在数据落点、扩缩容、故障恢复、成本和尾延迟上的差异；
能够创建 Storage Vault，并理解表、数据库和默认 Vault 的选择优先级；
能够查看、授权、切换和扩缩 Compute Group；
能够设计读读隔离、读写隔离和写写隔离；
能够解释 File Cache 的 Cache Hit、Cache Miss、回填、淘汰和预热路径；
能够使用 TTL、索引优先、单查询配额和字节阈值控制缓存污染；
能够设计一次性、周期和事件驱动的缓存预热；
能够把 Workload Group 绑定到 Compute Group，形成物理隔离和组内精细治理；
能够设计冷缓存、热缓存、扩容首查、读写混合和故障恢复 POC；
能够建立对象存储、计算资源、本地缓存盘和网络请求的成本模型；
能够识别 Meta Service、FoundationDB、Recycler、File Cache 和 Storage Vault 的常见故障。

截至核验日，Apache Doris 官网将 4.1.3 标记为 Latest，将 4.0.8 标记为 Stable。本文以当前 4.x 文档为依据，对 4.0.3、4.0.8、4.1.x 等版本敏感能力单独标注。

二、为什么会出现存算分离

2.1 存算一体的资源绑定

存算一体模式中，每个 BE 同时提供计算、内存和本地数据盘。一张表的 Tablet 副本分布在多个 BE，查询优先读取本地副本。该模式具有很强的数据本地性，适合延迟敏感、负载稳定、基础设施可控的场景。

资源绑定也会带来几项工程约束：

计算资源不足时，新增 BE 通常伴随副本迁移和 Rebalance；
数据增长会占用高性能本地盘，即使 CPU 利用率很低，也可能被迫扩容；
为不同业务建立物理隔离时，常常需要额外副本，存储成本随隔离组增加；
节点缩容需要先迁移数据，缩容时间受到数据量和网络带宽影响；
容量规划需要同时满足计算峰值与存储峰值，资源利用率容易失衡。

2.2 存算分离的基本思路

存算分离把持久化数据放到共享存储，计算节点只保留本地 File Cache 和运行时状态。多个 Compute Group 访问同一份远端数据，各组拥有独立的 BE 进程、CPU、内存和缓存盘。

这带来四类变化：

存储容量由 S3、HDFS 或兼容对象存储承接；
Compute Group 可以按报表、Ad-hoc、ETL、租户或团队拆分；
新增计算组无需复制整份数据，重点转为热点缓存预热；
计算资源可以根据时间段和业务压力独立扩缩。

2.3 需要付出的代价

存算分离引入了更多基础组件，也把远端存储纳入查询关键路径。工程团队需要正面处理：

Meta Service 与 FoundationDB 的高可用；
Storage Vault 的凭据、权限、Endpoint 和路径治理；
File Cache 容量、命中率、淘汰和污染；
新 Compute Group 的冷启动；
Compaction、Schema Change 和新写入产生新 Rowset 后的缓存同步；
对象存储请求数、带宽和跨可用区费用；
Recycler 的回收进度和对象空间释放；
存算分离与存算一体之间无法原地切换的迁移成本。

因此，选型时应同时评估性能、弹性、成本、基础设施成熟度和运维能力。

三、存算分离的完整组件

3.1 FE：SQL 和控制面入口

FE 继续承担 MySQL 协议接入、SQL 解析、权限校验、Nereids 优化、分布式计划生成和查询协调。用户通过 FE 选择数据库、Storage Vault 和 Compute Group，FE 再把任务调度到对应的 BE。

生产环境仍需部署多个 Follower，保持元数据高可用和 Master 自动选举。客户端应通过 VIP、负载均衡或具备重试能力的连接池访问 FE，避免固定单点地址。

3.2 Meta Service：数据层元信息与事务协调

Meta Service 服务于存算分离的数据层，管理 Tablet、Rowset、版本、事务、Storage Vault 等信息，并向 FE 和 BE 提供元数据能力。自建集群中，FE 和 BE 需要配置 meta_service_endpoint，只应指向提供元数据操作的 Meta Service 实例。

生产环境建议部署多个 Meta Service 节点。节点之间的网络、端口、JDK、配置文件和 FoundationDB 连接串需要保持一致。Meta Service 不可达时，写入、版本发布和部分元数据操作会受到直接影响。

3.3 FoundationDB：一致元数据持久化

FoundationDB 持久化存算分离模式的数据层元信息。当前官方手工部署文档以 7.1.x 系列为基线，并建议生产环境使用至少三台 SSD 节点，分布在不同故障域。

FoundationDB 的故障具有基础设施级影响。运维团队应持续监控：

集群可用状态；
Coordinator 与 Storage Server 健康；
磁盘空间、I/O 和延迟；
进程内存和网络；
fdb.cluster 一致性；
备份与恢复演练。

3.4 Recycler：异步回收对象文件

共享存储中的文件删除不能简单依赖同步调用。Doris 使用标记后回收策略：DROP、Compaction 等操作先在元数据中标记待回收对象，Recycler 周期扫描对应 KV，先删除 Segment 等对象文件，再删除回收元数据。

这种顺序提供了缓冲时间和更稳定的批量 I/O。若对象存储空间长时间不下降，应检查 Recycler 进程、Lease、回收任务、对象权限、网络和远端错误。

Meta Service 可以同时承担元数据与回收功能，也可以将 Recycler 独立部署。独立部署有利于隔离回收 I/O 和故障，但增加了组件数量和监控面。

3.5 Compute Group：独立的计算子集群

一个或多个 BE 组成 Compute Group。每个组拥有自己的：

CPU 与内存；
Pipeline 执行线程；
查询队列和 Workload Group；
本地 File Cache；
故障域和扩缩容节奏。

多个 Compute Group 共享 Storage Vault 中的数据。新建组无需创建新的数据副本，第一批查询可能发生较多 Cache Miss，因此扩容验收需要包含缓存预热和首查性能。

3.6 Storage Vault：共享存储抽象

Storage Vault 把 S3、OSS、COS、MinIO 或 HDFS 等存储的地址、路径和凭据封装成 Doris 可管理对象。集群可以创建多个 Vault，并给不同数据库或表指定不同的存储位置。

四、Storage Vault 的创建与治理

4.1 创建 S3 Vault

下面是一份模板，凭据应通过安全方式注入，示例中的明文仅用于理解字段：

CREATE STORAGE VAULT IF NOT EXISTS s3_prod_vault
PROPERTIES (
    "type"           = "S3",
    "s3.endpoint"    = "https://s3.us-east-1.amazonaws.com",
    "s3.region"      = "us-east-1",
    "s3.bucket"      = "doris-prod",
    "s3.root.path"   = "warehouse/main",
    "s3.access_key"  = "${ACCESS_KEY}",
    "s3.secret_key"  = "${SECRET_KEY}",
    "provider"       = "S3",
    "use_path_style" = "false"
);

对象路径需要具备 head、get、list、put、分片上传和 delete 等权限。生产环境优先采用云角色、短期凭据或集中密钥系统，降低长期 AK/SK 泄露风险。

4.2 创建 HDFS Vault

CREATE STORAGE VAULT IF NOT EXISTS hdfs_prod_vault
PROPERTIES (
    "type"                           = "hdfs",
    "fs.defaultFS"                   = "hdfs://nameservice1",
    "path_prefix"                    = "doris/warehouse",
    "hadoop.security.authentication" = "kerberos",
    "hadoop.kerberos.principal"      = "doris/_HOST@EXAMPLE.COM",
    "hadoop.kerberos.keytab"         = "/etc/security/keytabs/doris.keytab"
);

FE、BE 和 Meta Service 都需要访问目标 HDFS。Kerberos 环境要验证 DNS、时钟、Principal、Keytab 权限、NameNode HA 和跨机房网络。

4.3 设置默认 Vault

SHOW STORAGE VAULTS;
SET s3_prod_vault AS DEFAULT STORAGE VAULT;

创建表时的选择优先级为：

表级 storage_vault_name
    > 数据库级 storage_vault_name
    > 集群默认 Storage Vault

数据库级配置只影响后续新建表，不会移动已经存在的表。

4.4 表级绑定

CREATE TABLE cloud_lab.fact_orders (
    order_id   BIGINT,
    user_id    BIGINT,
    order_time DATETIME(3),
    region     VARCHAR(32),
    amount     DECIMAL(18,2)
)
DUPLICATE KEY(order_id, user_id)
PARTITION BY RANGE(order_time) ()
DISTRIBUTED BY HASH(user_id) BUCKETS 32
PROPERTIES (
    "storage_vault_name" = "s3_prod_vault",
    "replication_num" = "1"
);

表创建成功后，当前版本不支持直接修改其 Storage Vault。迁移到另一 Vault 需要新建目标表、回灌数据、增量追平、对账和切换。

当前官方文档还说明 Storage Vault 暂不支持删除。重命名、凭据轮换和数据库级引用变更应纳入正式变更流程。

五、写入和查询分别经过哪些路径

5.1 写入路径

以 Stream Load 为例，写入大致经过：

客户端请求
→ FE 建立事务并选择 Compute Group
→ BE 解析、路由、写 MemTable
→ Flush 形成 Segment / Rowset
→ Meta Service 记录版本与事务状态
→ Segment 和索引写入 Storage Vault
→ PublishVersion 后对查询可见

写入 Compute Group 会在本地缓存写入路径涉及的数据，后续在同一组查询通常具备更好的缓存基础。其他 Compute Group 可以立即获取新版本元数据，但本地 File Cache 可能还没有对应的新 Segment。

5.2 查询路径

查询会先确定 Compute Group，再由该组的 BE 执行：

SQL
→ FE 生成 Scan 与 Fragment
→ 目标 Compute Group
→ File Cache Lookup
→ 命中：本地 SSD
→ 未命中：S3 / HDFS
→ 可选写入 File Cache
→ 解压、过滤、Join、聚合

查询结果正确性不依赖 File Cache。缓存只影响访问路径和性能。清空缓存、节点重启或新增 Compute Group 后，查询仍能从共享存储读取数据。

5.3 数据一致性和缓存一致性

两个概念需要分别理解：

数据版本可见性由事务、Meta Service 和 Rowset 版本控制；
缓存是否具备新文件由 File Cache、写入路径和预热机制控制。

新版本已经可见而读组缓存尚未预热时，结果仍然正确，首批查询可能变慢。低尾延迟场景需要通过主动预热、事件驱动同步和延迟提交等机制缩小抖动。

六、Compute Group 的管理与路由

6.1 查看 Compute Group

SHOW COMPUTE GROUPS;

管理员可以查看全部计算组，普通用户只能看到拥有 USAGE_PRIV 的组。3.0.2 以前文档中常见的 Compute Cluster 已更名为 Compute Group。

6.2 新增 BE 并指定计算组

ALTER SYSTEM ADD BACKEND '10.0.0.21:9050'
PROPERTIES (
    "tag.compute_group_name" = "realtime_cg"
);

省略组名时，节点进入 default_compute_group。

6.3 授权与回收

GRANT USAGE_PRIV ON COMPUTE GROUP realtime_cg TO alice;
REVOKE USAGE_PRIV ON COMPUTE GROUP realtime_cg FROM alice;

6.4 设置用户默认组

-- 当前用户
SET PROPERTY 'default_compute_group' = 'realtime_cg';

-- 管理员为其他用户设置
SET PROPERTY FOR alice 'default_compute_group' = 'realtime_cg';

SHOW PROPERTY;

6.5 Session 路由

USE @realtime_cg;
USE cloud_lab@adhoc_cg;

同一 Session 内，默认 Compute Group 会保持稳定。若权限被回收、目标组删除或没有存活 BE，应用应重新建立会话并选择可用组。

6.6 三类隔离模式

读读隔离

经营大屏进入 realtime_cg，数据科学和 Ad-hoc 进入 adhoc_cg。大查询的 CPU、内存和 Spill 不会占用在线组的 BE 进程。

读写隔离

持续导入、Compaction 和 Schema Change 进入 write_cg，在线查询进入 realtime_cg。数据版本仍由共享元数据统一管理，读组通过预热获取新 Rowset 的缓存。

写写隔离

高频微批和 PB 级回灌进入不同 Compute Group，分别配置内存、并发和缓存策略，降低两类写入之间的资源竞争。

七、弹性扩缩和 Cloud Rebalance

7.1 扩容为何更快

存算一体扩容需要把 Tablet 副本搬到新 BE。存算分离中的持久化文件已经位于共享存储，新增 BE 主要完成：

进程启动并注册；
加入目标 Compute Group；
Cloud Rebalance 调整读写流量；
热点数据进入本地 File Cache；
达到目标 p95、p99 和命中率。

因此，扩容动作可以很快生效，性能稳定仍取决于预热进度和远端存储能力。

7.2 缩容

ALTER SYSTEM DECOMMISSION BACKEND '10.0.0.21:9050';

缩容不会搬迁持久化数据，但系统需要停止向目标 BE 分配流量，并确保正在执行的任务安全结束。生产环境仍应采用 Decommission，保留观察和回退时间。

7.3 Balance Type

当前官方文档为 Compute Group 提供三类 Rebalance 策略：

策略	行为	适用考虑
`without_warmup`	快速重新分配流量	扩容最快，首查可能出现冷缓存
`async_warmup`	异步预热并逐步平衡	当前默认起点，兼顾速度和稳定性
`sync_warmup`	完成预热后再切换	延迟要求高，扩容完成时间更长

计算组级配置示例：

ALTER COMPUTE GROUP realtime_cg
PROPERTIES (
    "balance_type" = "async_warmup"
);

balance_type 从 Doris 3.1.3 和 4.0.2 起支持。升级前应确认旧版本行为和全局 cloud_warm_up_for_rebalance_type 配置。

7.4 扩容验收

至少检查：

SHOW COMPUTE GROUPS 中节点状态；
SHOW BACKENDS 中每个 BE 的存活状态；
Tablet 流量分配是否接近均衡；
File Cache 使用量与命中率；
Warm Up Job 进度；
冷缓存和热缓存 p95/p99；
扩容期间错误率、队列和远端读取量。

云原生与存算分离