去年做MES数据迁移以为就是简单的ETL结果数据清洗搞了整整3个月。最坑的一次时间戳格式不统一有的精确到秒有的到分钟导致OEE计算结果差了20%PM差点找我麻烦。一、坑1时间戳格式不统一这是最大的坑。我们的MES数据来自3个不同系统设备层用Unix时间戳毫秒级中间层用SQLServer的datetime西门子PLC用YY-MM-DD HH:MM格式。三套数据合在一起时间戳格式多达12种。第一次做OEE统计算了半天结果跟现场对不上后来发现是格式混乱导致的时间偏差叠加。解决方案统一转为UTC毫秒时间戳用pandas解析所有格式。关键代码45行def normalize_timestamp(series):def parse_one(val):if pd.isna(val): return pd.NaTif isinstance(val, (int, float)):val int(val)if val 1e12: val val // 1000return pd.Timestamp(val, units, tzUTC)val str(val).strip()formats [%Y-%m-%d %H:%M:%S, %Y/%m/%d %H:%M:%S,%Y-%m-%d %H:%M, %Y/%m/%d %H:%M,%Y-%m-%d, %Y/%m/%d,%y-%m-%d %H:%M:%S]for fmt in formats:try: return pd.Timestamp(datetime.strptime(val, fmt), tzUTC)except ValueError: continuereturn pd.NaTreturn series.apply(parse_one)df[timestamp] normalize_timestamp(df[raw_timestamp])print(Parse success rate:, df[timestamp].notna().mean())二、坑2停机时数据缺失FAB设备停机时操作员往往不记录停机状态直接留空。导致数据里有一大堆NaN系统以为是正常生产OEE算出来虚高。我有一次报给PM的OEE是92%PM说我看设备停了3小时你们怎么算的当场社死。解决方案用设备状态字段和实际产量交叉验证自动补全停机记录。产量为0且时长5分钟→标记为计划停机连续3条以上NaN且设备状态IDLE→标记为故障停机。补全后OEE从92%修正到78%跟现场实际一致。三、坑3单位混乱设备数据里时间单位不统一有的是秒有的是分钟有的是小时。产能数据里有的是片/小时有的是批/天。混合在一起计算数值能差几十倍。我曾经把气体流量当成标准单位来算结果算出来ETCH机台的气体流量比大气压还高设备工程师看了直摇头。解决方案入库前统一转换为基础单位秒、ml/min、片。四、数据质量可视化图1 MES数据质量问题分布近3个月时间戳格式不统一是重灾区342条缺失值其次198条。这3个月累计发现897条脏数据都是靠自动化脚本检测出来的。图2 膜厚数据清洗前后对比原始数据有3个明显离群点850nm/200nm/900nm正常范围440-560nmIQR方法清洗后数据干净可用。异常值往往是传感器漂移或设备故障的信号清洗时别直接删要标记出来给设备工程师排查。五、总结MES数据清洗的坑远不止这3个但只要做到时间戳统一、停机补全、单位转换这三点基本能覆盖80%的脏数据。我的经验数据清洗花的时间永远比你预计的多留50%buffer不然天天被PM找麻烦。你们MES数据清洗遇到过什么奇葩问题评论区分享一个获取MES数据清洗工具包含时间戳统一停机补全单位转换私信回复【数据清洗】