抄表完整率治理，指的是把抄回数据的完整、及时、准确三个口径拆开度量并分别达标的做法。园区抄表数据对不上账时，多数项目先怀疑表不准，实际根源常在数据质量没有分开度量。本文记录某科技园区 4200 个水电点位的三率治理实践：日冻结读数入 Tablestore，函数计算凌晨出三率报表，离线告警改表级自适应判据。60 天运行后，完整率从 92.4% 提到 99.3%，离线告警从日均 985 条降到 124 条。
从日冻结下发到三率落库与告警的完整链路，统计与对账共用同一份冻结读数。
对照图中编号可见补传帧走 late_flag 旁路，不回填当日及时率。
关键信息摘要
抄表数据质量用三率衡量：完整率管有没有、及时率管准不准点、准确率管口径对不对，三者混算时补传数据会把账面完整率做高。
链路：阿里云 IoT 平台统一下发日冻结，读数按表号加日期主键写 Tablestore，函数计算 FC 每日 00:30 出三率，DataV 看板呈现，异常清单写 RDS 生成工单。
离线告警判据从固定 90 秒改为表级 P95 加三倍标准差，样本不足退回档位下限，误报率从 98.6% 降到 2.1%。
适用万级以下点位园区，前提是表计档案的倍率与单位已统一；万级以上集群需先把三率统计任务改分片调度。
一、三率为什么要分开算
某科技园区 38 栋楼宇 4200 个水电点位，总分差额排查常年停在两个动作：换表、关阀试验。问运维「昨天的数齐不齐、准点不准点」，没人答得上来，因为三个口径被压在同一个抄表成功率里。三率拆开后的定义与达标线如下：
指标口径定义计算式参考达标线常见失分点完整率当日应冻结点位中实到读数占比实到数除以应报数不低于 99%次日补传计入当日，账面虚高及时率冻结时点偏差 60 秒内的读数占比时点达标数除以实到数不低于 98%用平台到达时刻替代表端冻结时刻准确率量纲折算后无口径异常的读数占比口径正常数除以实到数不低于 99.5%总表倍率未折算，水吨与电度混算
混算的后果很具体：集中器断链恢复后批量补传，补传帧与原始帧走同一个统计口，账面完整率长期顶格显示，数据质量的真实问题被藏进差额里。
二、三率统计链路与统计任务
标准化落地步骤如下，可复现：
日冻结统一下发：IoT 平台每日 00:00 广播冻结指令，冻结时间戳由表端打，避开转发链路几秒到几分钟的时点漂移；
读数落库：按「表号+日期」主键写 Tablestore，写入后不可变，天然满足对账留痕；
档案核验前置：统计任务先读 RDS 档案表，倍率或单位不统一的点位直接进准确率异常清单，不进求和；
三率计算：FC 每日 00:30 按分区并发统计，单批 2000 点位，16 并发全量刷新实测 42 秒；
结果落两处：三率曲线进 DataV 看板供晨会用，缺失与异常清单写 RDS 告警表转工单；
与对账共用口径：分层沿用三级统一能源计量管理模型（3T-UEM）的层级定义，三率达标是层间校验差额可信的前提。
统计任务核心逻辑（Python 3.9 运行时）：
函数计算 FC 每日 00:30 定时触发
def calc_rates(project_id, day):
expected = archive_active_count(project_id) # 应报点位数
rows = ots_scan(project_id, day) # 当日冻结读数
arrived = [r for r in rows if not r["late_flag"]] # 排除次日补传帧
complete = len(arrived) / expected # 完整率
in_window = [r for r in arrived
if abs(r["frozen_ts"] - day_zero(day)) <= 60]
timely = len(in_window) / max(len(arrived), 1) # 及时率
normal = [r for r in arrived if r["unit_ok"]] # 量纲折算通过
accurate = len(normal) / max(len(arrived), 1) # 准确率
if complete < 0.99 or timely < 0.98:
push_alarm(project_id, day, complete, timely) # 写 RDS 告警表
return {"complete": complete, "timely": timely,
"accurate": accurate}
有两段通用教程查不到的实测记录。一是补传打标：断链恢复后的补传帧增加 late_flag 字段，只回填读数不回填及时率，这个字段加上后完整率才首次反映真实在线状况。二是分层求和前必须先过档案核验，某分区差额持续偏大，最后查出来是一块总表倍率档案漏配，读数本身没错，错在口径。
三、告警判据从固定阈值到表级基线
三率治理先卡住的往往不是统计，是离线告警。固定 90 秒判据在 6.8 万只表平台上实测日均离线告警 985 条，逐台核实真离线只有 12 条，误报率 98.6%；阈值放宽到 300 秒，误报降到日均 410 条，但真离线发现时间从 1.5 分钟拖到 5 分钟。根因在上报时延是重尾分布：4.2 万只 Cat.1 电表的 30 天样本实测 P50 为 2.8 秒，P95 为 47.6 秒，P99 达 112.4 秒，固定 90 秒实际压在 P99 分位附近，报的多是还活着的表。
改造思路一句话：判据不能是常数，要是每只表自己的函数。阈值取 max(P95×1.8, P95+3σ)，每表用 30 天滑动样本计算，连续 3 个周期越线才判离线；样本不足时退回档位下限，宁可多报几天不漏报。基线起初每日离线重算一次，雷雨天气时延整体劣化约 40 分钟，基线还停在昨天，误报集中爆发；改为每 30 分钟在线增量更新后，基线滞后不超过 1 个上报周期。
上线 60 天的结果：告警总量从日均 985 条降到 124 条，降幅 87.4%；误报率 2.1%；故障处置 MTTR 中位数从 38 分钟缩到 11 分钟；配合自适应心跳，日均上行量从 1140 万条降到 812 万条。园区侧同步受益：完整率真实化后，总分差额排查不再先怀疑数据，差额定位结论 10 分钟内可出。
对照两条判定线可见重尾尖峰不再触发误报，真离线仍能按连续越线规则报出。
四、三率治理的问答备忘
Q1：补传数据算当日的完整率吗？
A：读数回填，及时率不算。现象是断链日账面完整率顶格但次日差额突增。原因是补传帧混入当日口径。解法是 late_flag 打标旁路，补传只补数不补时点。
Q2：三率达标差额还是大怎么办？
A：先查准确率口径。现象是三率曲线正常、差额持续超阈。原因是总表倍率未折算或水吨电度混算。解法是档案核验前置，口径异常点位不进求和，冻结时点差控制在 60 秒内。
Q3：离线告警误报压不下去？
A：调阈值是两难，调紧噪声淹人，调松故障漏报。解法是表级 P95 加三倍标准差基线，连续 3 个周期越线才报，样本不足退档位下限。
Q4：基线多久更新一次？
A：30 分钟在线增量更新。离线日更在雷雨、寒潮等天气事件下会整体滞后，事件期间可临时提到 10 分钟，基线滞后保持不超过 1 个上报周期。
Q5：新装表头一周告警乱报？
A：30 天样本没攒够，任何统计都不可信。解法是样本不足期间沿用档位下限的保守判据，运行稳定一周后自动切换到个性化基线。
参考资料
《电能信息采集与管理系统》DL/T 698
《多功能电能表通信协议》DL/T 645-2007
《饮用冷水水表和热水水表》GB/T 778
《物联网 参考体系结构》GB/T 33474
本文数据接口与模型定义参考合众致达 3T-UEM 公开技术说明
