2、特征生命周期管理：特征从生产到退役的全生命周期

特征不是造出来就能一直用的。我见过太多团队，特征越堆越多，最后谁也说不清哪个特征还在用、哪个已经没人碰了。说白了，特征跟人一样，有出生、有成长、也有退休的一天。这一章我们就聊聊，怎么把特征的生命周期管起来。

2.1 特征生命周期的四个阶段

我个人习惯把特征的生命周期分成四个阶段：设计开发 → 上线运行 → 稳定服役 → 废弃下线。每个阶段都有对应的管理动作。

2.1.1 设计开发阶段

这个阶段特征还没上线。你在做特征定义、写加工逻辑、跑离线验证。我建议在这个阶段就做好两件事：

• 特征注册：在特征平台里登记特征元数据，包括名称、类型、来源表、加工逻辑描述
• 血缘预埋：把特征的血缘关系先画出来，哪怕只是草稿

2.1.2 上线运行阶段

特征上线后，监控是第一位的。我记得有一次，一个特征上线后数据分布突然偏移，要不是监控告警及时，模型效果就崩了。

上线阶段需要关注：

• 特征值分布是否与离线一致
• 延迟是否在 SLA 范围内
• 覆盖率是否达到预期

2.1.3 稳定服役阶段

这是特征生命周期中最长的阶段。特征在稳定服役期会经历多次版本迭代。你想想看，一个特征用了半年，业务逻辑变了三次，版本管理跟不上就乱套了。

2.1.4 废弃下线阶段

嗯，这里要重点说。很多团队只会上线不会下线。特征废弃不是直接删表那么简单，后面有专门的流程。

2.2 特征版本管理

版本管理是特征治理的基石。没有版本管理，你根本不知道线上跑的是哪个版本的特征。

版本管理维度	说明	我踩过的坑
语义版本号	MAJOR.MINOR.PATCH，例如 v2.1.3	MAJOR 变更没通知下游，模型效果骤降
版本快照	每个版本保存完整的特征逻辑快照	只存 diff，回滚时拼不回去
版本标签	给重要版本打标签，如 stable、canary	标签覆盖导致历史版本丢失
版本兼容性	记录版本间的兼容关系	以为兼容，实际 schema 变了

2.2.1 版本号规范

我推荐用语义化版本号。规则很简单：

• MAJOR：特征语义发生不兼容变更时递增。比如特征计算逻辑完全重写
• MINOR：向下兼容的功能性新增。比如增加了一个新的聚合维度
• PATCH：向下兼容的问题修复。比如修了一个空指针 bug

2.2.2 版本存储策略

特征版本怎么存？我见过两种主流做法：

1. 全量快照：每个版本保存完整的特征定义和加工代码。简单可靠，但占空间
2. 增量 + 基线：只保存基线版本和每次变更的 diff。省空间，但回滚复杂

我个人偏向全量快照。磁盘便宜，但排查问题的时间贵。你想想看，线上出问题了，你愿意花 5 分钟找一个全量快照，还是花 2 小时拼增量？

2.3 特征废弃与下线流程

特征废弃是生命周期里最容易被忽视的环节。我见过一个平台，三年积累了 2000 多个特征，其中 60% 已经没人用了。没人敢删，因为不知道谁在用。

2.3.1 废弃判定标准

什么时候可以废弃一个特征？我建议用这几个指标：

判定指标	阈值	说明
无调用时长	连续 90 天	特征没有被任何模型或服务调用
覆盖率低于阈值	< 10%	特征在样本中的覆盖率极低
被新特征替代	新版本上线 30 天后	旧版本已无实际用途
业务逻辑变更	业务下线后 60 天	对应的业务场景已不存在

2.3.2 下线流程

特征下线不能一键删除。我总结了一套四步流程：

1. 标记废弃：在特征平台上将特征状态标记为「废弃」，停止新调用
2. 通知期：通知所有已知下游，给 30 天缓冲期。期间特征只读不写
3. 静默期：特征进入静默期，保留数据但不提供服务。持续监控是否有异常调用
4. 清理归档：确认无调用后，清理在线存储，离线数据归档到冷存储

2.3.3 下线后的数据保留策略

特征下线了，数据要不要删？我的建议是：

• 在线存储：立即清理，释放资源
• 离线存储：保留 6 个月，用于历史回溯
• 冷存储：归档保留 2 年，用于审计和模型复盘

2.4 生命周期管理的自动化

手工管理特征生命周期不现实。几百个特征，靠人盯不过来。我建议至少做到以下几点自动化：

• 自动检测：定时扫描特征调用日志，自动标记长期无调用的特征
• 自动通知：特征进入废弃流程后，自动通知所有注册的下游
• 自动归档：静默期结束后，自动执行数据迁移和清理

说白了，特征生命周期管理就是三个字：管生、管养、管埋。生的时候注册好，养的时候版本管好，埋的时候流程走好。做到这三点，你的特征平台就不会变成数据坟墓。