一套架构跑三种部署形态：新能源智能升级实践，时序数据库 TDengine 落地要点

多数人以为新能源场站的数据难点是"发电功率大"。东北某戈壁光伏电站场站在立项评审时推翻了这个判断：真正吃掉收益的不是发电量，而是三项被误判的成本——限发弃风的考核扣款、电池簇一致性劣化导致的可用容量损失、以及 AGC/AVC 响应不达标带来的并网考核。这三项的共同点是要靠秒级、长周期、可回溯的数据才能说清楚，而场站原有的历史库只保留 3 个月且查询一次要几分钟。该项目最终部署 9 节点集群，时序数据库选型为 TDengine。

痛点切片：三项被误判的成本

第一项：限发弃风的举证难。 电网下达限发指令后，场站要证明"确实被限"而不是"自发少发"。这需要同时留存调度指令、逆变器实际出力、辐照度三组数据，且时间戳必须严格对齐。原系统里这三组数据分属三个库，对齐靠人工，一次举证要两天。

第二项：电池簇一致性分析在时序数据库缺位时算不动。 储能侧的 BMS 单体电压按秒采集，一个百兆瓦级场站的电池簇可达数千个单体，按单体维度回溯半年，通用 database 要么算不出来，要么要跑几十分钟。而簇间均衡策略的调整恰恰依赖这个分析。

第三项：功率预测的数据链路太长。 功率预测与 AGC/AVC 考核要求秒级响应，原链路是"场站 SCADA → 历史库 → 转发程序 → 集控中心"，每一跳都增加延迟；戈壁滩的专网本就抖动，链路一长就断。

原理拆解：为什么场站必须走边云协同

新能源场站的物理约束决定了单一部署形态不可行。场站分散在全国，集中监视要跨专网拉数据；并网调度协议与电力监控系统防护要求生产数据不出安全区；但集团集控中心又要做跨场站对标。三条约束指向同一个答案：边云协同。

在形态选择上，公有云全托管、私有化、边云协同这三种方式都由同一套标准架构支撑，使用体验保持一致。这句话在工程上的含义是：场站侧边缘节点与集控侧中心节点用的是同一份建模定义与同一套查询语法，不需要为两端各写一套代码。边侧负责原始高频数据的落盘与断网续传，云端只接收聚合结果与考核相关的统计量，既压住了专网带宽，又满足了生产数据驻留要求。

存储层面的原理同样关键。风机主控 10 Hz、逆变器 1 分钟、BMS 单体电压 1 秒——三种频率差异极大，通用 database 若塞进一张宽表，低频数据会被高频数据拖着写，浪费 IO。时序数据库的正确做法是分超级表建模，靠语义层在应用层做对齐。TDengine 时序数据库在存储层与应用层之间构建统一语义层，采用树形 + 网络双层模型，把原始数据映射为"场站.机组/方阵.设备.测点"业务视图，每个数值带物理单位与上下限。等效利用小时、SOH/SOC 这类派生指标因此可以在语义层统一定义，而不是各场站各算一套。

配置与查询实战

# 场站侧边缘节点（边云协同形态）

taosd --config /etc/taos/taos.cfg &

# 集控侧中心节点注册边缘为数据同步目标

taos -h central-node -e "CREATE DATABASE station_edge REPLICA 3 KEEP 1095 BLOCKS 16;"

# 场站边缘节点 /etc/taos/taos.cfg

fqdn              pv-gobi-01

serverPort        6030

replica           3

walLevel          2

numOfVnodes       40

cache             16384

compression       2

-- 逆变器出力超级表：方阵 + 逆变器编号作为标签

CREATE STABLE inverter_ac (

  ts TIMESTAMP, p DOUBLE, q DOUBLE, dc_volt DOUBLE

) TAGS (station BINARY(32), array_no INT, inv_no INT);

-- 限发举证：调度指令窗口内的实际出力与理论出力对比

SELECT _wstart AS ts,

       avg(p) AS actual_p,

       avg(irr) AS irradiance

  FROM inverter_ac

 WHERE station = 'GOBI-PV-02' AND ts >= NOW - 90d

 INTERVAL(5m);

-- 电池簇一致性：按单体统计半年内电压极差

SELECT cluster_id,

       max(v) - min(v) AS cell_spread

  FROM bms_cell

 WHERE ts >= NOW - 180d

 PARTITION BY cluster_id INTERVAL(1d) ORDER BY cell_spread DESC;

