Enabling AI-Based Intelligent Inspection: A 60% Reduction in Manual Work with TDengine

TDengine Team

December 16, 2025 / News

At a critical stage when the hydropower industry is transitioning from traditional operations and maintenance to intelligent, digital operations, China Datang Corporation’s subsidiary Guangxi Guiguan Electric Power took the lead in breaking away from labor-intensive inspection routines. Working with TDengine, the company developed an intelligent inspection and patrol system for hydropower stations. By integrating intelligent terminals such as drones and robots with AI technologies, the system establishes a coordinated “device–edge–cloud” architecture. This approach significantly improves inspection coverage, accelerates fault response, and substantially reduces labor costs—effectively addressing long-standing challenges in the hydropower industry, including low inspection efficiency and high safety risks.

The deployment of the system has also led to notable improvements in power generation efficiency. Each generating unit achieves an efficiency gain of approximately 2–5%. After being applied to major hydropower units, the system enables an annual increase in electricity generation of about 300 million kWh. Its intelligent monitoring capabilities support low-staffed or unmanned operation modes, reducing monitoring workload by more than 60%, greatly easing operational burdens while further improving monitoring accuracy and response speed.

This article shares how TDengine TSDB plays a key role in the construction of the data lake.

Simplifying the Data Lake Storage Architecture

Within the data lake, TDengine TSDB serves as the source (ingestion) layer, supporting the storage of all OT data. As shown in the table below, there are clear differences between OT data and IT data:

Dimension	IT	OT
Objective	Support business management and data workflows	Enable control and automation of physical industrial processes
Core focus	Data and information	Physical equipment and industrial processes
Real-time requirements	Can tolerate some latency (seconds to minutes)	Strict real-time requirements (milliseconds)
Security priority	Data confidentiality and integrity	System reliability and physical safety
Typical technologies	Data storage, software applications, network communication	Industrial equipment monitoring, real-time operational optimization
Typical systems	ERP, CRM, databases	SCADA, DCS, PLC, APC, sensors
Typical protocols	TCP/IP, HTTP, SQL	OPC, Modbus, IEC 104
System upgrade cycle	Fast (1–3 years)	Slow (5–30 years)

To achieve optimal performance for both OT and IT data, the company adopted a layered storage architecture, using a relational database for the IT layer and TDengine TSDB for the OT layer. This approach enables each type of data to be stored and processed by the most suitable system. The overall architecture is shown in the diagram below:

In the current architecture, the capabilities of TDengine TSDB make large-scale OT data storage much more efficient and manageable:

The “one table per device” design provides an intuitive mapping to the data acquisition models of various IoT devices.
The supertable mechanism makes it straightforward to query data across multiple measurement points in a single operation.
The distributed architecture supports both horizontal and vertical scaling, eliminating the need for multiple clusters within the same layer:
- A virtual partitioning strategy enables full utilization of resources on each node.
- Dynamic data redistribution helps avoid business interruptions caused by single-node resource bottlenecks.
Built-in time-series computation functions allow most business calculations to be performed directly within the database, removing the need for additional layered storage within the same domain.

Constraint Design for Business Modeling

Based on the modeling principle of “one device per subtable,” the company models and stores data for devices and their measurement points accordingly. During the modeling process, the following key issues must be addressed:

Device dimension design: identifying the key dimensions used to describe a device.
Uniqueness design: defining the field used to uniquely identify a device, equivalent to the Primary Key of a device table.
Multi-dimensional uniqueness design: determining combinations of fields that can uniquely identify a device, equivalent to Candidate Keys in a device table.

TDengine’s supertables support tag columns, which are used to store device metadata. Each tag column is independent, similar to fields in a relational database. Since supertables do not support primary keys or unique indices, constraints must be enforced through conventions in practical use:

db_name: serves as a business-level partition. Different db_name values correspond to different businesses, ensuring that tbname values do not conflict within the same business domain and preventing incorrect data writes.
tbname: acts as the uniqueness constraint for a single system and serves as the true unique identifier within a specific business scope.
tag::point_code: records the measurement point name and serves as a uniqueness identifier within a given business domain.
Tag columns such as tag::mtype, station_name, etc.: describe device attributes and are combined to form candidate keys.

Taking the single-column measurement-point model pointdata as an example, the table structure is as follows:

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
)

Built-in Time-Series Computation Improves Business Efficiency

In the company’s business systems, TDengine significantly simplifies application development thanks to its excellent performance and powerful built-in time-series computation capabilities.

For business logic and certain intelligent algorithms, it is often necessary to align timestamps and retrieve measurement values at a specified frequency, which requires computation based on raw data. Traditionally, there are two common approaches:

Precomputation: Downsampling results are calculated in advance through scheduled jobs or stream processing and then stored for later use.
Real-time computation: Raw data is queried and calculated on the fly before being returned to the application.

The advantage of precomputation is that applications can retrieve results very quickly. However, it requires maintaining a complete scheduling system, including job scheduling, exception handling, and backfilling, which introduces significant operational complexity.

Real-time computation ensures that results always reflect the latest logic, but it can incur high computation latency and excessive memory consumption.

TDengine TSDB’s built-in time-series computation effectively avoids these issues. Even in the era of microservices and low-code development, the business simplification brought by TDengine remains highly valuable. For example, consider the case of calculating and visualizing daily average values for a measurement point:

