前两年接手了一个燃气场站的泄漏监控改造项目现场的情况估计不少人见过每个调压柜里挂一个可燃气体报警器浓度就地显示超标了就地闪灯响铃值班员听到声音再挨个柜子排查。点位少还能应付点位一多、数据要追溯、误报要分析的时候这套老办法根本顶不住。后来我把整个系统重写成了一个基于大数据的泄漏仪设备监控系统把设备接入、数据清洗、实时告警、可视化大屏和离线分析一整套链路全部跑通。这篇就把做这个系统时的架构思路、关键细节和实际踩过的坑整理出来给正在做工业物联网监控、大数据方向毕业设计或者正准备上工厂数采平台的朋友参考。这个项目表面看是“监控系统”本质其实是一条完整的数据工程链路从泄漏仪采集端到传输网关再到Kafka、Spark、Hive这些大数据组件最后落到告警和可视化。围绕“大数据”这三个字的核心命题是怎么高效接收、可靠存储、及时分析和准确研判海量监测点位的浓度数据。下面按照从思路到落地的顺序来讲内容偏工程实践会给出大量可以直接抄作业的配置和代码。1. 这个系统到底在解决什么问题1.1 传统泄漏监控模式的痛点传统泄漏仪监控最常见的问题是“数据孤岛”。绝大多数可燃气体报警器、有毒气体检测仪都只做就地显示设备本身有自己的蜂鸣器和指示灯可以联动风机、切断阀但它的历史和实时数据基本是封闭的。很多厂子里的报警器装了十几年除了每年年检时校验一下平时根本没有人系统地看过这些数据。一旦一个区域有多台设备问题就来了某个点半夜报警了值班员只能先看是哪台设备在叫再跑到现场确认定位时间完全靠人。报警原因没法回溯。究竟是瞬时波动、真泄漏还是传感器老化翻记录本根本说不清。多个点位之间的关联关系完全丢失。某区域几个点位同时缓慢上升时单台设备可能都还没到报警阈值但“整个区域都在异常”这个信号人很难及时捕捉。把泄漏仪数据接入大数据平台之后情况就完全不一样了。每一个点位每一个秒级的浓度变化都可以被保存、分析和关联不仅能做实时告警还能做趋势预判和点位联动分析。这才是“监控”这两个字该有的完整含义。1.2 大数据能够带来的实际变化很多人觉得监控系统用一台关系型数据库加一个Web页面也就够了为什么非要扯上大数据这里要区分场景。如果只是三五十个点位一分钟采一个数MySQL确实没问题。但真正到工业现场设备数量很容易突破几百台采集频率高起来之后每秒就是几百几千条数据日积月累是亿级规模关系型数据库在写入压力、存储成本和查询性能上都会逐渐吃力。大数据组件在这个场景里的角色是明确的Kafka负责接入缓冲。现场设备数据是持续涌进的处理程序可能重启、可能阻塞数据不能丢Kafka像一个蓄水池把峰值流量先接住。HDFSHive负责长时间留存和海量历史统计。按天分区之后一年甚至几年的历史数据都能低成本保存下来。Spark负责实时清洗和离线计算对流式数据做降噪、校正、阈值判定再对离线数据做关联统计。Redis这类组件负责状态缓存点位最新值、告警状态这些高频读写的场景用关系型数据库反而别扭。最终呈现的效果就是从秒级实时曲线到按天的泄漏统计报表再到跨一整年的趋势对比各个时间维度都能支持而不是“当下看一眼”。1.3 系统边界与适用场景这套系统适合的场景包括燃气调压站、化工装置区、加油站、加气站、污水处理厂厌氧区域、实验室气瓶间等需要大量可燃或有毒气体监测的场所。具体到可复制的功能清单大致可以分成五块数据采集支持Modbus RTU/TCP、MQTT等协议接入适配市面主流泄漏仪。数据存储与治理原始数据全量入湖清洗规则处理超量程、卡滞、跳变等脏数据。实时告警支持分级阈值的即时预警配合变化率、联动分析降低误报。可视化实时曲线、点位仪表盘、GIS分布、历史报表。系统运维设备离线监测、心跳管理、通道质量评估。2. 整体架构设计从传感器到监控大屏2.1 感知层泄漏仪的选型与信号读出泄漏仪本身的选型直接决定了后面数据的质量和可信度。工程上最常用的传感器类型有几种我整理了一个对照方便做方案时快速判断传感器类型适用场景典型量程特点催化燃烧式可燃气体LEL检测0-100%LEL便宜技术成熟怕中毒硅、硫化物会钝化电化学式有毒气体CO、H2S、NH3、Cl2等ppm级精度高寿命约2-3年温度漂移需补偿红外式(NDIR)甲烷、二氧化碳等高浓度场景0-100%VOL抗中毒维护量小适合长期在线激光式(TDLAS)甲烷微量泄漏、长距离检测ppb-ppm级响应快、精度高价格贵适合重点区域信号读出方式是另一个关键点。现场泄漏仪常见输出有4-20mA模拟量、RS485 Modbus RTU、无线LoRa/NB-IoT几种。老设备大多是4-20mA需要经过AI采集模块转成数字量再进网关。Modbus RTU是现在的主流能直接读到浓度值和设备状态寄存器一台上位机可以轮询多台设备。无线方案适合布线困难的露天管廊、罐区等场景但要注意电池供电和信号遮挡问题。选型上我的原则是重要防护区肯定选带数字通讯功能的设备不要省那点差价去买只有模拟量输出的老型号。Modbus设备维护和调试都方便寄存器地址表还支持远程配置量程等参数后期做平台化接入省事很多。2.2 传输与接入层网关、协议与通道选择传感器信号要上平台中间必须有网关设备。现场最常见的方案是工业协议网关或DTU一个网关通过RS485总线挂十几台泄漏仪网关再通过以太网、4G或5G上行到服务器。这里有个关键的工程折中Modbus轮询频率决定了数据分辨率。比如一条RS485总线上挂了十几台设备每台设备读两个寄存器指令一个轮询周期可能要3到5秒。如果要求每台设备的秒级数据就得让网关的采集命令排队更紧凑或者增加采集模块和总线数量。设计采集频率时先估算总线的最大报文数量和响应时间再定采集任务周期不要一上来就盲目设1秒。协议层面上网关到平台部分我推荐统一转成MQTT或直接生成JSON推送到Kafka。MQTT的好处是主题清晰、轻量、支持断线重连平台侧订阅主题即可获取数据。如果网关本身支持Kafka SDK也可以直接推Kafka少一跳开销。但现场很多第三方网关只支持HTTP上报或者MQTT所以平台侧做一个统一的协议接入服务是必要的我在实际项目中是用一个轻量的Kafka Connect或自写消费者去握手这些异构数据源。2.3 存储与计算层大数据组件选型背后的考量存储计算层的选型要先想清楚一个事情数据进来之后哪些是要实时响应的哪些是要长期留存统计的。这两类数据的处理路径不同混在一套组件里一定会出问题。我自己落地的方案是双链路实时链路设备数据 → Kafka → Spark Structured Streaming → 清洗逻辑 → Redis(状态缓存) MySQL(告警记录) 可视化接口。这条链路解决“现在发生了什么”的问题延迟控制在秒级。离线链路Kafka原始数据 → 每小时/每天由Spark批作业拉取经过清洗后写入Hive分区表 → 用SQL做多维统计。这条链路解决“历史上发生了什么”的问题。组件选型的理由要摆出来。为什么用Kafka做缓冲因为采集端是不稳定的现场网络抖动、设备断电都会导致数据突变如果后端处理服务直接连接采集端任何一个环节重启都可能造成数据丢失。Kafka一放生产和消费就解耦了。为什么用Spark而不是Flink对大多数泄漏监控场景秒级处理延迟已经完全够用Spark生态熟悉、能和Hive无缝衔接团队上手快维护成本低。如果项目对毫秒级延迟和复杂事件处理有硬性要求再考虑Flink不迟。存储上HDFS只做原始数据的持久化底座真正的数据表都在Hive里。分区策略按日期加小时两级分区dt2025-01-15/hr14这样兼顾查询裁剪和文件规模。性能优化主要体现在文件格式能用ORC绝不用纯文本加上列式存储和轻量压缩存储空间能省一半以上。2.4 应用层可视化、告警与外联应用层是直接给厂里的值班员、安全员用的交互和展示逻辑要聚焦几个简单场景当前浓度是多少、过去几小时变化趋势、有没有报警、报警怎么处置。后端我选Flask或FastAPI原因是和大数据组件衔接顺手写REST API快团队里的Python技术栈能统一。前端展示用ECharts足够实现实时曲线、仪表盘、点位分布图都不费劲。大屏页面除了折线图和仪表盘一定要做一个“点位状态总览”的表格视图按点位列出当前值、所属区域、状态正常/预警/报警/离线值班员扫一眼就能定位问题点。告警闭环要做“通知”和“处置”的配合。系统产出告警之后通过短信、钉钉或企业微信机器人推送到责任人同时在Web页面生成一个待处理事项。值班员确认“收到”、填写现场处置结果后告警关闭。这一步看起来很基础但很多监控项目都忽略了导致告警发出去了有没有人管完全不知道这是管理闭环的硬伤。3. 核心数据处理链路与泄漏判定模型3.1 数据接入与全流程流转一条完整的数据链路是这样的泄漏仪 → 网关轮询采集 → Modbus寄存器解析 → 网关以JSON格式上报 → Kafka Topic → Spark流式消费清洗 → 写入Redis最新值 → 按规则判断告警 → 写MySQL告警表 → 前端轮询/推送 → Web大屏这里的几个环节生产环境中每一步都容易出幺蛾子。Modbus解析时每个厂家设备寄存器地址都不一样有的浓度值在0x0001有的在高位字和低位字需要字节序调换我见过数据平台上显示一千多ppm的“怪数据”排查下来实际上值是正常二十几就是字节序读反了。所以接入阶段一定要保留一张“设备寄存器映射表”每个型号的设备单独维护配置不要试图用一个模板覆盖所有设备。另外网关的时钟也是一个隐患。很多网关没有接NTP跑几天之后系统时间能差好几秒。数据的ts字段如果用了网关本地时间而采集轮询和平台处理时间混在一起后面做时间窗口统计会出现“数据错位”。规范做法是保留仪器原始时间戳但平台统一以网关到达时间为准生成统一的平台事件时间分析只用平台时间原始时间仅作为设备追溯参考。3.2 数据清洗规则让数据先“变干净”不管是实时告警还是离线统计脏数据的危害都很大。一个跳变的异常值可能直接触发一次误报警一个卡滞的传感器可能导致真实泄漏被淹没在“固定值”里。我在项目里总结了一套三级清洗规则每一条都可以写成独立的判断函数第一级是物理合法性检查。值是否为null、是否为负数、是否超过传感器量程上限。这些是最底层、最不可能“误杀”的规则直接丢弃。第二级是传感器状态检查。连续N条数据完全相同且变化量为零说明传感器可能卡滞或信号断线。这里不能一刀切因为气体浓度确实可能在稳定状态下长时间保持不变。我的经验是配合“分辨率”判断如果连续20条采样值都没有超过传感器的最小分辨率变化就标记为可疑状态并不直接丢弃只是从实时告警计算里降权。第三级是统计学异常检查。对每个点位维护一个滑动窗口比如最近30条数据计算均值和标准差。新来数据如果偏离均值超过3倍标准差会被标记为“异常峰”进入人工确认队列而不是直接告警。这套规则的好处是普适性强不需要针对每个点位单独调阈值。三级清洗规则的执行顺序也有讲究先做物理合法性再做设备状态最后做统计异常。前两级不通过的数据直接不入库第三级标记的数据照常入库但打上标志位方便后面回溯。3.3 泄漏判定从单点阈值到多点联动泄漏判定是监控系统的灵魂规则设计要既灵敏又尽量减少误报。单点阈值是最基础的方式可燃气体一般设置两个级别预警阈值25%LEL。达到这个级别需要确认现场情况但不强制立即疏散。报警阈值50%LEL。必须联动启动风机、切断阀门人员紧急撤离。这里有一个非常容易踩的坑阈值回差。如果只设一个报警值浓度在48%和52%之间反复横跳告警会像抽风一样反复触发和恢复。必须设置迟滞区间比如恢复值低于触发值5个点。这也叫“回差保护”在仪表控制里很常见但在软件逻辑里经常被忽略。变化率判定也很关键。一个点位浓度在几秒内从正常值跳到20%LEL这基本不会是慢泄漏而是突发泄漏或者传感器故障。我建议实时计算相邻两次数据的差值和滑动窗口内的平均变化速度如果每分钟上升幅度超过阈值比如5%LEL/min生成“突发泄漏”的高优先级告警不等浓度阈值到了再发。多点联动规则是我在整个系统里最看重的一块。设泄漏源周围的多个点位在相近时间窗内都出现浓度抬升即使单点都没有到预警值也应该生成区域预警。比如在同一个区域ID下5分钟内如果有3个及以上点位同时出现超过自身基准值50%以上的上升判为区域异常。这个判断在Spark流式任务里实现起来不复杂对区域内的点位做时间窗口分组聚合就行但它能提前识别很多单点看不出来的风险。4. 实操过程从零搭建一个可运行的监控系统4.1 环境准备与组件部署下面给出一套可以在开发环境复现的完整方案不用真实设备也能跑通全链路。硬件层面用三台虚拟机或者一台12核以上、内存32G的服务器都够用。软件组件包括Hadoop 3.xHDFS、Hive 3.x、Kafka 2.8、Spark 3.x、MySQL 8.0、Redis、Python 3.8。如果只是想快速验证流程Hadoop、Hive、Spark可以用Docker部署Kafka和Zookeeper也都有现成镜像。注意几个部署细节Kafka的advertised.listeners一定要配置成外部可访问的主机IP否则客户端连不上。Hive需要先初始化Schema执行schematool -initSchema -dbType mysql。Spark任务如果跑YARN模式客户端机器要有Hadoop配置文件和对应的权限。4.2 模拟泄漏仪数据源与Kafka接入没有真实泄漏仪也不影响开发写一个Python脚本模拟产生数据就行。这段时间我习惯模拟三类场景正常波动、缓慢上升、短时跳变这样才能测试后面的清洗和告警逻辑。import time import json import random from kafka import KafkaProducer producer KafkaProducer( bootstrap_serverslocalhost:9092, value_serializerlambda v: json.dumps(v, ensure_asciiFalse).encode(utf-8), ) devices [ {id: PT-101, base: 2.0}, {id: PT-102, base: 3.5}, {id: PT-103, base: 1.0}, ] while True: ts int(time.time() * 1000) for dev in devices: value round(random.uniform(dev[base] - 0.5, dev[base] 0.5), 2) rnd random.random() if rnd 0.002: # 模拟突发泄漏直接跳到高值 value round(random.uniform(20, 40), 2) elif rnd 0.01: # 模拟慢上升趋势 value round(dev[base] random.uniform(5, 15), 2) record { ts: ts, deviceId: dev[id], value: value, unit: %LEL, } producer.send(leak_raw, keydev[id].encode(utf-8), valuerecord) time.sleep(1)Kafka里创建topickafka-topics.sh --bootstrap-server localhost:9092 \ --create --topic leak_raw --partitions 3 --replication-factor 1分区数设成3主要考虑下游Spark任务的并行度。如果之后需要扩大吞吐分区数要提前想好Kafka分区数在创建后可以增加但会增加管理复杂度。4.3 Spark实时清洗与告警计算Spark Structured Streaming读取Kafka数据做实时清洗这是整个链路里最核心的一段。from pyspark.sql import SparkSession from pyspark.sql.functions import from_json, col, window from pyspark.sql.types import StructType, StructField, StringType, LongType, DoubleType spark SparkSession.builder \ .appName(leak_etl) \ .master(yarn) \ .config(spark.sql.shuffle.partitions, 6) \ .getOrCreate() schema StructType([ StructField(ts, LongType(), True), StructField(deviceId, StringType(), True), StructField(value, DoubleType(), True), StructField(unit, StringType(), True), ]) df spark.readStream \ .format(kafka) \ .option(kafka.bootstrap.servers, node01:9092,node02:9092,node03:9092) \ .option(subscribe, leak_raw) \ .option(startingOffsets, latest) \ .load() \ .selectExpr(CAST(value AS STRING) AS json_str) \ .select(from_json(col(json_str), schema).alias(data)) \ .select(data.ts, data.deviceId, data.value, data.unit) # 清洗第一层物理合法性 df_clean df.filter( col(value).isNotNull() (col(value) 0) (col(value) 100) ) # 清洗第二层卡滞判断对每个设备连续3条数据差值做检查 from pyspark.sql.window import Window from pyspark.sql.functions import lag, abs, count window_spec Window.partitionBy(deviceId).orderBy(ts) df_lag df_clean \ .withColumn(prev_value, lag(value, 1).over(window_spec)) \ .withColumn(diff, abs(col(value) - col(prev_value))) df_mark df_lag.withColumn( is_suspect, col(diff) 0.01 ) # 告警判定超过25%LEL且非可疑状态 df_alarm df_mark.filter( (col(value) 25) (col(is_suspect) False) ) query df_alarm.writeStream \ .foreachBatch(write_alarm_to_mysql) \ .outputMode(update) \ .start()这里要说明几个配置关键点startingOffsets如果设成latest作业重启后会跳过重启期间的数据如果要保证不丢应该用earliest或者记录offsets。foreachBatch是Structured Streaming里很实用的模式可以在每个微批次里复用已有的MySQL写入逻辑也能对批次内的数据做去重。卡滞判断那里注意lag函数依赖窗口内数据的顺序如果Kafka分区乱了顺序会导致判断失真。真实项目里我通常会按设备ID单独写一个带状态的自定义聚合性能更好代码量也更多但这里为了展示简洁用了窗口函数。4.4 Hive离线存储与数据分区实时链路处理完之后原始和清洗后的数据还需要落到Hive里做长期统计。考虑到流式写Hive会产生海量小文件的问题我的做法是用一个单独的Spark批处理作业每小时调度一次拉取上一小时的Kafka数据清洗后写入Hive按天和小时分区的ORC表。建表语句CREATE EXTERNAL TABLE IF NOT EXISTS dwd_leak_point ( ts BIGINT, device_id STRING, value DOUBLE, unit STRING ) PARTITIONED BY (dt STRING, hr STRING) STORED AS ORC LOCATION /warehouse/dwd_leak_point;写入的时候把ts转成对应的dt和hrfrom pyspark.sql.functions import from_unixtime, col df_with_partition df_clean \ .withColumn(dt, from_unixtime(col(ts) / 1000, yyyy-MM-dd)) \ .withColumn(hr, from_unixtime(col(ts) / 1000, HH)) df_with_partition.write \ .mode(overwrite) \ .partitionBy(dt, hr) \ .format(orc) \ .saveAsTable(dwd_leak_point)分区策略选择小时而不是分钟是因为分钟级分区会产生大量小目录导致NameNode内存压力和维护成本飙升。一天最多24个分区兼顾查询裁剪和文件规模。4.5 Flask API与ECharts可视化后端接口用Flask来实现。三个核心接口分别服务不同的页面组件当前值接口返回所有点位实时值、状态、区域供大屏总览。历史曲线接口按设备ID和时间范围查询Hive或MySQL返回趋势数据。告警接口返回最近告警记录和处置状态。from flask import Flask, jsonify, request import pymysql import redis app Flask(__name__) r redis.Redis(hostlocalhost, port6379, decode_responsesTrue) app.route(/api/current) def current(): # 从Redis获取每个点位的最新值和告警状态 data [] device_ids [PT-101, PT-102, PT-103] for dev_id in device_ids: value r.get(flatest:{dev_id}) status r.get(falarm:{dev_id}) or normal data.append({deviceId: dev_id, value: value, status: status}) return jsonify(data) app.route(/api/history) def history(): device_id request.args.get(deviceId) hours int(request.args.get(hours, 24)) conn pymysql.connect(hostlocalhost, userroot, passwordxxxx, dbleak_db) cursor conn.cursor() start_ts int(time.time()) - hours * 3600 cursor.execute(SELECT ts, value FROM leak_history WHERE device_id%s AND ts%s ORDER BY ts, (device_id, start_ts)) rows cursor.fetchall() cursor.close() conn.close() return jsonify([{ts: r[0], value: r[1]} for r in rows]) if __name__ __main__: app.run(host0.0.0.0, port5000)前端用ECharts画实时曲线配置上注意平滑曲线别过度ele曲线数据点直接在setOption时更新一条最近窗口的数组即可不必全量刷新。大屏场景建议用animationfalse避免高频更新时图表卡顿。4.6 告警通知闭环告警判定完成之后只写MySQL还不够。我在生产中增加了一步将告警明细推送到Redis队列由单独的通知Worker消费负责调用钉钉机器人、短信接口或企业微信。这样做的原因是告警服务和通知服务相互独立即使通知服务挂掉告警记录也不会丢恢复后可以继续消费。钉钉机器人通知的关键实现很简洁import requests import json def send_dingtalk_alert(message): webhook https://oapi.dingtalk.com/robot/send?access_tokenxxxx payload { msgtype: text, text: {content: message} } requests.post(webhook, jsonpayload, timeout5)通知内容至少包括点位编号、当前浓度、触发阈值、时间、所属区域。如果可以加一条“建议动作”比直接甩一个数字对值班员友好得多。5. 实施中踩过的坑与排查实录5.1 数据漂移与时钟问题第一次联调时发现一条明确的泄漏上升曲线在可视化大屏上竟然是“波浪形”的一会儿高一会儿低。排查半天发现不是数据错了而是多个网关的时钟不同步峰谷的时间戳互相错位Spark窗口聚合把不同发生时刻的数据算在了一起。解决方案前面已经说了平台统一以网关注入时间为准其他原始时间戳仅供追溯。还有一次是NTP没生效网关重启之后时钟归零导致数据全都堆积在1970年直接把当天所有告警统计打挂了。从那以后我把网关时钟校验加入了自己的运维巡检脚本。5.2 传感器脏数据与误报处理现场最折腾人的不是大数据框架而是传感器本身。有一组点位的数值一天之内剧烈跳动了七千多次查到最后是接线端子氧化造成接触不良。另一个点位连续两周输出固定值看起来一切正常实际上传感器元件已经失效真实泄漏根本不会被捕捉到。这两类问题在数据侧的表现就是“跳变”和“卡滞”靠前面说的清洗规则能筛掉大部分但根源还是需要现场排查硬件。我的经验是平台一定要有“数据质量视图”能展示每个点位的波动次数、离线时长、卡滞标记运维人员才能有方向地去现场处理硬件问题。5.3 告警风暴与处置机制告警风暴这个问题几乎所有监控系统都会遇到。规则设置得太灵敏一个区域的设备会像点鞭炮一样连续告警值班手机半夜响个不停第二天全部被当成噪音拉黑。解决方法是多管齐下对同一设备的同一级别告警做合并进入告警后短时间内重复触发只更新确认次数不新增记录。增加迟滞窗口和恢复确认浓度回落后要持续正常一段时间才解除告警。同一区域多点联动告警总结成“区域告警”而不是逐台设备刷屏。5.4 常见问题速查表现象可能原因处理办法平台收不到某个点位数据网关掉线、串口故障、设备断电检查网关心跳每个点位维护最近活跃时间并生成离线告警数值明显偏大/偏小寄存器双字序读反、量程配置错误核对设备寄存器映射表用已知浓度做对比校准告警迟迟不触发清洗规则误判真实值被当成脏数据丢弃查看清洗日志将对应规则加白名单或调整阈值告警频繁触发传感器老化漂移、阈值无回差、环境干扰校验设备、增加迟滞区间、提高统计学异常门槛曲线有断点Kafka积压、Spark重启跳过了窗口调整消费并行度检查offsets消费模式避免latest跳数据Hive查询慢分区不生效、ORC压缩配置不对检查分区裁剪开启Hive向量化查询和ORC谓词下推这些排查经验都是直接从现场问题里提炼的建议把这一页打印出来贴在机房里比任何操作手册都好用。6. 这套系统还能往哪个方向扩展系统跑稳定之后可以往三个方向演进。一个是预测性维护利用历史浓度数据和时间序列模型尝试预判传感器寿命和泄漏趋势。简单做法是对上升段数据做线性拟合外推估算多久会达到预警值为处置争取时间。另一个方向是设备管理深度融合把泄漏仪的校准记录、年检到期提醒、维修工单全部纳入平台让数据平台直接支撑设备全生命周期管理。第三个方向是和现有DCS/PLC系统打通告警不只是通知人而是自动触发联锁逻辑比如关闭泄漏源阀门、启动强排风机形成自动处置闭环。我认为这里面最有实际价值的是预测方向因为监控系统从“事后通知”升级为“事前预警”价值有一个量级的提升。比如管线法兰微漏浓度可能在几个小时内从2%LEL缓慢爬到23%LEL如果靠阈值告警人到场时泄漏已经在发展中了。但按趋势外推在浓度5%LEL的时候就能估算出后续走向留给人工介入的时间窗口宽敞得多。在做这个功能时需要注意训练数据里正常波动和真实泄漏趋势的区分否则预测模型反而会带来大量误报。最后说点个人体会。做这类系统到最后难点很少在算法大量精力都花在脏数据识别、告警准召率和现场设备状态管理上。报警这件事宁可信噪比高一点也不要天天误报“狼来了”喊多了真正泄漏的时候反而没人当回事。我在项目里的原则是先把数据链路修到一条数据都不丢、不重、不错位再谈怎么分析和展示。链路可靠了上面的预测模型、联动规则才有立足之地。这个顺序建议所有准备动手做类似监控项目的团队都认真遵守。