ClickHouse 与对象存储 S3 集成：冷热分层、外部表与备份恢复

本地磁盘的局限：
□ 容量有限：单机磁盘/SSD 贵，扩容要加机器
□ 成本高：热存储贵，海量冷数据存本地是浪费
□ 集群扩容复杂：加节点、重分布

对象存储（S3 兼容）的优势：
□ 成本低：每 GB 价格远低于本地 SSD/HDD
□ 容量无限：按需扩，不占本地盘
□ 弹性：多个 ClickHouse 节点共享同一对象存储

对象存储的代价：
□ 延迟高：网络往返 >> 本地盘（几百毫秒 vs 微秒）
□ 吞吐受限：并发上限、单对象大小限制
□ 一致性：S3 是「最终一致/强一致」视厂商（读后写）

结论：对象存储不是「替代本地盘」，是「第二层」
□ 热数据（近期/高频查询）→ 本地盘（快）
□ 冷数据（历史/低频查询）→ S3（省）
→ 冷热分层：热本地 + 冷 S3

成本示意：
本地 SSD 1TB 的成本 ≈ S3 存储数 TB~几十 TB
→ 把 80% 的历史冷数据放 S3，磁盘开销大幅下降

S3 兼容生态：
□ AWS S3（原生）
□ MinIO（自建、国产替代）
□ 阿里 OSS / 腾讯 COS / 华为 OBS（各云厂商 S3 兼容）

ClickHouse 的集成方式（多选）：
□ 表引擎 S3(...)：直接读 S3 上的文件为「只读表」
□ 表函数 s3(...)：查询时临时读 S3 文件
□ 存储策略（冷热分层）：把部分 part 存到 S3
□ BACKUP 命令：备份目标直接写 S3
□ Kafka/对象存储作为数据管道中转

配置要素：
□ endpoint / bucket / key / secret
□ region（区域）、访问凭证
□ 路径格式：s3://bucket/path/file.*（通配符支持）
□ 文件格式：Parquet/JSON/CSV（与查询格式联动）

接入注意：
□ 网络：ClickHouse 节点能访问对象存储（内网/VPC）
□ 凭证：环境变量或 config 配置（勿硬编码）
□ 版本兼容：不同 ClickHouse 版本 S3 功能演进

-- S3 表引擎（只读外部表，示意）
CREATE TABLE s3_events
ENGINE = S3('s3://my-bucket/events/*.parquet', 'Parquet')
SETTINGS ...;
-- 查询 s3_events 即查询对象存储中的文件

S3 表引擎特点：
□ 只读：不能写回 S3（数据在外部管理）
□ 文件即表：一行 = 文件里一条记录
□ 支持通配符：s3://bucket/logs/2026-09-*.json
□ 文件格式：Parquet/ORC/JSONEachRow/CSV
  → Parquet 列式最适配（裁剪、压缩）

典型场景：
□ 临时分析：直接查 S3 上的离线导出/日志文件
□ 数据湖查询：ClickHouse 当「SQL 查询层」读 Data Lake
□ 事件日志：历史日志归档在 S3，随时可查
□ 不落库的探索：先看 S3 数据再决定要不要导入

限制：
□ 查询慢于本地表（网络 + 无索引优化依赖分区裁剪）
□ 无主键索引（依赖文件结构/分区裁剪）
□ 写入要单独做（INSERT INTO ... SELECT FROM s3）

实践技巧：
□ Parquet 文件按「分区前缀」组织 → 查询走前缀裁剪
□ 表函数 s3() 临时用，表引擎建长期用

-- 表函数临时查询 S3 上的 Parquet
SELECT count(), sum(amount)
FROM s3('s3://my-bucket/events/2026-09-*.parquet', 'Parquet')
WHERE user_id = 123;

-- 从 S3 导入本地表
INSERT INTO events_local
SELECT * FROM s3('s3://my-bucket/events/all.parquet', 'Parquet');

Data Lake + ClickHouse 查询层：
□ 数据湖：海量原始数据统一放 S3（Parquet/Iceberg/Hudi）
□ ClickHouse 角色：SQL 查询层，直接查湖上数据
□ 湖仓一体：湖存原始、仓管模型、ClickHouse 查