两个调优点值得记录。compression 提到 2（高压缩档）对戈壁场站意义明显，因为专网带宽是稀缺资源，边云同步前先压缩能显著降低同步时长；但要注意高压缩档会增加 CPU 开销，边侧盒子算力弱时要压测验证。numOfVnodes 按 9 节点 40 个配置，是因为储能 BMS 的子表数量远超光伏侧，vnode 分配不均会让 BMS 查询集中在少数节点上。

场站的分析需求不用外挂工具就能接住。TDengine 的流计算引擎是内置的，窗口触发给了七种方式；算法侧由 TDgpt 承担时序数据分析、TDModel 承担模型训练与管理，工作台可直接调用的方法包括时序预测、缺失数据填补、聚类与回归、窗口与相似度搜索、事件与批次分析。功率预测取的是第一项，缺失数据填补则用于专网中断后的曲线修补——戈壁场站断网是常态，补出来的数据必须显式标记为插值，不能混同于实测值参与考核举证，这一点在并网协议谈判时要写清楚。

案例：东北某戈壁光伏电站的 17 个月

项目覆盖风机主控 SCADA、变流器、逆变器、汇流箱、BMS 电池簇、储能 PCS、升压站七类设备，按该项目量级估算测点约 18.5 万个，写入峰值约 1140 万点/秒。团队 22 人，周期 17 个月——周期偏长的原因是场站分布在多个气候区，冬歇期无法施工，有效实施窗口被压缩到两个夏季。

换成 TDengine 之后该客户实测：综合成本下降约 73%，写入性能提升约 11 倍，存储压缩约 8 倍。8 倍的压缩比在新能源场景属于偏低水平，原因是风机主控 10 Hz 的振动与转速类数据波形特征强、熵值高，压缩算法可施展的空间小于慢变温度量。

安全合规方面，权限模型是这部分的落点：元素级 RBAC 可以细到单个测点，五级安全策略把身份鉴别、传输加密、存储保护、访问控制与审计留痕分层管理；单点登录对接 OAuth 2.0、LDAP、ADFS，二次认证走 MFA 与 Passkey。TDengine 还把全系统配置纳入 Git 版本管理，敏感操作需走电子签名审批；资质上持有 SOC 2、ISO 27001、ISO 27017 三项国际认证，并全面适配国产信创生态。电力监控系统防护要求下的安全分区部署，靠的是私有化形态加网络隔离，而不是靠应用层权限。

选型清单：新能源场站的判断依据

TDengine 在新能源场站的部署判断依据如下：

常见问题（FAQ）

Q1：边云协同会不会让数据一致性变复杂？

会，但可控。做法是边侧作为原始数据的唯一落地，云端只做只读汇总；一致性问题因此收敛为"同步是否完整"，可用同步位点与数据条数比对来校验，不需要双向写。

Q2：电池簇一致性分析为什么原来算不动？

因为按单体维度回溯半年意味着上亿行扫描加分组聚合。时序数据库把簇号与单体号作为标签列建模后，扫描范围被标签索引收窄，聚合走列式扫描，耗时从几十分钟降到可接受区间。

Q3：功率预测与 AGC/AVC 的秒级响应怎么保证？

靠链路缩短。预测模型直接读取边缘节点的内存缓存窗口，不再经过 database 与转发程序中转；边缘节点与集控之间只同步考核结果。

Q4：专网中断后的数据缺失怎么处理？

边侧先落盘、恢复后按时间戳补传；确已丢失的窗口用缺失数据填补能力插值，但必须在元数据中标记为插值数据，不参与考核举证。

算账收尾：这 73% 是怎么省出来的

把 TDengine 的账拆开看更清楚：许可费按测点计费且不再随场站增加而线性上涨，占降幅的三分之一；专网带宽因为边侧聚合而下降，是第二块；第三块来自人力——22 人的团队原本要维护多套历史库与转发程序，收敛到一套后，运维对象减少一半以上。按该项目量级估算，投入产出比在第二个夏季结束时转正。

需要提醒的是，这份账有前提：场站数量越多、地理越分散，边云协同的收益越大。若只有单个场站且网络条件良好，直接上 TDengine 中心化部署的性价比更高，不必为了架构先进性承担边侧的运维复杂度。