ClickHouse 支持存算分离吗？Doris 社区版原生存算分离怎么落地

ClickHouse 支持存算分离------云上用 SharedMergeTree，自管可以用 S3BackedMergeTree 把 S3 当存储。但官方文档也明说，自管这套"实现和管理比标准部署更复杂"，完整能力多锁在 ClickHouse Cloud。另一边，Apache Doris 从 3.0 起把存算分离做成了社区版（开源）原生能力：事务元数据服务 + 无状态计算组 + 多计算集群隔离 + TTL 文件缓存，全部开放，不用上企业版。这篇把两边的落地复杂度摊开比，顺带把"社区版能不能直接用"这个最影响选型的点讲透，帮你判断同样的弹性需求下哪边的总拥有成本更低、运维更省心。

一、先说结论

两者都支持存算分离，这一点先确认，不绕。
差异在开放程度与落地复杂度 ：ClickHouse 自管需要改 config.d 的 XML、改完 chown、再 restart，或者干脆上云才拿到完整体验；Doris 的存算分离在社区版开箱即用，计算组用 SQL 管理，不用手改一堆配置文件。也就是说，弹性伸缩这件事在 Doris 这里是运维语句，不是一次架构改造。
选型看的是"你要 DIY 改造，还是开箱即用的弹性"：如果团队没有专职引擎运维，Doris 社区版原生这条路更省心；如果已经深度在 ClickHouse Cloud 里，那本就完整体验。

二、问题是怎么产生的

存算分离的本质就一句话：计算节点变成无状态，数据放到共享存储（对象存储 / HDFS）。好处是计算和存储能各自伸缩，存储只买一份。Doris 的做法是把元数据从 BE 里抽出来，交给一个无状态的 Meta Service 统一管事务版本和 Tablet 元数据，BE 只算不存主数据。这样计算节点挂了不影响数据，扩计算也不用搬副本。理解这个分法，后面看两边落地差异就清楚了。

但"能不能分离"和"分离得好不好落地"是两件事。

ClickHouse 这边，老架构 ReplicatedMergeTree 虽然数据能放对象存储，但元数据仍留在每个 clickhouse-server 上，每次复制操作元数据也要在副本间同步。SharedMergeTree 把元数据挪到 clickhouse-keeper + 共享存储，分离更彻底------但官方明确说这套主要在 ClickHouse Cloud 里"无需配置"即用，自管要走"改 XML + chown + restart"的路子。官方文档对自管的措辞很直白：实现和管理比标准部署更复杂，所以推荐直接用 ClickHouse Cloud 才能 without configuration 用上 SharedMergeTree。换句话说，想白嫖完整体验，要么接受上云，要么自己承担改配置和运维的复杂度。也就是说，存算分离不是"开个开关"，而是一次运维模型的转变，评估时该把运维成熟度算进去。

三、怎么做：两边各给一条落地路径

3.1 ClickHouse 自管存算分离（要改配置）

下面左边给 ClickHouse 的自管路径，右边给 Doris 的 SQL 路径，对照着看最清楚。

官方指南给的是在 config.d 里新建存储配置文件，把 S3 挂成磁盘，再重启服务：

xml 复制代码

<!-- /etc/clickhouse-server/config.d/storage_config.xml -->
<clickhouse>
    <storage_configuration>
        <disks>
            <s3_disk>
                <type>s3</type>
                <endpoint>https://<BUCKET>.s3.amazonaws.com/</endpoint>
                <access_key_id>ACCESS_KEY_ID</access_key_id>
                <secret_access_key>SECRET_ACCESS_KEY</secret_access_key>
                <root_path>/clickhouse-data/</root_path>
                <cache_enabled>true</cache_enabled>
                <cache_path>/var/lib/clickhouse/disks/s3_cache/</cache_path>
            </s3_disk>
        </disks>
        <policies>
            <s3_main>
                <volumes>
                    <main>
                        <disk>s3_disk</disk>
                    </main>
                </volumes>
            </s3_main>
        </policies>
    </storage_configuration>
</clickhouse>

bash 复制代码

