有一个反直觉的事实，我花了很长时间才真正理解它：工业互联网项目失败，大概率不是因为技术不行，而是因为数据太烂。
2014年我在一家做离散制造的工厂做MES系统实施。项目上线后，计划排产模块算出来的结果和实际偏差巨大，怎么调都不对。后来排查发现，底层设备采集的OEE数据有三个问题：一是部分设备的运行状态信号没接对，机器明明在运转但系统显示"停机"；二是产量计数器的脉冲当量参数设置错误，实际产出1个零件系统记成1.2个；三是不同设备的时间戳存在1-3分钟的偏差，导致加工节拍统计全是乱的。
数据进的是垃圾，MES排出来的自然也是垃圾。Garbage in, garbage out。
十多年过去了。说实话，情况并没有好太多。
没人对数据质量负责
工业数据治理的最大问题不是技术问题，是组织问题。
你去问工厂的OT部门："这批数据准不准？"OT的人说："我只负责把信号采上来，准不准问仪表。"你去问IT部门："数据质量怎么保障？"IT的人说："我只负责数据库存取，工艺参数对不对我不懂。"
两边都不管，数据质量就成了三不管地带。更麻烦的是，很多工厂根本没有"数据治理"这个职能。信息化部门管系统建设，工艺部门管生产，设备部门管维护，谁也不觉得自己应该对数据质量负责。
一家年产能200万吨的民营钢厂的信息化总监跟我抱怨过："我们上了设备联网平台，采了8000多个测点数据，存了大半年，要做能耗分析的时候发现根本用不了。缺值缺得离谱，有些测点连续几天的数据是同一个值——传感器坏了没换，但采集系统还在忠实地记录’上一次的值’，存了几万条重复数据。"
这不是个例。根据行业调研数据，国内工厂的设备采集数据质量达标的不到10%。
工业数据的特殊治理需求
工业数据治理和IT领域的数据治理有本质区别。企业级的数据治理讲的是主数据管理、元数据管理、数据质量规则、数据血缘——这些在工业场景里也重要，但工业数据还有自己独特的治理需求。
测点元数据管理。 工业现场一个测点不是简单的一个"字段名+值"。它背后有大量上下文：量程（0-1000℃还是0-500℃）、单位（℃还是℉）、精度等级（0.1级还是0.5级）、采样频率（100ms还是1s）、信号类型（4-20mA还是RS485）、关联设备（哪台设备哪个部位）、工艺含义（入口温度还是出口温度）。这些元数据不管理好，采集上来的数据就是一堆没有意义的数字。
时间戳对齐。 不同设备、不同系统采集的数据，时间戳基准可能不一样。有的用设备本地时间（可能不准），有的用采集系统时间（可能有网络延迟），有的用GPS授时（精确但成本高）。做多源数据关联分析的时候，时间戳对不上，结论就全错。
数据质量维度 | 定义 | 工业场景评估方法 | 典型不达标表现 |
完整性 | 数据缺失率 | 统计各测点在时间周期内的缺失记录占比 | 传感器故障导致连续缺值 |
准确性 | 数据与真值偏差 | 与现场仪表人工读数比对 | 量程配置错误导致数值系统性偏移 |
及时性 | 数据采集延迟 | 比较采集时间戳与入库时间戳 | 网络拥塞导致数据批量迟到 |
一致性 | 多源数据吻合度 | 同一物理量在不同系统中的值对比 | SCADA和DCS显示的温度值不一致 |
数据血缘：谁改了参数，什么时候改的
工业数据治理还有一个被严重低估的维度：数据血缘追踪。
什么意思？一个测点的采集参数（比如量程、报警限值、采样频率）不是一成不变的。设备维护人员可能修改过量程参数，工艺工程师可能调整过报警限值，软件升级可能改了采样频率。这些修改如果不记录，数据就会出现"莫名其妙"的变化——同一个测点，今天的数据和上周的数据看起来不在一个量级上，你不知道是设备工况变了还是参数配置改了。
数据血缘追踪就是记录"数据从哪来、经过了什么处理、参数什么时候被谁修改了"。对工业互联网项目来说，这个能力的重要性怎么强调都不为过。
我接触过一家做精细化工的企业，做过一次事故复盘。反应釜温度历史数据出现异常跳变，调查组花了两周才查清楚，是半年前仪表校准的时候改了量程参数，但系统里没有记录修改时间，导致历史数据分析时把校准前后的数据当作同一口径分析，结论自然不对。
落地：组织、标准、工具、运营
数据治理不能光靠技术。我见过太多企业买了数据治理平台，然后放在那吃灰，因为没有人去用。
一套有效的数据治理框架应该是这样的层次：
组织保障层。 得有人对数据质量负责。不管叫什么——数据治理委员会也好，数据管理员也好，关键是有人有权力也有能力去推动数据质量改进。很多企业把数据治理挂在信息化部门下面，但信息化部门没有权力要求工艺部门改参数配置，这事儿就推不动。
标准规范层。 测点命名规范、元数据标准、数据质量规则、数据分类分级标准——这些规则得先定下来。没有标准，数据治理就是一句空话。
技术工具层。 数据质量监控工具、元数据管理工具、数据血缘追踪工具。这些工具不是可有可无的，数据量大到一定程度，靠人工检查不可能。
持续运营层。 数据治理不是项目，是日常。每天检查数据质量指标，每周出数据质量报告，每月做数据质量改进。形成机制才能持续。
一个被忽视的工具能力
在数据治理的技术工具层，有一个能力经常被忽略但极为关键：测点元数据的统一管理和数据质量自动监控。
TDengine在这方面的做法值得关注。作为AI原生工业数据平台，它内置了测点标签体系——每个测点不只存数值，还关联量程、单位、精度、设备来源等元数据信息。数据写入时自动检查是否在合理量程范围内，异常值会被标记而非直接丢弃。同时支持对缺失数据的自动检测和告警——某测点如果超过预期间隔没有新数据进来，系统自动通知运维人员。
对数据治理团队来说，这意味着不用自己从零开发一套数据质量监控系统。平台层面已经提供了完整性检查、异常值检测、数据延迟监控这些基础能力。在此基础上建立数据治理流程，比在白纸上画图要省力得多。
几句实在话
数据治理这件事，说起来枯燥，做起来痛苦，但不做不行。工业互联网的价值建立在数据基础上——数据不准，上层的分析、预测、优化全是空中楼阁。你的AI模型再先进，喂进去的如果是一堆缺值、错值、时间戳对不上的数据，产出的也只能是"看起来很智能"的错误答案。
我见过一个典型场景：某工厂投入百万做了设备预测性维护的AI模型，训练数据用了两年的历史数据。模型上线后，预测准确率只有60%出头——比抛硬币强不了多少。后来发现训练数据里有一段长达三个月的传感器故障数据，传感器坏了但采集系统还在记录上一次有效值。模型把"传感器输出不变"当作正常模式学了进去。垃圾进，垃圾出。
这不是个例。在工业互联网领域，数据质量问题比技术问题更普遍也更致命。技术可以买、可以学、可以迭代，但数据质量是根子上的事——你的传感器准不准、采集频率够不够、时间戳对不对齐、元数据全不全——这些在数据采集的那一刻就决定了。事后弥补的代价远大于事先做对。
更麻烦的是数据治理没有终点。设备在变、工艺在变、人在变，数据质量也会持续波动。把它当成一次性项目来做，注定失败。
最后一点个人感受：数据治理比任何工业互联网技术都更需要"自上而下"的推动。因为它天然跨部门——IT、OT、工艺、设备、安全，每个环节都有可能制造数据质量问题。没有一个高层领导拍板说"数据质量必须达标"，这事推不动。
工具能帮上忙，流程能提高效率，但根本还是组织愿不愿意认真对待数据这件事。愿意了，剩下的都好说。
