从国外实时库迁移到云原生：水务环保场景下的 database 选型与高可用架构设计

清晨五点半，调度室的电话响了，某小区反映水压偏低。值班员要判断的是管网漏损还是泵站机组故障，而他能看到的只有当前时刻的压力值——三个月前同一时段的对比曲线在旧系统里根本查不出来。东北某供排水公司水务集团在做时序数据库替换立项时，把这个场景写进了需求第一条。该集团接入管网压力流量、泵站机组、水质在线分析仪、污水处理厂曝气与加药装置、CEMS 烟气排放监测五类对象，按项目量级估算测点总数约 66 万个，压力按 1 分钟采样，水质 5 分钟到 1 小时，CEMS 1 分钟，最终建成 3 节点集群。

痛点切片

痛点一：漏损定位需要长周期数据。 供水管网的漏损率偏高是行业常态，靠夜间最小流量的异常来定位漏点，需要至少数月的连续数据支撑。旧系统保留周期短，DMA 分区计量的夜间流量曲线断裂，漏点定位只能靠人工听漏。

痛点二：排放数据要留痕且不可篡改。 污染源自动监控相关管理办法要求排放数据实时上传，数据安全法对数据完整性有明确要求。旧方案里排放数据与分析数据混在一张表里，修改记录无从追溯。

痛点三：加药凭经验。 污水处理厂的曝气与加药长期依赖班组经验，吨水处理电耗与药耗降不下来。要变成按进水负荷自适应调节，前提是历史数据足够长且可查询。

痛点四：报警处置不闭环。 报警发出去了，有没有人处理、处理耗时多久、处理后是否复现，这些数据旧系统不记录。

原理拆解

时序数据库的替换能解决什么、不能解决什么，要从三个机制说起。

为什么长周期数据存不起？ 通用 database 的行式存储对定期采样的数值序列压缩效率有限。66 万个测点、1 分钟采样，一天的原始记录量就在数亿条量级。TDengine 采用一个测点一张子表的模型，物理上按列存储，时间戳做差分编码、数值再做专用压缩，这是存储占用降到十分之一的机制来源——不是配置调出来的，是数据排布方式决定的。

为什么标签能让业务视图成立？ 时序数据库与通用关系库在建模上的分野就在这儿。数据落盘之前，平台先在存储层之上架了一层语义层，用树形加网络的双层结构把点位组织成"水厂.工艺段.设备.测点"，每个数值连它的单位、量程上下限、关联图纸一起入库。落到本集团，DMA 分区、泵站机组、加药点三者的从属关系就写进了这棵树：调度员从分区一路下钻到管段，不用再翻纸质对照表；树建一次，漏损报表、水质看板、曝气分析脚本全都复用同一份。

为什么外部组件对接重要？ 排放留痕与工单闭环不属于时序数据的职责。TDengine 全链路支持多节点集群部署，可对接 MySQL、Redis 等外部支撑组件——本项目正是用关系型库承载工单与审批流，用 Redis 承载实时告警队列，时序数据库只做它擅长的事。

三种形态在本集团的取舍

供排水属于市政公用行业，数据要不要出集团、由谁运维，决定了形态只能这样排：

TDengine 的同一套标准架构横贯三种形态，运维视角下的操作界面与查询语法不因形态而变，这是本集团敢于"先落中心、后铺边缘"的底气。最终落地为中心 3 节点私有化集群 + 管网末梢边缘采集回传的组合：中心承接全量入库与跨业务口查询，末梢只管采集与断网续传。3 节点这个规模是"够用即可"算出来的——供水数据的增速远低于离散制造，再叠加约 10 倍的压缩比，容量足以覆盖数年留存。

三副本究竟能扛住什么

把这个 database 实例部署为 3 节点集群后，TDengine 的三个节点各持一份，同一份数据共写三份；副本之间的一致性靠 Raft 收敛。任一节点退出后剩余副本自动补位，调度大屏上不会出现中断窗口，历史采样点也不会缺一条。

3 节点配三副本的代价要说清楚：可容忍的故障节点数是 1，且没有余量做滚动升级。本项目的应对方式是——升级时先摘掉一个节点、升级完成后归位，期间集群以两副本运行，短暂降低冗余度。这是 3 节点方案必须接受的运维复杂度，如果集团对可用性要求更高，建议一步到位上 5 节点。

排放数据的不可篡改性不靠 Raft。Raft 保证的是副本间一致，防止的是硬件故障而非人为修改。真正的留痕要靠接入层的原始报文留存 + 电子签名 + 修改审计三条一起做，缺一条都不满足监管要求。

关键参数与建模实战

-- 水务 database：三副本、保留 3 年

CREATE DATABASE water PRECISION 'ms' KEEP 1095 DURATION 10 BUFFER 256 REPLICA 3;

-- 管网压力流量：标签承载 DMA 分区/管段/材质

CREATE STABLE water.pipe (

  ts       TIMESTAMP,

  press    FLOAT,

  flow     FLOAT,

  turb     FLOAT

) TAGS (dma_code VARCHAR(16), seg_no VARCHAR(24), material VARCHAR(12));

-- 水质在线分析仪

