海量设备遥测数据，报表统计怎么做才不会慢？

场景：设备一多，统计就"算不出来"

在智能用电、能耗监测这类物联网项目中，设备通常以分钟级频次上报遥测数据。设想上千台设备、每台每天上报一千多条心跳与电量数据，日数据量可达百万级，月数据量数千万，年数据量更是以亿计。数据表一旦膨胀到这种规模，直接对明细做统计就会出现明显的性能瓶颈——例如计算一个区域的整体功率因数，因涉及设备多、时间跨度长，常规查询往往长时间无法返回，甚至超时失败。

更麻烦的是，电量尖峰平谷这类按时段划分的统计，必须依赖全量明细才能算准，无法靠简单粗粒度抽样规避。

核心矛盾：既要全量明细的精度，又要可用的查询速度

这类统计需求有三个共性特征，决定了不能简单地"少采点数据"来解决：

• 指标算法多元：有的指标要累加（如累计电量），有的要取均值（如功率因数），需按指标适配各自的统计方法。
• 统计维度灵活：既能按资产目录，也能按组织口径核算，往往以设备为最小统计单元，再借由设备与资产的关系做层级聚合。
• 需要历史回溯：报表要支持对过去任意时间段做回溯统计，需要纵向压缩时间维度的数据。

解决方案：按日聚合的"遥测汇总表"

可行的方向，是对海量明细遥测做按日预聚合：把每天、每台设备、每个指标的最基本统计结果（累计、条数、均值、最小、最大）提前算好、落成一张"每日汇总表"，报表查询时只读这张小得多的表，从而让统计性能获得量级提升。

• 数据自动累计：明细遥测写入时，通过触发器实时同步到按日汇总表。表中以"设备 + 指标 + 日期"为唯一键，累加当日累计值、累计条数与均值，并记录当日最小、最大值，冲突时自动合并更新。
• 只汇总需要的指标：并非所有遥测字段都需要聚合，通常只对数值型的关键指标做处理，需要哪些指标直接在触发逻辑中定义，无需额外维护一张参数表。
• 可随时重算：为避免一次性全量重算耗时过长，提供"按某天、某指标"局部重算的存储过程，可对指定日期区间逐日刷新，历史数据修正或补采后也能方便地对齐。

实施中的几个要点

• 建好覆盖索引：重算或回溯查询依赖"指标 + 时间 + 设备"的过滤，需为明细表建立覆盖所需字段的索引，否则批量重算会非常慢；聚合完成后再及时清理临时索引。
• 时区要统一：遥测时间戳多为 UTC 毫秒，聚合前需统一换算到目标业务时区（如北京时间）的"自然日"，否则日界会错位，导致统计跨天数据不准。
• 区分明细与汇总职责：实时看板、异常追溯仍读明细；面向趋势、累计、对比的报表读汇总表，两者各司其职，互不拖累。

为什么这体现的是"能不能把物联网真正用起来"

很多物联网项目卡在"数据收上来了，却因为太慢而没法做经营级分析"。按日聚合看似是一个数据库细节，实则是让海量设备数据从"能采集"走向"能决策"的关键一步——管理者需要的功率、电量、能耗趋势与时段分布，只有在统计能秒级返回时才有实际意义。共方在 ThingsBoard 二次开发与部署中，会针对客户的数据规模与统计需求做这类底层优化，确保上线的不是一套"能连上却跑不动"的系统。

小结

面对分钟级、上亿条的设备遥测数据，通过按日聚合汇总表 + 触发器实时累计 + 局部可重算，可以让经营级报表统计获得数量级的性能提升。这是共方 ThingsBoard 物联网服务在处理真实海量数据时的工程实践，也是保障智慧用电、能耗监测等项目"可统计、可回溯、可决策"的重要基础。