TDengine公共事业数据建模最佳实践

摘要

合理的数据建模是公共事业时序数据管理的基础。本文总结TDengine时序database在水、气、热等公共事业行业的数据建模最佳实践，包括超级表设计、标签优化、分区策略等关键技术要点。

 

正文

一、公共事业数据建模的挑战

水、气、热等公共事业行业的数据建模面临独特挑战：

数据维度复杂。 公共事业数据涉及用户、表计、区域、管网等多个层级，数据之间存在复杂的关联关系。

数据类型多样。 包括流量、压力、温度、累计量等不同类型，需要不同的存储和处理策略。

数据规模巨大。 大型城市可能有数百万只智能表计，数据建模需要考虑扩展性。

查询需求多样。 既需要实时监控的点查，也需要历史分析的范围查询，还有聚合统计等复杂查询。

时序数据库TDengine的超级表机制为公共事业数据建模提供了强大支持，通过合理的建模设计，可以实现高性能、易维护的数据管理。

二、超级表设计原则

2.1 按业务实体分类

-- 智能水表数据超级表

CREATE STABLE IF NOT EXISTS water_meter_data (

    ts TIMESTAMP,

    instant_flow FLOAT,

    total_volume DOUBLE,

    pressure FLOAT,

    temperature FLOAT,

    valve_status TINYINT,

    battery_level FLOAT,

    signal_strength INT,

    alarm_code INT

) TAGS (

    meter_id BINARY(32),

    meter_model BINARY(32),

    meter_size BINARY(16),

    district_id BINARY(32),

    community_id BINARY(32),

    building_id BINARY(32),

    user_id BINARY(32),

    user_type BINARY(16),

    install_date BINARY(16)

);

 

-- 智能燃气表数据超级表

CREATE STABLE IF NOT EXISTS gas_meter_data (

    ts TIMESTAMP,

    instant_flow FLOAT,

    total_volume DOUBLE,

    pressure FLOAT,

    temperature FLOAT,

    leak_alarm TINYINT,

    valve_status TINYINT,

    battery_level FLOAT,

    signal_strength INT

) TAGS (

    meter_id BINARY(32),

    meter_model BINARY(32),

    meter_size BINARY(16),

    district_id BINARY(32),

    community_id BINARY(32),

    building_id BINARY(32),

    user_id BINARY(32),

    user_type BINARY(16),

    gas_type BINARY(16)

);

 

-- 智能热量表数据超级表

CREATE STABLE IF NOT EXISTS heat_meter_data (

    ts TIMESTAMP,

    supply_temp FLOAT,

    return_temp FLOAT,

    temp_diff FLOAT,

    flow_rate FLOAT,

    heat_power FLOAT,

    total_heat DOUBLE,

    valve_status TINYINT,

    battery_level FLOAT

) TAGS (

    meter_id BINARY(32),

    meter_model BINARY(32),

    meter_size BINARY(16),

    district_id BINARY(32),

    community_id BINARY(32),

    building_id BINARY(32),

    user_id BINARY(32),

    heating_type BINARY(16),

    heat_source BINARY(16)

);

 

-- 管网监测数据超级表

CREATE STABLE IF NOT EXISTS pipeline_monitor_data (

    ts TIMESTAMP,

    pressure FLOAT,

    flow_rate FLOAT,

    temperature FLOAT,

    turbidity FLOAT,

    chlorine FLOAT,

    ph_value FLOAT,

    alarm_status TINYINT

) TAGS (

    point_id BINARY(32),

    point_type BINARY(16),

    district_id BINARY(32),

    pipeline_id BINARY(32),

    install_location BINARY(64)

);

2.2 子表创建策略

-- 为居民水表创建子表

CREATE TABLE IF NOT EXISTS wm_res_001 USING water_meter_data

TAGS ('WM202400001', 'Model-A', 'DN15', 'DIST001', 'COM001', 'BLD001', 'USER001', '居民', '2024-01');

 

