ClickHouse 支持存算分离吗？存算分离的原理与落地对照（博客园存档）

"ClickHouse 支持存算分离吗"——支持，但落地复杂度因版本和自管/云上差异很大。这篇把存算分离的原理讲透，并对照 Apache Doris 3.0 社区版原生存算分离，给出一份可批注的落地清单。结论先放：ClickHouse 云上 SharedMergeTree、自管 S3BackedMergeTree，官方明说自管比标准部署更复杂；Doris 3.0 社区版把存算分离做成开源原生，计算组 SQL 管理，不用手改配置，弹性是"加节点即算力"而非数据迁移。

一、先说结论

• 两者都支持存算分离，这点先确认。
• 差异在开放程度与落地复杂度：ClickHouse 自管要改 XML、chown、restart，或上云才拿完整体验；Doris 社区版开箱即用。
• 原理：计算变无状态，数据放共享存储，存储只买一份。
• 选型看"DIY 改造还是开箱即用弹性"。

二、问题是怎么产生的

存算分离本质：计算节点变无状态，数据放共享存储（对象存储 / HDFS），计算和存储各自伸缩，存储只买一份。Doris 把元数据从 BE 抽出来交给无状态 Meta Service 统一管事务版本和 Tablet 元数据，BE 只算不存主数据；计算节点挂了不影响数据，扩计算不搬副本。

ClickHouse 这边，ReplicatedMergeTree 数据能放对象存储，但元数据仍留在每个 clickhouse-server 上，复制时元数据也要在副本间同步。SharedMergeTree 把元数据挪到 clickhouse-keeper + 共享存储，分离更彻底——但官方明确说这套主要在 ClickHouse Cloud 里"无需配置"即用，自管走"改 XML + chown + restart"。官方对自管措辞直白：实现和管理比标准部署更复杂。所以存算分离不是"开个开关"，而是一次运维模型转变。

这里有个容易忽略的坑：ClickHouse 官方在存算分离指南里特别提醒，不要给 S3 / GCS 配对象存储生命周期策略，会导致表损坏。也就是说，自管这条路不仅要会改 XML、chown、restart，还得避开生命周期策略这个雷。很多团队评估时只看了"支不支持"，没把运维成熟度算进去，上线后才发现自管比想象中重。把"能不能分离"和"分离得好不好落地"分开看，选型才不会偏。

把"能不能分离"和"分离得好不好落地"分开，关键在运维成熟度。存算分离把数据一致性、版本管理、缓存命中这些都从 BE 内部挪到了共享存储 + Meta Service 这一层，系统边界变了，排障思路也要变。ClickHouse 自管这条路，官方自己都明说比标准部署更复杂，因为它要你既懂对象存储、又懂 clickhouse-keeper、还得记住"别配生命周期策略"这种反直觉的雷；Doris 社区版把这些复杂性收进 Meta Service 和计算组，对外只暴露 SQL。所以同样是分离，团队要具备的运维能力完全不同——评估时别只比特性列表，要比对"谁的配置我能稳稳维护"。

三、怎么做：两边落地路径

下面把两条路并排放，最能看清复杂度差异。

3.1 ClickHouse 自管（要改配置）

官方指南在 config.d 新建存储配置，把 S3 挂成磁盘，再重启：

<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>

chown clickhouse:clickhouse /etc/clickhouse-server/config.d/storage_config.xml
service clickhouse-server restart

官方特别提醒：不要给 S3 / GCS 配对象存储生命周期策略，会导致表损坏。

3.2 Doris 计算组（一条 SQL）

Doris 计算组用 ALTER SYSTEM ADD BACKEND 加 tag.compute_group_name 指定，无单独"建计算组"语句：

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;

加完数据不动、只做缓存预热，无副本搬迁。Compute Group 隔离不靠多副本：数据在共享存储只有一份，多个组读同一份。

3.3 授权与切换

GRANT USAGE_PRIV ON COMPUTE GROUP etl TO 'etl_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）放热数据块。新计算组刚建好时是冷的，首查回源对象存储，之后热点自然缓存到本地，查询就回到本地盘速度。弹性是"加节点即算力"，代价只是一次缓存预热，而不是一次数据迁移。Doris 官方口径：相比存算一体三副本，存储成本最高降 90%——因为共享存储只存一份，计算组之间不再各存各的副本，副本从 3 降到 1，加对象存储比块存储便宜。

