供水数据的典型画像
一座百万人口级别城市的供水系统，SCADA终端数量通常在3000到8000台之间。这些终端分布在水厂、加压泵站、阀门井、用户水表井等位置，采集的物理量涵盖：
监测点类型 | 主要物理量 | 采样频率 | 数据量级/天/单测点 |
水厂出水 | 压力、流量、余氯、浊度、pH、水池水位 | 1秒 | 86,400条 |
加压泵站 | 进出口压力、流量、水泵状态、电流 | 1秒 | 86,400条 |
阀门井 | 阀门开度、前后压力、流量 | 5秒 | 17,280条 |
DMA分区计量 | 分区入口流量、压力 | 5秒 | 17,280条 |
用户水表井 | 瞬时流量、水压 | 10秒 | 8,640条 |
若按5000个终端计算，日新增原始数据约30亿条。这还未包含报警事件、离线在线状态、以及故障时的高频录波。一个中型地级市的完整供水数据，一年就能突破10TB原始存储量。
DMA分区计量的核心逻辑
DMA（District Metering Area，独立计量分区）技术是国际水协（IWA）推荐的供水管网漏损管理标准方法。其基本思路是将管网按自然边界或阀门关断划分为独立计量区，只允许有限的入口和出口，分别安装计量表计，通过出入口流量差计算该分区的漏损量。
DMA的核心计算链路：
夜间最小流量（1:00-5:00）
→ 减去合法夜间用水量（通过用户水表折算）
→ 得出真实漏损量
→ 漏损率 = 漏损量 / 分区供水量
→ 报警阈值 = 历史均值 × 1.15（动态设定）这里的关键挑战在于：夜间流量是秒级或5秒级的原始数据，而漏损分析需要天级甚至月级的聚合视角。同时，分区入口流量与出口流量需要精确时间对齐，否则流量差计算会出现伪差。一个DMA分区可能有4~8个计量点，数据量虽不及整个管网大，但时间同步精度要求在100ms以内。
时序数据库的标签模型设计
供水管网的数据天然具有空间层级属性：水厂→管网干管→DMA分区→街区→楼栋→用户。TDengine的标签体系可以直接映射这一结构。
CREATE STABLE water.pressure_sensor (
ts timestamp,
val float,
quality tinyint
) TAGS (
city nchar(16), -- 城市
water_plant nchar(32), -- 所属水厂
dma_zone nchar(16), -- DMA分区编号
pipe_type nchar(16), -- 管材类型（PE/铸铁/钢管）
elevation int -- 海拔高度（用于压力校正）
);
CREATE TABLE water.p_sensor_0001 USING water.pressure_sensor
TAGS ('Hangzhou', 'Qiantang', 'DMA-018', 'PE-200', 12);这种设计的优势体现在两个查询场景：当运行人员需要查询”西湖区DMA-018分区过去7天的压力波动”时，标签过滤直接定位到相关子表；而当需要统计”杭州市所有PE管材管道的年平均压力”时，可以跨DMA分区聚合，不需要复杂的JOIN操作。
漏损定位的数据链路
传统漏损检测依赖夜间听音、相关仪、电磁定位等现场手段，效率低、覆盖有限。基于SCADA数据的漏损分析，核心是通过流量异常模式识别可能的漏点位置。
一个有效的漏损定位算法需要同时拉取以下数据：
- 目标DMA分区出入口的秒级流量曲线
- 分区内主要干管压力曲线（用于判断是否存在异常压降）
- 相邻分区的流量变化（排除跨区转供干扰）
- 历史同期数据（用于季节性调整基线）
计算引擎需要在秒级完成上述多源数据的拼接和聚合，这对数据库的JOIN性能和标签过滤能力提出了要求。TDengine的分布式计算引擎可以将关联计算下推到数据节点执行，避免将大量原始数据拉到查询端处理。
通信链路的特殊性
供水SCADA终端的通信方式以GPRS/4G/5G为主，部分偏远阀门井使用LoRaWAN或NB-IoT。这些链路的稳定性远不如有线以太网，丢包率在恶劣天气下可达10%~20%。
数据库层面需要处理的情况包括：数据延迟到达（超过写入窗口）、数据乱序（终端本地缓存断电重启后批量上报）、以及虚假时间戳（终端时钟漂移未同步）。TDengine通过时间窗口排序和质量码过滤来应对前两类问题，同时支持对延迟到达数据的写入配置专门的窗口阈值。
实际部署中，建议在采集网关层增加本地缓存（至少24小时容量）和时间戳校验逻辑，确保进入数据库的数据在时序上是基本连续的。
产销差计算的准确性保障
产销差（Non-Revenue Water，NRW）是供水企业最核心的KPI之一，计算公式为：
产销差率 = (水厂供水量 - 用户计费水量) / 水厂供水量 × 100%供水量来自水厂出水总管的高精度流量计（通常是电磁流量计或超声波流量计，精度0.2%），计费水量来自用户水表（精度1%~2%）。两者的计量精度差异本身就会引入计算偏差，需要数据库在聚合计算时对不同精度的数据源加权处理。
实践中，供水量按小时粒度存储聚合值，计费水量按天粒度存储，产销差计算按天输出。TDengine的多级连续查询可以自动从原始数据生成小时级和天级聚合表，产销差计算作为依赖链的末端任务，在上游聚合完成后自动触发。
典型部署规模参考
城市规模 | 终端数量 | 日原始数据量 | 年存储量（原始+聚合） | 推荐集群规模 |
县级市（10~30万人口） | 1000~2000 | 5~10亿条 | 30~50TB | 3节点，每节点8C32G×2TB SSD |
地级市（50~100万人口） | 3000~6000 | 15~30亿条 | 80~150TB | 6节点，每节点16C64G×4TB SSD |
直辖市/省会（200万+人口） | 10000~20000 | 50~100亿条 | 300~600TB | 12+节点，每节点16C128G×8TB SSD |
结语
城市供水的数据架构，本质上是在有限的通信资源和分散的终端条件下，构建一条从物理管网到数字孪生的感知通道。时序数据库的选型，不能只看实验室写入TPS，更要看在真实网络条件下数据能否准确、连续地入库、能否支撑DMA分区这种跨终端的关联查询、以及能否以可接受的成本支撑5年以上的数据留存。TDengine在供水行业的多个标杆项目中，已经验证了其在这些维度上的工程可行性。
