2.4
数据质量问题

"If you torture data sufficiently，it will confess to almost anything."

——Fred Menge

数据质量是数据分析和应用的基础，数据质量问题一直是数据系统和分析的重要课题之一。对于数据分析师来说，数据“质量”问题不限于数据模式（Data Schema）层面的数据质量问题。传统意义上，“质量问题”是指实际结果和设计期望不一致的问题；而数据分析的“数据质量”关心的是妨碍当前数据建模分析活动的与数据相关的所有问题。前者姑且称之为数据模式层面的质量问题，后者称为应用场景（Application Context）下的数据质量问题。本节重点讨论的是应用场景下的数据质量问题。

数据模式的设计是为了满足特定应用（例如MES）需求的，只要符合设计初衷，数据就不存在数据模式层面的质量问题；而数据分析的目的是解决一个特定问题，并且通常要跨多个数据集，对数据集的要求与一个应用的需求可能不同，因而，数据分析项目中的“数据质量”问题除了数据模式层面，还要关心应用场景下的数据质量问题。数据模式层面的质量问题通常可以用数据模型（如关系数据表的三范式）、数据约束［如OCL（Object Constraint Language）］等形式化模型去描述，独立于具体应用。而应用场景相关的数据质量问题，与研究问题的范畴和业务上下文有关，通常不容易发现，有一定规律但不存在通用的方法。各种数据系统、工具和企业级的数据治理大多集中在前者，而留给行业数据分析师的往往是后者。没有经验的数据分析师往往很难发现这些问题，造成基于有问题的数据训练出的机器学习模型不可信。

对于数据模式层面的质量问题，业界有很多成熟的探索。在数据质量评价上，业界有很多类似的评价维度体系，例如，国际数据管理协会 ^[15] 提出了Accuracy、Completeness、Consistency、Integrity、Reasonability、Timeliness、Uniqueness/Deduplication、Validity、Accessibility等9个指标，Fan和Geets ^[16] 主要考虑Consistency、Deduplication、Accuracy、Completeness、Currency等指标，Strong-Wang框架 ^[17] 从数据内在（Intrinsic）、上下文（Contextual）、表征性（Representational）、可访问性（Accessibility）4大方面提出了14个数据质量度量指标。在数据质量跟踪与治理方法上，Alex ^[18] 按照颗粒度，将数据质量问题分为标量（Scalar，即一条记录的一个具体字段的数值）、字段（Field）、记录（Record）、单数据集（Data Set）、跨数据集（Cross-data set）等5个层面。

但对于应用场景下的数据质量问题，目前还没有系统化的讨论。下面以一些典型的行业分析领域的实际例子，来阐述这些“隐秘”的数据质量问题是通常出现在何处及如何被发现的，最后给出数据分析中，数据质量问题的发现方法。

2.4.1 数据的业务化

“数据异常”也许是被忽略的一些“正常场景”。

【业务背景】

风电机组大部分采用同步变桨，在正常情形下，三个桨距角应该非常接近。因此，在变桨驱动系统异常研判中，常常会将三个桨距角的不一致性（如角度差或短期时序相关度）作为一个重要特征。

【数据现象1】

如图2-3所示，某个风电机组在2013年8月9日21:45—21:47的表现。三个桨距角的初始值都在87.5°左右，然后三个桨距角逐步变为0°。

【业务解读】

这个过程实际上是调试过程中，变桨控制系统逐个重启造成的。在2013年8月9日21:45:40左右，第一个变桨控制电路进行了人工重启，然后依次对第二个、第三个进行了重启。

【对数据分析师的启发】

上面的场景，对于风电领域的业务人员非常简单，简单到“忘记在业务访谈中提到”。另外对于偶发场景，不少领域专家也是不确定的（毕竟主控程序不是他写的），只能看到数据“事后”解读。所以，很难完全指望业务专家把所有场景提前告知。

这就要求数据分析师对于关键数据、关键结果要做必要的数据探索（画图或者看统计分布），数据中包含的内容超过我们的“预设”和“专家经验”。上面的异常也是数据分析师在加工完特征变量后，看特征变量分布的时候发现的。

【数据现象2】

有了上面的现象，可以理解系统重启或初始化过程很多变量为0或空。但风电机组的累计工作时间在启动后应该不会出现跳变。

但图2-4中，可以看到风电机组在2013年8月9日21:37:54—21:38:40的重启过程中，各个变量均为0。启动过程结束后，桨距角的数值恢复为之前的87.5°左右。但累计工作时间（wtur_tmexflt_acttmval）竟然从之前的289.4跳变为314876。更有趣的是在21:40:56又恢复到289.4。

【业务解读】

对于上面的跳变问题，业务上也无法解释其原因。另外，对近万台风机5年左右的历史数据做扫描，也没有发现类似案例，因此，把它当作一个偶发事件看。

