冷热数据分层：业务库、归档库、对象存储和湖仓
冷热数据分层的目标是在查询性能、存储成本和历史可追溯之间取得平衡。
冷热数据分层：业务库、归档库、对象存储和湖仓
业务系统运行几年后，数据库里会堆积大量历史数据。最近 30 天订单经常被查询，三年前订单偶尔用于客服或审计，五年前日志可能只在合规场景下访问。
如果所有数据都放在业务主库里，成本和性能都会变差。冷热数据分层就是把不同访问频率的数据放到不同位置。
什么是热、温、冷数据
热数据是高频访问的数据。比如最近订单、当前库存、活跃用户、未完成工单。它需要低延迟和强一致。
温数据是低频但还会被业务查询的数据。比如半年内订单、历史报表、客服查询数据。
冷数据是极少访问但不能删除的数据。比如多年历史日志、审计流水、合规留存数据。
为什么要分层
第一是性能。历史数据越多，索引越大，备份越慢，DDL 越重，查询越容易扫到无关数据。
第二是成本。高性能数据库存储很贵，把极少访问的数据长期放在主库里不划算。
第三是治理。不同数据有不同保留周期、权限和访问方式，分层后更容易管理。
分区是分层的前提
时间分区是最常见的方式。订单、日志、流水都适合按时间分区。
CREATE TABLE orders (
id BIGINT,
order_date DATE NOT NULL,
user_id BIGINT,
amount DECIMAL(12, 2)
) PARTITION BY RANGE (order_date);
有了分区，归档时可以按分区迁移或删除，而不是一行一行处理。
归档流程
一个常见归档流程是：
- 识别超过保留期的数据。
- 导出到归档库或对象存储。
- 校验行数和校验和。
- 标记归档完成。
- 从业务库删除或脱敏。
- 保留查询入口。
归档一定要可验证。不能只看任务成功，还要确认数据完整。
对象存储和湖仓
冷数据通常会进入 S3、OSS、HDFS 等对象存储，再用 Parquet、ORC 这类列式文件格式保存。
如果还需要表级管理、Schema 演进、快照和查询，可以使用 Apache Iceberg、Hudi、Delta Lake 这类湖仓表格式。
对象存储成本低，但查询延迟一般高于数据库。它适合离线分析、审计和低频历史查询。
查询入口设计
归档后不要让业务方完全找不到历史数据。可以设计统一查询入口：
- 最近 90 天查业务库。
- 90 天到 2 年查归档库。
- 2 年以上查对象存储或离线查询。
应用层可以屏蔽后端差异，但要明确不同层的延迟和能力差别。
常见坑
第一个坑是归档后没有校验。数据搬走了，但缺行、重复、字段错误没人知道。
第二个坑是只归档不提供查询。客服、审计、财务需要历史数据时会非常痛苦。
第三个坑是归档影响主库。大批量删除会产生锁、日志和复制延迟，必须分批执行或按分区操作。
小结
冷热分层的本质是把数据按价值和访问频率重新放置：
- 热数据留在业务库。
- 温数据进入报表库或归档库。
- 冷数据进入对象存储和湖仓。
好的分层设计，既能降低成本，也能保护业务库性能。