小T导读：为推进 “数智运营” 转型，广西桂冠电力携手涛思数据，采用 TDengine 时序数据库构建智能巡点检系统，融合 AI 与智能终端打造“终端—边缘—云端”协同架构，破解水电巡检效率低、安全风险高等难题。TDengine 在其数据湖中承担 OT 数据核心存储角色，通过“一个设备一张表”“超级表”等设计简化架构，凭借内置时序计算与订阅机制显著提升效率。系统投运后，单机机组增效 2–5%，年增发电量约 3 亿 kW·h，监盘工作量减少超 60%，助力桂冠电力迈向 AI 驱动的数智运营新阶段。
业务背景：电力巡检 + AI
在水电行业从“传统运维”迈向“数智运营”的关键阶段，桂冠电力率先打破依赖人工的巡点检模式，携手涛思数据（TDengine）创新研发水电站智能巡点检系统。该系统融合无人机、机器人等智能终端与 AI 技术，构建“终端—边缘—云端”协同架构，实现巡点检作业覆盖率显著提升、故障响应更迅速、人力成本大幅降低，有效破解了水电行业巡检效率低、安全风险高的长期难题。
在 AI 的赋能下，我们实现了智能巡盘、智能告警、智能预警、智能处置等多项 AI 功能，把巡检工作从“人工主导”升级为“机器主导”的自动化监控模式。借助高级逻辑判断与辅助处置机制，系统能将设备事故处置由被动应对转化为主动预警，提前识别潜在风险并同步提供操作指导与优化方案，既显著提升机组运行的安全性与经济性，又大幅减轻运行人员的监屏劳动强度和心理压力。
同时系统的实施使得发电效率也得到显著提升：单台机组的增效约为 2-5%。主要水电机组应用后，每年可增加发电量约 3 亿 kW.h。系统的智能监盘功能实现了适用于少人、无人监盘的模式，减少了监盘 60% 以上的工作量，大幅减轻了运行人员的工作强度，进一步提高了监盘的准确性和响应速度。
本文将与大家分享 TDengine TSDB 在我们数据湖建设中发挥的关键作用。
业务上的具体应用实践
简化数据湖的存储架构
在数据湖当中，TDengine TSDB 作为数据湖的贴源层，支撑了全部 OT 数据的存储。如下表所示，OT 数据与 IT 数据之间有着明显的区别：
为在 OT 与 IT 数据上实现最佳性能，我们分别采用某关系型数据库与涛思数据 TDengine TSDB 作为 IT 层与 OT 层的存储组件，构建分层存储体系。架构图如下图所示：
在当前架构当中，TDengine TSDB 所具有的特性，使得海量 OT 数据的存储更加便捷：
- “一个设备一张表”的设计，非常直观地映射到 IoT 中各类设备的采集值模型；
- 超级表的设计，使得一次查询多个测点变得非常简单；
- 分布式的架构设计，可以支持横向扩展和纵向扩展，在同一层无需多集群；
- 虚拟分区策略，可以充分利用每一个节点的资源；
- 动态调整数据分布，可以避免单点资源瓶颈带来的业务阻塞；
- 特色的时序计算函数，使得大部分业务计算可以直接获取，同一区域内无需分层存储。
业务建模的约束设计
基于“一个设备对应一个子表”的建模原则，我们对设备及其点号的数据进行建模与存储。在建模过程中，需要重点解决以下几个问题：
- 设备维度的设计：确定用于描述设备的关键维度；
- 唯一性的设计：明确用于唯一标识设备的字段，即设备表的 Primary Key；
- 多维选择唯一性的设计：确定可用于唯一检索设备的多个字段组合，即设备表的 Candidate Key。
TDengine 的超级表具备标签列特性，可用于实现设备表的存储。各标签列相互独立，类似于关系型数据库中的字段。由于超级表不具备 Primary Key 和 Unique Index 机制，因此在实际应用中需要通过约定来实现约束：
- db_name：作为业务分割单元，不同 db_name 的服务于不同业务，保证同一业务内的 tbname 不重复，避免写入错误数据；
- tbname：作为单个系统的唯一性约束，用于单个业务范围内的真正唯一 id；
- tag::point_code：作为测点名字记录，用于单个业务领域内的唯一性标记；
- tag::mtype/station_name 等标签列：作为设备的属性进行描述，联合起来作为候选主键。
以单列模型的测点 pointdata 为例，表结构如下所示：
CREATE STABLE `all_station_st` (
`data_time` TIMESTAMP,
`point_value` DOUBLE
) TAGS (
`point_code` VARCHAR(20),
`addr` INT,
`mtype` VARCHAR(20),
`station_name` NCHAR(30),
`description` NCHAR(64),
`kks` VARCHAR(100),
`measure_code` VARCHAR(60),
`original_one` VARCHAR(40),
`original_two` VARCHAR(64),
`idx` NCHAR(32),
`status` TINYINT
)由于标签列之间缺少约束功能（如索引、主键），因此需要从业务上做验证和校验，才能保证最终唯一。期望 TDengine TSDB 后续能在这一个维度进行进一步开发，降低业务开发的复杂度。
内置时序计算优化业务效能
在我们的业务系统中，TDengine 以其卓越的性能与强大的时序计算能力，大幅简化了业务开发工作。
对于业务逻辑和部分智能算法而言，常常需要对时间戳进行对齐，并在指定频率下获取测量值，这就要求我们基于原始数据进行计算。传统做法有两种：
- 提前计算：通过定时计算或者流式计算，提前把降采样的结果计算完存放起来；
- 实时计算：通过查询原始数据，实时计算后返回给应用。
提前计算的优势在于能让应用以最快速度获取结果，但缺点是需要维护一整套定时调度机制，涉及任务调度、异常处理和补数等运维工作，复杂度较高。
实时计算能够保证每次计算结果都是最新的计算逻辑，缺点是计算耗时有可能太大，计算内存消耗过大。
而 TDengine 的特色时序计算，就很好地避免了这些问题。即使是在微服务 + 低代码的时代，TDengine 带来的业务简化依然具有重要价值。以获取测点的日平均值进行绘制为例：
提前计算的实现通常需要部署独立的 Java 程序并持续监控其运行状态。编写计算逻辑本身并不复杂，真正的工作量在于多出一套需要维护的应用，同时还要应对算法更新、数据更新带来的重算问题，使整个过程显得十分笨重。
实时计算是指在业务产生数据需求时，直接查询数据库中的原始数据并即时计算结果。在我们的场景中，这类操作往往会演变为 CPU + MEM + Network 的高负载任务——在 queryRawData 过程中，需要占用大量内存来缓存 TSDB 返回的原始数据，消耗 CPU 进行数据解析，同时占用大量网络带宽完成数据传输。
而使用 TDengine 内置的 interval 库函数进行计算，则很轻便的完成了这个计算。interval 库函数是一个时间窗口函数，可分为：滑动时间窗口、翻转时间窗口。在我们的业务当中，大多数情况下会采用等时间窗口的平均值计算方式。例如：
taos > select _wstart, avg(`point_value`) from db.$point_code where _c0 >= ‘2025-01-01’ and _c0 < ‘2025-02-01’ interval(1d);整个集群内存几乎没波动。做一个简单规模的查询对比：
# 在 1w 测点 10s 采样间隔，统计 7 天内的日平均值
# 使用 TDengine 的计算，只需要 1.14 秒
taos> select _wstart, count(*), avg(`current`), avg(`voltage`), avg(`phase`), tbname from test.meters partition by tbname interval(1d);
Query OK, 70000 row(s) in set (1.140877s)
# 对于提前计算，每日的计算，只是查询 1 天的数据就占用 15.49 秒：
taos> select * from test.meters where _c0 >= '2025-01-01' and _c0 < '2025-01-02' >> /dev/null;
Query OK, 14400000 row(s) in set (15.496163s)
# 对于实时计算，只是查询原始数据，就占用了 106.85 秒
taos> select * from test.meters >> /dev/null;
Query OK, 100800000 row(s) in set (106.852480s)通过上述的数据可以得到：
从上述数据可以看出，实时计算方案在性能上明显不及 TDengine 内置计算，因此在实际业务中几乎不会被采用。提前计算方案在应用次数超过 16 次后能够带来正向收益（实际业务中查看次数会很容易超过这个数量）。因此，我们在系统中同时采用了提前计算与内置计算的组合方案。其中，内置计算帮助我们有效减少了网络传输、内存占用、CPU 计算以及业务研发等多方面的开销。
订阅替代数据分发
作为企业级数据湖，我们既需要满足桂冠电力内部的数据共享，也要支撑与外部系统之间的数据分发。借助 TDengine 的订阅机制与 taosX 企业级同步组件，这一需求得到了高效而可靠的解决。
对于分发内容的类型，我们主要有 2 大类：
- 针对设备订阅，订阅设备的时序数据
# 选择部分设备进行同步，只订阅时序数据
create topic topic_fzd as select tbname,data_time,point_value from pointdata.all_station_st where status = 1 and idx in ('辐射','辐照度') ;- 针对业务进行订阅，需要订阅设备的元数据和时序数据
# 选择未知设备进行同步，并且同步元数据变动
create topic topic_longtan with meta as stable pointdata.all_station_st where status = 1 and station_name = 'DJK_LT_90000208'同步方式上，我们分为两大类：
- 目的地是 TDengine，应用使用 taosX 进行订阅和写入，保证稳定性。
- 目的地未知，应用由需求方使用官方 driver 编写，订阅对应的 topic，自行安排应用。
通过以上的 topic 方式和应用方式，我们解决了数据湖上的数据分发需求。与过往的其他大数据组件相比，属实是非常轻便了。
大规模的运维经验
在正式投产之后，我们经历过 3.0.3、3.3.4 和 3.3.6 多个大版本。测点规模从百万走向千万，是一个 10 倍增长的运维过程。在这里分享几个 TDengine TSDB 大规模集群运维的经验。
容量规划
基于桂冠的业务场景进行估算，我们最终使用了 64c256g * 3 的虚拟机运行 TDengine TSDB。按照双副本（企业版特性），每个 vgroup 处理 2w 的测点的经验数据，我们预估 64c*3 可以处理：
64 vnode/节点 * 3 节点 / 2 副本 * 20,000 测点/vgroup = 192,000 测点
实际过程中从刚上线的性能宽裕，逐步发展到后来的性能拮据。我们发现 20,000 测点/vgroup 这个经验数值，会随着业务应用的开发出现下滑。其核心原因在于业务开发的增多，会带来显著的 CPU 资源消耗。因此我们把预估方式调整为：
Unit = 20,000 / (insert_ratio + query_ratio) 测点/vgroup
其中 insert_ratio 代表写入强度，query_ratio 代表查询强度。可以初步分成几种情况：
- insert_ratio
- 0.5：代表数据频率已知，顺序写入，日常没有数据补写。
- 1.0：代表数据频率已知，大部分时候顺序写入，存在常规的数据补写、部分乱序写入
- 2.0：代表数据频率未知，大部分时候顺序写入，存在常规的数据补写、乱序写入
- query_ratio
- 0.5：代表常规有监控类查询（last/last_row），短期时间区间查询（7天内）。
- 1.0：代表常规有监控类查询（last/last_row），短期时间区间查询（7天内），伴随定期任务查询。
- 2.0：代表常规有监控类查询（last/last_row），短期时间区间查询（7天内），伴随定期任务查询，同时提供历史数据查询。
这部分经验分别对应：单个物联网项目、综合物联网平台和集团数据湖平台。
写在最后
在 TDengine TSDB 的多年应用过程中，桂冠电力团队与涛思数据团队共同积累了丰富的大规模运维经验，并将实践成果转化为补丁与功能回馈社区。同时桂冠也见证着 TDengine 从一个时序数据库，逐步走向一个成熟的时序存算平台。在未来的日子里，相信 TDengine 能够成为物联网的一个标准全栈解决方案，为我们的电力业务进一步释放业务价值。
关于广西桂冠
广西桂冠电力股份有限公司是中国大唐集团有限公司的二级企业，主要经营水电、火电、风电及其他清洁能源的开发及运营，电站检修、技术咨询业务，兼营有色金属加工、金融服务等业务。公司拥有广西龙滩、岩滩、平班等共 41 座水电站、1 座火电厂和广西、贵州、山东烟台 9 个风电场，并网范围覆盖国家电网和南方电网的多个区域，资产分布于广西、四川、贵州等数个省市自治区，是一个集多能源、多网源、跨地域为一体的大型综合发电企业。