CREATE TABLE IF NOT EXISTS wm_res_002 USING water_meter_data

TAGS ('WM202400002', 'Model-A', 'DN15', 'DIST001', 'COM001', 'BLD001', 'USER002', '居民', '2024-01');

 

-- 为工商业水表创建子表

CREATE TABLE IF NOT EXISTS wm_com_001 USING water_meter_data

TAGS ('WM202400101', 'Model-B', 'DN50', 'DIST002', 'COM010', 'BLD050', 'COM001', '工商业', '2024-02');

 

-- 为燃气表创建子表

CREATE TABLE IF NOT EXISTS gm_001 USING gas_meter_data

TAGS ('GM202400001', 'Model-G1', 'G16', 'DIST001', 'COM001', 'BLD001', 'USER001', '居民', '天然气');

 

-- 为热量表创建子表

CREATE TABLE IF NOT EXISTS hm_001 USING heat_meter_data

TAGS ('HM202400001', 'Model-H1', 'DN25', 'DIST003', 'COM020', 'BLD100', 'USER001', '集中供暖', '热电联产');

三、标签设计优化

3.1 标签选择原则

-- 优化前：标签过多

CREATE STABLE IF NOT EXISTS meter_data_bad (

    ts TIMESTAMP,

    reading_value FLOAT

) TAGS (

    meter_id BINARY(32),

    meter_name BINARY(64),

    meter_desc BINARY(128),

    manufacturer BINARY(32),

    serial_number BINARY(32),

    district_id BINARY(32),

    district_name BINARY(64),

    community_id BINARY(32),

    community_name BINARY(64),

    building_id BINARY(32),

    building_name BINARY(64),

    user_id BINARY(32),

    user_name BINARY(64),

    user_phone BINARY(16),

    user_address BINARY(128)

);

 

-- 优化后：精简标签

CREATE STABLE IF NOT EXISTS meter_data_optimized (

    ts TIMESTAMP,

    reading_value FLOAT

) TAGS (

    meter_id BINARY(32),      -- 唯一标识

    district_id BINARY(32),   -- 区域ID，用于分组

    community_id BINARY(32),  -- 小区ID，用于过滤

    user_type BINARY(16)      -- 用户类型，用于分类

);

3.2 标签索引优化

-- 创建带有复合标签的超级表

CREATE STABLE IF NOT EXISTS optimized_meter_data (

    ts TIMESTAMP,

    flow_rate FLOAT,

    total_volume DOUBLE,

    pressure FLOAT

) TAGS (

    -- 复合标签：区域_小区_表计

    location_id BINARY(64),

    -- 表计类型：水表/燃气表/热量表

    meter_category BINARY(16),

    -- 用户类型：居民/工商业

    user_category BINARY(16)

);

 

-- 子表创建示例

CREATE TABLE IF NOT EXISTS wm_001 USING optimized_meter_data

TAGS ('DIST001_COM001_WM001', '水表', '居民');

 

CREATE TABLE IF NOT EXISTS gm_001 USING optimized_meter_data

TAGS ('DIST002_COM010_GM001', '燃气表', '工商业');

四、分区策略设计

4.1 时间分区

-- 创建数据库时设置分区参数

CREATE DATABASE IF NOT EXISTS utility

    KEEP 3650        -- 保留10年数据

    DAYS 30          -- 每30天一个数据文件

    BLOCKS 6         -- 每表6个内存块

    COMP 2           -- 压缩级别

    CACHEMODEL 'both';  -- 缓存最近数据和最新数据

 

-- 查看分区信息

SELECT

    table_name,

    start_time,

    end_time,

    rows,

    blocks,

    compressed_size

FROM information_schema.ins_partitions

WHERE db_name = 'utility'

ORDER BY start_time DESC

LIMIT 10;

4.2 查询性能优化

-- 高效查询：使用标签过滤

SELECT

    AVG(flow_rate) as avg_flow,

    SUM(flow_rate) as total_flow

