春节假期还没结束我就抱着一个塞满安装包和演示脚本的移动硬盘去了 ProveIt! 现场。我们要把一套跑在 TDengine 上的工业智能平台第一次带到全球工业现场平台的名字叫无问智推。简单说它做的是把车间里的设备数据接进来用 TDengine 做时序数据的存储和计算再让 AI 模型直接给出诊断结论和操作建议——哪个设备有异常、问题可能出在哪个部件、建议什么时候检修。这个概念我在办公室里演示过很多次但真正到了工业现场的场地面对不熟悉的网络、临时调配的工控机和可能随时断电的插线板整个系统的脾气完全不一样。这篇复盘会从架构选择、数据建模、现场踩坑到工程化取舍完整过一遍给同样在做工业数据平台或预测性维护的朋友一些参考。1. 为什么是无问智推先回答现场真正要问的问题1.1 工业现场的三类低频高成本问题在设计无问智推之前我们花了很长时间泡在车间里做调研。最后发现很多工厂真正痛的不是数据少而是数据读不出来、读出来没人看得懂。最突出的问题大概有三类。第一类设备坏了才知道坏了。不少产线的点检仍然靠老师傅听声音、摸温度数据采集系统可能早就装了但告警阈值是拍脑袋定的误报漏报都很严重。第二类专家经验带不走。一个老师傅能凭振动特征和工艺参数配合判断设备状态可一旦人不在现场问题就卡在那里没人敢拍板。第三类工艺参数靠试错。换个物料、换个批次调参要停机试很多轮时间成本全是隐性流失。针对这三类问题无问智推给自己定了三条原则。第一不追求大而全的平台每个场景只解决一个具体问题。第二输出必须能直接指导动作要么是停机检查要么是把参数调整到某个范围不给一堆图表让用户自己猜。第三数据底座必须可靠因为现场不会给你机会解释刚才是查询卡了。至于为什么叫无问智推无问不是说我们不接受提问而是我们希望使用者不需要会写 SQL、不需要懂统计模型只要像问老师傅那样问一句这台设备要不要停系统直接给答案智推则是把诊断结论和处置建议一起给出来。这个定位在 ProveIt! 现场交流时特别管用因为观众只有几分钟时间理解系统没有人愿意看一套需要解释半天的架构图。1.2 为什么数据底座选了 TDengine无问智推最初的原型用的是普通关系型数据库加一堆定时任务写到后面维护成本越来越高。传感器数据的特征是持续写入、按时间窗口查询、按设备维度聚合关系型数据库的行式存储在长时间范围聚合统计时性能衰减很明显。后来我们评估了几种时序数据库最终把底座定在 TDengine主要是看中几个点。首先是建模方式贴合。TDengine 的超级表和标签模型可以把一类设备映射成一张超级表设备编号、产线、测点类型都放标签查询时天然按设备裁剪。对多设备、多测点的工业场景来说这比传统关系库建一堆索引要省心得多。其次是连续查询和订阅能力。数据清洗、降采样、告警状态判断都可以直接用 SQL 在库里做不需要额外维护一套流处理框架。对一个只有几个人的项目团队来说少一个组件就少一类故障少一套运维成本。然后还有部署成本。TDengine 单机版资源占用很克制一台普通工控机跑几十万测点没有压力对展会演示和边缘侧部署都很友好。但选它也不是没有代价。TDengine 的生态没有通用数据库那么庞大有些 BI 工具和自定义可视化组件需要自己调接口它擅长的是时间序列场景如果要做复杂的多表关联分析需要提前设计好中间结果表。我们在无问智推里把这些特点变成了设计原则能用 SQL 聚合解决的绝不上第三方的重型计算框架能本地跑的模型绝不依赖云端。2. ProveIt! 现场方案从传感器采样到操作建议的完整链路2.1 现场数据入口协议适配与边缘缓存ProveIt! 现场没有条件接一条真实产线所以我们用了一套仿真 PLC 加真实采集程序来模拟。但协议适配的逻辑和实际工厂完全一样底层是 Modbus TCP、OPC UA 和 MQTT 三种典型接口采集网关把它们统一转换成内部数据结构——时间戳、测点 ID、浮点数值、质量标志位。质量标志位特别重要后面排查问题全靠它比如某条数据是采集正常、估计值还是无效值一眼就能看出来。为了抵抗不稳定的网络采集网关没有直接把数据写进 TDengine而是先写本地缓存队列。这个队列是持久化的程序重启、断网重连都不会丢数据。网络恢复后网关按时间戳顺序补传保证乱序数据不会污染时序曲线。我们内部把这套机制叫做无问式接入数据源不需要关心平台在不在线只要能保证数据到边缘网关后面的事情平台全包。这套接入机制后来在现场帮了大忙。展会当天的无线网络跳 ping 很严重高峰期丢包率一度接近两位数但因为采集网关有本地缓存写入 TDengine 的任务完全没受影响观众看到的趋势曲线始终是连续的。如果没有这层缓冲光是网络抖动就能让演示效果看起来像一帧一帧的 PPT。2.2 TDengine 数据模型超级表、标签与保留策略无问智推在 TDengine 里设计了两类超级表一类存原始采样数据一类存推理结果。原始采样表的简化结构如下CREATE STABLE raw_signal ( ts TIMESTAMP, val DOUBLE, quality INT ) TAGS ( device_id BINARY(32), line_id BINARY(16), measure_id BINARY(16) );每个设备的一个测点会创建一张子表比如振动测点可以这样建CREATE TABLE dev_001_vib USING raw_signal TAGS (dev_001, line_a, vib);这里的关键是把标签和列分开。device_id、line_id、measure_id 这些元数据放标签之后查询时按标签过滤能直接定位到对应的子表集合效果相当于传统数据库的复合索引但又不需要我们手动维护索引。对三班倒连续采集的工厂来说省掉的索引维护工作量很可观。推理结果也用独立的超级表保存这个设计当时有人问过为什么不放到 MySQL 或者直接丢给消息队列。我当时的回答是原始数据和推理结果时间戳天然对齐看板联查时一条 SQL 能把当时的信号和当时的结论一起拉出来省掉跨库 join。更重要的是后续做模型反馈闭环时需要把预测结果和真实维修记录放在同一条时间线里分析存进时序库自然是最顺的。保留策略上演示环境原始数据保留 30 天推理结果保留 90 天。这个设定直接对应使用场景原始数据用于近期诊断推理结果要保留更长时间做模型效果评估。没有保留策略的时序库磁盘早晚被写满这个坑在工业现场尤其致命。2.3 推理链路连续查询清理数据模型服务给结论无问智推的推理链路分三步。第一步用 TDengine 的连续查询定期把原始信号做降采样生成 5 分钟级的均值表和波动率表相当于提前给模型准备好干净的中间特征。第二步模型服务通过订阅方式拿到新增数据或者在推理触发时按固定窗口查询最近 N 条数据在内存里做特征工程——滑动窗口均值、标准差、趋势斜率、频域能量。第三步模型输出异常分、健康度和建议动作通过 REST API 回写到 infer_result 表。演示时我们特意让模型全部本地化运行。现场网络情况复杂如果模型推理依赖云端服务一旦网络抖动整个演示就会卡壳。模型本身采用的是轻量隔离森林 统计基线的组合统计基线负责抓缓慢劣化隔离森林负责抓突发异常两者输出归一化到 0 到 1异常分超过阈值才推告警。这样设计的好处是解释性强现场工程师能理解为什么报这台设备而不是面对一个黑盒。提示时序异常检测不要一上来就上深度模型。工业故障样本通常很少几十条标注数据很难训练出可靠模型。先用统计基线和隔离森林这类方法把可信异常和疑似异常分开后续再慢慢积累标注数据这才是能落地的节奏。2.4 看板与告警链路轮询是万恶之源看板最初的做法是前端每两秒拉一次 TDengine 的 REST API结果设备一多一个页面十几张图同时刷新接口响应越来越慢。后来我们把查询逻辑彻底拆成三类。实时趋势直接查最近 5 分钟降采样结果利用连续查询预计算前端按需刷新设备状态板每 10 秒刷新一次而且只会查状态有变化的设备子表告警事件不靠前端轮询而是用 TDengine 的订阅功能把连续查询产出的结果推给后端由后端负责去重、升级、推送消息。这一个改动配合标签过滤接口的 P99 响应时间从 2.8 秒降到了 400 毫秒以内。ProveIt! 现场那台普通笔记本跑这套看板完全扛得住。现场有不少海外背景的工程师来交流问法不同但关心的问题出奇一致数据量大了怎么办、断网怎么办、误报怎么控制。我们发现只要底层链路的缓冲和裁剪设计得足够好这些问题基本都能从架构层面化解而不是靠现场调参数硬撑。3. 春节假期备战的工程细节把不确定性提前杀掉3.1 工具箱什么都要离线、什么都要可重放春节假期做项目最麻烦的是团队不在同一个地方没法随时联调。所以我们给自己定了一条规矩任何步骤都要能在没有外网的环境下重放。Python 环境整体打包成 venvTDengine 用官方离线安装包模型权重文件直接打进包里再配上预生成的演示数据文件。现场安装流程被压缩成两条命令一条启动 TDengine一条初始化数据库并导入预置数据。这里有个容易被忽视的细节依赖版本锁死。我们在 requirements.txt 里全部固定到精确版本号连 numpy、pandas 这种基础库都锁死。因为现场机器可能装了别的东西一旦某个依赖被意外覆盖模型推理结果可能都会变化。这种事在办公环境里很少发生但在展会现场和工厂办公室机器环境往往比想象中复杂得多。3.2 预置数据与故障注入脚本现场没有真实故障数据演示效果一部分靠预置数据脚本控制。我们提前生成了三类数据轨迹健康工况、缓慢劣化工况、突发异常工况。每条轨迹的振幅、频率、温度曲线都不一样模型对这三类数据的响应也是可预期的。观众看到的既不是纯静态录像也不是看我们手忙脚乱地调参数而是一套系统正在自主发现问题。故障注入脚本也很关键。它不是简单地往数据库里写一段假数据而是模拟采集网关持续运行在设定时间点自动切换数据源。这样整个演示过程是连续感很强的大屏上先是一台设备状态正常然后某段时间振动趋势缓慢抬升看板打出建议关注的提示再过几分钟出现一次瞬时尖峰模型升级为建议停机检查。这套流程跑下来观众自然能理解系统的价值。3.3 远程值守与快速回滚清单设备不在身边只能靠自动化脚本值守。我们在每个演示节点装了一个轻量监控服务每 30 秒检查四项TDengine 进程是否在跑、磁盘空间是否低于 10%、模型服务响应是否超过 3 秒、缓存队列积压量是否异常。任何一项异常都会把现场日志和相关上下文推到值班群。所有配置、建表语句、数据导入脚本都放在 git 仓库里现场如果改了配置改完立刻提交并打标签。回滚不是手工改文件而是跑一条写好的 rollback 脚本。这套版本化 一键回滚的习惯在春节远程协作场景里特别重要——人不在现场能自动解决的就不要远程猜。顺带说一下演示前我们还会跑一遍检查清单包括系统时间同步、端口占用、磁盘剩余空间、TDengine 健康检查全部通过才开始正式演示。4. 现场踩坑记录Demo 和真实工业现场的差距有多大4.1 时间戳错了后面全白搭第一天布展采集程序启动后TDengine 里数据看着在涨但查询某台设备最近一小时的数据时总是缺一段。排查链路是这样的先看采集端日志发现时间戳正常数据本身没问题再看写入程序发现写入时从秒级转毫秒级的时间戳丢了时区信息最后对比 TDengine 服务端和工控机的系统时间发现差了整整 8 小时——查询窗口按本地时间算数据按另一个基准落库前后一错位就丢数据。解决方法是统一约定所有设备端时间戳按毫秒 Unix 时间戳上传入库时不依赖当前时间服务端和客户端时区统一配置TDengine 连接参数里也显式指定时区。这类问题在办公环境很少遇到但工业现场的工控机系统时间经常没人维护开机时时间就是错的必须在采集端做时间同步校准否则后面所有查询、告警、模型窗口全都会跑偏。4.2 查询慢不是数据库弱是标签裁剪没触发现场有位同行看完演示后问了一句你们不是用了超级表吗为什么点开设备详情要等三秒我们当场排查发现前端查询只是按时间范围过滤没有带 device_id 标签条件。TDengine 的超级表是标签 时间两级裁剪不带标签条件时逻辑上要扫描该类型下所有子表自然慢。修复很简单查询加一行 WHERE device_iddev_001裁剪范围就缩小到一张子表。同样的逻辑也推给了模型服务模型取数只查特定设备最近窗口绝不全局扫描。这个坑特别典型凡是第一次用超级表的人几乎都会踩一次。后来我们把查询必带标签过滤写进了开发规范并且在看板接口层做了强制校验不传 device_id 直接拒绝请求。4.3 应用级缓存别让前端把实例打死展位参观者会反复点大屏特别是演示异常检测时好几个人同时拿手机拍屏幕。后来有人连续点了十几次查看关联数据后端接口立刻开始排队。原因是全链路没有做应用级缓存每条请求都会穿透到数据库而查询窗口大、计算量不小。我们在后端加了一个很简单的缓存层最近 30 秒内相同的查询直接返回缓存结果演示脚本、看板接口、模型服务都接入同一套缓存。改完后无论观众怎么点数据库压力都稳住了。这个教训也说明一个道理Demo 环境的负载虽然小但交互模式可能比生产环境更极端必须把缓存、限流这些基本功提前做掉。4.4 断电与重启进程守护是标配ProveIt! 现场的设备供电比较随意展会方提醒尽量不要在演示间隙拔电源但总有人不小心碰到插线板。第一天下午就遇到一次断电重启TDengine 服务正常恢复了但采集进程没有自动起来导致一段时间的数据空窗。现场排查时又发现采集程序没有做开机自启断电后必须人工登录启动。回来后我们把所有采集、推理、缓存进程都交给守护进程管理配置了开机自启和自动拉起再遇到断电重启就基本不用管了。对工业现场来说意外断电不是低频事件进程守护应该从一开始就是标配而不是演示翻车之后才补。下面把这个环节踩过的坑整理成一张速查表方便大家直接对照排查现场现象根因解决方式查询总是缺一段数据时区不一致时间戳错位统一毫秒 Unix 时间戳显式配置时区超级表查询响应 3 秒以上查询未带标签条件全表扫描WHERE 加 device_id强制标签过滤接口排队、点击卡死无应用级缓存重复查询穿透后端加 30 秒查询缓存断电后服务无法自动恢复进程无守护、无开机自启守护进程托管全部核心服务5. 首次亮相复盘数据质量比算法更值钱5.1 脏数据治理把哪些数据不能信做成常态化监控这次现场演示虽然顺下来了但回到酒店复盘时我们几个人一致认为后面的投入重点应该是数据质量而不是模型精度。现场传感器数据常见的几类问题这次在预置数据里也特意做了缺失值采集网关掉线一小段补零会骗过模型必须标记缺失段重复值某些 PLC 在通信超时后会重发上一帧导致同一时间戳出现两条记录入库前要去重毛刺偶发干扰造成瞬时尖峰直接进模型容易误报检测端要做中值滤波和限幅。无问智推在库里专门设了一张数据质量表记录每个测点的缺失率、重复率、毛刺计数。演示看板有一页实时刷新哪些数据不能信这个页面反而吸引了不少关注。很多同行说他们也有同样的问题但很少人把它做成常态化监控。数据质量面板的意义在于当告警出现时运维人员可以第一时间判断是设备真的有问题还是传感器本身不可信这比单纯看一个异常分数靠谱得多。5.2 避免看着准、实际虚的模型陷阱无问智推的模型在演示中的表现确实理想但我们心里清楚亮点更多来自场景设计。模型一旦脱离现场物理约束很容易做出统计显著但工程无意义的结论。举个例子模型能识别某台设备振动随转速升高的趋势但如果不知道这台设备的工况区间同一个振动水平在 600 转和 3000 转时意义完全不同。所以在推理结果里我们强制带上工况上下文模型输出异常分的同时会把当前的转速、负载、温度范围一并写进建议字段让现场工程师看到的是在什么工况下出现问题、建议怎么调而不是孤零零一个分数。这个细节帮我们在现场交流时省了很多解释成本也让系统显得更可信。5.3 还没做好的多工厂接入、模型灰度、长期归档ProveIt! 上的展示以单点场景为主真正要铺开还有很多工程问题要解决。多工厂接入时网络隔离和权限模型要做得很细不同区域的数据不能随意互通标签规范也得统一。模型升级要走灰度路径先在一条产线跑一周对比误报率之后再推全量否则一个回归模型上线现场告警能炸一整天。历史数据要设计冷热分层和归档策略只靠保留策略删数据后续想做回溯分析和模型复盘就没有材料了。这些内容都留到了下一阶段。一次现场演示能证明的是方案本身可行而一个工业智能平台要走得远拼的其实是数据工程能力。无问智推这次亮相只是一个开始后面还会不断遇到更复杂的现场工况。最后说点个人体会。春节假期把一个新平台第一次带到全球工业现场最大的收获不是演示有多顺利而是环境逼着我们把方案简化到不能再简化能离线就离线能自动就不手动能回滚就留后路。无问智推这个名字将来可能还会调整但不问设备背后的数据有多乱只管给出能落地的智能推荐这个定位经过 ProveIt! 这一次我觉得是站得住的。如果你也在做类似的工业数据项目我的建议很简单先把数据质量表做起来再谈模型先把部署脚本练熟再谈算法。现场不会给你重来一次的机会但充分的准备会。