核心是将数据访问频率、业务语义与重建成本三类信号转化为可执行的存储资源配置，实现容量增长与业务节奏同步，避免为冷数据支付热存储费用。
容量规划中处理冷热数据分离存储，核心是把“数据什么时候用、用得多不多、能不能慢一点”变成可执行的存储资源配置动作。不是简单按时间切一刀，而是让容量增长与业务访问节奏同步，避免为冷数据持续支付热存储的费用。
明确冷热定义，避免一刀切归档
冷热不能只看“创建时间”。比如AI制药中，半年前的某次靶点筛选结果可能下周就要复用；区块链项目里，三年前某笔交易虽不常查，但合规审计必须保留且可即时调取。建议结合三类信号综合判断：
- 访问行为：过去90天内是否被查询过？平均响应延迟是否超过5秒？
- 业务语义：是否标记为“归档”“合规保留”“只读快照”？是否关联已关闭的项目ID？
- 重建成本：该数据能否从原始链上/日志中重新生成？生成耗时是否超过2小时？
只有同时满足“极少访问+无重建价值+长期保留义务”的数据，才适合进入冷层。
分层介质选型要匹配SLA而非仅看单价
便宜≠合适。对象存储（如OBS/S3）单位GB成本低，但首次读取延迟可能达秒级；磁带库成本更低，但恢复一份数据需人工装带+数小时等待。关键看你的冷数据真实使用场景：
- 需要随时可查、允许秒级延迟→ 选支持分层缓存的对象存储（如阿里云OSS IA、AWS S3 Glacier IR）
- 仅用于年度审计、接受小时级恢复→ 可用标准Glacier或本地光盘库
- 冷数据仍需高频JOIN热表查询→ 优先选支持联邦查询的方案（如Doris 2.0冷热统一SQL接口），避免应用改写
自动化迁移策略要留出弹性窗口
硬性规定“超30天自动下沉”容易误伤。实际操作中推荐组合策略：
- 按分区+最后修改时间（LMT）双条件触发：例如“分区最后更新时间早于45天，且该分区近7天查询次数＜3次”，才启动迁移
- 保留最小热分区数（HPN）兜底：如设置HPN=5，确保最新5个时间分区始终在高性能层，防止突发回溯需求卡顿
- 迁移后保留元数据本地化：像DWS和TiDB那样，把冷数据的表结构、索引、统计信息留在本地，查询时能快速路由，避免全量元数据跨网络拉取
容量水位监控要区分逻辑与物理维度
传统监控只看“磁盘用了85%”，但冷热分离后更需关注：
- 热层IO饱和度：SSD盘的IOPS利用率是否持续＞70%？若是，说明热数据范围过大或缓存未生效
- 冷层对象生命周期合规性：检查OBS/S3中冷数据的保留策略是否与法规要求一致（如GDPR要求7年，实际配置是否为7年+1天？）
- 迁移积压队列长度：如果冷数据待迁移量连续3天增长＞5%，说明迁移吞吐跟不上写入速度，需扩容迁移任务资源或调整下沉阈值
冷热分离不是一次配置就一劳永逸，而是让容量规划从静态预算转向动态调节——数据在哪存、怎么存、何时动，都由真实访问反馈驱动。
