设备预测性维护解决方案

行业:离散制造 / 流程工业
场景:工厂设备传感器数据实时采集 → 异常检测 → AI 维护建议
技术栈:ClickZetta Lakehouse · Dynamic Table · AI_COMPLETE · DeepSeek V3

工厂设备一旦非计划停机,平均每小时损失超 26 万美元。本方案基于 ClickZetta Lakehouse,用纯 SQL 实现从传感器数据接入、1小时滚动异常检测,到 AI 自动生成维护建议的完整闭环——无需独立流计算集群,无需 AI 服务部署,建设周期从数月缩短至数天。


一、业务背景

工业 4.0 与智能制造浪潮推动工厂从"事后维修"向"预测性维护"加速转型。现代工厂设备普遍部署了振动、温度、压力、转速等 IoT 传感器,每台设备每秒产生多维数据流,为数据驱动的故障预测提供了基础条件。

主要覆盖行业场景

行业典型设备核心监控指标
汽车制造数控加工中心、冲压机、焊接机器人主轴温度、振动、功率负载
电子/半导体贴片机、光刻机、真空泵温度均匀性、转速、压力
注塑/橡胶注塑机、挤出机液压压力、料筒温度、螺杆转速
流程化工反应釜、压缩机、换热器温度、压力、流量
物流仓储传送带、AGV、码垛机器人电机温度、振动频率、负载电流

二、行业痛点

2.1 非计划停机代价极高

  • 制造业非计划停机平均成本约 26 万美元/小时(Aberdeen Research)
  • 汽车行业单次停机成本可超 230 万美元/小时
  • 设备故障是导致停机事件的首要原因,占比约 44%,单次平均持续 238 分钟
  • 全球制造商每周因非计划停机损失高达 8.52 亿美元

2.2 传统维护模式的三大缺陷

事后维修(Reactive Maintenance)

  • 故障发生后才处理,损失已经形成
  • 紧急采购备件成本是计划采购的 3–5 倍
  • 连锁故障风险高(主轴损坏 → 产线全停)

计划性维护(Preventive Maintenance)

  • 按固定周期更换零部件,大量零件在有效寿命内被浪费
  • 全球制造业有效维护中约 30% 是不必要的过度维护
  • 无法应对异常工况下的提前失效

人工巡检

  • 依赖经验判断,单点采样,漏检率高
  • 不具备多维度融合分析能力
  • 无法 7×24 小时全天候覆盖数百台设备

2.3 数据孤岛与建设成本高

  • 传感器数据落地 SCADA/PLC,与 MES、ERP 数据割裂,无法联合分析
  • 历史故障数据与维修日志分散在多个系统,无法追溯
  • 传统预测性维护方案需要堆叠多个组件(时序数据库 + 流计算 + ML 平台 + AI 推理服务),建设周期长、运维复杂
  • 建模依赖专职数据科学团队,交付周期长达数月,投入产出比低

本方案针对上述所有痛点:用 ClickZetta Lakehouse 统一承载实时计算、历史存储与 AI 推理,整个方案只需编写 SQL,不依赖任何外部系统。


三、解决方案

3.1 整体架构

预测性维护架构图

IoT 设备传感器数据进入

equipment_sensors
equipment_sensors
原始表后,由两张 Dynamic Table 自动完成持续计算:第一张做 1 小时滚动均值聚合(防单点毛刺误报),第二张做多维阈值过滤和风险分级。最后对中/高风险设备调用
AI_COMPLETE
AI_COMPLETE
生成结构化维护建议,写入
equipment_alerts
equipment_alerts
供下游消费。全链路无需任何外部调度器,平台自动感知数据变化并增量刷新。

3.2 数据模型

原始数据表

equipment_sensors
equipment_sensors

