4. 数据管理：数据收集、数据标注、数据版本化、数据质量检查

4.1 核心原理：数据是MLOps的“地基”，而非“燃料”

在端到端MLOps实践中，数据管理不是一次性预处理步骤，而是贯穿模型开发、部署、监控全生命周期的持续工程活动。业界常将数据比作“燃料”，但更准确的比喻是“地基”——地基的承重能力决定了上层建筑的高度与稳定性。模型性能的上限由数据质量决定，而算法只是逼近这个上限的手段。因此，数据管理需要围绕四个核心支柱展开：可收集性（能否持续获取）、可标注性（能否形成监督信号）、可追溯性（能否复现任意历史版本）、可验证性（能否量化质量缺陷）。

关键认知：数据版本化与代码版本化同等重要。没有数据版本标签的模型实验，本质上不可复现——你无法回答“这个模型是用哪一批数据训练出来的”。

4.2 方法流程：从原始数据到可追溯数据资产

4.2.1 数据收集：明确边界与采样策略

数据收集的第一步不是写爬虫或接Kafka，而是定义数据契约：字段名、类型、取值范围、时区、单位、缺失值语义。推荐使用Schema Registry（如Confluent Schema Registry）统一管理。采样策略需兼顾时间覆盖（包含业务周期、节假日、异常时段）与空间覆盖（不同地域、设备、用户群体）。对于流式数据，需设计窗口策略（如Tumbling Window）与背压机制，防止数据堆积。

# 数据契约示例（YAML片段）
schema_version: 1.2
fields:
  - name: user_id
    type: string
    nullable: false
    description: "脱敏后的用户唯一标识"
  - name: event_time
    type: timestamp
    format: "yyyy-MM-dd'T'HH:mm:ssZ"
    nullable: false
  - name: device_type
    type: enum
    values: ["ios", "android", "web"]
    nullable: true
sampling:
  strategy: stratified
  key: user_region
  rate: 0.1  # 10%分层采样

4.2.2 数据标注：质量比数量更重要

标注环节的核心矛盾是成本与一致性。对于分类任务，建议采用多人标注+仲裁机制：至少2人独立标注，计算Cohen's Kappa系数，低于0.7则进入仲裁或重新培训。对于序列标注或检测任务，需定义明确的边界规则（如“车辆遮挡超过50%是否标注”）。主动学习策略可显著降低标注成本：先用小样本训练初版模型，筛选高不确定性样本优先标注。

标注类型	一致性指标	推荐阈值	仲裁策略
二分类	Kappa系数	≥0.8	第三标注员投票
多分类	Fleiss' Kappa	≥0.7	专家评审
目标检测	IoU + 类别一致率	IoU≥0.5且类别一致率≥0.9	重新标注+边界规则修订
文本NER	实体级F1	≥0.85	标注规范补充

4.2.3 数据版本化：不可变快照与血缘追踪

数据版本化推荐采用内容寻址存储（Content-Addressable Storage）。每个数据集版本由其内容的哈希值唯一标识，任何一行数据变化都会产生新的哈希，从而形成不可变快照。DVC（Data Version Control）是常用的开源工具，其核心命令如下：

# DVC数据版本化工作流
dvc init
dvc add data/raw/click_log.parquet
git add data/raw/click_log.parquet.dvc
git commit -m "feat: 新增2024-06-01点击日志"
dvc push  # 推送至远程存储（S3/GCS/MinIO）

# 回滚到历史版本
git checkout v1.0
dvc checkout

版本化必须与模型训练联动：在训练配置中记录data_version字段，确保模型可复现。建议在MLflow或Kubeflow中注册数据集版本与模型版本的映射关系。

4.2.4 数据质量检查：六维评估体系

数据质量检查应自动化、持续化运行，而非一次性脚本。推荐从六个维度构建检查规则：

完整性：必填字段缺失率、空行比例
唯一性：主键重复率、唯一约束违反数
有效性：字段格式、取值范围、枚举合法性
一致性：跨表关联字段匹配率、单位换算正确性
时效性：数据延迟时间、事件时间与处理时间偏差
漂移检测：特征分布（PSI/KL散度）、标签分布变化

工程实践：使用Great Expectations定义数据质量断言，并将其嵌入CI/CD管道。每次数据更新后自动执行断言，失败则阻断后续训练任务并发送告警。

4.3 案例场景：金融风控模型的数据管理实战

某消费金融公司开发反欺诈模型，数据管理面临三大挑战：多源异构（埋点日志、第三方征信、内部交易流水）、标签稀疏（坏样本率仅0.3%）、监管审计（需保留5年数据血缘）。其解决方案如下：

收集层：采用Debezium捕获MySQL变更日志，Kafka Streams做实时清洗，统一落地至数据湖（Iceberg表格式），按天分区。
标注层：定义“欺诈”标签为“交易后30天内确认欺诈”，由风控专家团队标注，每周抽样50条做交叉验证，Kappa系数控制在0.85以上。
版本化：使用DVC管理特征工程输出，每个特征文件记录生成脚本版本、输入数据版本、运行参数。训练时锁定data_version与feature_version。
质量检查：部署Scheduler（Airflow）每日运行质量任务，监控特征PSI（群体稳定性指标），当PSI>0.2时自动触发告警并暂停模型自动重训。

4.4 误区与复盘：数据管理的五个常见陷阱

陷阱一：忽视数据版本与代码版本的绑定。只记录“数据文件路径”，不记录哈希值。导致模型上线后无法定位训练数据，排障困难。
陷阱二：标注规范“口头化”。没有书面标注手册，人员流动后标注风格漂移，一致性指标持续下滑。
陷阱三：质量检查“事后诸葛”。训练完成才发现数据异常，浪费算力与时间。应将质量检查前置到数据入库阶段。
陷阱四：采样策略“一刀切”。随机采样导致小类别样本严重缺失，模型对长尾场景失效。应使用分层采样或重要性采样。
陷阱五：数据血缘“断链”。只记录直接上游，不记录原始来源。当第三方数据源变更时，无法评估影响范围。

复盘要点：数据管理不是“一次性治理项目”，而是需要制度化、工具化、持续运营的工程体系。建议每季度进行一次数据资产审计，检查版本覆盖率、质量规则执行率、标注一致性趋势。只有将数据视为一等公民，MLOps的自动化与可复现性才有根基。