Precomputation typically requires deploying a separate Java application and continuously monitoring its runtime status. While the computation logic itself is not complex, the real workload comes from maintaining an additional application and handling re-computation triggered by algorithm updates or data changes, making the overall process heavy and cumbersome.

Real-time computation, on the other hand, involves querying raw data directly from the database and calculating results on demand when the business requires them. In this business scenario, this approach often turns into a high-load operation across CPU, memory, and network resources. During the queryRawData process, large amounts of memory are consumed to cache raw data returned by the TSDB, CPU resources are used to parse the data, and significant network bandwidth is required for data transmission.

By contrast, using TDengine’s built-in interval function makes this type of computation lightweight and efficient. The interval functions are time-window functions that include sliding windows and tumbling windows. In this business scenario, equal-interval window average calculations are used most of the time. For example:

select _wstart, avg(`point_value`) from db.$point_code where _c0 >= ‘2025-01-01’ and _c0 < ‘2025-02-01’ interval(1d);

The memory usage across the entire cluster showed almost no fluctuation. Let’s look at a simple, small-scale query comparison:

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)

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)

taos> select * from test.meters >> /dev/null;
Query OK, 100800000 row(s) in set (106.852480s)

The results clearly show that the real-time computation approach performs significantly worse than TDengine’s built-in computation, and therefore is rarely adopted in actual business scenarios. The precomputation approach begins to deliver positive returns once the number of application accesses exceeds 16 times — a threshold that is easily surpassed in real-world use.

As a result, the company adopted a hybrid approach that combines precomputation with built-in computation. Among these, TDengine’s built-in computation effectively reduces overhead across multiple dimensions, including network transmission, memory usage, CPU consumption, and overall business development effort.

Using Subscriptions to Replace Traditional Data Distribution

For this enterprise-level data lake, it is necessary to support both internal data sharing within the company and data distribution to external systems. With TDengine’s subscription mechanism and the taosX enterprise-grade synchronization component, these requirements are addressed in an efficient and reliable manner.

In terms of the types of data being distributed, there are two main categories:

Device-oriented subscriptions, which subscribe to time-series data generated by specific devices.

create topic topic_fzd as select tbname,data_time,point_value from pointdata.all_station_st where status = 1 and idx in ('辐射','辐照度') ;

Business-oriented subscriptions, which require subscribing to both device metadata and time-series data.

create topic topic_longtan with meta as stable pointdata.all_station_st where status = 1 and station_name = 'DJK_LT_90000208'

Synchronization methods are divided into two main categories:

When the destination is TDengine, applications use taosX for subscription and writing, ensuring stability.
When the destination is unknown, downstream consumers develop their own applications using official drivers, subscribe to the relevant topics, and manage application execution on their own.

Through this topic-based approach and flexible application model, data distribution requirements have been addressed across the data lake. Compared with other big data components, this solution is truly lightweight.

Large-Scale Operations Experience

After the system went into production, the company went through several major TDengine versions, including 3.0.3, 3.3.4, and 3.3.6. During this period, the scale of measurement points grew from millions to tens of millions, a tenfold increase that posed significant operational challenges. Below are several lessons learned from operating TDengine TSDB at large cluster scale.

Capacity Planning

Based on the company’s business scenarios, TDengine TSDB was deployed on virtual machines with a configuration of 64 cores, 256 GB memory × 3 nodes. Using dual replicas (an Enterprise feature) and based on empirical data where each vgroup handles approximately 20,000 measurement points, it was initially estimated that a 3-node cluster with 64 cores per node could handle:

64\ \text{vnodes}/\text{node} \times 3\ \text{nodes} \div 2\ \text{replicas} \times 20000\ \text{points}/\text{vgroup} = 192000\ \text{measurement points}

In practice, the system evolved from having ample performance headroom at launch to becoming increasingly resource-constrained over time. It was observed that the empirical value of 20,000 points per vgroup tends to decline as business applications grow. The core reason is that additional business logic significantly increases CPU consumption.

As a result, the estimation method was adjusted to:

\text{Unit} = 20000 \div (\text{insert\_ratio} + \text{query\_ratio})\ \text{points per vgroup}

Where insert_ratio represents write intensity, and query_ratio represents query intensity. These can be roughly categorized as follows:

insert_ratio

0.5: Known data frequency, sequential writes, no regular backfilling
1.0: Known data frequency, mostly sequential writes, with routine backfilling and some out-of-order writes
2.0: Unknown data frequency, mostly sequential writes, with routine backfilling and frequent out-of-order writes

query_ratio

0.5: Regular monitoring queries (last / last_row) and short time-range queries (within 7 days)
1.0: Regular monitoring queries, short time-range queries, plus scheduled task queries
2.0: Regular monitoring queries, short time-range queries, scheduled task queries, and historical data queries

These experience-based parameters correspond respectively to a single IoT project, an integrated IoT platform, and a group-level data lake platform.

About Guangxi Guiguan Electric Power

Guangxi Guiguan Electric Power is a subsidiary of China Datang Corporation. Its core businesses include the development and operation of hydropower, thermal power, wind power, and other clean energy projects, as well as power plant maintenance and technical consulting services. The company also engages in non-ferrous metal processing, financial services, and other diversified businesses.

Guiguan Electric Power is a large-scale integrated power-generation enterprise characterized by multiple energy types, multiple grid systems, and cross-regional operations. The company owns 41 hydropower stations along with one thermal power plant and nine wind farms located across Guangxi, Guizhou, and Shandong. Its grid connections span multiple regions served by both the State Grid and China Southern Power Grid.