Mi&Bee Blog
English

可观测技术存储架构总览：从 Gorilla 到 Parquet 的演进

可观测性技术 可观测性, 存储架构, Gorilla, Parquet, 列式存储 可观测技术系列 3925 字 8 分钟阅读

引言

可观测性（Observability）已成为云原生时代的基础设施核心。Metrics、Logs、Traces、RUM、Profiling 五大信号各自产生海量数据，而它们的存储效率直接决定了平台的成本边界和查询性能。而在采集侧，eBPF 技术正在重塑数据获取方式。这一切的背后，存储架构的演进是支撑可观测性规模化落地的基石。

mermaid
flowchart TD
    A[可观测性<br/>五大信号] --> B[Metrics<br/>指标]
    A --> C[Logs<br/>日志]
    A --> D[Traces<br/>调用链]
    A --> E[RUM + Profiling<br/>前端 + 性能]

    style A fill:#9C27B0,color:#fff
    style B fill:#2196F3,color:#fff
    style C fill:#2196F3,color:#fff
    style D fill:#2196F3,color:#fff
    style E fill:#2196F3,color:#fff
mermaid
flowchart TD
    G[存储演进<br/>殊途同归] --> H[专用格式<br/>→ 列式标准]
    G --> I[索引膨胀<br/>→ 弱索引 + 对象存储]

    style G fill:#FF9800,color:#fff
    style H fill:#4CAF50,color:#fff
    style I fill:#4CAF50,color:#fff

图说明：可观测性五大信号（指标、日志、调用链、前端监控、性能分析）各自产生不同特征的数据，但它们的存储演进殊途同归——两条核心主线贯穿所有信号：一是从专用存储格式走向 Parquet/Arrow 列式标准，二是从全字段倒排索引走向弱索引策略 + 对象存储。

本篇作为系列开篇，从两条存储演进主线出发，深入剖析 Gorilla 压缩算法这一所有 TSDB 的共同理论基础，梳理关键技术共识与三大演进趋势，为后续各信号的深度分析奠定基础。

新手速查 — 五大信号一句话理解

信号类比典型数据示例
Metrics系统的"心率监护仪"CPU=80%, QPS=12k, mem=6GB
Logs系统的"工作日志"[ERROR] 10:03 连接超时
Traces请求的"快递物流"网关 → 订单 → 支付 → 库存
RUM用户的"体验报告"首屏=3.2s, CLS=0.05
Profiling代码的"X 光片"函数调用栈火焰图

如果你刚开始接触可观测性，不用被术语吓到——本质上就是用五种不同角度给系统"做体检"，核心目标是：出了问题能快速定位原因。

采集 Collect — 从应用、系统、网络中收集可观测性数据
处理 Process — 数据清洗、聚合、打标、格式化
存储 Store — 时序数据库、列式存储、索引优化
查询 Query — PromQL、SQL、Trace 查询、可视化

可观测性存储的两条演进主线

经过对 InfluxDB、Prometheus、VictoriaMetrics、TimescaleDB、Loki、Elasticsearch、ClickHouse、Tempo、Pyroscope 等十余个系统的深入调研，可观测性存储技术的发展呈现两条清晰的主线：

演进主线痛点共识方案代表迁移
专用格式 → 列式标准自研格式绑定引擎、生态封闭Apache Parquet + Arrow 成事实标准[E11]InfluxDB TSM→Parquet（3.0 FDAP）；Tempo flatbuffer→Parquet；Pyroscope V2 列式 segment；FrostDB
索引膨胀 → 弱索引 + 对象存储全字段倒排索引成本随数据量爆炸只索引关键标签 + 顺序扫描 + 列裁剪 + 对象存储Loki（只索引标签）；Tempo（只索引 TraceID）；VictoriaLogs（自动索引 + 极致压缩）

这两条主线并非独立演进——列式格式天然支持高效的顺序扫描和列裁剪，为弱索引策略提供了底层能力；而对象存储的低成本又让"扫描代替查找"成为经济上可行的方案。

新手类比：想象你在记录每天的温度。未压缩时，每个温度记录需要存 “2026-06-14 10:00:00 → 25.3°C” 这样一长串字符。但如果温度变化不大，你会本能地说 “和昨天差不多”——这就是压缩的本质。Gorilla 算法把这个直觉做到了极致：时间戳用 “和上一个间隔一样” 代替，数值用 “和上一个值差不多” 代替。下方的动画会演示这个过程。

理论基础：Gorilla 压缩算法

