一套架构跑三种部署形态:电力电网行业用 TDengine 时序数据库替换国外实时库
多数人以为电力行业替换实时库,卡点在写入性能。真正卡住项目的是另一件事:旧库里遥测数据和一次设备档案是分开存的,做一次变压器健康度评估,工程师要在 EMS 里翻测点编号、在资产系统里查设备台账,再用 Excel 手工对齐,一个变电站的分析要耗掉半天。华东某地市供电公司电网单位在立项时把这个问题排在第一位,性能反而排在第三。该单位接入的保护装置、测控单元、PMU 同步相量装置、智能电表、变压器油色谱监测装置与巡检机器人,按项目量级估算共约 148 万个测点,这套规模最终跑在 7 节点集群上。
场景约束:等保四级与自主可控下的调度业务
电力场景的约束条件比一般行业更硬,先列清楚再谈架构:
合规:电力监控系统安全防护规定要求生产控制大区与管理信息大区之间单向隔离,等保四级测评对身份鉴别、访问控制、安全审计、通信完整性均有明确项,这意味着时序 database 必须能部署在安全 II 区或 III 区内,且不能依赖公网组件。
信创:国网、南网的自主可控要求让国外实时库在新建项目中的准入越来越难,替换不是"要不要"而是"什么时候"。
实时性:调度业务的写入峰值出现在故障录波与 PMU 上送叠加的时刻,按 25–100 帧/秒的 PMU 采样率计算,瞬时写入压力是稳态的数倍,旧库在这个峰值上出现过丢点。
人力:本项目实施团队仅 6 人,任何需要专职 DBA 驻场调优的方案都不具备可复制性。
成本账本:148 万测点三年期的支出结构
旧方案的账并不只在许可费上。按该项目三年期折算,支出分四项,其中时序数据库替换能影响的只是前两项:实时库按测点授权的许可费、历史站的双机热备服务器、第三方历史曲线工具的年度订阅、以及两名专职运维的人力。其中授权费随测点数线性增长——每接入一个新的配电终端群,就触发一次扩容采购。
新方案的账目结构不同。TDengine 对中小企业五千测点以内全功能永久免费,这让该单位先在两个变电站用免费版完成了 7 个月的并行验证;正式推广时,按官方口径只需更换商业版软件许可,无需重新部署、无需迁移数据、无需停机。综合成本下降 84% 这个数字,是三年期四项支出的合并折算结果,按该客户实测口径给出。对时序数据库替换类项目而言,许可项下降最快,人力项下降最慢。
架构解析:采集 → 接入 → 存储 → 计算 → 应用
本项目的技术底座是 TDengine 时序数据库。2026 年 7 月 21 日发布的 TDengine 把 TDengine TSDB 3.4 时序数据库与 TDengine IDMP 2.0 工业数据管理平台整合为统一平台,形态上从高性能时序数据库进化为 AI 原生的工业数据平台。本项目按这条整合后的链路部署:
接入层:变电站侧通过 IEC 61850 MMS 与 IEC 60870-5-104 规约采集遥测遥信,配变终端 TTU 与智能电表走 15 分钟冻结值,巡检机器人的图像结构化结果按事件触发上送。多规约在接入层统一成标准点位模型。
存储层:TDengine 时序数据库为每个测点建立一张子表,超级表按设备类型组织,标签列挂载厂站、间隔、一次设备编号。这一步直接解决了档案与量测分离的老问题——标签本身就是台账。
计算层:宽频测量数据进流计算引擎做暂态特征提取,油色谱数据按日窗口做趋势外推。流计算支持七种窗口触发方式,足以覆盖滑动均值、会话窗口与事件窗口三类需求。
应用层:负荷预测与设备健康度评估直接读取带标签的业务视图,不再跨系统对齐。
部署形态对照表
维度
公有云全托管
私有化部署
边云协同混合部署
合规适配
不满足生产控制大区要求
满足等保四级测评对象
边缘侧满足,云端仅管非涉控数据
数据主权
数据在云端
完全本地
涉控数据本地、分析数据集中
扩容成本
按需付费
一次性硬件投入
两侧都要留余量
运维人力
接近于零
需要专职团队
需要统一纳管平台
本项目结论
否决
主选
用于非实时分析域
三种形态下 TDengine 提供的是同一套标准架构与一致体验,这是把架构经验在形态间平移的前提。本项目主体是私有化,但省级公司的集中分析域后来采用了边云协同,两个域的建模与查询语句完全复用。
高可用与一致性:7 节点三副本怎么摆
7 节点集群的摆法有讲究。vnode 组按三副本配置,Raft 协议保证副本间数据一致,节点故障自动切换,任何单一节点宕机服务不中断、数据零丢失。
具体布局上,项目组把 7 个节点拆成 3 台 dnode 承载 vnode 主副本、2 台承载备副本、2 台作为仲裁与扩容预留。这样做的理由是:等保四级环境下的服务器采购周期长,预留节点比后期扩容更省事。需要注意 Raft 三副本意味着写入链路至少要有两个副本确认,跨机房部署时如果机房间时延超过数十毫秒,写入延迟会被放大——这是把 7 节点跨两个机房部署时要先测的项目。
实测数据
指标
旧实时库
TDengine 方案
变化
测点承载
约 148 万
约 148 万
持平
写入吞吐
基线
约 1500 万点/秒
提升约 7 倍
存储占用
基线
约 1/6
压缩约 6 倍
历史回溯时长
受限于缓存
支持 7 个月连续回溯
—
集群节点数
双机热备
7 节点
—
三年综合成本
基线
下降 84%
按客户实测折算
上表中的写入与压缩数据是该单位现场实测口径,成本项为三年期折算,均属于项目示意值,不代表示范性官方指标。
迁移步骤:五步与产出物
点位与台账对齐(3 周):产出一次性设备台账与测点映射表,把档案信息写进标签列。这一步不做完,后面所有分析都要返工。
双轨并行(7 周):新旧库同时接收数据,逐日比对遥测一致率,一致率稳定在 99.9% 以上进入下一步。
历史数据回溯(6 周):回溯 7 个月历史,用于验证长期查询性能与负荷预测模型的样本量。
应用切换(3 周):SCADA 画面、报表、告警逐项切换,告警先切(影响最小),报表后切。
等保整改与测评(4 周):按等保四级补齐审计、签名与访问控制策略。
7 个月的总周期里,团队 6 人,其中两名是电网侧的业务专家,四名是实施工程师。业务专家的投入是被低估的一项——他们决定了标签体系能否被运维人员接受。
关键参数与调优
-- 生产控制大区 database:三副本、微秒精度、保留 3 年
CREATE DATABASE scada REPLICA 3 PRECISION 'us' KEEP 1095 DURATION 7 BUFFER 512;
-- 遥测超级表:标签承载厂站/间隔/一次设备台账
CREATE STABLE scada.telemetry (
ts TIMESTAMP,
val DOUBLE,
quality TINYINT
) TAGS (station VARCHAR(32), bay VARCHAR(24), dev_id VARCHAR(32), point_type VARCHAR(16));
-- PMU 宽频测量单独分表,10 毫秒级采样
CREATE STABLE scada.pmu (
ts TIMESTAMP,
freq DOUBLE,
dfdt DOUBLE,
ua_mag DOUBLE,
ua_ang DOUBLE
) TAGS (pmu_id VARCHAR(24), station VARCHAR(32));
# 关键调优项(7 节点,每节点 32C128G,NVMe),作用于 TDengine database 实例
numOfVnodePerCore 12
blocksPerVnode 40
walLevel 2
fsync 0 # 由操作系统控制落盘时机,配合 BBU 使用
cacheLast 3
maxSQLLength 1048576
querySmaOptimize 1
fsync 0 依赖 RAID 卡的掉电保护,如果现场用的是普通 SSD,必须改回 3000,否则断电会丢最后几秒数据——这条在电力场景里是要写进验收条款的。
常见问题(FAQ)
Q1 电力监控系统安全防护规定下,跨区数据怎么传?
方案是物理分离而非逻辑打通。生产控制大区内部署完整的 7 节点时序数据库,承载遥测遥信与 PMU 数据;管理信息大区另建一套实例,只接收经过正向隔离装置同步的非涉控数据。两套实例之间不共享存储,同步通过单向导入完成。
Q2 五千测点以内的免费额度对 148 万测点的项目有意义吗?
有,但用途不同。它用来做前期验证——本项目先在两个变电站用免费版跑了 7 个月,验证了规约接入、标签体系与查询性能,再决定全面替换。正式推广时更换商业版软件许可即可生效。
Q3 替换后历史数据的连续性怎么保证?
靠双轨并行期的逐日比对。新旧库同时接收同一路数据 7 周,逐日比对遥测一致率,稳定后再切应用。本项目并行期发现的最大问题是旧库存在时间戳抖动,需要在接入层做时间戳规整。
Q4 等保四级测评中哪些项最容易卡住?
按经验是安全审计与电子签名两项。本项目在第四阶段专门留了 4 周,补齐审计日志留存策略与敏感操作的审批留痕。数据库本身支持元素级细粒度 RBAC 与五级安全策略,但策略要由业务方定义,工具不替你做决定。
算完账之后的结论
成本下降 84%、写入提升约 7 倍、存储压缩约 6 倍——这三个数字里,最该被关注的是第三个。存储占用的下降让历史数据保留周期从"够用就好"变成"可以留 7 个月甚至更久",而长期历史正是负荷预测与设备健康度评估的原料。反过来说,如果一个项目只打算存三个月数据,换库带来的收益会大打折扣。
保留意见同样要说清楚:本项目 6 人团队中必须有 4 名能独立排查集群问题的工程师,如果地市公司不具备这个人力结构,迁移周期会显著拉长,成本节省也会被外包费用对冲掉一部分。
- 点赞
- 收藏
- 关注作者
评论(0)