物联网数据的时序压缩算法：如何在存储成本和查询性能间平衡

物联网数据为什么需要专门的时序压缩

如果你维护过一套物联网数据平台，大概率会遇到一个矛盾：采样频率调高一点，存储成本就跟着涨；调低一点，又怕丢掉业务细节。很多人第一反应就是压缩数据，但真正动手之后才发现，压缩率上去了，查询反而慢了。这篇文章想从时序压缩算法本身出发，聊聊存储成本和查询性能之间到底该如何权衡。

物联网场景和传统日志、关系型事务数据不太一样。设备按固定或准固定的频率上报数据，每条记录是时间戳加上若干测点值。这样产生的数据有几个明显特征：时间戳单调递增、相邻测点值变化通常很平缓、且往往带有剧烈的周期性。比如室温传感器白天高晚上低，工厂机床的振动信号在停机时段基本不变。这些特征让时间序列数据拥有很高的可压缩空间，前提是你选对算法。

无损压缩：利用数据结构本身的水分

无损压缩的目标是压缩前后完全一致，常用于原始数据的长期归档和需要精确回放的场景。在时序数据里，最有代表性的无损算法是 Facebook 开源的 Gorilla 压缩，它后来也成为了 Prometheus 等系统默认的存储压缩方案。

Gorilla 的核心思路是同时压缩时间戳和值。时间戳部分使用 delta-of-delta（差分再差分），因为大多数采样间隔是稳定的，做两次差分后会得到大量 0 或很小的整数，再配合变长编码把不同范围的整数用最少的空间记下来。值部分则对浮点数的 IEEE 754 位模式做异或（XOR），相邻两次采样浮动不大时，异或后的结果会集中在高位或低位，于是可以跳过大量的零字节，再根据实际情况决定是否采用全零、前导零对齐等编码方式。

这里可以看一个 Gorilla 时间戳压缩的简化示意，感受一下两次差分的实际效果：

原始时间戳：  1000, 1001, 1002, 1010, 1011
一级差分：      1,    1,    8,    1
二级差分：      0,    7,    -7
// 大部分二级差分绝对值很小，适合用少量字节表示

如果一组采样点间隔恒定，二级差分清一色为 0，那么时间戳的存储开销甚至可以压缩到每点 1 比特左右。这就是为什么专门为时序设计的压缩算法，比直接拿通用压缩工具（如 gzip、Zstandard）压整个文件要高效得多——它先对数据做了重排和转换，让信息熵大大降低。

但无损压缩也不是没有代价。压缩块必须被完整解压后才能读取内部任一数据点。现在很多时序数据库会按时间段构建索引，但落在某个块里的数据，大多时候还是需要整块解压。当压缩块很大时，压缩率好看，但点查询和小范围查询的延迟会明显上升。

有损压缩：用精度换空间的工程决策

与无损压缩相对的，是有损压缩。物联网场景里相当一部分数据并不需要 100% 精确，比如温度传感器显示 25.0001 和 24.9 对大多数分析来说没有本质区别。有损压缩通过在允许的误差范围内丢弃一些难以表达的数据点，来换取更高的压缩率。

最常见的两种有损压缩是死区压缩和旋转门压缩。死区压缩的思路是设定一个误差阈值，只要当前值与上一个保留值的偏差在阈值内，就跳过；超过阈值才保存一个点。旋转门压缩则更聪明一些，它维护一个“门”的上下边界，当一组连续的数据点都能在这个门的范围内通过时，就只保留第一个点，直到某个点突破了边界，才记录上一个点并重新开一扇门。

旋转门压缩的示意逻辑大概是这样：

设最大偏差阈值为 max_dev，保存第一个点
对后续每个点 p：
    计算上边界 = max(上边界, p.value + max_dev)
    计算下边界 = min(下边界, p.value - max_dev)
    如果下边界 > 上边界：
        保存上一个点，重新用 p 初始化上下边界
    否则：跳过 p 的点，继续下一个

这个算法的迷人之处在于，它既不采样固定频率，也不简单剔除孤立点，而是在保留数据整体趋势的同时，尽量把直线段附近冗余的点压缩掉。对于一条缓慢变化的曲线，压缩率常常能做到 10:1 到 50:1，甚至更高。

存储成本和查询性能的平衡，到底卡在哪里

很多团队选压缩算法时只盯着压缩率，忽略了查询的形态。但物联网数据的读取模式，和一般日志检索完全是两回事。

