2. 特征生命周期管理:特征发现、特征创建、特征验证、特征下线全流程
特征生命周期管理是特征平台的核心能力之一,它确保特征从被需求方发现、创建、验证、上线到最终下线的全过程可追溯、可治理。一个完善的生命周期管理流程能够有效避免特征重复建设、数据质量失控以及废弃特征长期占用存储与计算资源的问题。
2.1 生命周期全景视图
特征的生命周期通常划分为四个核心阶段:特征发现、特征创建、特征验证、特征下线。每个阶段都对应明确的治理节点与API操作。
核心原则:特征平台应保证每个特征在其整个生命周期内都处于“可追溯、可审计、可回滚”的状态。任何状态的变更都必须通过API记录操作人、时间与变更原因。
2.2 特征发现
特征发现是生命周期的起点,旨在帮助数据科学家与工程师快速定位已有特征,避免重复建设。特征平台应提供统一的特征目录与检索API。
2.2.1 特征发现的核心能力
| 能力项 | 说明 | 对应API |
|---|---|---|
| 关键词检索 | 支持按特征名称、描述、标签进行模糊搜索 | GET /api/v1/features/search |
| 血缘追溯 | 查看特征的数据源、加工链路与下游消费方 | GET /api/v1/features/{id}/lineage |
| 相似度推荐 | 基于特征元数据与使用频率推荐相似特征 | GET /api/v1/features/similar |
| 热度统计 | 展示特征被引用、被调用的频次与趋势 | GET /api/v1/features/{id}/stats |
最佳实践:建议在特征创建前强制调用检索API,若发现相似度超过80%的已有特征,平台应弹出复用建议并阻断重复创建。
2.3 特征创建
特征创建阶段包括特征的定义、开发与注册。平台应提供标准化的特征定义模板与版本管理机制。
2.3.1 特征创建流程
- 特征定义:填写特征名称、类型(连续型/离散型/文本型)、所属领域、业务含义描述。
- 数据源绑定:指定特征计算所依赖的原始数据表或流式数据源。
- 计算逻辑开发:编写SQL或Python特征计算脚本,支持窗口聚合、多表Join等常见模式。
- 特征注册:调用创建API将特征元数据写入特征注册中心,生成唯一特征ID。
- 版本初始化:自动生成v1.0.0版本,后续每次修改均触发版本递增。
2.3.2 特征创建API规范
POST /api/v1/features
Content-Type: application/json
{
"name": "user_7d_order_amount",
"display_name": "用户近7天订单金额",
"type": "continuous",
"domain": "user_profile",
"description": "统计用户最近7天成功支付订单的总金额",
"data_source": "dwd_order_pay_di",
"compute_logic": "SELECT user_id, SUM(pay_amount) AS amount FROM dwd_order_pay_di WHERE dt >= DATE_SUB(CURRENT_DATE, 7) GROUP BY user_id",
"owner": "team_a",
"tags": ["order", "amount", "7d"]
}
注意:特征创建后默认状态为“开发中”,不允许直接上线。必须经过验证阶段才能进入“已发布”状态。
2.4 特征验证
特征验证是保障特征质量的关键环节,包括数据质量校验、性能压测与合规审查三个维度。
2.4.1 验证维度与标准
| 验证维度 | 检查项 | 通过标准 |
|---|---|---|
| 数据质量 | 空值率、异常值、分布漂移 | 空值率 < 5%,无超出业务阈值的异常值 |
| 性能压测 | 单次查询P99延迟、吞吐量 | P99 < 50ms,QPS > 1000 |
| 合规审查 | 数据脱敏、权限范围、GDPR合规 | 不包含明文手机号/身份证,权限最小化 |
2.4.2 验证流程
- 自动化验证:提交验证请求后,平台自动触发数据质量扫描与性能压测。
- 人工审批:合规审查需要特征负责人与数据治理委员会双重审批。
- 验证报告:验证完成后生成包含所有检查项结果的报告,支持在线查看与导出。
- 状态变更:验证通过后特征状态自动变更为“已发布”,失败则回退至“开发中”。
2.5 特征下线
特征下线是生命周期管理的收尾阶段,用于清理不再使用的特征,释放存储与计算资源,降低维护成本。
2.5.1 下线触发条件
- 无调用:特征连续30天未被任何模型或服务调用。
- 替代上线:有新的特征版本或替代特征已发布并切换流量。
- 数据源下线:特征依赖的原始数据源已废弃或迁移。
- 业务变更:对应业务指标或策略已不再使用。
2.5.2 下线流程与API
| 步骤 | 操作 | API |
|---|---|---|
| 1. 下线申请 | 提交下线请求,注明原因与影响范围 | POST /api/v1/features/{id}/deprecate |
| 2. 影响分析 | 平台自动扫描下游依赖,列出所有消费方 | GET /api/v1/features/{id}/downstream |
| 3. 审批确认 | 特征负责人与下游消费方确认后审批 | POST /api/v1/features/{id}/approve-deprecation |
| 4. 灰度下线 | 先停止写入新数据,保留查询能力7天 | POST /api/v1/features/{id}/soft-delete |
| 5. 硬删除 | 清理存储数据与元数据,释放资源 | DELETE /api/v1/features/{id} |
重要:硬删除操作不可逆,执行前必须确保所有下游已切换至替代特征。建议保留至少30天的软删除缓冲期。
2.6 生命周期治理清单
下表汇总了特征生命周期各阶段的治理要点与API操作,供平台建设与审计参考。
| 阶段 | 治理要点 | 关键API | 状态 |
|---|---|---|---|
| 特征发现 | 检索效率、去重机制、血缘可视化 | search / lineage |
— |
| 特征创建 | 元数据完整性、版本初始化、权限绑定 | create / version |
开发中 |
| 特征验证 | 质量门禁、性能基线、合规审批 | validate / approve |
验证中 → 已发布 |
| 特征下线 | 影响分析、灰度缓冲、资源清理 | deprecate / soft-delete / delete |
已废弃 |
总结:特征生命周期管理不是一次性的开发活动,而是一个持续治理的过程。通过标准化的API与状态机,特征平台能够实现从发现到下线的全流程自动化与可审计,为上层模型提供稳定、高质量的特征服务。