4. 数据清洗工程框架设计

制造数据清洗不是一次性脚本，而是一条可重复运行的工程流水线。它要解决的核心问题是：来自设备、MES、ERP、质检系统的数据在进入分析或建模之前，如何被稳定地接入、量化评估、按规则修复、识别异常，并把处理结果反馈回数据源与规则库，形成持续改进的闭环。本节围绕这条流水线，给出可落地的框架设计与关键实现细节。

一、框架总体结构：五段式流水线加一条反馈回路

工程化框架可以拆成五个处理段：数据接入、质量评估、清洗规则、异常检测、治理闭环。前四段是数据在管道中的正向流动，第五段是把评估结果、异常标签、规则命中率反向写回元数据与规则库的反馈路径。正向流动保证“数据可用”，反馈回路保证“框架可进化”。

与临时脚本相比，工程化框架有三个硬性约束：可追溯（每条记录经过哪些规则、被改成什么值都要留痕）、可配置（规则以配置或规则表形式管理，不写死在代码里）、可度量（每段都有量化指标，能判断清洗是否有效）。

二、数据接入：先统一“语言”再谈清洗

接入段的目标不是把数据搬进来，而是把异构数据变成结构统一、时间对齐、可追溯的中间层。制造现场常见三类接入方式：批量抽取（如每日从 MES 导出工单表）、流式接入（如 OPC UA 采集设备实时点位）、CDC 变更捕获（如数据库 binlog 同步）。

接入时必须完成三件事。第一，Schema 映射：把源字段映射到统一字段名，例如把 EQP_ID、equip_code、设备编号 统一为 equipment_id，并记录映射关系。第二，时间戳对齐：设备时间、系统时间、采集时间可能不一致，需明确以哪个为基准，并统一时区与精度（如统一到毫秒）。第三，接入元数据登记：每条数据记录来源系统、接入批次、原始文件名，为后续追溯提供依据。

示例：某注塑车间从 OPC UA 采集温度点位，原始字段为 TagName=Inj_Temp1，值为 238.6，单位 ℃，采集时间 2024-06-11 08:23:15.120。接入后统一为 equipment_id=INJ-01、metric=barrel_temp、value=238.6、unit=C、ts=2024-06-11T08:23:15.120+08:00。这一步不做数值修改，只做结构统一。

三、质量评估：用可量化指标定位问题

质量评估段对中间层数据计算一组指标，输出每条记录或每个批次的质量分 DQ Score。常用维度包括：

• 完整性：关键字段非空率，如 equipment_id、ts、value 非空比例。
• 唯一性：主键或业务键重复率，如 (equipment_id, ts, metric) 组合重复条数。
• 一致性：单位、编码、枚举值是否符合标准字典，如 unit 只允许 C、mm、MPa。
• 时效性：数据到达时间与事件时间的差值，超过阈值（如 5 分钟）标记为延迟。
• 值域合理性：数值是否落在物理可能范围内，如温度 -50~400℃。

DQ Score 可按加权计算，例如完整性 30%、唯一性 20%、一致性 20%、时效性 15%、值域 15%。某批次 1000 条记录中，缺失 12 条、重复 8 条、单位异常 5 条、延迟 20 条、值域越界 3 条，则各维度得分分别为 98.8、99.2、99.5、98.0、99.7，加权后约 98.9 分。分数本身不是目的，目的是定位哪一类问题最集中，从而决定清洗规则的优先级。

四、清洗规则：按优先级执行，避免互相覆盖

清洗规则段把评估发现的问题转化为可执行动作。规则应配置化，每条规则包含：规则 ID、适用字段、触发条件、处理动作、优先级、是否留痕。常见动作包括：

• 去重：按业务键保留最新或最完整的一条，其余标记为重复。
• 补缺：对缺失值采用前向填充、均值填充或标记为 NULL 并进入异常表，具体策略按字段语义决定。
• 标准化：单位换算（如 238.6 华氏度转摄氏度）、编码统一（如 M/Male 统一为 M）、格式统一（日期统一为 ISO 8601）。
• 值域修正：对越界值不直接删除，而是标记 out_of_range 并保留原值，供异常检测段判断。

规则优先级很关键。例如“去重”应先于“补缺”，否则重复记录会干扰填充统计；“单位换算”应先于“值域判断”，否则华氏度数值会被误判为越界。建议按 结构类 → 标准化类 → 补缺类 → 值域类 的顺序执行，并在规则表中显式声明 priority 字段。

五、异常检测：在清洗后数据上识别“不该出现”的模式

异常检测与清洗规则的区别在于：清洗规则处理的是已知的、确定性的问题，异常检测处理的是统计上或模式上的偏离。常用方法包括：

• 阈值法：如温度超过 300℃ 直接告警，适合有明确工艺上限的场景。
• 3σ 法：对某设备某指标的历史数据计算均值 μ 和标准差 σ，超出 μ±3σ 标记为异常。示例：某注塑机料筒温度历史 μ=235℃、σ=4.2℃，则 247.6℃ 以上或 222.4℃ 以下为异常。
• IQR 法：对偏态分布更稳健，超出 Q1−1.5×IQR 或 Q3+1.5×IQR 标记异常。
• 时序突变检测：相邻点变化率超过阈值，如温度 1 分钟内跳变超过 15℃。

异常检测的输出不是简单删除，而是生成异常标签表，包含记录 ID、异常类型、检测方法、置信度、检测时间。这样既保留原始数据，又为后续根因分析提供线索。

六、治理闭环：让框架越跑越准

治理闭环段做三件事。第一，统计规则命中率与误报率：如果某条补缺规则命中率极高但误改率也高，说明规则阈值或策略需要调整。第二，根因反馈：把高频异常按设备、班次、数据源分组，反馈给设备维护或系统负责人。例如某台设备温度异常集中在夜班，可能是传感器漂移而非工艺问题。第三，规则库迭代：根据反馈新增、修改或停用规则，并记录版本号与生效时间。

七、可直接参考的规则配置示例

下面给出一份简化的清洗规则配置片段，字段与本节框架对应，可直接作为规则表设计的起点：

rule_id: R001
field: equipment_id
condition: is_null
action: mark_as_missing
priority: 10
trace: true

rule_id: R002
field: (equipment_id, ts, metric)
condition: duplicate
action: keep_latest
priority: 20
trace: true

rule_id: R003
field: unit
condition: unit == "F"
action: convert_to_celsius
priority: 30
trace: true

rule_id: R004
field: value
condition: value < -50 or value > 400
action: mark_out_of_range
priority: 40
trace: true

这份配置体现了三个工程原则：规则按优先级顺序执行、每条规则可追溯、异常不直接删除而是标记。实际落地时，可把规则表存入数据库或配置中心，由清洗引擎读取执行，并把每次执行的命中记录写入审计表。

整体来看，这条流水线的价值不在于某一段特别复杂，而在于段与段之间的衔接和反馈。接入保证结构统一，评估提供量化依据，清洗解决确定性问题，异常检测捕捉统计偏离，闭环让规则持续进化。只有五段都具备可配置、可度量、可追溯的能力，数据清洗才能从“一次性脚本”变成“可持续运行的工程能力”。