冷热温数据定义：数据访问频率模型与判定标准

做数据生命周期管理，第一件事不是写脚本，也不是搭平台。你得先搞清楚一件事——你的数据，到底有多「热」？

我见过不少团队，一上来就搞自动降冷，结果把高频访问的热数据给归档到冷存储去了。业务方炸了，运维背锅。说白了，就是没把「数据温度」这个概念定义清楚。

这一章，我们就来聊聊冷、热、温数据到底怎么区分。我会结合我自己的项目经验，把判定标准和业务场景掰开揉碎了讲。

数据访问频率模型：温度计的原理

数据温度，本质上是一个时间衰减模型。你想想看，一条数据被创建的瞬间，访问频率最高。随着时间的推移，访问次数会逐渐下降。这个下降曲线，就是我们判断数据温度的依据。

我个人习惯把数据访问频率模型分为三个维度：

• 时间维度：最近一次访问时间（Last Access Time）
• 频率维度：单位时间内的访问次数（QPS/TPM）
• 周期维度：是否存在周期性访问规律（如月末结算、季度报表）

我在项目中遇到过一种情况：某张表平时几乎没人查，但每到月底最后三天，查询量暴增100倍。如果只看平均访问频率，它会被判定为「冷数据」。但实际上，它是典型的「温数据」——有规律的热周期。

冷/温/热数据的判定标准

先给出一套我常用的判定标准。这套标准我在三个不同规模的项目中验证过，从日均百万请求到十亿级别都适用。

数据类别	访问频率	最近访问时间	典型存储介质	响应时间要求
热数据	≥ 1000 次/天	最近 1 小时内	SSD / 内存	< 10ms
温数据	10 ~ 1000 次/天	最近 1 天 ~ 30 天	SATA HDD / 标准存储	< 100ms
冷数据	< 10 次/天	超过 30 天	归档存储 / 磁带	分钟级

嗯，这里要注意。上面的数字不是死规矩。我见过一些金融系统，热数据的判定标准是「最近 5 分钟内访问过」，因为交易数据延迟 1 秒就是事故。而做日志分析的场景，可能「最近 1 周内访问过」就算热数据了。

业务场景与数据温度的关系

数据温度不是技术指标，它本质上是业务价值的映射。同一个数据，在不同业务场景下，温度天差地别。

举个例子。用户订单数据：

• 电商场景：下单后 7 天内是热数据（用户频繁查物流），30 天后变成温数据（偶尔查历史订单），1 年后基本是冷数据。
• 财务审计场景：3 年前的订单依然是热数据，因为审计随时要调阅。我做过一个项目，财务系统里 5 年前的凭证还在被高频查询。
• 数据分析场景：订单数据在 T+1 的报表生成周期内是热数据，之后迅速变冷。

为什么会这样？因为业务对数据的「时效性敏感度」不同。电商关心的是「现在能不能发货」，财务关心的是「这笔账能不能对上」，分析关心的是「昨天的数据全不全」。

数据温度判定模型：一个实用的框架

下面这张图是我在项目中总结的数据温度判定模型。它把访问频率、时间窗口和业务场景三个维度整合在一起。

实战中的判定策略

理论说完了，聊聊落地。我一般用三步法来判定数据温度：

1. 采集访问日志：从数据库审计日志、应用层访问日志、缓存命中日志中提取访问记录。至少采集 90 天的数据。
2. 计算温度评分：对每条数据计算加权评分。公式我常用的是：Score = 0.3 × 频率分 + 0.2 × 时效分 + 0.5 × 业务权重分
3. 动态调整阈值：每季度重新跑一次评分分布，根据业务变化调整冷热分界线。

不同行业的温度定义差异

最后，我整理了几个典型行业的冷热温数据定义差异。你可以对照自己的行业，找到参考基准。

行业	热数据特征	温数据特征	冷数据特征
电商	最近 7 天订单、购物车	1-6 个月历史订单	超过 1 年的订单
金融	当日交易流水、实时风控	当月结算数据	超过 3 年的交易记录
医疗	当前就诊患者病历	近 1 年复诊患者数据	超过 5 年的归档病历
物联网	最近 1 小时设备上报数据	最近 1 天聚合数据	超过 7 天的原始数据

你看，同样是「超过 1 年」，在电商是冷数据，在金融可能还是温数据。这就是业务场景对数据温度的决定性影响。