3. 冷热数据分层理论：数据温度的定义、冷热分层标准、分层存储策略

数据湖里存的数据，不是所有数据都值得用同样的方式对待。这是我做了几年数据湖之后，最深的一个体会。

你想想看，有些数据每天被查询几百次，有些数据存进去之后就再也没人碰过。如果把它们放在同一个存储层，成本上根本扛不住。所以，我们需要一个理论来指导——冷热数据分层。

3.1 数据温度的定义

什么叫「数据温度」？说白了，就是数据被访问的活跃程度。

我习惯把数据温度分成三个档位：

• 热数据：最近7天内频繁被查询、写入、更新的数据。比如今天的交易流水、实时监控指标。
• 温数据：过去1-3个月内偶尔被访问的数据。比如上个月的报表、历史订单。
• 冷数据：超过3个月甚至更久未被访问的数据。比如去年的日志、归档的审计记录。

但这里有个坑——温度不是一成不变的。数据会随着时间推移自然降温。我在项目中遇到过，有些团队把三个月前的数据直接归档到冷存储，结果业务部门突然要跑一个季度报表，冷存储的读取延迟直接让报表超时。嗯，这里要注意：降温策略要跟业务节奏对齐。

3.2 冷热分层标准

分层标准不能拍脑袋。我一般会从三个维度来定义：

维度	热数据	温数据	冷数据
访问频率	每天 ≥ 100 次	每周 1-10 次	每月 ≤ 1 次
响应时间要求	< 100ms	< 5s	可接受分钟级
数据保留周期	7 天内	1-3 个月	3 个月以上
存储介质	SSD / 内存	HDD / 标准对象存储	归档存储 / 磁带
副本数	3 副本 + 跨 AZ	2 副本	1 副本 + 纠删码

这个表是我在实际项目中反复调整过的。举个例子，副本数这块，我曾经为了省钱把热数据也降到2副本，结果一次AZ故障导致数据恢复花了整整两天。从那以后，热数据的副本数我再也没省过。

3.3 分层存储策略

有了标准，接下来就是怎么落地。我一般会设计一个自动化分层策略，而不是手动搬数据。

3.3.1 基于时间的自动降冷

最简单的策略：按数据的时间戳自动迁移。

-- 伪代码示例：数据降冷策略
IF data.age > 7 days THEN
    move_to_warm_storage(data)
ELIF data.age > 90 days THEN
    move_to_cold_storage(data)
ELSE
    keep_in_hot_storage(data)
END IF

这个策略虽然简单，但够用。我建议在实现时加上一个冷却窗口——比如每天凌晨2点执行一次降冷任务，避免影响白天的高峰查询。

3.3.2 基于访问频率的动态分层

有些数据虽然时间久，但突然被业务翻出来频繁查询。这时候静态策略就不够用了。

我习惯的做法是：

1. 记录每个数据分区的最后访问时间
2. 如果某个冷数据在24小时内被访问超过5次，自动提升为温数据
3. 如果温数据连续30天无人访问，降为冷数据

3.3.3 混合存储架构

实际落地时，我不会只用一种存储。下面这张图是我常用的分层架构：

这张图里，数据从热到冷是单向流动的。但别忘了，冷数据也可以回温。我一般在冷数据层保留一个回温接口，当业务需要时，可以手动或自动把冷数据恢复到温数据层。

3.4 分层策略的常见误区

最后，分享几个我踩过的坑：

• 误区一：一刀切。所有数据都按同一个时间策略降冷。实际上，不同业务线的数据温度曲线完全不同。比如财务数据可能半年后才开始审计查询，不能按通用的90天归档。
• 误区二：忽略元数据。冷数据虽然访问少，但元数据（比如文件列表、分区信息）依然需要热存储。否则查询冷数据时，光扫描元数据就要花几分钟。
• 误区三：不做回温测试。我曾经把一批冷数据归档到冰川存储，结果半年后合规审计需要调取，回温花了整整12小时。从那以后，我每个季度都会做一次回温演练。