外部表（External Table）：
□ 在 ClickHouse 建「指向 S3 的只读表」
□ 统一 schema：把湖上的 Parquet 映射成可查的表
□ 与「本地物化表」并存：热数据本地、冷数据湖上

查询路径选择：
□ 冷数据查询 → 直接查 S3 外部表（慢但省）
□ 热数据查询 → 查本地表（快）
□ 混合 → 本地 + 外部表 union（冷热合并查询）

架构价值：
□ 存储解耦：数据在 S3，不绑 ClickHouse 节点
□ 多引擎共享：Spark/Flink/ClickHouse 都可读湖上数据
□ 弹性：湖上数据增长不影响本地磁盘

-- 湖上 Parquet 映射为外部表（示意）
CREATE TABLE lake_orders
ENGINE = S3('s3://lake/orders/*.parquet', 'Parquet')
SETTINGS schema = 'order_id UInt64, user_id UInt64, amount Float64, ...';
-- 本地表 + 湖上表统一查询（冷热合并）
SELECT ... FROM orders_local WHERE ts > today() - 7
UNION ALL SELECT ... FROM lake_orders WHERE ts <= today() - 7;

冷热分层机制：
□ 存储策略（storage policy）：定义本地盘 + S3 的层级
□ TTL 迁移：数据到期 → 自动从本地迁到 S3
  （不是删除，是搬到 S3 冷层）
□ 查询透明：迁到 S3 后查询仍可读（走网络较慢）

配置三层：
□ 卷（volume）：本地卷（热）+ S3 卷（冷）
□ 策略：把卷组合成策略（move_factor / TTL 规则）
□ 表指定策略：建表时挂 storage policy

TTL 规则：
□ 按列/按表设置过期：TTL + TO DISK / TO VOLUME
□ 例：数据 7 天后迁到 S3（热 7 天）
□ 部分/全部迁移：按分区/按时间

收益：
□ 本地盘只用「热窗口」（近 7 天）
□ 历史数据自动进 S3（低成本无限容量）
□ 查询：热数据快、冷数据可查（接受延迟）

注意：
□ 迁移有后台任务开销（Move 过程占 IO/网络）
□ 查询冷层走网络 → 看板要「热窗口优先」
□ 迁移进度监控：part 是否在预期层

-- 存储策略 + TTL 迁移（示意）
CREATE TABLE events (
  ts DateTime, data String
) ENGINE = MergeTree()
ORDER BY ts
TTL ts + INTERVAL 7 DAY TO VOLUME 's3_cold'
SETTINGS storage_policy = 'hot_then_cold';
-- 7 天前的 part 自动迁到 S3 冷卷

为什么 S3 适合备份：
□ 容量无限 + 低成本（备份常是多份历史快照）
□ 生命周期管理（版本、过期清理）
□ 跨地域/跨可用区容灾（对象存储自带冗余）

ClickHouse 备份到 S3：
□ BACKUP ... TO S3('s3://bucket/backup/...')
  → 支持全量/增量、表/数据库级
□ 元数据 + 数据：备份是「一致性快照」
□ 恢复：RESTORE FROM S3(...)

备份策略：
□ 全量 + 增量组合（定期全量 + 频繁增量）
□ 保留周期：按版本保留 N 份（S3 生命周期清理）
□ 异地容灾：备份到「另一个区域/云」

恢复演练：
□ 定期做「恢复演练」（验证备份可用）
□ 恢复耗时测试（大数据量恢复是小时级）
□ 灾难场景：集群全挂 → 新集群 RESTORE

注意：
□ 备份一致性：BACKUP 自带一致性（快照）
□ 加密：S3 服务端加密 / 客户端加密
□ 权限：备份桶最小权限（防误删/防泄漏）

-- 备份到 S3（示意）
BACKUP TABLE db.events TO S3('s3://bucket/backups/2026-09-28/')
SETTINGS ...;
-- 恢复
RESTORE TABLE db.events FROM S3('s3://bucket/backups/2026-09-28/');

