从故障诊断到寿命预测用 DolphinDB 构建工业设备的预测性维护管线摘要做工业设备运维的人多半听过状态维修CBM的三个递进层次诊断现在有没有故障、评估一群设备整体多健康、预测这台设备还能用多久。前两层已经有不少实践——频谱分析能告诉你轴承是不是出了早期点蚀健康评分能给整厂设备排个名。但真正能把运维从被动响应推向主动排程的是第三层预测设备的剩余使用寿命Remaining Useful LifeRUL。知道了某台泵还有多少天会失效维修排程、备件采购、停机窗口就能提前安排而不是等故障报警了才手忙脚乱。但 RUL 预测在工程上一直不好做。难点不在算法而在管线原始波形怎么变成建模特征、标签从哪来设备又不会主动告诉你它还能撑几天、训练好的模型怎么从离线搬到实时。这条管线一旦要跨 Python 训练 Flink 推理 数据库存储三个系统光是特征对齐就能耗掉团队大半精力。本文分享我用 DolphinDB 构建 RUL 预测管线的过程特征工程、标签构造、库内训练、批量流式推理全在一个平台里闭环。重点不在用了一个多先进的模型而在标签怎么构造、管线怎么搭——这两件事是预测性维护工程化的真正难点。一、诊断、评估、预测状态维修的三层递进在动手之前先把预测性维护在整个运维体系里的位置摆清楚避免和已有实践混淆。层次回答的问题典型手段时间指向诊断现在有没有故障故障在哪频域特征、包络解调当下评估这批设备谁更该关注健康评分、群体排名当下预测还能用多久什么时候会失效RUL 回归、失效概率未来诊断和评估都是看当下区别只在前者针对单台定位故障、后者针对群体排出优先级。预测则是唯一看未来的——它要给出一个量化的剩余寿命数字。为什么要强调这个区分因为很多人把做了健康评分等同于做了预测性维护其实没有。评分告诉你这台设备现在状态差但没告诉你它还有多久会彻底失效。前者是状态快照后者是时间外推。维护排程需要的恰恰是后者备件到货要两周那这台设备至少得撑过两周才有意义。本文聚焦的就是第三层——用历史数据训练一个能输出 RUL 的模型并把它接到实时数据流上。二、预测性维护的四段式管线把 RUL 预测拆成工程上可落地的四段后文逐段展开原始时序数据 │ ▼ ① 特征工程 ── 滚动窗口从波形里抽出建模特征时域 频域 │ ▼ ② 标签构造 ── 用已知的故障时间点倒推每条历史样本的 RUL 标签 │ ▼ ③ 模型训练 ── 库内训练回归模型随机森林回归验证泛化能力 │ ▼ ④ 推理打分 ── 批量给历史数据打分 流式给实时数据打分四段里①特征工程和②标签构造是真正的难点。模型选什么反而没那么关键——只要特征干净、标签准确随机森林这种笨模型也能给出可用的 RUL 估计反过来特征噪声大、标签错了再花哨的深度模型也是垃圾进垃圾出。所以下文把篇幅主要给前两段。三、特征工程从原始波形到建模特征3.1 一条原则特征要在设备 时间维度上滚动计算RUL 预测的特征不是单点值而是一段时间窗内的统计特征。设备此刻的健康状态不取决于某一毫秒的振动幅值而取决于过去一段时间的振动趋势、峰值、能量分布。这就要求特征计算必须按设备分组、按时间滚动。DolphinDB 的context by 移动函数天然适合这件事复杂度是增量 O(n)不会随数据量线性变慢。3.2 滚动窗口特征表假设原始振动表已经按八期的方法算出了每秒的振动 RMS有效值现在要在它之上滚动计算建模特征// 基础表每台设备每秒一条 RMS由高频波形聚合而来 // 字段ts, deviceId, rms, temperature, rpm // 滚动窗口特征过去 10 分钟600 秒的统计量 features select deviceId, ts, rms as feat_rms, mavg(rms, 600) as feat_rms_mean, mstd(rms, 600) as feat_rms_std, mmax(rms, 600) as feat_rms_peak, mmin(rms, 600) as feat_rms_min, // 峰值因子 峰值 / 有效值反映冲击性故障 mmax(rms, 600) \ mavg(rms, 600) as feat_crest, // 温度和转速作为工况特征 mavg(temperature, 600) as feat_temp, mavg(rpm, 600) as feat_rpm, // 趋势特征当前 RMS 相对均值的偏离 (rms - mavg(rms, 600)) \ mstd(rms, 600) as feat_zscore from loadTable(dfs://iot_point, vibration_1hz) context by deviceId几个设计要点窗口长度要对齐工况周期。设备一个运行周期可能是几分钟窗口太短抓不到趋势太长又把早期故障信号平滑掉了。10 分钟是个起点具体要结合设备类型调。峰值因子crest factor是好特征。它对早期冲击性故障轴承点蚀、齿轮断齿特别敏感且对转速变化相对稳健是 RUL 建模的常客。z-score 趋势特征捕捉当前值偏离自身常态多远比绝对幅值更能反映退化趋势。3.3 频域特征的接入八期已经讲过怎么用fft算频谱、用imax定位主频。在 RUL 管线里频域特征主频幅值、特定故障频率的能量可以作为补充特征拼进来。关键是频域特征要和时域特征对齐到同一个时间戳上否则标签和特征对不上模型就学乱了。对齐用ajasof join把每秒级时域特征关联上同一时刻最近的频域特征。// 把时域特征和频域特征按时间对齐 model_input select f.deviceId, f.ts, f.feat_rms_mean, f.feat_crest, f.feat_zscore, s.feat_bpfo_energy, s.feat_peak_freq from aj(features as f, freq_features as s, deviceIdts)到这一步每行就是某台设备某个时刻的一组特征可以喂给模型了。但还差一样东西——标签。四、标签构造的艺术倒推 RUL本文核心这是预测性维护工程化里最容易被忽略、又最关键的一步。模型要预测还能用多久可历史数据里的每条记录并没有一个现成的剩余寿命字段。标签得我们自己造。4.1 核心思路从已知的故障时间点往回倒推假设我们从历史记录里知道设备PUMP-007在2026.04.12 03:15:00发生了一次故障停机。那么这台设备在故障前任意时刻t的 RUL就是RUL 故障时刻 - t把这条规则套到整段历史数据上每条特征记录就都带上了 RUL 标签。距离故障越近RUL 越小正常运行早期RUL 很大。用 SQL 实现关键是先把每台设备的故障时刻找出来再 join 回特征表做减法// 第一步找出每台设备最近一次故障或大修的时刻 // statusFAULT 表示故障停机记录 fault_times select deviceId, max(ts) as faultTime from loadTable(dfs://iot_txn, alertTicket) where status FAULT and ts between 2026.01.01 : 2026.06.30 group by deviceId // 第二步把故障时刻 join 回特征表倒推每条样本的 RUL单位小时 labeled select f.deviceId, f.ts, f.feat_rms_mean, f.feat_crest, f.feat_zscore, f.feat_bpfo_energy, f.feat_peak_freq, f.feat_rpm, (g.faultTime - f.ts) \ 3600000 as rul // 毫秒转小时 from model_input as f inner join fault_times as g on f.deviceId g.deviceId where f.ts g.faultTime // 只取故障前的样本到这一步labeled表里每一行就是一个带标签的训练样本特征 RUL。这就是监督学习的输入。4.2 一个坑远端样本的标签噪声直接用故障时刻 - 当前时刻作为 RUL会带来一个隐蔽的问题设备刚投运、状态完全健康时RUL 标签很大比如几千小时但这段时间的特征和健康几乎没区别。模型在这些远端样本上学不到退化信号反而会被大量健康 大 RUL的样本主导导致对临近故障的样本预测不准。工程上常用的处理是分段线性标签piecewise RUL给 RUL 设一个上限超过上限的统统截断。// 分段线性 RUL超过 240 小时的截断为 240 // 含义设备还很健康和还能用 240 小时以上对排程决策没有区别 labeled_capped select deviceId, ts, feat_rms_mean, feat_crest, feat_zscore, feat_bpfo_energy, feat_peak_freq, feat_rpm, iif(rul 240, 240, rul) as rul from labeled这一步看似简单但对模型效果影响很大。截断上限怎么定通常结合业务备件采购周期的 1.5~2 倍是个实用参考——再远的 RUL 对排程没决策价值不如让模型把精力集中在临失效区间。4.3 数据划分按设备切不要按时间切训练 RUL 模型时一个常见错误是按时间随机划分训练集/验证集。这会导致同一台设备的样本同时出现在训练集和验证集里——模型记住了这台设备的个性验证指标虚高换一台没见过的设备就垮。正确做法是按设备划分一部分设备全程数据进训练集另一部分设备全程数据进验证集。这样验证的是模型对没见过设备的泛化能力才是上线后真实面对的场景。// 取一批设备做训练集另一批做验证集按 deviceId 哈希划分 train select * from labeled_capped where hashBucket(deviceId, 100) 70 valid select * from labeled_capped where hashBucket(deviceId, 100) 70五、库内训练随机森林回归 RUL特征和标签都就绪后训练这一步反而简单。DolphinDB 内置了机器学习函数不用把数据导出到 Python 训练再导回模型整个过程在库内闭环。5.1 训练用随机森林回归randomForestRegressor做 RUL 预测。选它的原因对特征量纲不敏感、能处理非线性、可解释性比神经网络好、不易过拟合——对工程落地很友好。// 训练随机森林回归模型 // 输入训练集特征列 RUL 标签列 featCols feat_rms_meanfeat_crestfeat_zscorefeat_bpfo_energyfeat_peak_freqfeat_rpm rulModel randomForestRegressor( ds sqlDS(select * from train), yColName rul, xColNames featCols, numTrees 80, maxDepth 16 )几个工程注意点numTrees和maxDepth不是越大越好。树太多训练慢、收益递减太深容易记住训练集噪声。80 棵树、深度 16 是个保守起点按验证集指标微调。特征列里不要混入 deviceId、ts 这类标识列。它们不是退化特征混进去模型会去记设备编号泛化直接崩。sqlDS把训练集包装成数据源支持分布式训练数据量大时能并行。5.2 验证在验证集上预测看误差。RUL 这种回归问题看平均绝对误差MAE比看均方误差MSE更直观——MAE 的单位就是小时业务能直接理解。// 在验证集上预测 pred predict(rulModel, valid) // 拼回真实标签算 MAE平均绝对误差单位小时 valid_pred select *, pred as rul_pred from valid mae select avg(abs(rul - rul_pred)) as mae_hours from valid_pred比如 MAE 是 18 小时含义是模型预测的剩余寿命平均偏差约 18 小时。这个数能不能用取决于业务对预测精度的容忍度——用于排程参考往往够用用于精确到小时的停机决策则还需要继续调特征和标签。六、推理打分批量 流式训练完的模型要能同时服务两类需求离线回溯给历史数据批量打分分析退化曲线和实时预警新数据一进来就给当前 RUL。6.1 批量打分对任意一段时间的历史特征批量预测画出每台设备的 RUL 退化曲线用于复盘和模型调优// 给 2026 年 3 月的特征批量打 RUL 分 scores select deviceId, ts, rul_pred, // 按预测 RUL 分档 48h 高危 120h 关注其余正常 iif(rul_pred 48, HIGH, iif(rul_pred 120, WATCH, OK)) as risk_level from ( select *, predict(rulModel, model_input) as rul_pred from model_input where ts between 2026.03.01 : 2026.03.31 ) order by deviceId, ts按设备画rul_pred随时间的曲线理想情况下应该看到一条从高位平滑下降、临近故障趋近于 0 的轨迹。如果曲线剧烈抖动说明特征里还有噪声回到第三节调窗口和特征。6.2 流式打分实时场景下新特征一算出来就要立刻得到 RUL。把训练好的模型挂到流计算引擎上即可——离线训练用的特征管道和实时推理用的特征管道是同一套这是管线闭环的核心价值。// 实时特征流由前面的滚动窗口引擎产出每秒一条 share streamTable(1:0, deviceIdtsfeat_rms_meanfeat_crestfeat_zscorefeat_bpfo_energyfeat_peak_freqfeat_rpm, [SYMBOL, DATETIME, DOUBLE, DOUBLE, DOUBLE, DOUBLE, DOUBLE, DOUBLE] ) as featureStream // 输出流实时 RUL 预测 rulOut table(1:0, deviceIdtsrul_predrisk_level, [SYMBOL, DATETIME, DOUBLE, SYMBOL]) // 响应式状态引擎进一条特征出一条 RUL 预测 rulEngine createReactiveStateEngine( name rulPredict, metrics [ predict(rulModel, feat_rms_mean, feat_crest, feat_zscore, feat_bpfo_energy, feat_peak_freq, feat_rpm) as rul_pred, iif(predict(rulModel, feat_rms_mean, feat_crest, feat_zscore, feat_bpfo_energy, feat_peak_freq, feat_rpm) 48, HIGH, WATCH) as risk_level ], dummyTable featureStream, outputTable rulOut, keyColumn deviceId ) // 订阅实时特征流 subscribeTable(tableNamefeatureStream, actionNamerul, handlertableInsert{rulEngine}, msgAsTabletrue)这样实时特征一流入featureStream引擎就立刻输出当前 RUL 预测和风险等级。下游可以把HIGH级别的设备推送给排程系统触发备件预占和维修窗口预约。整条管线的价值就在这里训练时算特征的那套context by mavg/mstd逻辑推理时原封不动地挂在流引擎上跑。没有离线 Python 特征 在线 Java 特征两套要对齐的代码特征定义只有一处不会漂移。七、写在最后预测性维护是工业 IoT 里被谈得很多、做出来却很少的场景。原因不在算法多难而在管线特征怎么滚动算、标签从哪来、模型怎么从离线搬到实时。这三件事每一件单独看都不复杂但要在跨系统的架构里保持一致工程量就会失控。用 DolphinDB 做这件事的价值不是它有个多强的机器学习模型——随机森林回归是很朴素的算法。价值在于整条管线在一个平台里闭环特征用context by滚动算增量更新标签用 SQL 倒推分段截断去噪模型库内训练数据不出库推理把训练时的特征管道直接挂到流引擎离线在线同源回过头看状态维修的三层诊断看当下、评估看群体、预测看未来。前两层解决现在怎么办预测这一层才真正回答接下来怎么办——而接下来怎么办恰恰是运维从成本中心转向价值中心的关键一步。落到工程上记住一点RUL 模型的天花板由标签质量决定不由算法决定。把标签构造倒推 截断 按设备划分做扎实朴素的模型也能给出可排程的预测标签错了再复杂的模型也只是过拟合训练集。 从故障诊断到寿命预测：用 DolphinDB 构建工业设备的预测性维护管线
从故障诊断到寿命预测用 DolphinDB 构建工业设备的预测性维护管线摘要做工业设备运维的人多半听过状态维修CBM的三个递进层次诊断现在有没有故障、评估一群设备整体多健康、预测这台设备还能用多久。前两层已经有不少实践——频谱分析能告诉你轴承是不是出了早期点蚀健康评分能给整厂设备排个名。但真正能把运维从被动响应推向主动排程的是第三层预测设备的剩余使用寿命Remaining Useful LifeRUL。知道了某台泵还有多少天会失效维修排程、备件采购、停机窗口就能提前安排而不是等故障报警了才手忙脚乱。但 RUL 预测在工程上一直不好做。难点不在算法而在管线原始波形怎么变成建模特征、标签从哪来设备又不会主动告诉你它还能撑几天、训练好的模型怎么从离线搬到实时。这条管线一旦要跨 Python 训练 Flink 推理 数据库存储三个系统光是特征对齐就能耗掉团队大半精力。本文分享我用 DolphinDB 构建 RUL 预测管线的过程特征工程、标签构造、库内训练、批量流式推理全在一个平台里闭环。重点不在用了一个多先进的模型而在标签怎么构造、管线怎么搭——这两件事是预测性维护工程化的真正难点。一、诊断、评估、预测状态维修的三层递进在动手之前先把预测性维护在整个运维体系里的位置摆清楚避免和已有实践混淆。层次回答的问题典型手段时间指向诊断现在有没有故障故障在哪频域特征、包络解调当下评估这批设备谁更该关注健康评分、群体排名当下预测还能用多久什么时候会失效RUL 回归、失效概率未来诊断和评估都是看当下区别只在前者针对单台定位故障、后者针对群体排出优先级。预测则是唯一看未来的——它要给出一个量化的剩余寿命数字。为什么要强调这个区分因为很多人把做了健康评分等同于做了预测性维护其实没有。评分告诉你这台设备现在状态差但没告诉你它还有多久会彻底失效。前者是状态快照后者是时间外推。维护排程需要的恰恰是后者备件到货要两周那这台设备至少得撑过两周才有意义。本文聚焦的就是第三层——用历史数据训练一个能输出 RUL 的模型并把它接到实时数据流上。二、预测性维护的四段式管线把 RUL 预测拆成工程上可落地的四段后文逐段展开原始时序数据 │ ▼ ① 特征工程 ── 滚动窗口从波形里抽出建模特征时域 频域 │ ▼ ② 标签构造 ── 用已知的故障时间点倒推每条历史样本的 RUL 标签 │ ▼ ③ 模型训练 ── 库内训练回归模型随机森林回归验证泛化能力 │ ▼ ④ 推理打分 ── 批量给历史数据打分 流式给实时数据打分四段里①特征工程和②标签构造是真正的难点。模型选什么反而没那么关键——只要特征干净、标签准确随机森林这种笨模型也能给出可用的 RUL 估计反过来特征噪声大、标签错了再花哨的深度模型也是垃圾进垃圾出。所以下文把篇幅主要给前两段。三、特征工程从原始波形到建模特征3.1 一条原则特征要在设备 时间维度上滚动计算RUL 预测的特征不是单点值而是一段时间窗内的统计特征。设备此刻的健康状态不取决于某一毫秒的振动幅值而取决于过去一段时间的振动趋势、峰值、能量分布。这就要求特征计算必须按设备分组、按时间滚动。DolphinDB 的context by 移动函数天然适合这件事复杂度是增量 O(n)不会随数据量线性变慢。3.2 滚动窗口特征表假设原始振动表已经按八期的方法算出了每秒的振动 RMS有效值现在要在它之上滚动计算建模特征// 基础表每台设备每秒一条 RMS由高频波形聚合而来 // 字段ts, deviceId, rms, temperature, rpm // 滚动窗口特征过去 10 分钟600 秒的统计量 features select deviceId, ts, rms as feat_rms, mavg(rms, 600) as feat_rms_mean, mstd(rms, 600) as feat_rms_std, mmax(rms, 600) as feat_rms_peak, mmin(rms, 600) as feat_rms_min, // 峰值因子 峰值 / 有效值反映冲击性故障 mmax(rms, 600) \ mavg(rms, 600) as feat_crest, // 温度和转速作为工况特征 mavg(temperature, 600) as feat_temp, mavg(rpm, 600) as feat_rpm, // 趋势特征当前 RMS 相对均值的偏离 (rms - mavg(rms, 600)) \ mstd(rms, 600) as feat_zscore from loadTable(dfs://iot_point, vibration_1hz) context by deviceId几个设计要点窗口长度要对齐工况周期。设备一个运行周期可能是几分钟窗口太短抓不到趋势太长又把早期故障信号平滑掉了。10 分钟是个起点具体要结合设备类型调。峰值因子crest factor是好特征。它对早期冲击性故障轴承点蚀、齿轮断齿特别敏感且对转速变化相对稳健是 RUL 建模的常客。z-score 趋势特征捕捉当前值偏离自身常态多远比绝对幅值更能反映退化趋势。3.3 频域特征的接入八期已经讲过怎么用fft算频谱、用imax定位主频。在 RUL 管线里频域特征主频幅值、特定故障频率的能量可以作为补充特征拼进来。关键是频域特征要和时域特征对齐到同一个时间戳上否则标签和特征对不上模型就学乱了。对齐用ajasof join把每秒级时域特征关联上同一时刻最近的频域特征。// 把时域特征和频域特征按时间对齐 model_input select f.deviceId, f.ts, f.feat_rms_mean, f.feat_crest, f.feat_zscore, s.feat_bpfo_energy, s.feat_peak_freq from aj(features as f, freq_features as s, deviceIdts)到这一步每行就是某台设备某个时刻的一组特征可以喂给模型了。但还差一样东西——标签。四、标签构造的艺术倒推 RUL本文核心这是预测性维护工程化里最容易被忽略、又最关键的一步。模型要预测还能用多久可历史数据里的每条记录并没有一个现成的剩余寿命字段。标签得我们自己造。4.1 核心思路从已知的故障时间点往回倒推假设我们从历史记录里知道设备PUMP-007在2026.04.12 03:15:00发生了一次故障停机。那么这台设备在故障前任意时刻t的 RUL就是RUL 故障时刻 - t把这条规则套到整段历史数据上每条特征记录就都带上了 RUL 标签。距离故障越近RUL 越小正常运行早期RUL 很大。用 SQL 实现关键是先把每台设备的故障时刻找出来再 join 回特征表做减法// 第一步找出每台设备最近一次故障或大修的时刻 // statusFAULT 表示故障停机记录 fault_times select deviceId, max(ts) as faultTime from loadTable(dfs://iot_txn, alertTicket) where status FAULT and ts between 2026.01.01 : 2026.06.30 group by deviceId // 第二步把故障时刻 join 回特征表倒推每条样本的 RUL单位小时 labeled select f.deviceId, f.ts, f.feat_rms_mean, f.feat_crest, f.feat_zscore, f.feat_bpfo_energy, f.feat_peak_freq, f.feat_rpm, (g.faultTime - f.ts) \ 3600000 as rul // 毫秒转小时 from model_input as f inner join fault_times as g on f.deviceId g.deviceId where f.ts g.faultTime // 只取故障前的样本到这一步labeled表里每一行就是一个带标签的训练样本特征 RUL。这就是监督学习的输入。4.2 一个坑远端样本的标签噪声直接用故障时刻 - 当前时刻作为 RUL会带来一个隐蔽的问题设备刚投运、状态完全健康时RUL 标签很大比如几千小时但这段时间的特征和健康几乎没区别。模型在这些远端样本上学不到退化信号反而会被大量健康 大 RUL的样本主导导致对临近故障的样本预测不准。工程上常用的处理是分段线性标签piecewise RUL给 RUL 设一个上限超过上限的统统截断。// 分段线性 RUL超过 240 小时的截断为 240 // 含义设备还很健康和还能用 240 小时以上对排程决策没有区别 labeled_capped select deviceId, ts, feat_rms_mean, feat_crest, feat_zscore, feat_bpfo_energy, feat_peak_freq, feat_rpm, iif(rul 240, 240, rul) as rul from labeled这一步看似简单但对模型效果影响很大。截断上限怎么定通常结合业务备件采购周期的 1.5~2 倍是个实用参考——再远的 RUL 对排程没决策价值不如让模型把精力集中在临失效区间。4.3 数据划分按设备切不要按时间切训练 RUL 模型时一个常见错误是按时间随机划分训练集/验证集。这会导致同一台设备的样本同时出现在训练集和验证集里——模型记住了这台设备的个性验证指标虚高换一台没见过的设备就垮。正确做法是按设备划分一部分设备全程数据进训练集另一部分设备全程数据进验证集。这样验证的是模型对没见过设备的泛化能力才是上线后真实面对的场景。// 取一批设备做训练集另一批做验证集按 deviceId 哈希划分 train select * from labeled_capped where hashBucket(deviceId, 100) 70 valid select * from labeled_capped where hashBucket(deviceId, 100) 70五、库内训练随机森林回归 RUL特征和标签都就绪后训练这一步反而简单。DolphinDB 内置了机器学习函数不用把数据导出到 Python 训练再导回模型整个过程在库内闭环。5.1 训练用随机森林回归randomForestRegressor做 RUL 预测。选它的原因对特征量纲不敏感、能处理非线性、可解释性比神经网络好、不易过拟合——对工程落地很友好。// 训练随机森林回归模型 // 输入训练集特征列 RUL 标签列 featCols feat_rms_meanfeat_crestfeat_zscorefeat_bpfo_energyfeat_peak_freqfeat_rpm rulModel randomForestRegressor( ds sqlDS(select * from train), yColName rul, xColNames featCols, numTrees 80, maxDepth 16 )几个工程注意点numTrees和maxDepth不是越大越好。树太多训练慢、收益递减太深容易记住训练集噪声。80 棵树、深度 16 是个保守起点按验证集指标微调。特征列里不要混入 deviceId、ts 这类标识列。它们不是退化特征混进去模型会去记设备编号泛化直接崩。sqlDS把训练集包装成数据源支持分布式训练数据量大时能并行。5.2 验证在验证集上预测看误差。RUL 这种回归问题看平均绝对误差MAE比看均方误差MSE更直观——MAE 的单位就是小时业务能直接理解。// 在验证集上预测 pred predict(rulModel, valid) // 拼回真实标签算 MAE平均绝对误差单位小时 valid_pred select *, pred as rul_pred from valid mae select avg(abs(rul - rul_pred)) as mae_hours from valid_pred比如 MAE 是 18 小时含义是模型预测的剩余寿命平均偏差约 18 小时。这个数能不能用取决于业务对预测精度的容忍度——用于排程参考往往够用用于精确到小时的停机决策则还需要继续调特征和标签。六、推理打分批量 流式训练完的模型要能同时服务两类需求离线回溯给历史数据批量打分分析退化曲线和实时预警新数据一进来就给当前 RUL。6.1 批量打分对任意一段时间的历史特征批量预测画出每台设备的 RUL 退化曲线用于复盘和模型调优// 给 2026 年 3 月的特征批量打 RUL 分 scores select deviceId, ts, rul_pred, // 按预测 RUL 分档 48h 高危 120h 关注其余正常 iif(rul_pred 48, HIGH, iif(rul_pred 120, WATCH, OK)) as risk_level from ( select *, predict(rulModel, model_input) as rul_pred from model_input where ts between 2026.03.01 : 2026.03.31 ) order by deviceId, ts按设备画rul_pred随时间的曲线理想情况下应该看到一条从高位平滑下降、临近故障趋近于 0 的轨迹。如果曲线剧烈抖动说明特征里还有噪声回到第三节调窗口和特征。6.2 流式打分实时场景下新特征一算出来就要立刻得到 RUL。把训练好的模型挂到流计算引擎上即可——离线训练用的特征管道和实时推理用的特征管道是同一套这是管线闭环的核心价值。// 实时特征流由前面的滚动窗口引擎产出每秒一条 share streamTable(1:0, deviceIdtsfeat_rms_meanfeat_crestfeat_zscorefeat_bpfo_energyfeat_peak_freqfeat_rpm, [SYMBOL, DATETIME, DOUBLE, DOUBLE, DOUBLE, DOUBLE, DOUBLE, DOUBLE] ) as featureStream // 输出流实时 RUL 预测 rulOut table(1:0, deviceIdtsrul_predrisk_level, [SYMBOL, DATETIME, DOUBLE, SYMBOL]) // 响应式状态引擎进一条特征出一条 RUL 预测 rulEngine createReactiveStateEngine( name rulPredict, metrics [ predict(rulModel, feat_rms_mean, feat_crest, feat_zscore, feat_bpfo_energy, feat_peak_freq, feat_rpm) as rul_pred, iif(predict(rulModel, feat_rms_mean, feat_crest, feat_zscore, feat_bpfo_energy, feat_peak_freq, feat_rpm) 48, HIGH, WATCH) as risk_level ], dummyTable featureStream, outputTable rulOut, keyColumn deviceId ) // 订阅实时特征流 subscribeTable(tableNamefeatureStream, actionNamerul, handlertableInsert{rulEngine}, msgAsTabletrue)这样实时特征一流入featureStream引擎就立刻输出当前 RUL 预测和风险等级。下游可以把HIGH级别的设备推送给排程系统触发备件预占和维修窗口预约。整条管线的价值就在这里训练时算特征的那套context by mavg/mstd逻辑推理时原封不动地挂在流引擎上跑。没有离线 Python 特征 在线 Java 特征两套要对齐的代码特征定义只有一处不会漂移。七、写在最后预测性维护是工业 IoT 里被谈得很多、做出来却很少的场景。原因不在算法多难而在管线特征怎么滚动算、标签从哪来、模型怎么从离线搬到实时。这三件事每一件单独看都不复杂但要在跨系统的架构里保持一致工程量就会失控。用 DolphinDB 做这件事的价值不是它有个多强的机器学习模型——随机森林回归是很朴素的算法。价值在于整条管线在一个平台里闭环特征用context by滚动算增量更新标签用 SQL 倒推分段截断去噪模型库内训练数据不出库推理把训练时的特征管道直接挂到流引擎离线在线同源回过头看状态维修的三层诊断看当下、评估看群体、预测看未来。前两层解决现在怎么办预测这一层才真正回答接下来怎么办——而接下来怎么办恰恰是运维从成本中心转向价值中心的关键一步。落到工程上记住一点RUL 模型的天花板由标签质量决定不由算法决定。把标签构造倒推 截断 按设备划分做扎实朴素的模型也能给出可排程的预测标签错了再复杂的模型也只是过拟合训练集。