常见的查询大致分为三类：单点查询（例如查某个设备在某个时刻的精确值）、时间范围查询（例如拉取最近一小时温度曲线）、聚合查询（例如按小时统计平均压力）。这三类查询对压缩数据的要求不同。单点查询最讨厌大块压缩，因为为了一个值可能要解压整个块，代价非常高。时间范围查询喜欢按时间顺序组织块，这样至少可以只解压命中的时间段。聚合查询则可能希望块内数据能做时上聚合，而不是先把所有原始点都解出来。

压缩算法的选择，本质上是在压缩率、解压 CPU 开销、随机访问能力和写入成本之间找平衡。我见过不少系统刚开始用高压缩率配置，比如把旋转门的死区阈值设得很大，压缩率确实漂亮，但业务方后来要精确回放设备每次上报的原始值，结果发现数据已经被丢了，只能把压缩参数降下来，这是典型的取舍没做对。

另一个容易被忽略的点是压缩块的大小。很多时序数据库允许配置 block size 或 chunk interval。块太小，压缩率低，但查询时解压快；块太大，压缩率上升但随机访问变慢。数据块的选择应该结合写入频率和查询窗口。如果大家主要是按天出报表，把块配置成 1 小时或 6 小时是合理选择，再通过索引去定位小时块；如果想要支持毫秒级定位到具体设备状态，块的尺寸就得小很多。

常见误区：为了省存储而牺牲一切

根据我在不同项目里看到的情况，以下几个误区特别容易踩：

只关注压缩率，不看压缩/解压的 CPU 开销。嵌入式网关或高吞吐边缘节点上，CPU 可能比存储更稀缺。
把有损压缩用于计费或下单场景。电表计量、金融交易记录等要求原始值可溯源的场景，绝不能使用死区压缩或旋转门。
忽略访问模式直接套用默认压缩参数。默认参数往往是兼顾大多数场景的次优解，真正常运行的系统必须按自己的查询频率分布调整。
把通用压缩算法直接用于时序文件。比如先写 CSV 再 gzip，虽然能压缩，但无法支持高效的块级查询，也不利于后续的聚合。

不同压缩方案怎么选：一张表看明白

为了方便做方案对比，我把几种典型压缩方式放在一张表里。注意压缩率是经验参考，具体取决于数据特征和阈值配置。

压缩方式	压缩率参考	CPU 开销	数据精度	查询友好度	典型适用场景
Delta-of-delta + 变长编码	中高	低	无损	中	高频率、时间戳规律的设备数据
Gorilla（XOR 差值）	高	低中	无损	中	Prometheus 等监控时序存储，浮点数值变化平缓
旋转门压缩	很高（视阈值）	低	有损	低	温度、压力等缓慢变化的传感器，长期归档
死区压缩	高	很低	有损	低	近似监控，趋势观察
通用压缩（Zstandard/LZ4）	中	低中	无损	低	离线文件备份、不强调随机查询的场景

从这张表可以看到，没有任何一种方案在所有维度上都赢。实际系统往往需要在存储层分层设计：热数据用压缩率适中的块来保证查询速度，冷数据用高压缩率甚至更有损的算法降本，再通过数据生命周期管理把数据迁移到不同存储介质。

落地时的几条实操建议

如果你的团队正在建设物联网数据平台，需要真正平衡存储和查询，建议从这几个方向入手。

第一，先采集一段时间真实数据做压缩率评估，不要拍脑袋选算法。统计时间戳的抖动情况、数值变化幅度、周期模式，看看信号在丢失多少个点后仍能还原出业务所需的曲线。用真实数据同时压测 Gorilla 和旋转门，比较压缩率和查询 P99 延迟。

第二，把查询模式量化。列出业务方最常用的查询类型：是看实时曲线，还是看历史报表？是精确回溯，还是趋势分析？据此确定无损和有损的边界。能用近似结果的地方，完全可以考虑在有损通道之外另建一条低精度的数据摘要，与原始数据并存。

第三，认真调教压缩参数，而不是只改压缩格式。旋转门的越界阈值、Gorilla 的块大小、写入端的 flush 间隔，每一个参数都影响端到端的延迟。建议把参数暴露在配置中心，先使用保守配置，观察集群的 I/O 与 CPU 成本，逐步向激进方向靠拢，直到查询延迟达到接受上限再回调。

一个常见的工程架构是：边缘节点做一层轻量级旋转门压缩，只把关键点上报到中心；中心使用 Gorilla 无损压缩存储原始点，但通过索引和按时间分块来保证查询速度；更冷的数据再定期转成 Parquet 之类的列式格式，加上字典和谓词下推，用于离线分析。这样每一层都用适合自己访问频次的压缩策略，而不是把所有数据一股脑压进同一种算法。