📚 课程目录第4章自动降冷策略设计

4、自动降冷策略设计：基于时间、基于访问频率、基于业务标签

降冷策略，说白了就是决定「什么时候把数据挪到冷存储里去」。

我见过不少团队，一上来就搞复杂的机器学习预测模型，结果折腾半年还没上线。其实大部分场景，三种基础策略就能覆盖 90% 的需求：基于时间、基于访问频率、基于业务标签。

这一章，我把这三种策略掰开揉碎了讲。每种策略我都会给出具体的规则设计、适用场景，以及我在项目中踩过的坑。

4.1 基于时间的降冷策略

这是最直观、最容易落地的一种。说白了就是：数据放那儿不动，到了一定时间就自动降冷。

4.1.1 核心规则

规则只有一条：数据创建时间或最后修改时间，超过阈值就触发降冷。

时间阈值	目标存储层	典型场景
30 天	低频存储（如 AWS S3 Infrequent Access）	日志文件、临时报表
90 天	归档存储（如 AWS S3 Glacier）	历史订单、监控快照
365 天	深度归档（如 AWS S3 Glacier Deep Archive）	合规审计数据、备份

我的习惯：时间策略一定要留一个「缓冲期」。比如设置 30 天降冷，实际在 28 天时先打一个标记，第 30 天再真正执行。这样万一业务方说「我还有用」，还能紧急撤回。

4.1.2 实现示例（伪代码）

def apply_time_based_policy(file_metadata):
    age_days = (now() - file_metadata['create_time']).days
    
    if age_days >= 365:
        return 'DEEP_ARCHIVE'
    elif age_days >= 90:
        return 'ARCHIVE'
    elif age_days >= 30:
        return 'INFREQUENT'
    else:
        return 'STANDARD'

注意：时间策略有个大坑——「最后访问时间」不准。很多文件系统或对象存储，读操作不一定会更新访问时间戳。我曾经因为这个原因，把一批还在频繁读取的热数据给降冷了，结果第二天业务方投诉说查询慢得像蜗牛。所以，我建议优先用「创建时间」或「最后修改时间」。

4.2 基于访问频率的降冷策略

这个策略更智能一些。它不看你放了多久，而是看你最近被用了多少次。

4.2.1 核心逻辑

我一般用「滑动窗口」来统计访问频率。窗口大小通常是 7 天或 30 天。

热数据：最近 7 天内被访问超过 10 次 → 留在高性能存储
温数据：最近 7 天内被访问 1-10 次 → 降冷到低频存储
冷数据：最近 7 天内被访问 0 次 → 降冷到归档存储

关键点：访问频率策略一定要配合「冷却期」。比如某条数据今天被访问了 1 次，你不能明天就把它升回热存储。我通常设置一个 24 小时的冷却期，避免频繁升降导致成本反而增加。

4.2.2 实现示例

def apply_frequency_based_policy(access_logs, cooling_period_hours=24):
    recent_accesses = get_access_count_last_7_days(access_logs)
    last_access_time = get_last_access_time(access_logs)
    
    # 检查冷却期
    if (now() - last_access_time).hours < cooling_period_hours:
        return 'NO_CHANGE'  # 冷却期内不操作
    
    if recent_accesses >= 10:
        return 'STANDARD'
    elif recent_accesses >= 1:
        return 'INFREQUENT'
    else:
        return 'ARCHIVE'

避坑指南：我曾经遇到过一个场景——某条数据平时没人访问，但每周一凌晨的批处理任务会扫一次。如果按 7 天窗口统计，它每周只被访问 1 次，很容易被降冷。但实际上它是关键任务数据。解决方案：把批处理任务的访问单独标记为「系统访问」，不纳入降冷统计。

4.3 基于业务标签的降冷策略

这个策略最灵活，也最考验你对业务的理解。说白了就是：给数据打标签，不同标签走不同的降冷规则。

4.3.1 标签设计

标签	含义	降冷策略
`compliance`	合规数据，必须保留 7 年	365 天后直接深度归档，不可删除
`hot`	业务方明确要求热数据	永不降冷
`temp`	临时数据，生命周期短	7 天后直接删除，不降冷
`archive`	业务方确认可归档	30 天后直接归档

4.3.2 标签继承与覆盖

我习惯把标签设计成「可继承」的。比如一个目录打了 compliance 标签，里面所有文件自动继承这个标签。但单个文件也可以覆盖父级标签。

def get_effective_tags(file_path):
    # 先取文件自身标签
    file_tags = get_file_tags(file_path)
    if file_tags:
        return file_tags
    
    # 如果没有，向上找目录标签
    parent_dir = os.path.dirname(file_path)
    while parent_dir:
        dir_tags = get_directory_tags(parent_dir)
        if dir_tags:
            return dir_tags
        parent_dir = os.path.dirname(parent_dir)
    
    # 都没有，返回默认标签
    return ['default']

注意：业务标签策略最大的风险是「标签泛滥」。我曾经见过一个团队，半年内定义了 200 多个标签，最后没人搞得清楚每个标签是什么意思。我的建议是：标签数量控制在 10 个以内，并且每个标签必须有明确的负责人和生命周期。

4.4 三种策略的组合使用

在实际项目中，我很少只用一种策略。通常是三种策略组合使用，形成一个决策矩阵。

4.4.1 优先级规则

我通常这样定优先级：

业务标签优先：如果数据打了 hot 或 compliance 标签，直接跳过时间和频率检查。
访问频率次之：如果最近 7 天有访问，即使时间到了也不降冷。
时间兜底：如果既没有特殊标签，也没有访问记录，按时间策略执行。

举个例子：某条数据创建了 100 天，按时间策略应该归档。但它最近 3 天被访问了 5 次，按频率策略应该留在低频存储。同时它打了 compliance 标签。最终结果：按标签策略，直接深度归档，且不可删除。

4.5 策略执行的注意事项

嗯，这里有几个我踩过的坑，你一定要注意：

不要频繁执行策略：我建议每天执行一次就够了。执行太频繁，不仅浪费计算资源，还容易导致存储层抖动。
一定要有回滚机制：我曾经有一次策略写错了，把一批热数据降冷到了深度归档。恢复花了 12 小时。从那以后，我每次执行策略前都会先备份一份元数据，万一出问题可以快速回滚。
监控策略执行效果：我习惯在策略执行后，自动生成一份报告，包含降冷的数据量、节省的成本、以及是否有业务方投诉。这样能持续优化策略参数。

我的习惯：新策略上线前，先跑一周的「模拟模式」——只记录应该降冷的数据，但不真正执行。等确认无误后，再切换到「执行模式」。这个习惯帮我避免了好几次生产事故。

三种策略，各有各的适用场景。时间策略简单粗暴，适合日志、备份这类确定性数据；频率策略更智能，适合用户数据、业务数据；标签策略最灵活，适合有明确治理需求的数据。组合使用，才能覆盖绝大多数场景。