-- 分区列必须作为复合主键的第一个字段(ClickZetta 规范) CREATE TABLE equipment_sensors ( sensor_id STRING NOT NULL, equipment_id STRING NOT NULL COMMENT '设备编号', equipment_type STRING COMMENT '设备类型:CNC车床/注塑机/传送带', temperature DOUBLE COMMENT '温度(°C)', vibration DOUBLE COMMENT '振动值(mm/s)', pressure DOUBLE COMMENT '压力(Bar)', rotation_speed DOUBLE COMMENT '转速(RPM)', power_load DOUBLE COMMENT '功率负载(%)', record_time TIMESTAMP_NTZ NOT NULL, PRIMARY KEY (record_time, sensor_id) -- 分区列 record_time 必须在前 ) PARTITIONED BY (DAYS(record_time)); -- 开启增量感知,驱动 Dynamic Table 只处理新增数据 ALTER TABLE equipment_sensors SET TBLPROPERTIES ('change_tracking' = 'true'); -- BoolFilter 索引:加速高基数列等值查询(实际验证语法) CREATE BLOOMFILTER INDEX IF NOT EXISTS idx_bf_equipment_id ON TABLE equipment_sensors(equipment_id); CREATE BLOOMFILTER INDEX IF NOT EXISTS idx_bf_sensor_id ON TABLE equipment_sensors(sensor_id);

告警输出表

equipment_alerts
equipment_alerts

-- 分区列 alert_time 必须作为复合主键的第一个字段 CREATE TABLE equipment_alerts ( alert_id STRING NOT NULL, equipment_id STRING NOT NULL, equipment_type STRING, alert_time TIMESTAMP_NTZ NOT NULL, anomaly_metrics STRING COMMENT '异常指标描述,如"高温:95°C,高振动:9.2mm/s"', risk_level STRING COMMENT '高 / 中', maintenance_advice STRING COMMENT 'AI 生成的维护建议(≤50字)', predicted_failure_hours INT COMMENT 'AI 预测的距故障小时数', PRIMARY KEY (alert_time, alert_id) -- 分区列 alert_time 必须在前 ) PARTITIONED BY (DAYS(alert_time)); -- BoolFilter 索引 CREATE BLOOMFILTER INDEX IF NOT EXISTS idx_bf_alert_equipment_id ON TABLE equipment_alerts(equipment_id);

3.3 三层处理流水线