3.5 弹性与缓存命中的实测关注点

加完计算组别急着压测，先观察缓存预热曲线。新组首查必然回源对象存储，慢是正常的；判断预热是否到位，可以看 BE 的 File Cache 命中率随查询次数上升的趋势，以及首查与第 N 查的耗时差是否收敛到本地盘水平。另一个要点是多组共享一份数据带来的"读放大"问题：一个组的大量扫描会把冷数据拉进自己缓存，别的组再用时已经热了，这其实是好事，但也意味着首次全量扫描的带宽要算进上线窗口。把这些观测项写进上线检查单，弹性才可控。

四、关键维度对照表

维度	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 托管；国内无官方本地化商业团队做信创 / 等保适配

五、可批注落地清单

核对项	动作	通过标准	批注
CK 自管	改 config.d XML	重启生效	复杂度高 □
CK 坑	不配生命周期策略	表不损坏	注意 □
Doris 模式	部署选分离模式	Meta Service 起	□
计算组	ADD BACKEND tag	SHOW 显示	□
授权	GRANT / SET	用户生效	□
隔离	USE @组	读写分离	□
成本	算副本数	降 90%	□

迁移改造的工作量，和你们对运维成熟度的要求成正比。Doris 社区版虽然开箱即用，但仍要规划 Meta Service 与共享存储；ClickHouse 自管同样要会配对象存储与缓存。把这张清单在测试环境挨个打勾，比凭感觉争论"哪个支持"更有决策价值。最后一句：选型看的是"开箱即用弹性还是 DIY 改造"，不是"支不支持"。

六、常见问题（FAQ）

Q：ClickHouse 支持存算分离吗？

支持。云上 SharedMergeTree，自管 S3BackedMergeTree，但自管官方明说更复杂。

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

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

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

Doris 官方：相比三副本最高降 90%，共享存储只存一份。

Q：ClickHouse 自管坑？

改 XML、chown、restart；别配对象存储生命周期策略，否则表损坏。

Q：选型看什么？

看"DIY 改造还是开箱即用弹性"。无专职运维的，Doris 社区版更省心。

落地清单的价值，是让"运维成熟度"从一句空话变成可打勾的动作。每一项背后都是一次真实验证：CK 自管改 XML 重启后是否真的生效、Doris 计算组 SHOW 出来布局对不对、授权后用户能不能按组路由、隔离是否真的读写分开。清单打满，上线才有底气。

Q：计算组之间数据会互相影响吗？

多计算组读同一份共享存储，数据不重复；但默认 Peer 读开启时缓存会互通，严格隔离场景要在 BE 关掉 Peer 读，让各组缓存独立，避免一个组的扫描污染另一个组的缓存命中。

Q：存算分离适合小数据量吗？

如果数据量小、增长慢，存算一体的三副本往往更简单也更省心；分离带来的 90% 存储降幅要在数据量真正大、对象存储比块存储便宜的差距拉开后才划算，小体量上分离反而多了 Meta Service 的运维项。

再补一句给运维读者：存算分离上线后，监控口径要从"看 BE 磁盘"切换到"看共享存储 + File Cache 命中"。很多团队沿用存算一体的老监控，盯着 BE 本地盘使用率，结果分离后本地盘几乎不涨，误以为没写入——其实数据在对象存储。正确做法是把 File Cache 命中率、远程读占比、共享存储容量与账单都接进监控，否则弹性带来的"存储只买一份"反而让你看不清真实用量。监控视角的切换，是存算分离落地里最容易被忘、却最关键的一步。

Q：存算分离后本地盘还用大吗？

BE 本地盘主要放 File Cache 热数据，容量按热数据比例规划即可，不需要像一体模式那样按全量数据三副本配盘；冷数据在共享存储，本地盘压力小很多，这也是存储降本的来源之一。

最后落到一句大白话：存算分离省的是存储的钱，费的是运维的心。账要两边一起算——一边是对象存储比块存储便宜、副本从三降到一带来的成本降幅，一边是你要多懂一层共享存储、缓存、元数据服务的运维心智。哪边重，取决于你的数据量和团队人力。把这两本账摆平，再决定上不上分离，比盯着"支持不支持"这种对错问题有用得多。架构没有免费的答案，只有明码标价的取舍。