【对数据分析师的启发】

物理世界上肯定发生了一些事件（如电磁干扰、I/O异常等），这些事件也反映在数据中。但一旦时间久远，业务专家也很难解释。对于当下发生的数据质量问题，应该及时纠正。对于数据分析师，再次说明了数据探索的重要性，不要过度相信数据。

类似的问题在工程车联网的分析中也遇到过，“月累计工作时长”按说不应该超过744h（每个月最多31天），但数据中存在不少超过744h的记录，大家的猜测是：车辆联终端在维修更换时，原来的数据没有清零。这个猜想在一些有中间结果的记录中初步得到证实：有些车辆的工作时长在月中突然被清零。这样的发现，也解释了在一些地区分析中，累计工作时长与备件需求相关性很弱。

【数据现象3】

在早期业务访谈中，大家一直认为低风速下风电机组应该处于停机状态（桨距角在90°左右），但图2-5所示的实际数据表明，某机组在2013年6月16日21:09:47到6月17日00:44:55的低风速期间，桨距角保持在50°。

【业务解读】

这对于业务人员来说是默认的常识，风电机组处于待机状态（保持之前的姿态），发生频度也不高，故在早期业务访谈中没有提及。

【对数据分析师的启发】

若数据探索不够细致，这样的风险将传递给后续的建模环节。

数据分析师也曾遇到过不太常见的解缆过程数据，这些领域内默认的常识不可能指望业务专家不加遗漏地传递给数据分析师。这需要数据分析师在数据探索中“较真”一些，把相对于当前认知的“数据异常”都暴露出来，主动寻求业务专家的帮助。

2.4.2 业务的数据化

“业务专家的解读也不一定完全正确”。

【业务背景】

风电机组的齿形带断裂后，通常会引起机舱加速度超限，变桨系统会快速收桨（即以最大允许的变桨速率，将桨距角快速变到90°左右）。

【数据现象】

大部分齿形带断裂后的表现的确符合上面的业务背景描述。但在一次故障事件中，如图2-6所示，10:25:04时刻（从故障录波数据中确认）叶片3的齿形带断裂（此时桨距角在4.5°左右），按照上面的逻辑，变桨速率应该是正的，而实际的wrot_vane1_speed1～3是-6°/s，这与专家经验是相违背的。

【业务解读】

高频故障录波数据（采样周期20ms）可以更清晰地还原整个过程：

1）风速稳定，没有限电，风电机组工作在额定转速17.3r/min;

2）10:25:04时刻齿形带断裂，叶片3失控、不迎风，叶轮吸收风能减小；

3）转速下降很快（至15.98r/min）;

4）控制逻辑（控制逻辑无法得知齿形带断裂的物理事件）要求往0°运行以期望转速维持在额定转速17.3r/min，但实际变桨速率受控制器的下限-7°/s限制，此限制导致转速掉得离额定转速很远但桨距角还没达到0°；

5）机舱加速度增大；

6）10:25:10时刻加速度故障，触发停机保护程序，以近8°/s的速率快速收桨。

基于这样的观察，不难总结出齿形带断裂的影响路径图，如图2-7所示，齿形带断裂后，一方面会引起振动，然后传播到机舱加速度传感器上，若振动过大，PLC保护逻辑会向90°收桨；另外叶片自由旋转也造成发电功率低于理论预期值，在一切正常情形（严格讲是PLC感知的正常，而不是物理世界的正常）下，控制逻辑会向0°变桨。这2条路径的发展都需要时间，到底PLC采取何种动作取决于2条路径的发展速度。

进一步，在额定风速下，风电机组通常处于恒功率控制。如果仔细研究故障录波数据，如图2-8所示，就可以发现：齿形带断裂后，转速（generator_speed_momentary）下降和转矩（gh_local_control_torque_demand）上升是立刻的，功率的变化有些滞后（因为有惯性，功率在很短时间内还可以保持稳定）。

【对数据分析师的启发】

虽然机器学习是数据驱动，但基本的机理或逻辑还是需要掌握的，如，FMEA（Failure Mode&Effect Analysis，失效模式和影响分析）、系统动力学图、流程工业的P&ID（Piping and Instrumentation Diagram，管道仪表流程图）等。否则，很容易被数据的“假”象误导。

另外，工业设备通常是自动控制或人工操控的，很多动态变化是这些控制行为的结果（而不是设备故障引起的）。这就要求数据分析师对其相关的控制逻辑有一定了解（例如，除了当前感兴趣的功率控制外，还有防过速、防共振以及PLC对风速变化的响应等逻辑），只有将隐性先验知识与大数据分析结合，征兆的研判才可靠，机器学习模型才可能比较强壮。很多模型太敏感，很多时候是因为忽略了太多的背景知识。