Gorilla 是 Facebook 于 2015 年在 VLDB 发表的内存时序数据库，其压缩算法是现代 TSDB 压缩技术的基石，被 Prometheus、InfluxDB、VictoriaMetrics、TimescaleDB 等广泛借鉴[1][16]。Gorilla 将时间序列压缩到平均 1.37 字节/数据点，实现 12 倍压缩比[1]。

时间戳压缩：Delta-of-Delta 编码

时序数据的关键特性是采集间隔通常固定。Gorilla 利用这一点，对时间戳采用"差值的差值"（delta-of-delta）编码[1][2]：

1

计算公式: D = (t_n - t_{n-1}) - (t_{n-1} - t_{n-2})

可变长位编码规则[2][5]：

Delta-of-Delta 范围编码位数说明
D = 01 bit仅标志位'0’，等间隔时最常见
D ∈ [-63, 64]9 bits2 位头 + 7 位值
D ∈ [-255, 256]12 bits3 位头 + 9 位值
D ∈ [-2047, 2048]16 bits4 位头 + 12 位值
其他36 bits4 位头 + 32 位值

实际效果：对于 15 秒等间隔采集，第一个时间戳存全量（64 bit），第二个存 delta（14 bit），此后每个时间戳仅需 1 bit[2]。一次采集延迟会导致额外 32 bits 开销，因此一致的采集间隔直接影响压缩效率。

Gorilla Delta-of-Delta 编码（15s 等间隔采集）采样点时间戳DeltaDelta-of-Delta编码位数t₁100——64 bitst₂11515—14 bitst₃1301501 bitt₄1451501 bitt₅1601501 bit未压缩: 5 × 64 = 320 bitsGorilla: 64 + 14 + 1 + 1 + 1 = 81 bits等间隔越长压缩比越高，理论极限 64x

动画说明：上方动画循环演示 5 个等间隔（15s）采集点的 delta-of-delta 编码过程。注意从 t₃ 开始，每一行只需要 1 bit 存储（绿色高亮）——因为 delta-of-delta 为 0，仅需一个标志位。这就是 Gorilla 实现 12x 压缩的核心原理。

浮点值压缩：XOR 编码

连续的浮点值通常相似（如 CPU 利用率 47.2%、47.3%），XOR 运算后会产生大量前导/尾部零[1][2]：

XOR 结果编码方式位数
XOR = 0（值相同）标志位'0'1 bit
XOR ≠ 0，零模式与上次相同‘10’ + meaningful bits2 + 有效位
XOR ≠ 0，零模式不同‘11’ + 5位前导零 + 6位尾部零 + meaningful bits13 + 有效位

生产环境统计（Facebook 测量）[2]：

XOR 结果占比平均位数
全零（值完全相同）51%1 bit
近似（仅少量有效位）30%~26.6 bits
差异大（值跳变）19%~36.9 bits
加权平均100%~9.5 bits/值
Gorilla XOR 浮点值压缩（CPU 利用率示例）采样值47.2%47.3%47.3%01000100...（64 bit float64）01000100...（仅末位不同）01000100...（完全相同）XOR 结果51% → 全零（1 bit）值完全相同时30% → 近似（~27 bits）仅末几位不同19% → 差异大（~37 bits）值跳变时加权平均：约 9.5 bits/值（未压缩 64 bits）配合时间戳压缩 → 每数据点仅 1.37 bytes（12x 压缩）

动画说明：上方动画展示 CPU 利用率这类连续浮点值的 XOR 压缩过程。关键洞察：相邻采样值通常极度相似（47.2% → 47.3% → 47.3%），XOR 运算后 51% 的情况结果完全为零（只需 1 bit 标志位），30% 的情况仅有少量有效位。这就是 Gorilla 浮点值压缩的核心——它不压缩单个值，而是压缩值之间的差异。

整体压缩效果与局限

指标位数
平均时间戳~1.5 bits
平均值~9.5 bits
每数据点总计~11 bits ≈ 1.37 bytes
未压缩16 bytes (8B timestamp + 8B float64)
压缩比~12x

数据被分组为 chunk（块），每个 chunk 有固定开销（base timestamp 64 bit + 第一个值 64 bit），短 chunk 压缩效果差[2][3]。

mermaid
flowchart TD
    TS[时间戳序列] --> DD{计算 delta-of-delta}
    DD -->|D=0| B1[1 bit 编码]
    DD -->|"D ∈ -63~64"| B2[9 bits 编码]
    DD -->|"D ∈ -255~256"| B3[12 bits 编码]
    DD -->|其他| B4[36 bits 编码]

    style TS fill:#FF9800,color:#fff
    style DD fill:#2196F3,color:#fff
    style B1 fill:#4CAF50,color:#fff
    style B2 fill:#4CAF50,color:#fff
    style B3 fill:#4CAF50,color:#fff
    style B4 fill:#4CAF50,color:#fff

