标题：从“人巡”到“智巡”，人力减 60%：TDengine 助力桂冠电力实现 AI 智能巡检

logo：

小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 个风电场，并网范围覆盖国家电网和南方电网的多个区域，资产分布于广西、四川、贵州等数个省市自治区，是一个集多能源、多网源、跨地域为一体的大型综合发电企业。

作者：桂冠电力

每次在 Apache SeaTunnel 里配置非关系型数据库，看着那几百行还要手动定义的字段映射，是不是挺崩溃的？配置错一个字段，任务就报错，这种“体力活”真的该结束了。

最近 Apache SeaTunnel 社区的 Issue #10339 提案捅破了这层窗户纸：既然有 Apache Gravitino 这么强大的元数据服务，为什么不直接让它自动同步 Schema？这个提议一出，社区反响热烈，核心维护者们已经把它列入了年度 RoadMap。目前的讨论很务实，大家正盯着怎么让 Apache SeaTunnel 在提交作业时自动‘抓取’最新的元数据，好让大家彻底告别那种‘对着数据库手敲配置’的原始生活。

🫱 Issue 链接： https://github.com/apache/seatunnel/issues/10339

Issue 概述

先来看看提交这个 Issue 的作者是为什么想到这个点子的，以及他初步的核心设计概念。🔽

本 PR 实现了 Apache Gravitino 与 SeaTunnel 的集成，将其作为非关系型连接器的外部元数据服务。通过 Gravitino 的 REST API 自动获取表结构和元数据，SeaTunnel 用户无需再在连接器配置中手动定义冗长且复杂的 Schema 映射。

背景

目前，Apache SeaTunnel 中的许多非关系型连接器（如 Elasticsearch、向量数据库和数据湖引擎）要求用户在作业配置中显式定义完整的列 Schema。这导致了以下问题：

• 配置繁琐且易错：字段映射内容冗长，极易发生人为错误。
• 架构冗余：不同作业之间存在大量重复的 Schema 定义。
• 数据不一致风险：实际存储层与 SeaTunnel 配置文件之间容易出现架构脱节。

变更内容

本 PR 增加了基于 Gravitino 的 Catalog 和 Schema 解析器，使 SeaTunnel 能够：

• 通过 REST API 从 Gravitino 查询表定义。
• 自动获取列名、数据类型及相关属性。
• 直接根据 Gravitino 元数据构建 SeaTunnel 内部 Schema。
• 针对受支持的连接器，取消强制手动定义 schema { fields { ... } } 的要求。

实现后，用户只需在作业配置中指定 Gravitino Catalog 和相关的表引用即可。

核心优势

• 零手动映射：非关系型数据源实现 Schema 自动对齐。
• 单一事实来源：确保表结构与中心化元数据仓库保持高度一致。
• 提升可靠性：显著提高配置的准确性，降低长期维护成本。
• 支持复杂类型：通过统一元数据，简化了对嵌套结构、JSON、向量等高级类型的处理。

执行范围

所有基于 Gravitino 的 Schema 解析和校验均在 SeaTunnel Engine 客户端完成（即在作业提交前）。这种设计确保了：

• 在作业预检阶段即可发现无效或不兼容的 Schema。
• 运行时的任务仅接收经过验证和标准化的 Schema，降低了执行失败的概率。

影响

这一更新极大地简化了非关系型连接器的作业设置。除了提升易用性，它还为整个 SeaTunnel 生态系统在统一架构管理、架构演进以及高级数据类型支持方面奠定了技术框架。

核心思路

针对 FTP、S3、ES、MongoDB 等半结构化与非结构化数据源，SeaTunnel 现支持通过 Gravitino REST API 自动解析表结构（Schema）。

需要注意的是，这并非要取代现有的显式配置，而是一项完全向前兼容的可选新机制。

解析优先级如下：

1. 显式配置（Inline Schema）永远优先

只要连接器配置中包含了 schema 代码块，SeaTunnel 就必须忽略 Gravitino，直接以显式定义的 Schema 为准。

FtpFile {
  path = "/tmp/seatunnel/sink/text"
  # ... 其他基础配置 ...
  
  # 只要这里定义了，就不会去查 Gravitino
  schema = {
    name = string
    age  = int
  }
}

2. 通过 env 全局配置 Gravitino（推荐模式）

SeaTunnel 已在引擎层面集成了 Gravitino Metalake。
在 env 中全局开启后，所有非关系型数据源都能直接通过名称引用 Schema。

env {
  metalake_enabled = true
  metalake_type    = "gravitino"
  metalake_url     = "http://localhost:8090/api/metalakes/metalake_name/catalogs/"
}

2.1 使用 schema_path 引用

FtpFile {
  # ... 基础配置 ...
  schema_path = "catalog_name.ykw.test_table"
}

2.2 使用 schema_url 引用

FtpFile {
  # ... 基础配置 ...
  schema_url = "http://localhost:8090/api/metalakes/laowang_test/.../tables/all_type"
}

3. 兜底逻辑：读取操作系统环境变量

如果在作业的 env 块中没有定义 Gravitino，SeaTunnel 会尝试从操作系统环境变量中读取以下配置：
metalake_enabled | metalake_type | metalake_url
其行为逻辑与第 2 节中的 env 配置完全一致。

4. 在连接器层级单独配置 Gravitino

如果全局没有配置元数据中心，也可以在具体的连接器（Connector）内部直接定义 Gravitino。

4.1 直接使用 schema_url

FtpFile {
  # ... 基础配置 ...
  metalake_type = "gravitino"
  schema_url = "http://localhost:8090/api/.../tables/all_type"
}

4.2 组合使用 metalake_url 与 schema_path

FtpFile {
  # ... 基础配置 ...
  metalake_type = "gravitino"
  metalake_url  = "http://localhost:8090/api/metalakes/metalake_name/catalogs/"
  schema_path   = "catalog_name.ykw.test_table"
}

5. 探测器定位 (Find detector)

系统会根据 metalake_type 自动匹配并加载对应的 REST API HTTP 探测器。

6. 映射与构建 CatalogTable

探测器调用拼接好的 URL 获取响应体（ResponseBody），随后将其交给映射器（Mapper）进行类型匹配，最终完成 CatalogTable 的构建。

7. 流程图如下

Issue 进展

目前，Apache SeaTunnel 项目核心贡献者对此提议给出了正面评价，并将其添加到 Apache SeaTunnel Roadmap 中。

Apache SeaTunnel PMC Member 对这个提议提出一些疑问，比如这种集成属于哪一层级，对多引擎兼容性的考量，类型转换的准确性等，并根据社区设计规范，要求发起者提交一份正式的设计文档（Design Document）。提交者的回复非常具有建设性，他通过 “客户端预处理”和“抽象 Catalog 接口” 这两个核心设计点，有效地回应了社区对于系统耦合度和运行稳定性的担忧。

目前，这个讨论的回到了该 Issue 的提交者手中，社区正在等待他提交那份正式的 Design Document。

可以看到，这个方案要是落地，咱以后写任务可能就一两行配置的事儿。目前设计稿正在打磨中，非常需要大家去评论区吐吐槽、提提建议，毕竟这个功能好不好用，咱们一线开发者最清楚。走，去 GitHub 围观一下，说不定你的一个提议就能决定下一个版本的样子！🔽
https://github.com/apache/seatunnel/issues/10339