如果做得够认真，也会发现有些风电机组的变桨角度指令会出现负的变桨度数（而不是以往默认的0°），实际的控制策略里的最小桨距角和叶片特性有关，可能是-1°。

最后，传感器数据不等于物理量，传感数据只是物理世界的间接和部分量测，受测量原理、传感器部署方式、传感器物理条件等限制。数字孪生概念的提法很好，但严格意义上不存在两个一模一样的系统，“等价系统”需要明确其适用范围或应用前提。

【专家经验1】

从上面分析来看，齿形带断裂后，短期内风电机组会通过增大转矩保持功率稳定。因此，专家总结经验根据变流转矩与参考转矩的误差去研判。

例如，以某风电机组为例，如图2-9所示，0时刻前变流转矩与参考转矩的稳态误差最大在50000N·m，约-0.8s发电机转速减小，转矩误差开始变大，此时刻风速无明显突变，说明叶片风载异常，判断在-0.8s时齿形带已经断裂。

【数据分析结果】

这个经验在几个实际故障事件中也的确成立。当应用到更多的数据上时，却发现虚假预警率过高。尽管此后做了很多改进，加入了风况等条件，虚假预警率虽然降低了不少，但仍存在。

【对数据分析师的启发】

专家经验：从机理定性分析上一般都讲得通，也有一些实际案例的支撑，很容易让数据分析师视为“神明”。但经验都有隐含的前提假设，也可能存在一定的认知偏差。基于大量数据的验证和优化仍必不可少。

【专家经验2】

根据 x 、 y 方向的机舱加速度的有效值（RMS值）变化，以及多个机组的横向对比，来研判是否存在叶片开裂等问题。

【数据分析发现】

以一个实际风电场数据为例，如图2-10所示，可以看出①不同机组间的差别很大，如果直接采用机组横向比较，故障案例（21#机组2017年4月发生了叶片开裂）反而被淹没掉了；②振动有效值存在不明原因的连续异常（一段时间的RMS均值明显降低或升高），具体原因业务上也没有办法解读。

因此，在应用业务规则中，需要做如下2个改进：①根据历史振动有效值，做相似机组聚类，使得横向比较更有价值；②加入窗口内指标的变化率做研判。

2.4.3 机理演绎法

数据是物理世界的“部分映像”：数据分析也需要演绎法。

案例1：磨煤机堵磨检测

【专家经验】

磨煤机堵磨研判，几小时内，电流持续上升，伴随入口风量下降。

【数据分析发现】

1）入口风量影响因素太多，测量稳定性差，不应作为主要研判依据：多台磨煤机共用一个管道，它们的入口风量存在强耦合。

2）电流量是在动态变化中的：机组负荷是系统的锚定量，机组负荷决定了给煤量，从而决定了电流的变化。给煤增加引起电流动态超调，这导致电流发生急速升降，打破电流持续上升或下降的趋势。在研判中，如图2-11所示，应该去除给煤阶跃变化对电流引起的短时扰动，再看电流上升情况。

3）窗口长度：专家认为在1～2h；但根据该多个案例统计，应该选择8h。

4）模型报警的运行周期：专家开始认为应实时报警（1min以内）；实际堵磨都有个发展过程，即便图2-11中的堵磨也没有达到停机检修的级别，快速堵磨故障也要有20min以上的形成过程；另一方面，快速研判窗口越短，抗干扰能力就越差，容易发生误判，最后与专家达成共识选择5min的调用周期进行堵磨预警。

【对数据分析师的启发】

对系统基本面的把控很重要，包括系统的动力学图、各个变量的测量方法（可测性、精度、稳定性等）和控制过程。只有这样，才能对行业专家的经验和数据可信度有一个可靠的研判。单台磨煤机的系统动力学如图2-12所示（其中可观测的变量用方框标出），很多重要状态变量并不可以直接观测，这就要求我们对分析模型的使用范围（例如，磨煤机的磨损程度、煤质的变化等）保持谨慎的态度。

案例2：备件销售预测

【业务背景】

根据各个省公司的历史备件销售量，预测未来3个旬的备件需求量。根据业务经验，备件销量有显著的地区特征（不同省份的销量和波动模式不同）和季节性。

【数据分析发现】

在实际分析中，发现除了时空模式和春节特殊处理（每年春节所在具体旬都不同）外，还应该有更多因素考虑。

1）促销活动，如图2-13所示，某省公司2011年12月28～30日3天的销售量占当月的68%，是过去2～3个月销量的和。这样的活动在其他年份没有重现过。不幸的是，促销活动信息在现实中无法获取。对于这样的“突变点”，算法上应该当作离群点处理；

2）地区公司合并，某些省份有多个分公司发生业务合并，这个无法提前获得；

3）备件的型号更新，有型号的替换关系可以利用；

4）宏观市场走势信息，这个可以尝试用工程车的开工情况数据去反映。

