4. 数据生命周期管理：数据从产生到归档的全流程
数据生命周期管理，说白了就是给数据安排一条从生到死的路。我见过太多团队，数据一进来就往湖里倒，从来不管它以后怎么办。结果呢？存储成本飙升，查询性能越来越差，到最后连哪些数据有用都搞不清楚了。
这一章，我们就来聊聊怎么给数据规划一条清晰的生命线。
4.1 数据生命周期的六个阶段
我个人习惯把数据生命周期分成六个阶段。每个阶段都有不同的存储策略、访问频率和管理方式。
| 阶段 | 状态 | 访问频率 | 典型存储 |
|---|---|---|---|
| 1. 数据产生 | 原始数据 | 极高 | 内存/SSD |
| 2. 数据采集 | 缓冲数据 | 高 | Kafka/消息队列 |
| 3. 数据存储 | 热数据 | 频繁 | 高性能存储 |
| 4. 数据使用 | 温数据 | 偶尔 | 标准存储 |
| 5. 数据归档 | 冷数据 | 极少 | 低成本存储 |
| 6. 数据销毁 | 过期数据 | 无 | 删除/清理 |
你想想看，一个日志数据从产生到归档，可能只需要几天时间。但有些合规数据，可能要保存好几年。不同阶段，成本差异巨大。
核心原则：数据越热，存储成本越高；数据越冷，访问延迟越大。生命周期管理的目标，就是在正确的时间，把数据放到正确的位置。
4.2 生命周期策略配置实战
嗯，这里要注意。生命周期策略不是写死的，它需要根据业务场景动态调整。我在项目中遇到过，有些团队把策略设得太死，结果业务部门要查三个月前的数据，发现已经被归档到冰川存储了，恢复一次要等几个小时。
4.2.1 基于时间的策略
这是最常用的策略。根据数据的时间戳，自动触发迁移动作。
-- AWS S3 生命周期策略示例
{
"Rules": [
{
"Id": "log-lifecycle",
"Status": "Enabled",
"Filter": {
"Prefix": "logs/"
},
"Transitions": [
{
"Days": 30,
"StorageClass": "STANDARD_IA" // 30天后转为低频存储
},
{
"Days": 90,
"StorageClass": "GLACIER" // 90天后转为归档存储
}
],
"Expiration": {
"Days": 365 // 365天后自动删除
}
}
]
}
这段配置，说白了就是告诉系统：日志数据进来后，30天转低频，90天转归档，一年后自动清理。我曾经见过一个团队，忘了配过期策略，结果存储账单翻了三倍才反应过来。
4.2.2 基于访问频率的策略
有些数据，时间上可能很老，但业务上经常被访问。这时候，基于时间的策略就不太合适了。
我个人习惯的做法是，结合数据湖的访问日志，动态调整策略。比如，一个数据分区如果连续30天没有被访问，就自动降级为温存储。
小技巧：在Hudi或Iceberg中，可以配置基于文件大小的策略。小文件合并后，再触发生命周期迁移，能有效减少存储碎片。
4.3 冷热数据分层架构
下面这张图，是我在多个项目中沉淀下来的冷热分层架构。你可以看到，数据从产生到归档，经过了三层存储。
这张图看起来简单，但落地的时候坑不少。我记得有一次，一个团队把热数据层的保留时间设成了7天，结果业务部门有个周报任务，每周一跑，刚好卡在数据被清理的边缘。后来我建议他们把策略改成基于访问频率的，问题才解决。
4.4 生命周期策略配置清单
下面是我总结的一份配置清单，你可以对照着检查自己的策略是否完整。
- 数据分类：先搞清楚数据属于哪一类（日志、交易、画像、合规）
- 保留期限：业务要求保存多久？合规要求保存多久？
- 迁移触发：基于时间？基于大小？基于访问频率？
- 存储层级：热、温、冷各用哪种存储介质？
- 恢复SLA：冷数据恢复需要多久？业务能接受吗？
- 清理策略：过期数据是直接删除，还是先标记再清理？
避坑指南：我曾经见过一个案例，团队配置了自动清理策略，结果把还在审计期内的财务数据删了。后来我们加了一个“合规锁定”机制，在数据进入归档层时，自动打上合规标签，清理前必须人工确认。
4.5 自动化与监控
生命周期管理，最怕的就是“配完就不管了”。我建议你至少做三件事：
- 配置告警：当策略执行失败时，第一时间通知运维
- 定期审计：每个月检查一次策略是否还符合业务需求
- 成本分析：对比策略执行前后的存储成本变化，验证效果
说白了，生命周期管理不是一锤子买卖。它需要持续优化，才能让数据湖既省钱又好用。