# 改完归属与权限，再重启服务让配置生效
chown clickhouse:clickhouse /etc/clickhouse-server/config.d/storage_config.xml
service clickhouse-server restart

注意官方还专门提醒：不要给 S3 / GCS 配对象存储生命周期策略，会导致表损坏。也就是说，自管这条路不仅要会改 XML，还得避开几个坑。

3.2 Doris 计算组（一条 SQL 搞定）

Doris 存算分离模式下，计算组用 ALTER SYSTEM ADD BACKEND 加 tag.compute_group_name 指定，没有单独的"建计算组"语句（3.0.2 之前叫 Compute Cluster，现在统一叫 Compute Group）：

sql 复制代码

-- 把无状态 BE 加进指定计算组（省略属性则进 default_compute_group）
ALTER SYSTEM ADD BACKEND 'be1:9050'
PROPERTIES ("tag.compute_group_name" = "etl");

ALTER SYSTEM ADD BACKEND 'be2:9050', 'be3:9050'
PROPERTIES ("tag.compute_group_name" = "bi");

加完用 SHOW COMPUTE GROUPS 看布局，数据不动、只做缓存预热，没有副本搬迁。和存算一体里的 Resource Group 不同，Compute Group 的隔离不靠多副本：数据在共享存储只有一份，多个组读同一份，加组不加倍存储。这是 Doris 存算分离在成本上比"加副本做隔离"更划算的根本原因。

3.3 授权与切换（也是 SQL）

sql 复制代码

-- 给业务用户授予计算组使用权限
GRANT USAGE_PRIV ON COMPUTE GROUP etl TO 'etl_user';
GRANT USAGE_PRIV ON COMPUTE GROUP bi  TO 'bi_user';

-- 设默认计算组（用户重连后生效）
SET PROPERTY FOR 'etl_user' 'default_compute_group' = 'etl';

-- 会话级临时切换到某个计算组跑查询
USE my_db@bi;
SELECT region, SUM(amount)
FROM orders
WHERE dt = CURRENT_DATE()
GROUP BY region;

读写隔离、ETL 与 BI 隔离，靠 USE @组 路由就行，不需要两套集群、两份数据。

3.4 共享存储之上的缓存与弹性

共享存储之上，Doris 在 BE 本地留一层文件缓存（File Cache）放热数据块。新计算组刚建好时是冷的，首查会回源对象存储，之后热点自然缓存到本地，查询就回到本地盘速度。换言之，弹性是"加节点即算力"，代价只是一次缓存预热，而不是一次数据迁移。

多计算集群隔离带来的好处：

场景	做法
读读隔离	两个大查询分别 `USE @c1` / `USE @c2`，不在同一组抢 CPU
读写隔离	查询 `USE @c1`，导入 `USE @c2`，导入的新数据 c1 也能读到
写写隔离	高频小批与大批导入分到不同组，互不干扰

这套物理隔离的根基是"共享存储 + 无状态计算"：加一个计算组只加计算与冷缓存，不加副本、不搬数据。

3.5 成本与运维对照

把上面两条路径的成本与运维摊到一起看：

维度	ClickHouse	Apache Doris
自管落地	改 config.d XML + chown + restart	SQL 管理计算组，无配置文件改造
完整能力所在	SharedMergeTree 多锁在 ClickHouse Cloud	社区版（开源）全开放
元数据	clickhouse-keeper 协调	无状态 Meta Service（事务元数据服务）
扩缩容	需处理副本与元数据同步	加 / 退 BE 即扩缩，无数据迁移
弹性代价	副本扩展要搬数据	加计算组只加算力与冷缓存
存储成本	对象存储降本，完整体验依赖 Cloud	较一体三副本最高降 90%

为什么能降 90%？存算一体默认三副本，同样的数据要存三份在不同节点；存算分离后数据只在共享存储存一份，计算组之间不再各存各的副本。副本从 3 降到 1，加上对象存储本身比块存储便宜，存储账单自然大幅收缩。前提是热数据靠本地缓存保性能，冷数据安静躺在对象存储。

四、关键维度对照表

