一年1956亿行：智能电表场景下的时序数据存储实践

某省的智能电表采集项目里500万个观测点按固定周期上报读数一年攒下来将近1956亿行时序数据。项目对数据库的要求很直白存得下、读得快、多年历史数据能快速装载。真正做进去才发现这三件事没一件省心。规模摆在那儿单这一年的原始数据就要占去数TB空间采集系统升级时多年的历史数据要迁到新环境业务等着上线运维和业务要拉某块表几个月甚至一年的负荷曲线响应慢一点儿两边都来找你。这篇笔记基于金仓时序数据库KES TSDB的落地过程整理而成把存储压缩、历史数据装载和数据组织三个方面的实践摊开聊聊附上实测数据和几个踩过的坑。先看数据特征再谈压缩工业时序数据有个明显特点按固定周期采集相邻时间点的值高度相关。智能电表场景尤其如此——15分钟一个采集点同一块表的读数不会跳变即便有突变大多数字段的变化也是缓慢的。重复信息占了存储的大头直接按行存大量空间浪费在冗余上。针对时间序列数据特点金仓时序数据库的存储引擎做了针对性优化主要手段有四类Delta-of-Delta差值编码、Gorilla XOR压缩、字典编码、列式存储。Delta-of-Delta处理的是时间戳。固定周期采集时相邻时间差恒定二阶差分直接退化成常量存储开销降到几个比特。Gorilla XOR处理数值相邻读数接近时异或结果高位大量为0压缩率很可观。字典编码留给状态类字段电表通断状态、异常代码这类枚举值存字典索引比存原文省得多。列式存储则让同列同类型的数据物理上聚在一起前面几种编码才真正发挥出威力。某省智能电表场景的实测500万观测点、一年1956亿行数据压缩比做到45:1。数TB的原始数据落到盘上只有两百GB量级同期与业界同类方案对比这个压缩水平约为对方的3.6倍。压缩不是免费午餐。查询时数据要解压CPU开销实打实写入太密集同批数据的局部性也会打折扣。我们的取舍是冷数据全量压缩热数据保留近线窗口查询密集的时段优先保延迟。历史数据装载701分钟465万行/秒系统升级、数据迁移、数据平台建设以及智能分析应用落地都会撞上同一个问题多年积累的历史数据要在业务窗口期内装完。TB级数据用常规导入方式并不划算。常规写入路径是为在线事务设计的批量装载反而处处受限单条语句的解析、提交、索引维护一样都省不掉1956亿行这个量级几天几夜都跑不完。金仓时序数据库面向时序场景优化了历史数据快速插入能力批量组织写入单元、按分区并行落盘、压缩与索引分开走把顺序写发挥到极致。分布式部署环境下的测试结果1956亿行历史数据701分钟装载完成平均写入速度465万行/秒约为业界同类方案的2.3倍以上。原本要跑两三天的迁移任务一个业务白天就能做完业务等待时间短了一大截。数据组织时序超表和手工分区表的差距500万观测点、多级标签区域、台区、电表型号数据怎么组织直接决定查询快慢。金仓时序数据库提供时序超表机制按时间自动分区空间维度设备、标签做内部分片分区生命周期交给数据库自己管。早期的方案是手工建分区表按月、按台区拆DDL和维护脚本越写越多后来每加一个维度都要动一批历史分区改造成本越来越高。同等数据规模、同等表结构条件下两种方案的对比测试测试场景时序超表普通分区表实时插入404秒549秒曲线查询253毫秒4834毫秒插入快了约四分之一曲线查询快了19.1倍。查询差距主要来自分区裁剪曲线查询带上了设备ID和时间范围超表能直接定位到对应分区和分片扫描量小一个量级分区表在大范围时间查询时裁剪粒度不足扫进去大量无效数据块。几个值得记下的坑时钟漂移躲不掉。部分老电表时钟不准上报时间乱序入库时按设备维度做了时间线校正否则分区会被打得碎片化。迟到数据要单独照顾。补报的数据跨了分区写入走了独立的late-data路径避免和实时流抢锁。稀疏观测点比想象中多。不是每个点每期都有数空值处理方式直接影响压缩率后来补了空值压缩标记才把压缩比稳住在45:1。小结时序数据库的价值能存只是起点存完之后管不管得动才见分晓。1956亿行这个量级上压缩决定成本装载决定工期组织方式决定查询体验。这三件事我们还在持续打磨尤其是压缩策略与查询延迟的平衡随着业务查询越来越复杂要调的地方还不少。