【对数据分析师的启发】

和案例1类似，针对一个问题，在构建数据模型前，把驱动因素、相关因素根据业务理解梳理一下，就可以发现当前数据集可以支撑的应用范围，以及需要验证的假设。“数据驱动”的机器学习问题不应该是“盲目被现有数据驱动”，而是从当前业务出发，利用“现实中所有可被利用的数据”。

备件需求的驱动关系可以用图2-14表示，其中，带框的变量表示有数据支撑的，不带框的表示系统的状态变量，实线表示驱动关系，虚线表示相关性关系。

2.4.4 细致求实的基本素养

物理对象是在变化的：细致求实是数据分析的基本素养。

【业务背景】

3个并行给水分支，共用一个给水母管，每个分支上都有一个阀门控制流量。数据分析本身的目标是检测阀门是否存在堵塞（非监督学习）。业务经验给出的研判规则是，在同样的开度下，给水流量长期低于预期值，则阀门存在堵塞。

【数据分析发现】

上述的检测逻辑和磨煤机堵磨类似，但更多的是管道分支结构和流体分配。其中一个基础逻辑比较容易理解，因为3个分支距离母管入口的远近不同，在同样的开度下，它们的流量不同（这和理论的理想情形有所不同，但很容易理解）。

但在跨维修周期后，这样的关系需要重新调整。如图2-15所示，阴影从深到浅分别代表1号、2号、3号分支；上面的子图是维修后的情形，下面的子图是维修前的情形。从统计数据可以看出，在10月底维修后，1号主阀开度升高，3号主阀开度降低，2号主阀开度稍微降低，3个回路流量分布没有大的变化。

业务上究其原因，就是维修前后物理对象发生了变化，原来的规律不再适用。这就要求我们针对每个维修周期单独拟合一个模型（特征变量一样，但具体参数不同）。不过，这对堵塞检测不是问题，因为堵塞通常发生在中后期，维修后有足够的时间去重新拟合一个模型。

【对数据分析师的启发】

在数据分析的时候，常有意无意假设物理系统的基本规律不变。但这种假设是否成立（即使业务专家确认），需要仔细审视。不要为了追求漂亮的结果和模型，有意无意忽略这些前提假设成立的风险。

在很多其他课题中也有类似问题，物理对象在人为干预（例如，养护、维修等）后基本面发生了变化。例如，在煤化工分析中，尝试用CH ₄ 含量去估算炉内温度时，就发现CH ₄ 在一个开车周期内有一个逐渐升高（氧气喷嘴在不断磨损）的过程。在液晶面板蒸镀分析中，也常常发现保养前后的两个周期的表现差别很大。很多风电机组的机舱加速度在一些例行运维后（例如塔基螺栓做了重新紧固）常常会出现显著下降的情况。但很不幸的是往往很多干预动作并没有在数据中被明确标记。

严格意义上，我们永远无法证明物理系统的基本规律不变，也无法保证分析数据集覆盖了所有关键要素信息，只能保证在我们认知的范围内，在尽可能多的数据上有较高置信度。

2.4.5 小结

在数据分析项目中，关心的数据问题远远超过了Data Schema层面的数据质量问题。有时候数据中包含的场景和信息远远超过了当前分析课题关心的范畴，这时候需要从现有数据中筛选出合适的数据；更多时候，数据分析问题的因素并没有完整地反映在数据中，或者数据反映的仅仅是部分生命周期的状态。这就要求数据分析师能够从业务上下文的角度去梳理问题的关键要素，以及它们之间的关系，审视数据在多大程度上反映问题的发展过程。业务上下文的理解也不是一个单向过程，通过“业务的数据化”和“数据的业务化”的迭代，不断加深对分析课题和数据集的理解。

深入理解业务问题和数据集后，常常会发现很多“你以为的不是你以为的”有趣问题。一些常见“意料之外”有趣问题见表2-5。

最后，数据分析师的“细心”不仅仅体现在数据内容上，也包括外部要处理的内容上。例如，图2-16中，为了批量处理数据的日期，程序代码中对文件名进行了字符串提取，按照约定，括号中最后一部分是生产日期，但其中一个数据文件名少写了一个点（写成了20303.26，实际应该是2020.3.26），就可能会让批量处理程序出错。

避免这样的错误除了细心，还与代码风格有关。如果用下面的代码，就会让错误“隐藏起来”，currentBatch会获得一个默认值22。

如果写成下面这样，错误就没有地方躲藏。

在批量的数据预处理中，宁愿把代码写得繁琐一点，检查逻辑丰富一些，避免一些“想不到的”瑕疵影响数据的正确性。 8p+26gv7X17hbAyVZGC0UsuoFPsYrtEPlhZhG3rDNYWgS6fP+s4kkvpBmaHSSzTt