4. 指标计算逻辑与数据溯源
在制造运营指标体系中，一个看似简单的指标往往不是“查一张表”就能得到的。以“设备综合效率（OEE）”为例，它由时间开动率、性能开动率、合格品率相乘而来，而这三个子项又分别依赖设备运行记录、生产节拍、检验结果等多张源表。如果指标口径不统一、计算链路不清晰，一旦数值异常，排查就会变成“盲人摸象”。因此，理解指标的分层计算逻辑与数据血缘，是数据服务工程的核心能力。
一、三类指标的计算语义
原子指标是最小不可再分的业务度量，直接来源于事实表或事件流，具有明确的业务事件和聚合方式。例如“设备停机时长”来自设备状态事件表，按“停机”状态区间累加得到；“生产数量”来自报工记录，按班次汇总。原子指标的关键特征是：有且仅有一个事实来源，不依赖其他指标。在制造场景中，原子指标通常对应“事件—度量”对，如“故障次数”“检验不合格数”“能耗度数”。
派生指标由原子指标经过时间、组织、产品等维度约束后形成，本质是“原子指标 + 修饰词”。例如“A车间昨日设备停机时长”就是原子指标“设备停机时长”加上“车间=A、日期=昨日”两个限定条件。派生指标不改变计算逻辑，只改变筛选范围，因此它仍然可以直接下推到源表执行。
复合指标由两个及以上指标通过算术运算组合而成，例如 OEE = 时间开动率 × 性能开动率 × 合格品率，或者“单位产品能耗 = 总能耗 ÷ 合格品数量”。复合指标的计算链路最长，也最容易出现口径歧义——分子分母的时间范围是否一致、是否使用同一组织维度、是否都剔除了返工，都会显著影响结果。
二、数据血缘追踪方法
数据血缘描述的是“指标从哪来、经过哪些加工、流向哪里”。在制造数据服务中，血缘追踪通常分三个层次落地。
第一层是表级血缘，记录源表与目标表之间的依赖关系。例如 OEE 结果表依赖设备状态事件表、生产报工记录表、质量检验记录表。表级血缘可以通过解析 SQL 的 FROM/JOIN 子句自动采集，适合快速定位“指标异常时应该先看哪几张表”。
第二层是字段级血缘，精确到“目标字段由哪些源字段计算而来”。例如 OEE 表中的“时间开动率”字段，来源于设备状态事件表的“状态类型”和“时间戳”两个字段。字段级血缘需要解析表达式，通常借助 SQL 解析器或 ETL 工具的元数据能力实现。
第三层是指标级血缘，在字段血缘之上叠加业务语义，记录“原子指标→派生指标→复合指标”的引用关系。这一层最贴近业务人员，也是根因定位时最常使用的视图。建议在指标定义时同步登记：指标编码、指标类型、计算公式、依赖指标列表、源表列表、责任人。
三、指标异常的根因定位实战
假设某日 A 车间 OEE 从平日的 78% 骤降到 52%，我们需要沿着血缘链路自上而下逐层拆解。下面给出一个可复用的排查过程。
第一步：确认异常层级。先看 OEE 的三个乘数因子。若时间开动率从 90% 降到 62%，性能开动率和合格品率基本持平，则问题集中在“停机时长”这条链路，而不是质量或节拍。
第二步：下钻到派生指标。查看 A 车间昨日的停机时长明细，发现总停机 286 分钟，而平日约 45 分钟。进一步按设备编号分组，发现 3 号注塑机单台停机 210 分钟，占绝对多数。
第三步：回溯到原子指标与源表。查询设备状态事件表中 3 号注塑机昨日的状态区间记录，发现 14:20—17:50 存在一段连续“停机”状态，持续 210 分钟。再关联设备台账维表，确认该设备属于 A 车间，归属无误。
第四步：判断是数据问题还是业务问题。检查该时段的报工记录，发现 14:20—17:50 确实没有产量上报，说明停机是真实的，不是数据重复或状态误标。此时可初步判定为设备故障导致的真实停机，而非数据质量异常。
第五步：验证口径一致性。确认“计划时间”是否包含了计划停机（如换模、保养）。若计划时间未剔除计划停机，而停机时长却把计划停机也算进去，就会造成时间开动率被低估。本例中经核对，计划时间已剔除计划保养，口径一致，排除该因素。
经过以上五步，根因定位为“3 号注塑机 14:20—17:50 非计划故障停机 210 分钟”，属于业务真实异常，而非数据链路错误。对应的处理动作是通知设备维护班组复盘故障原因，并在指标平台上对该时段打上“设备故障”事件标签，便于后续分析。
四、把溯源能力沉淀为工程能力
一次成功的根因定位，不应只停留在“这次查出来了”，而应转化为可复用的工程能力。建议在数据服务层做三件事：
- 指标定义即血缘登记。在指标注册时强制填写依赖指标和源表，由平台自动生成血缘图，避免事后补录。
- 异常检测与血缘联动。当复合指标触发阈值告警时，自动展开其下游依赖指标，按贡献度排序，优先展示波动最大的分支。
- 溯源过程留痕。将每次根因定位的结论（业务异常/数据异常/口径异常）回写到指标事件库，形成“异常—根因—处置”的闭环记录，为同类问题提供参考。
需要强调的是，血缘追踪解决的是“数据从哪来”的问题，而根因定位还需要结合业务上下文。数据链路正确，不代表业务结果合理；反之，业务异常也常常表现为数据异常。只有把指标计算逻辑、血缘关系和业务事件三者对齐，才能真正做到“异常可定位、根因可解释、处置可追溯”。