2019年凉山木里森林火灾，30名扑火人员牺牲。2020年凉山西昌森林火灾，19名扑火人员牺牲。两次惨痛的教训之后，全国森林防火监测系统建设进入了快车道。
但系统建了，效果如何？
我去过四川某个重点林区的防火指挥中心。一整面墙的大屏，左边是气象站数据，中间是视频监控画面，右边是烟感探测器状态。看着挺气派。但指挥中心的人告诉我："这些数据是三个不同供应商做的，互相不通。看气象数据要到左边电脑，看视频要到中间电脑，烟感告警在右边电脑。三个屏幕三个系统，出了事得三个一起看。"
2024年了，这种数据割裂的局面在很多地方仍然存在。森林防火需要多源数据融合——气象、烟感、红外、视频——但这几个数据源天然由不同设备产生，走不同协议，存在不同系统里。融合不起来，预警就只能靠单一数据源判断，漏报和误报都多。
森林防火的数据全景
森林防火监测涉及的数据源比很多人了解的要多。
数据来源 | 设备类型 | 核心参数 | 采样频率 | 典型数量 |
气象站 | 自动气象站 | 温度/湿度/风速/风向/降雨量 | 1-10分钟 | 10-30 |
红外热成像 | 红外摄像头 | 地表温度/温差/热异常区域 | 1-5分钟 | 5-20 |
烟感探测器 | 烟雾传感器 | 烟雾浓度/粒子数 | 10-30秒 | 100-500 |
视频分析 | 高清摄像头+AI | 烟雾识别/火焰识别 | 实时/触发 | 10-40 |
闪电定位 | 雷电探测仪 | 雷电位置/强度/时间 | 事件触发 | 1-5(区域级) |
土壤温湿度 | 土壤传感器 | 土壤含水量/温度 | 10-60分钟 | 20-80 |
可燃物含水率 | 称重式传感器 | 含水率 | 1-6小时 | 10-30 |
一个重点林区（面积约10万公顷）的防火监测系统，各类传感器加起来通常在200-700个点位之间。数据量级不算特别大——气象站每分钟一次，烟感每30秒一次，全部加起来每天几十万到一两百万条。
但森林防火对数据的实时性要求极高。火情从萌芽到不可控可能只有几十分钟到几小时。这段时间里数据每多延迟一分钟，扑救难度就上升一个台阶。
预警为什么滞后
传统监测系统的预警滞后，原因不在传感器——传感器够灵敏。原因在数据链路。
数据不融合。 这是最大的问题。气象站的温湿度数据可以判断火险等级——温度高、湿度低、风大=高火险。但高火险不等于有火。烟感探测器可以检测到烟雾——但烟感可能因为农业烧荒或者工业排放误报。视频AI可以识别烟雾和火焰——但视频AI的准确率受光线、雾气、距离影响。
每个数据源单独判断都有局限。只有多源数据融合才能提高预警准确率——烟感报警+气象高火险+视频识别烟雾=极大概率真火情，可以立即启动响应。
但三个数据源在三个系统里。融合靠人工在指挥中心同时看三个屏幕——反应慢不说，人还容易疏漏。
数据传输延迟。 林区偏远，通信条件差。很多监测点靠4G或者北斗短报文传数据，信号不好的时候数据会积压。一个30秒采样的烟感传感器，如果数据传输延迟5分钟，发现烟到告警到手可能已经过了5-10分钟。在森林火灾中，5分钟可以让火星变成明火。
历史数据无法做趋势分析。 火险等级评估不只是看当前温湿度，还要看趋势——连续几天的高温低湿使可燃物含水率持续下降，累积到一定程度就是极高火险。这个趋势分析需要至少一周到一个月的连续气象数据。很多系统只存近期数据，做不了累积趋势分析。
时序数据库怎么解决融合问题
时序数据库在森林防火场景中解决的核心问题不是"存得多"——数据量不大。解决的是"融合得起来"和"响应得够快"。
多源数据统一存储。 TDengine可以把气象站数据、烟感数据、红外数据、视频分析结果数据统一存储在同一个数据库实例中。不同类型的数据用不同的超级表，通过标签标注所属区域、设备编号、GPS坐标。做跨数据源融合查询时，"某区域当前气象参数+烟感状态+红外温度异常+视频分析结果"一条SQL拿到，不需要跨系统。
数据订阅实时告警。 烟感探测器的数据写入TDengine后，可以通过数据订阅机制实时推送给告警分析模块。告警分析模块同时获取气象数据流和视频分析结果流，做融合判断。多源数据融合判断在秒级完成，而不是等人工在三个屏幕之间切换。
连续查询做趋势分析。 配置连续查询每小时计算一次各气象站24小时温湿度均值和变化趋势，写入趋势结果表。火险等级评估模型直接从趋势表取数据做判断。可燃物含水率的累积变化趋势也在连续查询里自动计算。
标签模型适配多区域。 林区按行政区域或者山系分片区管理。每个传感器通过标签标注所属片区，查"大凉山东坡片区所有气象站过去一周的温湿度趋势"直接通过标签过滤命中。
火险等级评估
这是数据融合的核心应用。火险等级评估不是看单一参数，是多参数综合评分。
国家标准《全国森林火险等级》（LY/T 1172）定义了五级火险：I级（无危险）到V级（极度危险）。评估参数包括：气温、相对湿度、风速、连续无雨日数、可燃物含水率。
传统做法是人工查表——看当前气象数据，对照标准里的阈值，确定火险等级。这个做法的局限是只能看当前值，不能看趋势。而且可燃物含水率如果没有在线监测数据，只能靠经验估算。
用TDengine存了所有气象站和可燃物含水率传感器的长期数据后，火险等级评估可以做到：
- 实时评估——每分钟自动计算各片区当前火险等级
- 趋势预测——基于过去7天温湿度变化趋势和天气预报数据，预测未来24-48小时火险等级变化
- 可燃物状态评估——通过实际传感器数据计算可燃物含水率，而不是经验估算
某省级林业部门的防火指挥中心从2023年开始用TDengine做数据融合平台。之前三个系统（气象+烟感+视频）的数据融合靠人工，平均发现火情到确认需要8-12分钟。平台上线后，多源数据自动融合判断，平均缩短到2-3分钟。
听起来差距不大？在森林火灾中，从发现到确认的时间每缩短1分钟，扑火的难度和成本就显著下降。火在5分钟内发现，几个人带灭火器就能处置；30分钟后发现，可能就需要调直升机了。
火灾追溯分析
事后追溯是另一个常被忽视的应用。火灾发生后需要查明起因、起火点、蔓延路径。
数据在追溯中扮演的角色：
- 气象站的风向风速数据可以帮助推断火势蔓延方向
- 闪电定位数据可以判断是否雷击引发（凉山木里火灾就是雷击引发）
- 烟感探测器的首次报警时间序列可以帮助推断起火点和蔓延顺序
- 红外热成像的温度分布变化可以回溯火势扩展过程
这些数据如果只存近期就丢失了，火灾追溯就只能靠现场勘查，效率和准确性大打折扣。时序数据库的长期存储能力让火灾发生前后几天的全量监测数据可以随时调取分析。
TDengine在这个场景的标签模型很有用——查"某片区所有传感器在火灾发生前72小时到发生后24小时的全部数据"，通过片区标签过滤加时间范围查询一条SQL完成。数据来自不同类型传感器（气象、烟感、红外、视频分析），但在同一个数据库里统一管理，做关联分析不需要跨系统导数据。
边缘+云架构的必要性
森林防火场景有一个特殊需求——林区偏远，通信不稳定。如果数据全部上传到云端管理，通信中断时数据就断了。
TDengine的边缘+云架构在这个场景有实际意义。在林区防火指挥中心部署边缘节点，实时数据先写入边缘节点做本地告警判断。通信正常时数据同步到云端做长期存储和跨区域分析。通信中断时数据缓存在边缘节点，恢复后自动补传。
边缘节点的好处是——即使通信完全中断，烟感告警和气象数据融合判断仍然可以在本地完成。这个本地处理能力在林区可能断网的场景下很重要。
几个现实问题
森林防火监测系统的传感器部署密度有限。重点林区的气象站间距通常在5-15公里，不可能做到全覆盖。烟感探测器的覆盖范围也有限——一个烟感器的有效探测半径约50-100米。一座山几百平方公里，现有传感器数量只是"点状覆盖"，大量区域没有监测。这不是数据库能解决的——传感器密度取决于预算，预算取决于各级财政的投入意愿。
视频AI的准确率是个软肋。在雾天、逆光、远距离条件下，烟雾识别的误报率不低。有些林区把视频AI告警的阈值调得很低——宁可误报不可漏报——结果就是每天大量误报让指挥中心的人疲于奔命，真正的火情反而容易被忽略。多源数据融合可以在一定程度上缓解这个问题——视频AI+烟感+红外同时异常才判定为高置信度火情，降低误报率。但融合的前提是数据能在同一个平台里关联起来。
最后，森林防火的责任主体是各级林业部门。林业部门的信息化能力通常弱于电力、交通等行业。一个县级林业局可能就两三个人管信息化，指望他们维护一套复杂的数据平台不现实。系统的简洁性和可维护性比功能丰富更重要。TDengine的运维门槛不算高——SQL兼容、部署简单、不需要专职DBA——这对县级林业局来说是合适的选择。
森林防火这件事，说到底是和时间赛跑。数据早到1分钟，人就可能少冒一分险。技术不能消灭森林火灾，但好的数据平台可以让发现快一点、判断准一点、决策早一点。
在凉山的两次惨剧之后，这套道理不需要谁来强调。但知道和做到之间隔着一个数据融合的工程问题——传感器装了、系统建了、数据存哪？存在几个割裂的数据库里还是存在一个统一的时序数据库里？
这个选择决定了系统到底是"看起来在做防火"还是"真的在做防火"。
