建筑能耗数据架构：跨系统能效优化的存储与查询实践
建筑能耗数据的分项计量体系
大型商业建筑（商场、写字楼、综合体）的能耗管理需要分解到具体用能终端，才能识别节能空间。时序数据库在此承担分项计量数据的统一存储角色。国家标准GB 50189《公共建筑节能设计标准》和GB/T 51361《公共建筑能耗远程监测系统技术规程》明确了分项计量的技术要求。
分项计量将建筑能耗拆解为四个一级分项：照明插座用电（照明、插座、公共照明）、空调用电（冷热源、空调末端、通风）、动力用电（电梯、给排水、机械动力）、特殊用电（信息中心、厨房、其他）。每个一级分项进一步拆分为二级分项——空调用电下分为冷热源、空调箱（AHU）、风机盘管（FCU）、新风机组。二级分项下再按物理区域拆分（楼层、功能区、租户）。
数据采集点位的物理分布极为分散。一座10万平方米的写字楼，计量点位数量在2000-5000之间：电力计量（智能电表+互感器）覆盖总进线、分回路、楼层、租户，水计量覆盖进水、中水、回水，燃气计量覆盖锅炉房、厨房。暖通空调参数包括AHU的送回风温湿度、冷冻水供回水温度、冷却水温度、水泵频率、冷水机组COP。
采样间隔方面，GB/T 51361要求能耗数据采集间隔不大于15分钟。实际工程中，电表数据采集间隔多为1-15分钟，暖通参数采集间隔15秒-1分钟。一座2000个计量点的建筑，15分钟采样间隔下日均数据量19.2万条；如果暖通参数按1分钟采样（约500个点位），日均暖通数据72万条。合计日均近百万条数据点，年数据量3-4亿条。
传统BMS的跨系统数据断层
建筑能耗管理的技术困难不在于数据采集，而在于数据整合。现代建筑通常部署了多个独立子系统：
- BMS（楼宇管理系统）管理暖通空调的运行数据和设备控制
- 电力监控系统管理电表数据和配电回路状态
- 能耗计量系统管理分项计量数据
- 给排水系统管理水泵运行和水箱液位
- 照明控制系统管理公共照明回路
各子系统采用不同的通信协议（BACnet、Modbus、OPC UA、KNX）和不同的数据库（SQL Server、MySQL、InfluxDB）。系统间数据不共享，跨系统分析需要从多个系统导出数据后手动拼接。
跨系统分析的缺失直接影响节能决策的质量。一个典型场景：空调能耗占建筑总能耗的40%-60%，但仅靠空调系统的运行数据无法判断能耗是否合理——需要将空调用电与室外温湿度、室内温度设定值、人员占用数据关联分析。这些数据分布在BMS（暖通参数）、电力监控（空调用电）、气象服务（室外温湿度）、门禁系统（人员占用）四个独立系统中。
数据断层还导致需量管理失效。电力公司的两部制电价中，基本电费按最大需量（当月15分钟平均功率最大值）计收。降低最大需量需要实时监测各回路功率并预测峰值。当电力监控系统与空调系统不联动时，空调启动导致的功率叠加无法被预测和控制，需量超限损失难以避免。
能耗数据的统一存储架构
统一的能耗数据存储层是打破系统间数据孤岛的技术路径。将电表数据、暖通参数、水气数据、环境数据统一写入时序数据库，通过分项、区域、系统三个维度的标签实现跨数据源的关联查询。
数据模型设计上，能耗数据天然适配超级表结构。设计多个超级表覆盖不同数据类别：
超级表名称 | 标签字段 | 测量字段 | 采集间隔 | 数据来源 |
electricity_meter | 建筑/楼层/回路/分项类型 | 有功功率/无功功率/电压/电流/电度 | 1-15min | 电力监控系统 |
hvac_ahu | 建筑/楼层/机组号 | 送风温度/回风温度/风量/水阀开度 | 15s-1min | BMS |
hvac_chiller | 建筑/机组号 | 冷冻水温度/冷却水温度/COP/负荷率 | 15s-1min | BMS |
water_meter | 建筑/楼层/用途 | 瞬时流量/累计流量 | 5-15min | 给排水系统 |
environment | 建筑/楼层/位置 | 温度/湿度/CO2/PM2.5 | 1-5min | 环境传感器 |
标签设计中的反模式需要注意。租户ID不应作为标签值——商业建筑的租户变更频繁，租户搬出后回路重新分配给新租户，标签值变更会导致历史数据归属混乱。正确做法是将回路号作为标签，租户与回路的映射关系在外部关系表中维护，查询时通过JOIN关联。
能效指标计算的数据查询模式
建筑能效分析依赖多个指标的计算，每个指标的查询模式对存储引擎有不同要求。
EUI（Energy Use Intensity，单位面积能耗）是建筑能效的基准指标，单位kWh/m²·年。计算需要全年总用电量除以建筑面积。查询模式简单——对electricity_meter超级表按时间范围（1年）聚合电度字段，结果除以建筑面积。这一查询每年执行一次，对存储引擎性能要求不高。
PUE（Power Usage Effectiveness）是数据中心能效指标，PUE = 总能耗 / IT设备能耗。计算要求高频实时——大型数据中心的PUE要求15分钟更新一次。查询模式是对electricity_meter超级表中总进线电表和IT设备回路电表按15分钟窗口聚合有功功率，计算比值。连续查询每15分钟执行一次，写入PUE结果到专门的指标表。PUE的实时性要求意味着聚合计算必须在数据写入后15分钟内完成，对存储引擎的聚合查询性能有要求。
COP（Coefficient of Performance，制冷效率）是冷水机组的能效指标，COP = 制冷量 / 输入功率。制冷量通过冷冻水流量和供回水温差计算，输入功率从电表读取。这一计算涉及两个超级表的JOIN查询——hvac_chiller的流量和温度字段，electricity_meter的功率字段。时间戳对齐是JOIN的工程难点：冷冻水温度1分钟采样，电表功率15分钟采样，需要对齐到同一时间窗口。实践中通过降采样解决——将1分钟采样的冷冻水数据降采样到15分钟均值，再与电表数据JOIN。
峰谷分析是需量管理的数据基础。查询模式是按小时聚合所有回路的有功功率，绘制全天功率曲线。分析重点包括：峰值时段定位（通常出现在工作日9:00-11:00和14:00-16:00）、峰谷差分析、空调启动对功率曲线的贡献度。连续查询按15分钟窗口计算各回路平均功率，峰谷分析基于这些预聚合数据完成，避免每次分析都扫描原始15分钟数据。
连续查询与降采样的工程实践
15分钟聚合是建筑能耗场景最核心的降采样粒度。GB/T 51361要求能耗数据至少15分钟分辨率，连续查询按15分钟窗口对原始1分钟采样数据做聚合，将结果写入降采样表。降采样表的数据量是原始数据的1/15，查询效率显著提升。
连续查询的设计需要注意时间窗口的边界对齐。15分钟窗口应对齐到整点（00:00、00:15、00:30、00:45），而非从第一条数据到达开始计算。时间窗口不对齐会导致跨窗口的数据被错误分配，影响EUI和PUE计算的准确性。
多级降采样是长期存储的标准策略。1分钟原始数据保留7天（支撑实时调试），15分钟聚合数据保留1年（支撑月度能效报告），1小时聚合数据保留5年（支撑年度趋势分析）。三级降采样下，5年总数据量从原始数据的约18亿条压缩到1小时聚合表的约4.4万条，存储效率提升4000倍。
TDengine在建筑能耗场景的技术适配
TDengine的超级表标签模型适配建筑能耗的多层级分项结构。标签字段映射建筑→楼层→回路→分项类型的层次，查询时通过标签过滤快速定位特定分项或区域的数据。连续查询功能支撑15分钟、1小时多级降采样的自动执行，无需外部定时任务调度。
跨超级表查询能力在COP计算等场景中有实际需求——冷机参数和电表数据分属不同超级表，需要通过时间戳对齐做JOIN。TDengine支持通过子查询实现跨表关联，虽然性能不如单表聚合，但在15分钟降采样后的数据量下查询延迟可接受。
建筑能耗场景的写入特征平稳——采集间隔固定，无突发写入峰值，不像工业机器人或晶圆厂场景存在写入高峰。这一特征使得TDengine的内存缓冲和刷盘策略可以配置为低延迟模式（缩短刷盘间隔），换取更好的查询实时性，而不用担心写入吞吐压力。
结语
建筑能效管理的数字化转型面临的核心问题不是数据采集能力不足，而是跨系统数据整合能力缺失。暖通、电气、给排水、照明各系统已建立完善的采集体系，但数据在各自系统内形成孤岛，无法支撑跨系统的能效分析。时序数据库作为统一存储层的建立是打通数据孤岛的基础设施，但真正的能效优化还需要将存储层与控制层打通——从发现空调能耗异常到自动调整冷机运行策略，这一闭环的建立才是智慧建筑能效管理的终极目标。
