用途
当 ClickHouse 被用作低延迟分析服务的目标存储时，可使用本技能。它帮助智能体设计数据摄取、分区、物化视图和面向查询的 schema，在保证快速读取的同时兼顾运维安全与成本控制。
适用场景
- 为实时分析设计或修改 ClickHouse 表
- 构建事件密集型的分析聚合层
- 为预计算指标创建物化视图
- 优化低延迟仪表盘和指标 API
- 规划高吞吐事件流的摄取模式
当工作负载更适合事务型数据库，或更适合没有延迟要求的批处理数仓时，不应使用本技能。
工作流
1. 定义延迟、新鲜度和查询访问模式
需要包含：
- 可接受的查询延迟目标（p50、p99）
- 数据新鲜度要求（秒级、分钟级、最终一致）
- 主要查询模式（点查、时间范围扫描、聚合）
- 预期并发查询负载和用户规模
2. 选择合适的表引擎和 schema 设计
- 大多数分析负载使用 MergeTree 家族
- 需要最终一致下去重时使用 ReplacingMergeTree
- 需要预聚合汇总时使用 AggregatingMergeTree
- 需要可变状态时使用 CollapsingMergeTree 或 VersionedCollapsingMergeTree
- 定义与主要查询过滤条件对齐的排序键
- 分区键用于生命周期管理，而非查询速度
3. 为吞吐量和合并安全设计摄取
- 批量插入优于单行写入（目标每次插入 1000+ 行）
- 避免过多分区——高分区数会造成合并压力
- 写入并发高时使用 Buffer 表或异步插入
- 若来源保证至少一次投递，需定义去重策略
4. 构建带明确契约的物化视图
- 物化视图由插入触发，不会追溯处理历史数据
- 定义源 schema 变更时的行为
- 记录源插入到视图可用之间的延迟
- 测试合并后视图聚合结果仍然正确
5. 规划保留、TTL 和存储分层
- 使用 TTL 表达式自动删除分区
- 若关注成本，可分离热存储与冷存储层
- 为每张表记录保留 SLA
- 测试 TTL 不会静默删除消费者仍需要的数据
6. 让运维可观测、可恢复
- 监控合并积压、parts 数量和复制延迟
- 对查询延迟退化和内存压力设置告警
- 规划集群扩展：分片数、副本数和再平衡
- 为关键表定义备份与恢复流程
常见误区
- “ClickHouse 很快，所以不需要优化 schema。”——排序键、分区选择和引擎选择决定查询是毫秒级还是秒级。速度是设计出来的，不是保证的。
- “我们可以一次只插入一行。”——单行插入会导致 parts 过多、合并压力，最终性能退化。规模化场景下批量写入不是可选项。
- “物化视图会自动处理一切。”——视图由插入触发并依赖合并行为。schema 变更、回填和追溯修正都需要明确规划。
- “保留策略不紧急——存储很便宜。”——无界增长会增加合并开销、备份时间和查询扫描范围。TTL 和生命周期管理是运维要求。
风险信号
- 生产环境无缓冲的单行插入
- 分区键为查询速度而非生命周期管理选择
- 物化视图没有记录延迟或 schema 变更行为
- 高容量表没有保留或 TTL 策略
- 排序键与主要查询模式不对齐
- 没有监控合并积压或 parts 数量
- 数据量增长但集群扩展计划未定义
- 回填策略假设物化视图会追溯处理旧数据
验证清单
- 查询延迟、新鲜度和访问模式需求已记录
- 表引擎、排序键和分区键选择有依据
- 摄取使用批量写入并有明确去重策略
- 物化视图有记录的契约、延迟预期和 schema 变更计划
- 所有高容量表都定义了 TTL 和保留策略
- 运维监控覆盖合并积压、parts 数量、复制延迟和查询延迟
- 扩展和恢复流程已记录