数据归档与冷热分离。

数据量一上来，很多团队的第一反应是“加机器”。可真正撑过几年业务增长的人会发现，存储成本不是线性涨的，查询性能也不是靠堆资源就能一直扛住的。尤其是当一张订单表从千万行变成十亿行，最近三天的数据被频繁访问，三年前的数据一年也查不了一次，这时候继续把冷热数据混在一起，就像把当季衣服和十年前的老棉袄塞进同一个衣柜——找起来费劲，占地方，还容易把柜门撑坏。

冷热分离不是“搬数据”，而是生命周期管理

很多人把冷热分离理解成“把旧数据挪到便宜存储”，这只说对了一半。真正的冷热分离，核心是给数据定生命周期：什么时候是热数据，什么时候转温，什么时候归档，什么时候可以彻底删除。它既是一个存储架构问题，也是一个数据治理问题。

如果只做物理搬迁，不做访问模式分析和元数据管理，结果往往是：数据是搬走了，但业务方还是能通过某个隐藏查询接口扫全表，最后慢查询照样拖垮在线库。冷热分离的第一原则，是让不同温度的数据走不同的访问路径，而不是简单地换一个硬盘。

怎么定义“冷”和“热”

冷热边界不能拍脑袋。常见判断维度有三个：访问频率、访问延迟要求、数据保留合规要求。

访问频率最直观。比如订单数据，最近 7 天查询量可能占 95%，30 天外的查询不到 1%。延迟要求则决定存储介质：热数据要毫秒级，温数据可以接受秒级，冷数据几分钟甚至小时级也能忍。合规要求容易被忽略，金融、医疗等行业往往要求数据保留 5 年甚至更久，但“保留”不等于“随时在线可查”，这就给归档留出了空间。

实践中，我建议用“访问热度 + 业务价值”双维度划分。有些数据虽然访问少，但一旦需要就必须快速拿到，比如风控调证数据，这类更适合放在温存储，而不是直接丢进对象存储的深冷层。

三层存储模型是主流解法

目前比较成熟的落地方式，是热、温、冷三层：

热层用 MySQL、PostgreSQL 或分布式数据库，扛住在线事务和秒级查询。温层可以用 ClickHouse、Doris、Elasticsearch 这类分析型存储，承接历史查询和报表。冷层则放到 S3、OSS、HDFS 等对象存储或文件系统，配合 Hive、Spark、Presto 做离线分析。

以日志场景为例，最近 3 天放 Elasticsearch 热节点，4 到 30 天放温节点，30 天以上压缩后传对象存储。查询时通过统一 SQL 网关路由，业务方不用关心数据到底在哪一层。这种架构既能控制成本，又能保留历史数据的可查性。

落地时最容易踩的三个坑

第一个坑是“归档后查不了”。很多团队把数据导出成 CSV 丢到对象存储就完事了，没有建元数据索引，结果真要用的时候不知道文件里是什么，只能重新翻库。归档必须带 schema、时间范围、业务主键和校验信息。

第二个坑是“双写不一致”。冷热分离常伴随数据同步，如果在线库写完再异步写归档库，中间失败没有补偿，就会出现数据缺口。建议用 CDC 或 Binlog 做准实时同步，并建立对账机制。

第三个坑是“删除策略太激进”。冷数据不是垃圾数据，删除前必须确认合规要求和业务依赖。最好设置“冷归档 -> 深归档 -> 待删除”的缓冲期，到期前自动通知数据负责人。

总结

数据归档与冷热分离，表面看是存储成本问题，底层其实是数据架构和治理能力的体现。好的冷热分离，应该让热数据跑得更快，让冷数据存得更便宜，同时保证任何一层的数据都能被正确找到、正确理解、正确使用。别把它当成一次性的迁移项目，而要当成持续运转的数据生命周期机制。毕竟，数据不是越多越好，而是越可控越有价值。