FROM water_meter_data

WHERE district_id = 'DIST001'

    AND user_type = '居民'

    AND ts > NOW - 1d;

 

-- 高效查询：精确时间范围

SELECT

    _irowts as ts,

    AVG(flow_rate) as avg_flow,

    MAX(pressure) as max_pressure,

    MIN(flow_rate) as min_flow

FROM water_meter_data

WHERE ts >= '2024-01-01 00:00:00'

    AND ts < '2024-01-02 00:00:00'

    AND community_id = 'COM001';

 

-- 使用INTERVAL进行降采样

SELECT

    _irowts as ts,

    AVG(flow_rate) as avg_flow,

    SUM(total_volume) as daily_volume

FROM water_meter_data

WHERE district_id = 'DIST001'

    AND ts > NOW - 7d

INTERVAL(1h)

FILL(PREV);

五、数据生命周期管理

5.1 数据保留策略

-- 设置数据库保留策略

ALTER DATABASE utility KEEP 3650;  -- 保留10年

 

-- 设置数据文件保留天数

ALTER DATABASE utility DAYS 30;

 

-- 查看数据库配置

SELECT

    name,

    `keep`,

    days,

    blocks,

    cachemodel,

    precision

FROM information_schema.ins_databases

WHERE name = 'utility';

5.2 数据归档与清理

# Python脚本：数据归档管理

import taos

from datetime import datetime, timedelta

 

def archive_old_data():

    conn = taos.connect(host="localhost", database="utility")

    cursor = conn.cursor()

    

    # 查询3年前的数据量

    three_years_ago = (datetime.now() - timedelta(days=3*365)).strftime('%Y-%m-%d')

    

    cursor.execute(f"""

        SELECT

            COUNT(*) as record_count,

            MIN(ts) as min_time,

            MAX(ts) as max_time

        FROM water_meter_data

        WHERE ts < '{three_years_ago}'

    """)

    

    result = cursor.fetchone()

    if result and result[0] > 0:

        print(f"发现 {result[0]} 条3年前的历史数据")

        print(f"数据时间范围: {result[1]} 至 {result[2]}")

        

        # 导出数据到文件

        cursor.execute(f"""

            SELECT * FROM water_meter_data

            WHERE ts < '{three_years_ago}'

            INTO OUTFILE '/backup/water_meter_archive_{three_years_ago}.csv'

        """)

        print(f"数据已导出到 /backup/water_meter_archive_{three_years_ago}.csv")

    

    cursor.close()

    conn.close()

 

if __name__ == "__main__":

    archive_old_data()

六、实施效果

某水务集团采用TDengine进行数据建模后的效果：

查询性能提升。 通过合理的数据建模和标签设计，查询响应时间从秒级降至毫秒级，复杂分析查询速度提升10倍。

存储效率提高。 通过高效压缩和合理分区，存储空间占用降低至原来的1/5，年存储成本节省超过300万元。

运维成本降低。 自动化分区管理和数据保留策略，减少了DBA的运维工作量。

开发效率提升。 清晰的数据模型和标准的命名规范，降低了开发人员的理解成本，开发效率提升30%。

七、最佳实践总结

1. 合理设计超级表： 根据业务实体设计超级表，避免过度细分或过度聚合。

2. 优化标签设计： 标签用于数据过滤和分组，应选择合适的标签字段以提高查询效率。

3. 设置合理的保留策略： 根据业务需求和法规要求，设置合理的数据保留期限。

4. 监控存储使用情况： 定期监控存储空间使用情况，及时发现和解决存储瓶颈。

5. 利用压缩优势： 充分利用TDengine的压缩能力，降低存储成本。

6.标准化命名规范： 建立统一的命名规范，提高代码可读性和维护性。

TDengine时序database为水、气、热等公共事业行业提供了灵活、高效的数据建模能力，通过合理的建模设计，可以帮助企业构建高性能、易维护的数据基础设施。