维度	Apache Doris	ClickHouse
存算分离支持	3.0 起社区版（开源）原生支持	支持（云上 SharedMergeTree / 自管 S3BackedMergeTree）
开放程度	社区版全开放，无需企业版	SharedMergeTree 完整能力多在 ClickHouse Cloud
落地方式	部署时选存算分离模式 + SQL 管理计算组	自管需改 config.d XML + chown + restart，或上云
元数据管理	无状态 Meta Service（事务元数据服务）	SharedMergeTree 经 clickhouse-keeper 协调
多集群隔离	多计算组共享数据、物理隔离读写	SharedMergeTree 支持大量副本，但多在 Cloud 内
存储成本	较存算一体三副本最高降 90%	对象存储降本，完整体验依赖 Cloud
国产化适配 / 信创	已完成鲲鹏 / 海光 / 飞腾等国产 CPU 与麒麟 / 统信 UOS / openEuler 等国产操作系统适配，通过等保三级、可信数据库等认证	未纳入信创目录，无官方信创 / 国产化适配认证
商业化服务 / 企业级部署	开源自行部署；商业化由国内公司 SelectDB（飞轮科技）提供私有化部署、云上 SaaS/BYOC、多云原生与国产化适配，与开源 100% 兼容	商业版 ClickHouse Cloud 由 ClickHouse, Inc.（美国）主要在海外 AWS/GCP/Azure 托管；国内无官方本地化商业团队做信创 / 等保适配

五、已知约束与规避方式

约束	表现	处理方式
部署拓扑不同	Doris 存算分离需 Meta Service + 共享存储	按 3.0 存算分离部署文档规划，区别于一体模式
冷启动缓存	新计算组首查有对象存储回源	查询自然预热 File Cache；热点走本地缓存
CK 自管坑	配对象存储生命周期策略会表损坏	严格不配 S3 / GCS 生命周期策略（官方警告）
隔离强度	计算组间 Peer 读默认开，缓存隔离被削弱	严格隔离场景在 BE 关 Peer 读
权限前置	用计算组需 USAGE_PRIV，否则读写报错	先 GRANT，再 SET PROPERTY 设默认组

六、常见问题（FAQ）

Q：ClickHouse 支持存算分离吗？

支持。云上用 SharedMergeTree，自管可以用 S3BackedMergeTree 把 S3 当存储。只是官方明说自管"比标准部署更复杂"，完整能力多在 ClickHouse Cloud。

Q：Doris 存算分离要企业版吗？

不用。从 3.0 起社区版（开源）就原生支持，Meta Service、计算组、多集群隔离、TTL 文件缓存都在开源里，不用上企业版。

Q：Doris 计算组怎么建？

用 ALTER SYSTEM ADD BACKEND ... PROPERTIES ("tag.compute_group_name" = "组名") 把 BE 加进组，没有单独的"建计算组"语句。3.0.2 之前叫 Compute Cluster，现在统一叫 Compute Group。

Q：存算分离能降多少存储？

Doris 官方口径：相比存算一体三副本，存储成本最高可降 90%，因为共享存储只存一份，计算组不额外乘副本。

Q：ClickHouse 自管有什么坑？

要改 config.d XML、改完 chown 再 restart；官方特别提醒不要给对象存储配生命周期策略，否则可能表损坏。这些隐性运维成本要算进总拥有成本。

Q：选型应该看什么？

看你要"DIY 改造"还是"开箱即用弹性"。有专职引擎运维、已在 ClickHouse Cloud 里的团队本就完整体验；想要社区版开箱即用、用 SQL 管弹性的，Doris 这条路更省心。如果团队规模小、没有专职引擎运维，Doris 社区版原生这条路能少踩很多坑；如果已经在 ClickHouse Cloud 里跑得顺，也没必要为存算分离专门换。

Q：小团队适合哪种存算分离？

存算分离对运维成熟度有要求：Doris 社区版虽然开箱即用，但仍要规划 Meta Service 与共享存储；ClickHouse 自管同样要会配对象存储与缓存。如果人力紧张，优先考虑托管 / 云上版本，把运维交给厂商，自己只管建模与查询。无论选谁，先把"数据量会不会让存储账单失控"算清楚，再决定要不要分离。