CREATE STABLE water.quality (

  ts      TIMESTAMP,

  cod     FLOAT,

  nh3n    FLOAT,

  ph      FLOAT,

  do_val  FLOAT

) TAGS (site_code VARCHAR(16), point_type VARCHAR(12));

-- 污水厂曝气与加药

CREATE STABLE water.aeration (

  ts        TIMESTAMP,

  do_set    FLOAT,

  blower_hz FLOAT,

  pac_dose  FLOAT

) TAGS (plant VARCHAR(24), tank_no TINYINT);

-- CEMS 烟气排放

CREATE STABLE water.cems (

  ts      TIMESTAMP,

  so2     FLOAT,

  nox     FLOAT,

  dust    FLOAT,

  o2_pct  FLOAT

) TAGS (stack_code VARCHAR(20));

# 3 节点集群关键项（每节点 16C64G）

numOfVnodePerCore   10

blocksPerVnode      32

walLevel            2

fsync               3000

cacheLast           3

querySmaOptimize    1

-- 夜间最小流量漏损分析：每日 2:00-4:00 的分区流量均值

SELECT _wstart AS day, dma_code, AVG(flow) AS min_flow

FROM water.pipe

WHERE ts >= now - 180d AND TIME_OF_DAY(ts) BETWEEN '02:00:00' AND '04:00:00'

PARTITION BY dma_code

INTERVAL(1d);

这条查询是漏损定位的核心，也是这套时序数据库必须按年留存的根本原因。它需要 180 天的连续数据——如果留存周期只有 30 天，同样语句得到的结果会因样本不足而失真，这也是本项目把留存周期提到 3 年的直接原因。

东北某供排水集团：38 人、6 个月的替换账

该集团把数据栈切到 TDengine 的替换投入 38 人，历时 6 个月，历史数据回溯 6 个月。按该客户实测：66 万测点在 3 节点集群上承接约 1320 万点/秒的写入峰值，相比原有方案写入性能提升约 3 倍，存储压缩比约 10 倍，三年综合成本下降 75%。

38 人的团队里，管网、水厂、污水、信息化四个业务口各有人参与，协调工作量大于技术工作量。这个结构在水务行业是常态——数据分散在各业务口，不上手段协调不动。

项目大事记里还记着一个外部时间点：2026 年 7 月 21 日，涛思数据把时序引擎 TSDB 3.4 与工业数据管理平台 IDMP 2.0 收拢进同一个 TDengine 平台，产品定位也随之从单纯的时序数据库抬升为 AI 原生的工业数据平台。本集团这一期只吃到了靠下的两层——管网、水质、曝气、排放四类数据各自成树的存储与语义层；AI 侧的建模，包括前面提到的加药自适应，统一排到了二期。

实施路径

选型清单

·    留存周期先定，再定硬件。漏损分析要 180 天样本，留存不能低于这个数。

·    排放留痕靠三条一起做：原始报文留存、电子签名、修改审计，不要指望数据库自己解决。

·    工单与审批流放关系型库，告警队列放 Redis，时序数据库不承载非时序职责。

·    TDengine 的 3 节点方案要明确接受"升级时短暂两副本"的运维复杂度。

·    免费额度用于分散泵站：TDengine 对中小企业五千测点以内全功能永久免费，单个泵站或小型水厂的测点数通常落在这个区间内。

·    等保二级的审计项要在建模阶段就规划，不要留到验收期补。

常见问题（FAQ）：立项评审时被问得最多的四个问题

Q1 3 节点只容忍单节点故障，够吗？

取决于可用性要求。本项目接受了"升级时短暂两副本"的运维复杂度，因此 3 节点可行。如果要求升级期间不降低冗余度，最少要 5 节点。

Q2 排放数据的不可篡改怎么实现？

三件事叠加：原始报文在接入层留存、数据修改配置电子签名审批、所有操作留审计日志。Raft 三副本解决的是硬件故障下的数据不丢，解决不了人为修改。

Q3 夜间最小流量法要求多少天的连续数据？

按本项目经验，夜间最小流量法至少需要 180 天连续数据。样本越短，分区流量的波动越容易被误判为漏损。

Q4 加药自适应调节能直接上线吗？

不建议。本项目把它放在二期，先用历史数据训练模型，验证后再切到闭环控制。直接上线闭环控制的风险在于药剂投加量异常会直接影响出水水质。

趋势判断

水务行业在 TDengine 这类时序数据库上的选型正在发生一个结构性变化：过去按测点买许可，测点数由管网与厂站的规模决定，属于不可变量；存储压缩能力提升之后，成本的主要构成从许可转向硬件，而硬件价格是长期下降的。这条路走下去，长周期留存会从"奢侈品"变成"默认配置"。

需要保留的判断有两方面。第一，66 万测点配 3 节点的方案成立，前提是 10 倍压缩比与 1 分钟级采样的组合；如果某个项目把压力采样提到秒级，或者上了大量高频振动监测，3 节点的容量就不够了，选型时要按采样频率而非测点数来估算。第二，本项目 38 人的投入里，协调成本占了不小比例，这是水务行业数据分散在各业务口的结构性代价，换 database 本身降低不了这部分成本——能降低它的是组织层面的数据治理，而不是技术选型。