图说明：Gorilla 时间戳编码的决策流程。delta-of-delta 编码的核心假设是采集间隔稳定——当 D=0（等间隔采集）时，每个时间戳仅需 1 bit，这是实现 12x 压缩比的关键。若采集间隔不规则，D=0 的情况大幅减少，压缩比将从 12x 降至 5-7x。

算法局限[2]：

局限具体影响
顺序解码每个样本依赖前一个，chunk 内无法随机访问
不规则时间戳随机间隔时 delta-of-delta 很少为零，压缩比从 12x 降至 5-7x
元数据不压缩仅处理数值对，标签和元数据需单独的倒排索引

关键技术共识

通过多源交叉验证，可观测性存储领域已形成以下关键技术共识[1][3][E25]：

关键共识说明
Gorilla 压缩算法delta-of-delta + XOR，所有现代 TSDB 的压缩基石，约 12x 压缩比
列式存储解决高基数问题的根本方案——传统 label-set 模型在百万级 series 时崩溃
对象存储 + 计算存储分离S3/GCS 已成为云原生可观测性后端标配
OpenTelemetry 统一数据模型Resource + Signal 模型推动跨信号关联从 UI 层下沉到存储层
eBPF 采集侧聚合内核态过滤，降低数据量的前置策略

三大演进主线

综合各信号领域的发展趋势，可观测性存储正沿着三条主线演进[E25][E27][E11]：

主线核心范式代表方案
① eBPF 采集侧聚合内核态过滤 + 采集侧聚合 + 短期内存存储 + 按需查询，将数据量控制前置到采集端Pixie、Hubble、Inspektor Gadget
② 存储从分治走向统一LGTM 分库（每信号一库 + UI 关联）→ ClickHouse 统一列存（单引擎 + SQL JOIN）；对象存储 + 计算存储分离；压缩/分层/预聚合替代激进采样ClickHouse 统一列存
③ 数据模型标准化驱动关联OpenTelemetry 统一模型（Resource + InstrumentationScope + Signal）+ exemplar + trace_id 注入，跨信号关联下沉到存储层OpenTelemetry

本系列导读

本系列共 8 篇，按以下路径阅读效果最佳：

编号标题聚焦信号阅读建议
1存储架构总览（本篇）全部必读，建立全局认知
2时序数据库存储Metrics了解 TSDB 核心技术栈
3日志存储架构Logs日志量大，存储设计最具挑战
4调用链存储架构Traces分布式追踪的存储策略
5RUM 时序存储RUM前端监控的独特需求
6Profiling 存储架构Profiling列式存储的最新实战
7eBPF 与统一架构趋势跨信号采集与存储的未来方向
8存储选型指南全部场景化选型建议

建议按编号顺序阅读。篇 2-6 可跳过不感兴趣的信号直接阅读后续篇目，但篇 7-8 依赖前面各篇的技术背景。

来源

[1] [官方] Gorilla: A Fast, Scalable, In-Memory Time Series Database (VLDB 2015): https://www.vldb.org/pvldb/vol8/p1816-teller.pdf

[2] [二级资料] Gorilla Compression (Delta-of-Delta + XOR) 详细解析: https://crackingwalnuts.com/distributed-systems/gorilla-compression

[3] [二级资料] Time-Series Database Internals: InfluxDB 3, TimescaleDB, and QuestDB Under the Hood: https://iotdigitaltwinplm.com/time-series-database-internals-influxdb-timescale-questdb-2026/

[5] [官方] InfluxDB Time Series Index (TSI) Details: https://docs.influxdata.com/enterprise_influxdb/v1/concepts/tsi-details/

[16] [二级资料] CHIMP: Efficient Lossless Floating Point Compression for Time Series Databases (VLDB 2022): https://vldb.org/pvldb/vol15/p3058-liakos.pdf

[E11] [官方] Grafana: The open and composable observability platform: https://grafana.com/

[E25] [官方] OpenTelemetry — Overview (specs): https://opentelemetry.io/docs/specs/otel/overview/

[E27] [二级资料] What is OpenTelemetry? (Dash0): https://www.dash0.com/knowledge/what-is-opentelemetry

所属系列: 可观测技术系列
下一篇 → 时序数据库存储架构深度对比：InfluxDB、Prometheus、VictoriaMetrics、TimescaleDB