2. 历史项目数据溯源：数据来源识别、血缘追踪与质量初评
历史项目特征工程的第一步，也是最容易被忽视的一步，是数据溯源。没有清晰的数据来源和血缘关系，后续的特征提取和成本估算将建立在沙丘之上。本节聚焦于三个核心任务：识别数据来源、追踪数据血缘、以及进行数据质量的初步评估。
2.1 数据来源识别：三大核心系统
历史项目的数据散落在多个工程与管理系统之中。根据实践经验，超过 80% 的可用数据来源于以下三类系统：
| 系统类型 | 典型工具 | 关键数据字段 | 数据价值 |
|---|---|---|---|
| 版本控制系统 (VCS) | Git, SVN, Mercurial | 提交时间、作者、文件变更列表、提交信息、分支、标签 | 代码变更频率、模块耦合度、开发周期 |
| 工单/问题追踪系统 | Jira, Redmine, GitHub Issues | 工单类型、优先级、状态、解决时间、关联提交、组件 | 缺陷密度、需求变更率、修复耗时 |
| CI/CD 日志系统 | Jenkins, GitLab CI, GitHub Actions | 构建状态、构建时长、测试通过率、部署频率、失败原因 | 构建稳定性、自动化测试覆盖率、部署效率 |
实践提示： 在识别数据源时，优先通过 API 而非数据库直连获取数据。API 通常提供了更稳定的数据结构和更丰富的元数据，且不易因数据库 Schema 变更而中断。
2.2 数据血缘追踪技术
数据血缘（Data Lineage）描述了数据从产生、经过转换、到最终使用的完整生命周期。在历史项目中，追踪血缘有助于理解一个特征字段是如何从原始数据中派生出来的，从而避免重复计算或错误归因。
常用的血缘追踪技术包括：
- 基于代码解析的静态追踪： 通过解析 SQL 脚本、Python 或 Java 代码中的 ETL 逻辑，自动提取输入表、输出表和转换规则。适用于有明确代码仓库且 ETL 流程规范的项目。
- 基于日志的运行时追踪： 在数据管道运行时，通过拦截器或日志框架记录每条数据的来源和去向。适用于流式处理或复杂微服务架构。
- 基于元数据的手动标注： 在数据字典或特征存储中，由数据工程师手动填写每个特征的来源表和计算逻辑。适用于项目初期或数据源较少的情况。
2.3 数据质量初评：六维评估法
在正式进行特征工程之前，必须对原始数据进行一次快速的质量初评。我们推荐使用六维评估法，从以下六个维度对每个数据源进行打分（1-5分）：
- 完整性： 关键字段是否存在大量空值或缺失？
- 准确性： 数据值是否在预期范围内？是否存在明显的异常值？
- 一致性： 同一实体在不同系统中的数据是否一致？例如，工单状态在 VCS 和 Jira 中是否对应？
- 及时性： 数据更新的延迟是否在可接受范围内？
- 唯一性： 是否存在重复记录？主键是否唯一？
- 规范性： 数据格式、编码、单位是否统一？
初评产出物： 一份数据质量评分卡（Data Quality Scorecard），记录每个数据源在每个维度的得分，并标记出“不可用”、“需清洗”、“可直接使用”三个等级。这份评分卡将直接指导后续的特征提取策略。
2.4 初评后的决策路径
完成数据质量初评后，针对不同等级的数据源，应采取不同的处理策略：
- 可直接使用（评分 ≥ 4）： 直接进入特征提取管道。
- 需清洗（评分 2-3）： 制定数据清洗规则，如填充缺失值、修正异常值、统一格式等。清洗过程需记录在血缘图谱中。
- 不可用（评分 ≤ 1）： 标记为废弃数据源，寻找替代数据源或通过其他特征进行补偿。避免将低质量数据引入模型。
常见陷阱： 不要试图清洗所有数据。对于“不可用”等级的数据源，果断放弃往往比投入大量精力清洗更经济。在成本估算项目中，时间是最宝贵的资源。