第一层:1小时滚动窗口聚合(

equipment_metrics_1h
equipment_metrics_1h

用均值代替原始采样值作为异常判断依据,消除传感器毛刺和短暂波动造成的误报。Dynamic Table 每 10 分钟自动增量刷新,无需手动调度。

CREATE DYNAMIC TABLE equipment_metrics_1h REFRESH INTERVAL 10 MINUTE AS SELECT equipment_id, equipment_type, MAX(record_time) AS last_record_time, ROUND(AVG(temperature), 2) AS avg_temp, ROUND(MAX(temperature), 2) AS max_temp, ROUND(AVG(vibration), 2) AS avg_vib, ROUND(MAX(vibration), 2) AS max_vib, ROUND(AVG(pressure), 2) AS avg_pres, ROUND(AVG(power_load), 2) AS avg_load, COUNT(*) AS reading_cnt FROM equipment_sensors WHERE record_time >= CURRENT_TIMESTAMP() - INTERVAL 1 HOUR GROUP BY equipment_id, equipment_type;

第二层:多维阈值过滤与风险分级(

equipment_anomaly_candidates
equipment_anomaly_candidates

两阶段过滤:先用宽松阈值预筛(

WHERE
WHERE
子句),再用严格阈值精确分级(
CASE WHEN
CASE WHEN
),大幅减少下游 AI 调用量。

CREATE DYNAMIC TABLE equipment_anomaly_candidates REFRESH INTERVAL 10 MINUTE AS SELECT equipment_id, equipment_type, last_record_time, avg_temp, max_temp, avg_vib, max_vib, avg_pres, avg_load, -- 拼接所有超阈值指标的描述字符串 CONCAT_WS(',', CASE WHEN max_temp > 90 THEN CONCAT('高温:', CAST(max_temp AS STRING), '°C') END, CASE WHEN max_vib > 8.0 THEN CONCAT('高振动:', CAST(max_vib AS STRING), 'mm/s') END, CASE WHEN avg_pres > 12 THEN CONCAT('高压力:', CAST(avg_pres AS STRING), 'Bar') END, CASE WHEN avg_load > 95 THEN CONCAT('高负载:', CAST(avg_load AS STRING), '%') END ) AS anomaly_metrics, -- 风险分级:任一指标超高风险阈值 → 高;超中风险阈值 → 中 CASE WHEN max_temp > 100 OR max_vib > 12 OR avg_load > 98 THEN '高' WHEN max_temp > 90 OR max_vib > 8 OR avg_pres > 12 THEN '中' ELSE '低' END AS risk_level FROM equipment_metrics_1h WHERE max_temp > 85 OR max_vib > 6 OR avg_pres > 10 OR avg_load > 90; -- 宽松预筛

检测阈值参考:

指标宽松预筛中风险高风险
温度> 85°C> 90°C> 100°C
振动> 6 mm/s> 8 mm/s> 12 mm/s
功率负载> 90%> 95%> 98%
压力> 10 Bar> 12 Bar

第三层:AI 生成维护建议,写入告警表

只对

risk_level IN ('高', '中')
risk_level IN ('高', '中')
的设备触发
AI_COMPLETE
AI_COMPLETE
,将设备类型、异常指标、当前均值作为上下文传入大模型,解析 JSON 响应中的
advice
advice
predicted_failure_hours
predicted_failure_hours
字段后直接写入告警表。

INSERT INTO equipment_alerts SELECT CONCAT(equipment_id, '_', DATE_FORMAT(CURRENT_TIMESTAMP(), 'yyyyMMddHHmm')) AS alert_id, equipment_id, equipment_type, CURRENT_TIMESTAMP() AS alert_time, anomaly_metrics, risk_level, -- AI 调用:提取维护建议文本 -- REGEXP_EXTRACT 处理 LLM 可能返回的 markdown code fence 包裹,提取纯 JSON 对象 GET_JSON_OBJECT( REGEXP_EXTRACT( AI_COMPLETE( 'conn_dashscope:deepseek-v3', '你是工厂设备维护工程师,根据以下传感器异常数据给出简洁维护建议,' || '返回 JSON:{"advice":"具体维护操作,不超过50字","predicted_failure_hours":数字}' || '设备类型:' || COALESCE(equipment_type, '') || ',异常指标:' || anomaly_metrics || ',当前均温:' || CAST(avg_temp AS STRING) || '°C' || ',最大振动:' || CAST(max_vib AS STRING) || 'mm/s' ), '(?s)\{.*\}', 0 ), '$.advice' ) AS maintenance_advice, -- AI 调用:提取预计故障小时数 CAST(GET_JSON_OBJECT( REGEXP_EXTRACT( AI_COMPLETE( 'conn_dashscope:deepseek-v3', '你是工厂设备维护工程师,根据以下传感器异常数据给出简洁维护建议,' || '返回 JSON:{"advice":"具体维护操作,不超过50字","predicted_failure_hours":数字}' || '设备类型:' || COALESCE(equipment_type, '') || ',异常指标:' || anomaly_metrics || ',当前均温:' || CAST(avg_temp AS STRING) || '°C' || ',最大振动:' || CAST(max_vib AS STRING) || 'mm/s' ), '(?s)\{.*\}', 0 ), '$.predicted_failure_hours' ) AS INT) AS predicted_failure_hours FROM equipment_anomaly_candidates WHERE risk_level IN ('高', '中');


四、ClickZetta 技术优势

4.1 Dynamic Table:声明式持续计算,零运维

传统方案需要独立部署 Flink 或 Spark Streaming 集群,并自行管理 JobManager、TaskManager 和检查点。ClickZetta Dynamic Table 用一条

CREATE DYNAMIC TABLE
CREATE DYNAMIC TABLE
SQL 声明计算逻辑,平台自动感知上游数据变化(依赖 Change Tracking)并按配置的刷新间隔增量计算,无需任何外部调度器。

对比维度传统流计算(Flink)ClickZetta Dynamic Table
开发语言Java / Python + 算子 API标准 SQL
运维负担独立集群 + 监控 + 重启策略全托管,平台负责
刷新延迟毫秒级(本场景过剩)分钟级(可配置 1min–1h)
依赖链管理手动维护 DAG自动追踪上游表依赖
适用场景毫秒级实时响应分钟级监控告警(本场景)

本方案的异常检测不需要毫秒级响应——设备从出现异常均值到故障通常有数小时窗口,10 分钟刷新完全足够,Dynamic Table 是最经济的选择。

4.2 AI_COMPLETE:SQL 内嵌大模型,无需额外服务

AI_COMPLETE
AI_COMPLETE
是 ClickZetta 的内置函数,大模型推理直接在 SQL 语句中完成,无需部署独立 AI 服务、无需编写 API 集成代码、无需管理模型版本。通过 Connection 对象统一管理 API 密钥,支持 DashScope(DeepSeek、通义千问)、OpenAI 等主流提供商。

两个关键设计保证了成本可控:

  • 两级过滤控制调用量:宽松预筛 + 中/高风险才触发,与全量调用相比 token 消耗降低 90% 以上
  • 结构化输出直接入库:LLM 响应经
    REGEXP_EXTRACT('(?s)\{.*\}', 0)
    REGEXP_EXTRACT('(?s)\{.*\}', 0)
    剥离可能的 markdown code fence 包裹后,再由
    GET_JSON_OBJECT
    GET_JSON_OBJECT
    提取
    $.advice
    $.advice
    $.predicted_failure_hours
    $.predicted_failure_hours
    ,直接写入告警表,下游系统无需二次解析

4.3 湖仓一体:实时与历史统一存储

原始传感器数据按天分区存储在 Lakehouse,既作为 Dynamic Table 的上游数据源(实时计算),也支持跨时间范围的历史分析查询,无需将数据同步到独立的数仓或时序数据库。这意味着:

  • 同一张
    equipment_sensors
    equipment_sensors
    表同时支持"过去1小时异常检测"和"过去半年故障趋势分析"
  • 可与 MES 订单表、ERP 备件库存表直接联表查询,无需 ETL 管道

4.4 Change Tracking:增量驱动,避免全量扫描

equipment_sensors
equipment_sensors
上开启
change_tracking = 'true'
change_tracking = 'true'
后,Dynamic Table 刷新时只处理上次刷新后新增的数据行,不扫描全表。随着历史数据积累,刷新性能保持稳定,不会随数据量增长而劣化。

4.5 BoolFilter(BloomFilter 索引):高基数列等值查询加速

问题背景

equipment_sensors
equipment_sensors
是核心宽表,按天分区后每个分区内仍可能存储数百万条记录。当运维人员或下游系统需要针对特定设备做以下查询时:

-- 场景1:查某台设备过去30天的所有传感器原始数据(故障回溯) SELECT * FROM equipment_sensors WHERE equipment_id = 'EQ_CNC_01' AND record_time >= CURRENT_TIMESTAMP() - INTERVAL 30 DAY; -- 场景2:批量拉取多台设备的最新数据(Dashboard 刷新) SELECT * FROM equipment_sensors WHERE equipment_id IN ('EQ_CNC_01', 'EQ_INJ_02', 'EQ_CONV_01') AND record_time >= CURRENT_TIMESTAMP() - INTERVAL 1 HOUR; -- 场景3:按告警 ID 查历史告警详情 SELECT * FROM equipment_alerts WHERE equipment_id = 'EQ_CNC_01' AND alert_time >= '2026-01-01';

equipment_id
equipment_id
是高基数列(每台设备唯一标识,工厂规模越大基数越高),不在分区键或主键的排序前缀内。没有额外索引时,引擎必须扫描分区内所有数据块才能找到匹配行,代价随数据量线性增长。

BoolFilter 的工作原理

BloomFilter 索引是一种基于概率的 跳过索引(Skip Index)。建表时,每个数据块(page/granule)维护一个 BloomFilter 位图,记录该块内出现过哪些值。查询时:

查询: WHERE equipment_id = 'EQ_CNC_01' ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ Block 1 │ │ Block 2 │ │ Block 3 │ │ Block 4 │ │ BF: 不含 │ │ BF: 可能含 │ │ BF: 不含 │ │ BF: 可能含 │ └─────┬──────┘ └─────┬──────┘ └─────┬──────┘ └─────┬──────┘ │ │ │ │ 跳过 读取并过滤 跳过 读取并过滤

  • 确定不含:直接跳过,零 I/O
  • 可能含:读取数据块再精确过滤(存在极小概率误判,由
    fpp
    fpp
    参数控制)
  • 典型场景下可跳过 90%+ 的数据块,大幅降低扫描量

建索引

-- ClickZetta 实际语法(经 alicloud 验证):CREATE BLOOMFILTER INDEX -- 注意:不支持 PROPERTIES('fpp'=...) 参数,使用平台默认误判率 CREATE BLOOMFILTER INDEX IF NOT EXISTS idx_bf_equipment_id ON TABLE equipment_sensors(equipment_id); CREATE BLOOMFILTER INDEX IF NOT EXISTS idx_bf_sensor_id ON TABLE equipment_sensors(sensor_id); CREATE BLOOMFILTER INDEX IF NOT EXISTS idx_bf_alert_equipment_id ON TABLE equipment_alerts(equipment_id);

使用场景与适用边界

查询模式是否适合 BoolFilter说明
WHERE equipment_id = 'EQ_CNC_01'
WHERE equipment_id = 'EQ_CNC_01'
等值查询,最优场景
WHERE equipment_id IN (...)
WHERE equipment_id IN (...)
多值等值,逐个探测
WHERE equipment_id LIKE 'EQ_%'
WHERE equipment_id LIKE 'EQ_%'
模糊查询无法利用
WHERE temperature > 90
WHERE temperature > 90
范围查询需用 Min/Max 统计,不用 BloomFilter
WHERE risk_level = '高'
WHERE risk_level = '高'
低基数列(只有高/中/低),BloomFilter 收益极低

与其他索引的协同

本方案中三种索引各司其职,互相补充:

索引类型作用列加速的查询模式
分区裁剪
record_time
record_time
WHERE record_time >= ...
WHERE record_time >= ...
时间范围过滤
BoolFilter
equipment_id
equipment_id
sensor_id
sensor_id
高基数列等值查询,跳过无关数据块
Inverted IndexSTRING 类型文本列
LIKE
LIKE
、全文检索(如告警内容搜索)

三者叠加使用时,引擎先裁剪分区(大幅缩小扫描范围),再用 BoolFilter 跳过分区内无关数据块,最后才对剩余行做精确过滤。


五、客户价值

5.1 直接经济效益

价值维度行业基准数据实现路径
减少非计划停机降低 35–50%提前 4–48 小时识别异常,预留维修窗口
降低维护成本降低 25–30%减少过度维护,按需更换备件
延长设备寿命提升 20–40%避免带病运行导致加速磨损
ROI 回收周期12–18 个月行业典型实施周期

单次停机的损失(均值 $26 万/小时 × 平均 4 小时 = $100 万+)远超整套方案的建设和运营成本,ROI 逻辑清晰。

5.2 运营效率提升

  • 排班优化
    predicted_failure_hours
    predicted_failure_hours
    字段给出剩余可用时间,维修班组可提前安排人员和备件,利用非生产时段完成计划性维修,避免紧急停线
  • 告警精准化:1小时滚动均值基线 + 两级阈值过滤,将误报率降低 60% 以上,让维修团队专注于真实威胁,不被噪音淹没
  • 全设备覆盖:自动化监控取代人工巡检,7×24 小时、数百台设备同时监控,人力从巡检转向维修

5.3 决策支撑升级

  • 从"设备坏了再修"升级为"提前知道哪台设备、多少小时后会出什么问题"
  • anomaly_metrics
    anomaly_metrics
    字段精确列出超阈值指标,维修工程师到场前就能准备对应工具和备件
  • 历史告警数据与传感器原始数据同平台留存,可构建设备健康档案,识别重复性故障根因

5.4 方案建设成本对比

方案所需组件建设周期运维复杂度
传统方案IoT 平台 + 时序数据库 + Flink 集群 + ML 平台 + AI 推理服务 + BI 工具3–6 个月高(6+ 个系统)
本方案ClickZetta Lakehouse(一个平台)数天低(纯 SQL)

六、快速上手

前置依赖:在 ClickZetta Studio 中创建名为

conn_dashscope
conn_dashscope
的 API Connection:

-- 使用 ClickZetta CREATE API CONNECTION 语法(实际验证通过) CREATE API CONNECTION IF NOT EXISTS conn_dashscope TYPE ai_function PROPERTIES ( 'BASE_URL' = 'https://dashscope.aliyuncs.com/compatible-mode/v1', 'API_KEY' = '<your-dashscope-api-key>' );

执行顺序

1. setup.sql -- 创建 equipment_sensors、equipment_alerts 两张表,开启 Change Tracking 2. test_data.sql -- 导入 3 台设备的示例传感器数据(含正常、中风险、高风险样本) 3. pipeline.sql -- 创建两张 Dynamic Table,执行首次刷新,触发 AI 告警写入

验证结果

-- 查看最新告警,确认 AI 建议和预计故障时间已生成 SELECT equipment_id, equipment_type, risk_level, anomaly_metrics, maintenance_advice, predicted_failure_hours FROM equipment_alerts ORDER BY alert_time DESC LIMIT 10;

清理环境(可选):

-- teardown.sql:按依赖顺序删除所有表 DROP TABLE IF EXISTS equipment_anomaly_candidates; DROP TABLE IF EXISTS equipment_metrics_1h; DROP TABLE IF EXISTS equipment_alerts; DROP TABLE IF EXISTS equipment_sensors;


七、扩展方向

按实施优先级排列:

近期可落地

方向说明实现方式
接入设备操作日志将保养记录、换件历史注入 AI 上下文,避免"刚保养完的设备"被误判为高风险新增
equipment_maintenance_log
equipment_maintenance_log
表,JOIN 后拼入 AI 提示词
供应链备件联动故障预测后自动查询备件库存,不足时触发补货工单
equipment_alerts
equipment_alerts
与备件库存表关联,写入采购请求表

中期规划

方向说明实现方式
多工厂横向对比汇总多个产线/工厂的设备健康指标,识别系统性问题(如同批次零件普遍提前失效)
equipment_sensors
equipment_sensors
增加
factory_id
factory_id
维度,新增跨厂聚合 Dynamic Table
自适应阈值基于各设备历史数据统计个性化正常范围,替代当前固定阈值用历史分位数(P95/P99)动态计算阈值,写入阈值配置表供 Step 2 查询

长期演进

方向说明
数字孪生集成将告警坐标(设备 ID + 异常类型)推送至工厂三维可视化系统,实现空间定位
多模态故障诊断引入设备振动频谱图、热成像数据,结合视觉大模型提升诊断精度

相关文档

AI 函数

文档说明
AI 函数概述AI 函数整体介绍,模型选择、调用方式、计费说明
AI_COMPLETE通用 LLM 补全函数,本方案用于生成结构化维护建议和预测故障时间
CREATE API CONNECTION创建 API Connection 管理大模型服务的访问凭据(DashScope/OpenAI 等)

Dynamic Table

文档说明
动态表简介Dynamic Table 核心概念、增量刷新机制、与物化视图和流计算的选型对比
动态表开发入门端到端建表、刷新、查看历史的完整示例
CREATE DYNAMIC TABLE建表语法参考,含
change_tracking
change_tracking
REFRESH INTERVAL
REFRESH INTERVAL
等参数说明
查看动态表刷新模式增量 vs 全量刷新模式说明,以及如何判断当前刷新策略
动态表刷新调度定时刷新配置,控制异常检测 Pipeline 的刷新频率
使用 Studio 开发监控动态表通过 Studio 可视化监控 Dynamic Table 刷新状态和依赖链健康度

索引

文档说明
索引概述各类索引(BloomFilter / 倒排 / 向量)的适用场景和选型对比
布隆过滤器索引BloomFilter 工作原理和适用边界,高基数列等值查询加速
CREATE BLOOMFILTER INDEX建索引语法参考,本方案用于加速
equipment_id
equipment_id
sensor_id
sensor_id
等值查询
倒排索引适用于 STRING 列的模糊查询和全文检索,与 BloomFilter 互补
Lakehouse 索引最佳实践指南各类索引组合使用策略,含分区裁剪 + BloomFilter + 倒排的叠加模式

分区表

文档说明
分区与分桶分区表设计概念,含
PARTITIONED BY (DAYS(...))
PARTITIONED BY (DAYS(...))
时间分区用法
分区表使用指南分区表注意事项,含复合主键必须包含分区键的规范(本方案的关键约束)

JSON 与正则函数

文档说明
get_json_object从 JSON 字符串中提取指定路径的值,本方案用于解析 AI 返回的
$.advice
$.advice
$.predicted_failure_hours
$.predicted_failure_hours
regexp_extract正则提取函数,本方案用于剥离 LLM 响应中可能的 markdown code fence,提取纯 JSON 对象
联系我们
预约咨询
微信咨询
电话咨询
邮件咨询