为什么走 S3 中转：
□ 大量数据导出/导入：走网络直传慢、易断
□ S3 中转：先批量写 S3，再批量读 → 稳定、可重试
□ 跨集群/跨云迁移：S3 是中间媒介

导入（S3 → ClickHouse）：
□ 外部数据落 S3（导出/第三方）
□ ClickHouse 用 INSERT ... SELECT FROM s3(...) 批量灌入
□ 并行：多文件/多线程并发读 S3

导出（ClickHouse → S3）：
□ SELECT ... INTO OUTFILE s3://...（或 INSERT INTO FUNCTION s3(...)）
□ 导出格式：Parquet/CSV/JSON
□ 分区导出：按天/按维度分文件

批量迁移场景：
□ 旧集群 → 新集群（BACKUP/RESTORE 或导出导入）
□ 云迁移（本地 → 云上）
□ 数据仓库导出到数据湖（归档/共享）

批量优化的注意：
□ 文件大小合理（几十 MB~百 MB，勿太碎）
□ 并行度控制（S3 有请求限制，并发过高限速）
□ 校验：导入后 count/sum 对账

-- 导出本地表到 S3（示意）
INSERT INTO FUNCTION s3('s3://bucket/export/events.parquet', 'Parquet')
SELECT * FROM events WHERE day = '2026-09-28';
-- 导入 S3 到本地
INSERT INTO events
SELECT * FROM s3('s3://bucket/export/events.parquet', 'Parquet');

性能关键：
□ 网络延迟：每次 S3 读是网络往返 → 查询慢于本地
□ 并发限制：S3 单前缀有请求速率限制
  → 高并发读会限速/超时
□ 文件组织：按分区前缀组织 + Parquet 列裁剪 → 大量剪枝

优化手段：
□ 本地缓存：查询过的 S3 part 缓存在本地磁盘
  → 重复查询走缓存，减少网络往返
  （ClickHouse 的 S3 本地缓存机制）
□ 并行读：多 part 并发拉取
□ 索引/分区：按查询模式组织前缀

可靠性关键：
□ S3 一致性：读后写（read-after-write）→ 近期写入可读
  （部分厂商最终一致：写入后短暂读不到）
□ 网络故障：查询 S3 中断 → 重试/降级
□ 凭证过期/权限：授权失败 → 桶访问配置

权衡总结：
□ 冷数据查询「慢一点」可接受 → S3 直接查
□ 冷数据也高频 → 预热到本地 / 定期物化
□ 一致性敏感（刚写就查）→ 本地表为主，S3 兜底

决策：
冷查询低频 → S3 直接查（省）
冷查询高频 → 本地缓存/物化（快）
一致性敏感 → 本地为主 + S3 归档（稳）

生产架构分层：
□ 热层（本地盘）：近 N 天热数据，高频查询
  → MergeTree + 存储策略热卷
□ 冷层（S3）：历史数据，TTL 自动迁入
  → 存储策略冷卷 / 外部表
□ 备份层（S3 桶）：定期备份 + 保留版本
□ 数据湖（S3 桶）：原始数据 / 共享数据（外部表查）

落地步骤：
1. 网络与凭证：ClickHouse 节点可达 S3，凭证安全
2. 存储策略：定义热卷 + S3 冷卷
3. TTL 规则：热窗口（如 7 天）到期迁 S3
4. 备份：BACKUP 定期写 S3 + 恢复演练
5. 外部表：湖上数据建外部表按需查
6. 监控：迁移进度、冷查询延迟、备份成功

风险与对策：
□ 迁移任务挤压写入 → 调 move 并发/时间窗
□ 冷查询慢 → 热窗口设计 + 物化热点
□ S3 故障 → 本地热层兜底 + 备份可恢复
□ 成本失控 → 生命周期清理 + 分层预算

推荐分层（示意）：
本地热卷：近 7 天（高频）    → MergeTree
S3 冷卷：7 天~1 年（低频）    → TTL 迁移
S3 备份：每日/每周快照        → BACKUP
S3 数据湖：原始数据湖          → 外部表按需
→ 热查询快、冷可查、备可恢复