把 RustFS 当 ClickHouse 的 S3 存储盘：冷热分层落对象存储

一句话定位：RustFS 是面向 AI 时代、从零原生打造的高性能分布式对象存储，100% 兼容 S3 API，Apache 2.0 协议，可作为 MinIO 的 drop-in 替代方案。

[问题背景：ClickHouse 的冷数据去哪了](#问题背景：ClickHouse 的冷数据去哪了)
[RustFS 为什么能当 ClickHouse 的 S3 盘](#RustFS 为什么能当 ClickHouse 的 S3 盘)
[在 RustFS 上准备桶与账号](#在 RustFS 上准备桶与账号)
[配置 ClickHouse 的 S3 磁盘](#配置 ClickHouse 的 S3 磁盘)
真实场景里的三处边界
总结与下一步

1. 问题背景：ClickHouse 的冷数据去哪了

我维护过一套日志分析的 ClickHouse 集群，热数据放本地 NVMe，三个月前的分区几乎没人查，却实打实占着昂贵的高性能盘。盘快满的时候，要么扩容、要么手动 ALTER TABLE ... DROP PARTITION，这两种都不优雅。

ClickHouse 自己提供了一条更顺的路：把部分磁盘声明成 S3 类型，让冷分区直接落到对象存储，热数据继续留在本地。问题是选哪个 S3 端点------云厂商的对象存储出口贵、又怕被锁定；而 RustFS 这种自托管、100% S3 兼容的开源存储，能把冷数据留在你自己的机房，容量随对象存储横向扩展，不绑云。

2. RustFS 为什么能当 ClickHouse 的 S3 盘

ClickHouse 的 storage_configuration 支持把一块磁盘的 type 设成 s3，底层就走 S3 协议读写数据文件。只要端点满足 S3 兼容，它不关心背后是哪家。RustFS 从协议层实现了 S3 API 兼容，所以 ClickHouse 的 S3 磁盘把 endpoint 指到 RustFS 的 9000 端口就能用，不需要任何网关或适配层。

关键差异在寻址方式。ClickHouse 的 S3 磁盘默认按路径风格拼 URL，也就是 http://<host>:<port>/<bucket>/<key>；RustFS 这类自建端点正好也是路径风格，两边天然对得上，不需要额外配置虚拟托管域名。

数据必须来自官方 benchmark / 文档 / 已验证来源，严禁编造或夸大。

3. 在 RustFS 上准备桶与账号

先起一个 RustFS 实例（这里用 docker 单节点示意，生产请用固定版本与多节点分布式部署）：

bash 复制代码

docker run -d -p 9000:9000 -p 9001:9001 \
  -e RUSTFS_ACCESS_KEY=rustfsadmin \
  -e RUSTFS_SECRET_KEY=rustfsadmin \
  -v $(pwd)/data:/data \
  -v $(pwd)/logs:/logs \
  rustfs/rustfs:1.0.0-rc.5

建一个专门给 ClickHouse 用的桶，并建议建一个独立 IAM 用户而不是用默认 rustfsadmin：

bash 复制代码

rc alias set local http://localhost:9000 rustfsadmin rustfsadmin
rc mb local/clickhouse-bucket

官方建议每个上层应用用独立桶 + 独立账号，权限按最小原则收紧。RustFS 在 rc 阶段已废弃硬编码默认口令，部署必须显式设置 RUSTFS_ACCESS_KEY / RUSTFS_SECRET_KEY。

4. 配置 ClickHouse 的 S3 磁盘

在 config.xml（或 config.d/ 下的独立文件）里挂上 storage_configuration。下面这段把一块名为 rustfs_s3 的磁盘声明成 S3 类型，endpoint 直接带桶名 clickhouse-bucket，走路径风格：

xml 复制代码

<clickhouse>
  <storage_configuration>
    <disks>
      <rustfs_s3>
        <type>s3</type>
        <endpoint>http://rustfs:9000/clickhouse-bucket/</endpoint>
        <access_key_id>rustfsadmin</access_key_id>
        <secret_access_key>你的强密钥</secret_access_key>
        <metadata_path>/var/lib/clickhouse/disks/rustfs_s3/</metadata_path>
      </rustfs_s3>
    </disks>
    <policies>
      <rustfs_tier>
        <volumes>
          <main>
            <disk>rustfs_s3</disk>
          </main>
        </volumes>
      </rustfs_tier>
    </policies>
  </storage_configuration>
</clickhouse>

声明好磁盘后，建表时指定存储策略，让整张表或某个分区落到 RustFS：

sql 复制代码

CREATE TABLE events_cold
(
    ts DateTime,
    payload String
)
ENGINE = MergeTree
ORDER BY ts
SETTINGS storage_policy = 'rustfs_tier';

也可以只把冷分区迁过去，热数据留本地盘------这是冷热分层的常见做法。链路从 ClickHouse 服务到落盘如下：

5. 真实场景里的三处边界

第一，路径风格是默认、也是 RustFS 这边最稳的接法。endpoint 里把桶名写全（http://rustfs:9000/clickhouse-bucket/），不要指望 ClickHouse 去拼虚拟托管域名------RustFS 没有默认域名，路径风格最直接。

第二，凭证用独立 IAM 用户，不要拿默认 rustfsadmin 顶上。ClickHouse 磁盘把 access_key_id / secret_access_key 写进配置文件，一旦这台机器被读到配置，权限应该只覆盖 clickhouse-bucket 这一个桶，而不是整个 RustFS。

第三，生产走 HTTPS。示例里用 http 是为了在内部网络快速验证；跨节点、跨机房时，RustFS 支持原生 TLS（挂 RUSTFS_TLS_PATH 或前面放 Nginx/Caddy 反代），ClickHouse 侧把 endpoint 换成 https:// 即可。RustFS 仍处于 1.0 正式发布前的预发布阶段，上生产前先在 staging 用真实分区做一次 OPTIMIZE + 查询回放，确认数据能在 S3 盘上正常读写再切。

配置时真正要填的字段就这几项：

6. 总结与下一步

ClickHouse 的 S3 磁盘把"冷数据下沉到对象存储"变成了几行配置的事，而 RustFS 用 100% S3 兼容把这件事留在了你自己的基础设施里------不绑云、容量随对象存储横向扩展、和 ClickHouse 的本地热盘组成一套完整的冷热分层。

下一步建议这样验证：先在测试集群挂上 rustfs_tier，建一张小表写入、 SELECT 回读确认数据确实落在 RustFS 桶里，再挑一张真实的历史大表做分区迁移，观察查询延迟是否在可接受范围。需要多集群共享同一份冷数据时，RustFS 的分布式部署也能让多个 ClickHouse 节点指向同一个桶。

深入学习 RustFS：RustFS

技术文档： RustFS 技术文档- 提供架构、安装指南和 API 参考。

GitHub 仓库： GitHub 仓库 - 获取源代码、提交问题或贡献代码。