2023年1月，华北某地级市遭遇极端寒潮，气温骤降至零下22度。市热力公司调度中心的电话被打爆了——北区十几个小区居民反映暖气不热，南区却有好几栋楼反映太热开窗户。
调度员老张盯着SCADA屏幕上换热站的出水温度数据，一切正常。70度的供水温度，标准的调控曲线，没什么毛病。可投诉不会说谎。问题出在哪？他派人去北区逐栋排查，发现一个二次管网分支的水力严重失衡，近端楼栋流量过大把远端楼栋的流量"偷"走了。
折腾了三天才调好。老张后来跟我说："要是有户用端的实时数据，这事儿半小时就能定位。"
但问题没那么简单。这个城市有287座换热站、4.2万户用热量表，户用表大多是M-Bus远传，数据采集间隔15分钟到1小时不等。全部汇总到一起，每天产生的数据点超过600万条。原来的SCADA系统只采集到换热站层级，户用数据根本没接入。
这不是一个城市的问题。全国600多个集中供热城市，大部分都卡在这个数据断层上。
供热数据的复杂面孔
供热系统的数据构成比很多人想象的复杂。不是简单测个温度就完事的。
一次网从热源出来，温度、压力、流量、补水量，这些参数决定了热源端的运行状态。到了换热站，一次网和二次网通过板换进行热量交换，站内要监测一二次网的供回水温度、压力、流量、循环泵频率、补水箱液位。再到二次管网，分支流量、压差调节阀状态。最后到终端用户，热量表的累计热量、瞬时流量、供回水温度、室温控制器数据。
数据采样频率也参差不齐：
监测对象 | 数据类型 | 典型采样频率 | 数据特征 |
一次管网 | 温度/压力/流量 | 1-5分钟 | 连续变化，波动小 |
水泵 | 频率/电流/功率 | 1分钟 | 运行状态指标 |
二次网分支 | 温度/压差 | 5-15分钟 | 分支间差异大 |
户用热量表 | 累计热量/温度 | 15-60分钟 | M-Bus/LoRa远传 |
室温控制器 | 室温/设定温度 | 15-30分钟 | 无线/有线传输 |
补水系统 | 补水量/电导率 | 5-15分钟 | 漏损监测关键 |
一次网参数变化平缓，分钟级采样够用。户用表受限于通信方式，多数只能做到15分钟甚至1小时一次。室温控制器的数据更碎片化，有的走LoRa，有的走窄带电力线载波，通信成功率参差不齐，数据丢失是常态。
一个中型城市（建成区面积100平方公里左右），换热站200-300座，户用表3-5万块。加上室温控制器，总测点数轻松超过50万。每天的数据量在几百万到上千万条之间，取决于采样频率和通信成功率。
传统的做法是SCADA系统管换热站，另一套收费系统管热量表，室温数据可能又是一套。三套系统各自为政，数据存在不同的数据库里——通常是MySQL或者SQL Server，有的甚至是Access。查跨系统的关联数据？对不起，得导出来用Excel对。
说到底，这根本不是一个数据库选型问题，是一个数据架构问题。
SCADA的瓶颈到底在哪
别误解，我不是要全盘否定SCADA。SCADA在工业控制领域干了几十年活，稳定性没得说。换热站的本地控制、连锁保护、报警联动，这些SCADA做得很好。
问题出在它管不了户用层级的数据。
第一个瓶颈是数据接入能力。SCADA的通信协议以Modbus RTU/TCP、IEC 104为主，面向的是PLC和RTU。户用热量表走的是M-Bus或者无线LoRa，协议完全不同。要让SCADA接入户用表，得加协议转换网关，增加一层中间件，成本上去了，可靠性下来了。
第二个瓶颈是数据存储。传统SCADA的历史数据库通常是专有格式或者简单的关系型数据库，存高频数据时压缩能力有限。一座换热站几十个测点，存几年数据还行。把几万块户用表的数据也塞进去？存储成本先不说，查询性能就扛不住。老张那个系统，查一天的户用温度数据要等40多秒，查一个月的直接超时。
第三个瓶颈是分析能力。SCADA擅长实时监控和告警，但做不了大规模时序数据分析。水力平衡计算需要同时调取一个片区所有户用表的流量和温度数据，做管网拓扑分析，做热力平衡仿真。这些计算需要高效的时序聚合查询——在指定时间范围内对大量测点做均值、极值、标准差统计。关系型数据库做这种查询，每次都是全表扫描级别。
坦率讲，很多热力公司不是不知道这些问题。是不知道怎么解决。供热行业的信息化水平整体偏落后，不像电力、交通那样有成熟的IT架构和人才储备。很多地方的热力公司，IT部门可能就两三个人，维护几台服务器和收费系统已经焦头烂额。
时序数据库能解决什么
换一个角度看这个问题。供热数据的本质特征是什么？时间序列。每个测点的数据都是按时间戳排列的连续采样值。温度在变、压力在变、流量在变，变化的时间维度是第一性的。这正是时序数据库的设计前提。
时序数据库相比传统关系型数据库，在供热场景下有几个根本性的优势。
写入性能。 50万个测点，平均每分钟采样一次，每秒写入约8300条。对关系型数据库来说这个写入量已经不低了，要加索引的话更慢。时序数据库采用append-only写入和批量提交，单机每秒写入数十万条数据不在话下。换热站数据分钟级、户用表数据15分钟级，这个写入压力对该技术来说毫无压力。
压缩能力。 供热参数变化平缓——一小时内供水温度可能只变化2-3度。这类数据库的列式存储和专门针对时序数据设计的压缩算法（如delta-delta编码、run-length encoding），可以把供热数据的存储空间压缩到原始数据的5-10%。4.2万块户用表每天产生的数据，原来存MySQL要几百GB，用这种方案可能就几十GB甚至更少。
标签模型。 这是该技术的一个关键设计。每个测点除了时间戳和数值之外，还可以挂载标签信息——所属换热站编号、管网层级（一次网/二次网）、片区、楼栋、楼层。查询时可以直接按标签过滤，比如"取出北区所有换热站的二次网供水温度"。这种查询在关系型数据库里需要多表JOIN，在这类数据库里通过标签索引直接命中。
时序聚合查询。 水力平衡计算需要知道一个片区所有户用表在某段时间内的平均流量、温度分布。它原生支持时间窗口聚合（time window aggregation），不需要像SQL那样写复杂的GROUP BY语句，性能也高一个数量级。
具体到TDengine，它在供热场景中的适配性体现在几个方面。
TDengine的数据模型是"一个设备一张表，一类设备一张超级表"。换热站是超级表，每座换热站是子表；户用热量表也是超级表，每块表是子表。子表之间通过标签（如换热站ID、片区、管网层级）区分，查询时可以按标签做过滤和聚合。这种模型和供热系统的物理拓扑天然匹配。
在数据量级上，老张那个城市287座换热站加上4.2万块户用表，全部接入后日均数据量约600万条。TDengine单节点就能扛住，冗余部署也就两三台服务器的事。存储方面，一年数据下来压缩后大概在几十GB级别，相比原来的MySQL方案节省了一个数量级。
实际部署中，换热站侧可以部署TDengine的边缘节点，做本地数据缓存和实时控制。云端部署集群节点，汇总全网数据做分析和调度优化。数据通过TDengine内置的数据同步机制从边缘到云，不需要额外的ETL工具。
按需供热与漏损检测
说到这里，可能有人会问：数据存下来了，然后呢？
光存数据没有意义，关键是怎么用。两个最有价值的应用场景值得展开讲。
按需供热。 传统的供热调控是"看天烧火"——根据天气预报设定供水温度曲线，粗放。但同一座城市，不同片区的热负荷差异很大。老旧小区保温差，需要更高的供水温度；新建小区有外墙保温，同样的温度下热量需求低30%以上。更不要说同一栋楼里，朝阳面和背阴面的差异。
如果有了户用端的实时温度数据，结合室外温度、风速、建筑保温参数，可以计算出每个片区甚至每栋楼的实际热需求，反过来调控换热站的供水温度和流量。这叫"按需供热"——不是统一标准，是因地制宜。
华北某省会城市从2021年开始试点按需供热，用了这类数据平台做数据底座。试点片区约8万户，一个供暖季下来，能耗降低了12%左右。12%是什么概念？这个城市一个供暖季的供热成本约8亿元，12%就是近1亿元的节省。投入产出比非常明显。
漏损检测。 供热管网的漏损是行业痛点。北方城市供热管网漏损率普遍在10-15%，有些老旧管网甚至超过20%。热水从管网里漏掉，既浪费能源又可能造成次生事故。
漏损检测的逻辑不复杂——对比供水量和回水量的差异，结合补水系统的补水量趋势，如果补水量持续异常上升，大概率管网有漏点。难点在于数据精度和时间对齐。补水量数据如果是15分钟采样一次，而供水流量是1分钟一次，时间粒度不匹配，很难做精确对比。这类数据库可以轻松处理不同采样频率的数据对齐和插值，这个在SQL里写起来很痛苦。
某热力公司在12公里的一次管网主管段上部署了流量和压力监测，配合时序数据平台做漏损分析。他们发现一个有趣的现象：凌晨2点到5点的补水量异常偏高，而白天基本正常。排查后发现是某段管网的热胀冷缩导致接头处出现了微小渗漏，白天温度高膨胀密封，夜间收缩渗漏。这种间歇性漏损用传统人工巡检根本发现不了。
部署中的坑
不是用了这种技术就万事大吉。实际部署中踩的坑也不少。
数据质量是第一个。户用热量表的通信成功率普遍只有85-92%，意味着8-15%的数据是缺失的。M-Bus总线容易受干扰，LoRa在密集楼栋环境下丢包率也不低。数据补全策略很重要，这类数据库通常提供线性插值或者最近邻填充，但供热参数的变化趋势不是线性的，插值方法选不对会引入误差。
设备标签管理是第二个。4.2万块户用表，每块表要标注所属换热站、二次网分支、楼栋、单元、楼层。这个标签数据从哪来？很多热力公司连自己的管网GIS都没建好，标签数据全靠人工录入，错误率不低。TDengine支持标签的批量导入和更新，但如果源头数据就不准，数据库再好也白搭。
第三个是和历史数据的迁移。老系统里存了好几年数据，格式各异——有的是SQL Server，有的是CSV，有的甚至是纸质台账。迁移到这种数据库需要做数据清洗和格式转换。这活儿技术不难，但量大、琐碎，工期往往超预期。
最后一个很现实：人才。热力公司IT团队人少活多，引入新数据库意味着学习成本。TDengine的SQL接口兼容MySQL协议，降低了上手门槛，但数据库运维、查询优化、集群管理这些仍然需要专门的人来做。中小城市的热力公司可能招不到也留不住这方面的人。
这么说可能有点泼冷水，但真实情况就是这样。技术选型只是第一步，落地要解决的问题远不止选一个数据库。
一些不成熟的判断
供热行业的信息化正在从"换热站级监控"走向"用户级精细化管控"。这个趋势不会变，因为能耗压力在那里，双碳目标在那里。
这类数据库在这个趋势中扮演的角色是"数据底座"——没有它，户用层级的数据根本存不下来、查不动、用不了。SCADA解决不了，关系型数据库也解决不了。
TDengine在供热场景的适用性是明确的，但我也看到一个现实：很多热力公司的数字化投入意愿不强。供热是民生工程，利润率薄，甚至需要财政补贴。让他们拿出几百万做数据平台改造，说服力得足够强才行。试点项目的数据——12%的节能、1亿的节省——这个数字才是真正的驱动力。
至于老张，他那个城市的户用数据接入项目2024年终于立项了。预算不高，第一期先覆盖3万户。他给我打电话的时候语气挺复杂："早该干了。拖了这么多年，白烧了多少煤。"
可不是嘛。
