顶会论文解读：时序数据库 Apache IoTDB 中的时序数据压缩优化【VLDB 2025】

时序数据库 Apache IoTDB 顶会论文获中国信通院数据库应用创新实验室深度解读！以下为详解原文：

本文对清华大学王建民教授团队、中国人民大学杜小勇教授团队、天谋科技等机构联合发表的 VLDB 2025 论文《Improving Time Series Data Compression in Apache IoTDB》进行解读。该论文首次将同态压缩（Homomorphic Compression, HC）理论引入时间序列领域，并提出了一个名为 CompressIoTDB 的新型框架，旨在解决传统时间序列数据库中压缩与查询性能之间的核心矛盾。通过在压缩数据上直接执行查询，该工作显著提升了查询吞吐量并降低了资源消耗。

一、引言：压缩与查询的困境及同态压缩的破局

在物联网（IoT）、金融、工业监控等关键领域，时间序列数据正以前所未有的规模爆炸式增长。为了有效管理存储成本和网络传输带宽，压缩技术已成为 Apache IoTDB、InfluxDB 等现代时间序列数据库（TSDB）的标配。然而，这种优化并非没有代价。传统数据库系统在处理查询时，普遍遵循一种“先解压、后查询”的模式，这在处理大规模数据集时会引入显著的计算开销，形成严重的性能瓶颈。

论文通过分析 Apache IoTDB 的数据处理流程，精准地揭示了这一核心矛盾。

图 1：Apache IoTDB 中的物联网数据处理

如图 1a 所示，IoTDB 的数据处理管线首先对来自各类应用的高频、冗余、规律的时间序列数据进行轻量级压缩（如 RLE），再结合通用压缩（如 LZ4）存入其专有的TsFile文件格式。这一策略极大地降低了存储需求，例如，铁路系统每日产生的 5TB 原始数据，通过 TsFile 可压缩高达 95%。然而，当执行查询时，系统必须将这些数据完全解压回内存，才能进行后续的计算。图 1b 的性能测试结果直观地量化了这一开销：尽管压缩将磁盘使用量减少了 90%以上，但由于解压缩引入的 CPU 计算成本，查询延迟反而增加了 15.8%。

为打破这一困境，论文引入了同态压缩（Homomorphic Compression, HC）这一变革性方案。HC 的核心思想是允许直接在压缩数据上执行计算，从而彻底消除解压缩步骤。将其应用于时间序列数据管理，可以带来三大核心优势：

1.降低查询延迟：通过绕过整个解压缩过程，直接在压缩表示上进行计算，从根本上减少了查询执行时间。

2.提升资源效率：在查询的全生命周期中保持数据压缩状态，显著降低了内存占用，使系统能够在有限的资源下处理更大规模的数据集，增强了可扩展性。

3.提供原则性的设计方法：HC 提供了一个坚实的数学理论框架，将系统设计从依赖经验的、零散的优化，转变为一种有形式化保证的、系统性的方法论。

基于此，本文的核心目标为开发一个专为时间序列数据量身定制的新型 HC 框架——CompressIoTDB，并将其深度集成到 Apache IoTDB 中，以验证其在真实世界场景下的性能优势。

二、核心挑战：为何现有同态压缩不适用于时序数据库

尽管同态压缩（HC）的理论已相对成熟，但将其直接应用于时间序列数据库（TSDB）却面临着一系列独特的挑战。这些挑战源于时间序列数据本身的复杂特性以及 TSDB 系统的特定需求，现有通用的 HC 方法并未能充分解决这些问题。

挑战一：时间序列数据的独特复杂性

现有 HC 方法通常将数据视为通用的字节流，缺乏对时间序列数据内在结构和语义的理解，这导致了所谓的“语义鸿沟”。

·依赖时间戳的查询模式：TSDB 的核心查询，如基于时间的聚合、滑动窗口函数和时间戳对齐连接，都高度依赖于数据的时序关系。一个通用的 HC 系统或许能在压缩文本中查找子串，但它无法理解“计算一小时窗口内的平均值”这类具有时间语义的操作。它缺乏直接在压缩域中处理时间维度信息的能力。

·高比例的空值（Null）：在物联网场景中，由于设备离线、采样频率不一致等原因，数据中可能包含高达 90%的空值。TSDB 通常使用高效的空值位图（null bitmap）来管理这些缺失值。而通用的 HC 方法忽略了这种复杂的元数据管理，无法在保持数据压缩的同时正确地处理和恢复空值，这对于查询的正确性至关重要。

挑战二：压缩算法的失配

TSDB 的性能与压缩效率紧密相关，因此它们倾向于使用为时间序列数据特征专门优化的轻量级、无损压缩算法。

·TSDB 的偏好：常用的算法包括行程长度编码（RLE）、字典编码（Dictionary Encoding）以及基于差分的编码（如 Ts_2Diff）。这些算法能够高效地利用时序数据中值的重复性或平稳变化的特性。

·现有 HC 的局限：相比之下，现有的 HC 研究更多地集中在通用压缩算法上，如 LZW。这些算法虽然通用，但并未针对时序数据的特点进行优化，更重要的是，它们对 TSDB 中复杂的查询算子（如聚合、过滤）的同态计算支持非常有限。

挑战三：缺乏针对 TSDB 的统一框架

尽管在流处理系统等领域已有直接在压缩数据上计算的探索，但 TSDB 的场景有其本质区别。

·不同的设计优先级：流处理系统通常优先考虑低延迟，可能会牺牲压缩率；而 TSDB 需要同时兼顾高压缩率（以存储海量历史数据）和高效的查询性能。

·不同的数据范围：流处理系统通常操作于较小的时间窗口，而 TSDB 则需要支持对跨越数年、规模庞大的历史数据进行批量分析。

综上所述，将 HC 成功应用于 TSDB，需要的不仅仅是算法的简单移植，而是一个能够弥合“语义鸿沟”的全新框架。这个框架必须能够理解并直接在压缩域中操作时间序列的核心语义（时间、值、空值），同时与 TSDB 常用的轻量级压缩方案深度集成。

三、理论框架：为时序数据定制的同态查询模型

为了系统性地解决上述挑战，论文首先构建了一个坚实的理论框架，为在压缩时间序列数据上进行查询提供了形式化的定义和性能保证。这个框架不仅证明了方法的正确性，更重要的是，它为后续的系统设计提供了原则性的指导。

然而，仅仅正确是不够的，一个“好”的同态查询还必须是高效的。为此，论文进一步提出了两个关键性质：

表 1：运算符编码组件矩阵

最终，论文给出了一个关键的性能保证：对于那些在查询过程中数据量单调递减的典型查询，一个采用有效同态查询和有效辅助信息恢复的系统，其总成本必然低于传统的“先解压、后查询”系统。该证明将总成本分解为数据解压、辅助信息恢复和算子计算三个部分，并论证了同态方法在这三方面均具有优势，从而在理论上锁定了性能收益。

四、CompressIoTDB 系统：架构与核心设计

在上述理论框架的指导下，论文设计并实现了 CompressIoTDB，一个深度集成于 Apache IoTDB 查询层的新型同态压缩查询框架。该系统通过模块化的设计，实现了对压缩时间序列数据的高效、直接处理。

图 2：CompressIoTDB 框架

如图 2 所示，CompressIoTDB 的整体架构由三大核心模块构成，它们协同工作，共同完成从 SQL 解析到结果返回的整个流程。

核心模块

1.数据结构模块 (Data Structure Module)：这是整个系统的基石。该模块定义了核心的数据结构 CompColumn，它作为压缩数据在内存中的统一表示和访问接口。此外，还包括 Compression Offset Index 和 HintIndex 等辅助结构，为上层算子提供高效的数据定位能力。

3.优化模块 (Optimization Module)：该模块包含了一系列系统级的优化措施，旨在进一步提升查询性能和效率。主要包括延迟解压 (Late Decompression)和动态辅助信息管理 (Dynamic Auxiliary Management)，分别用于降低数据读取和预处理的开销。

系统工作流程

当一个 SQL 查询请求到达 IoTDB 时，CompressIoTDB 的处理流程可分为三个主要阶段：

1.加载与构建：查询所需的数据块（Chunk）从存储层的 TsFile 文件中被加载到内存。此时，优化模块介入：系统采用延迟解压策略，只对数据进行第一层通用解压（如 LZ4），而保持其轻量级压缩格式（如 RLE）。同时，通过动态辅助信息管理技术，高效地处理空值和删除标记。最终，这些经过初步处理的压缩数据被构建成内存中的 CompColumn 对象。

2.同态执行：查询计划中的各个算子由算子模块中的同态算子实现。这些算子直接在输入的 CompColumn 对象上进行计算。重要的是，算子之间传递的中间结果仍然是 CompColumn 对象，从而确保数据在整个查询执行管线中都保持压缩状态，最大化地减少了内存占用和数据移动。

3.结果返回：当查询执行完毕，最终的结果 CompColumn 会根据客户端的要求被解压成标准格式，然后返回给用户。

通过这种设计，CompressIoTDB 将复杂的压缩感知逻辑封装在了数据结构和算子模块内部，为上层查询引擎提供了一个透明、高效的执行环境。

五、核心数据结构 CompColumn：压缩数据的高效抽象

CompColumn 是 CompressIoTDB 系统中最核心的技术创新，它不仅是一个数据容器，更是一种架构模式，旨在通过抽象来解耦查询逻辑与底层物理数据表示。这种设计使得整个系统变得模块化、可扩展且易于维护。

设计理念

在传统数据库中，查询算子（如 AVG()）通常假设数据是以未压缩的、可随机访问的数组形式存在的。如果要让它支持多种压缩格式，一种糟糕的实现方式是在算子内部写满 if/else 分支来处理不同格式，这会导致代码臃肿且难以维护。

CompColumn 采用了更优雅的面向对象设计。它继承自 IoTDB 中通用的 Column 抽象类，为所有上层算子提供了一套统一的接口，如 getObject(position)。算子只需要针对这个通用接口编程一次，而将处理不同压缩格式的复杂性下沉到 CompColumn 的具体实现中。这样，无论是 RLE、字典编码还是其他未来可能支持的压缩算法，对于上层算子来说都是透明的。

CompColumn 的内部结构

图 3：RLE 的 CompColumn 示例

如图 3 所示，一个 CompColumn 对象内部主要包含以下几个部分：

·values 数组：这是存储压缩数据的主体。它不是一个简单的值数组，而是一个由“压缩块”（Compression Blocks）组成的数组。对于 RLE 编码，每个压缩块就是一个 Column 对象，代表一个行程（run），如(value, length)。

·compressionOffsetIndex (压缩偏移量索引)：这是实现对压缩数据进行高效随机访问的关键。由于压缩数据（尤其是 RLE）本质上是顺序访问的，我们无法像普通数组那样通过 index * size 来直接定位。该索引存储了一个映射关系，记录了每个压缩块在逻辑上的起始位置。例如，coIndex = 17 表示第四个压缩块（values）对应于原始未压缩序列的第 17 个位置。

以图 3 为例，当需要访问逻辑位置为 18 的数据时，系统首先通过 compressionOffsetIndex 定位到包含该位置的压缩块。通过查找，发现 coIndex = 17 而 coIndex = 22，因此目标位置 18 落在第四个压缩块 values 的范围内。由于该块是 RLE 编码的值为 7 的行程，系统便可直接返回 7。如果下一次访问是位置 19，hintIndex（此时为 3）将帮助系统立即在同一压缩块内定位，避免了重复的索引查找。

通过这种设计，CompColumn 将压缩数据的复杂性完美地封装起来，为上层提供了一个行为上类似未压缩列、但性能和内存占用远优于后者的强大对象。

六、同态算子实现：在压缩域直接计算

基于 CompColumn 提供的统一接口，CompressIoTDB 实现了一整套同态查询算子。这些算子的核心设计原则是充分利用压缩数据的结构特性来避免不必要的计算，从而实现比在解压数据上操作更高的效率。 

典型算子实现

·过滤算子 (Filter)：过滤操作被下推到压缩数据层。对于 RLE 编码的数据，过滤条件只需对每个行程（run）的值检查一次，而不是对行程中的每个数据点重复检查。例如，对于一个包含 1000 个重复值 5 的行程，WHERE value > 3 的判断只需执行一次。对于字典编码，过滤条件直接应用于字典表，快速生成一个匹配的 ID 位图，然后用该位图高效地过滤整个数据列。

·聚合算子 (Aggregation)：聚合计算采用增量更新的方式。算子在内部维护一个状态累加器（如 count, sum, sum_of_squares 用于计算方差）。当处理 RLE 编码的数据时，对于每个行程(value, length)，状态的更新可以通过数学公式一次性完成，而不是循环 length 次。

图 4：基于 RLE 数据的同态聚合

·时间戳连接算子 (Timestamp-based Join)：在 TSDB 中，连接通常是基于时间戳对齐的。对于未对齐的数据，连接过程可能会引入空值。CompressIoTDB 的同态连接算子通过动态编码来处理这种情况：它不会将整个列解压来插入空值，而是在压缩表示中直接插入一个“空值行程”，或者调整现有行程的长度，从而在不破坏数据压缩结构的前提下完成连接操作。

·切片算子 (Slicing)：该算子用于处理 LIMIT 和 OFFSET 子句，是实现大数据分批处理的关键。它利用 CompColumn 的 Compression Offset Index 和 HintIndex 快速定位到切片的起始和结束边界，然后仅提取相关的压缩块，并重建一个新的、更小的 CompColumn 作为结果，整个过程高效且内存友好。

运行示例

为了更具体地展示同态查询流程，论文提供了一个完整的示例：SELECT s/2 FROM series WHERE s>3 OFFSET 11 LIMIT 4，作用于图 3 所示的 RLE 编码数据。

1.构建与过滤：首先，数据被加载并构建成 CompColumn。在此过程中，WHERE s>3 的过滤条件被下推。值为 3 的行程被丢弃，值为(3, 4, 5, 3)的非行程块被过滤为(4, 5)。最终，构建出的 CompColumn 的 values 为(8, (4,5), 7)，其 coIndex 为(0, 9, 11, 16)。

2.表达式计算：接着，s/2 的表达式被应用。对于行程(9, 8)，计算只需执行一次 8/2=4。对于非行程块(2, (4,5))，计算逐个进行，得到(2, 2.5)。最终 values 变为(4, (2, 2.5), 3.5)。

3.切片操作：最后执行 OFFSET 11 LIMIT 4。系统利用 coIndex 和 hintIndex 快速定位到逻辑偏移量 11（对应 coIndex），并计算出结束位置 15。通过对压缩块进行精确的切割和重组，最终得到一个只包含(2.5, 3.5)两个值的 CompColumn，其 coIndex 也相应地被重构为(0, 1, 5)。

这个例子清晰地展示了数据如何在整个查询流程中保持压缩状态，以及各个同态算子如何协同工作，高效地完成复杂的查询任务。

七、系统级优化：进一步提升查询效率

除了核心的 CompColumn 和同态算子，CompressIoTDB 还引入了两项关键的系统级优化，以解决真实世界 TSDB 运维中的实际问题，并进一步压榨查询性能。这两项优化都遵循一个共同的设计哲学：将数据的解压或转换操作推迟到绝对必要的最后一刻。

优化一：动态辅助信息管理 (Dynamic Auxiliary Management)

·问题背景：在生产环境中，数据并非总是整洁的。对齐的时间序列（多个传感器共享一个时间戳列）会因数据缺失而产生大量空值，这些空值通常由一个独立的位图（bitmap）来管理。此外，为了提高写入性能，删除操作通常采用“懒删除”（lazy deletion），即只在一个删除列表中记录要删除数据的位置，而不立即进行物理删除。在查询时，传统方法需要先解压数据，然后根据位图和删除列表恢复出完整的逻辑视图，这个过程开销巨大且破坏了数据的压缩结构。

图 5：使用 RLE 的紧凑布局示例

·解决方案：CompressIoTDB 采用了一种“动态编码”策略来应对这一挑战。它不会将数据完全解压，而是在压缩域中直接对数据结构进行修改。如图 5 所示，当需要应用空值位图时，系统会分析位图和 RLE 行程的对应关系，然后智能地将连续的空值合并成一个新的“空值行程”插入到 CompColumn 中，或者将非连续的空值所在的小段数据退化为未压缩形式。同样，对于懒删除，系统会直接调整受影响的 RLE 行程的长度，而不是遍历删除每一个点。这种方式在保持数据紧凑的同时，正确地恢复了数据的逻辑视图。

优化二：针对 TsFile 的延迟解压 (Late Decompression)

·问题背景：Apache IoTDB 的存储文件 TsFile 采用了一种双层压缩策略：首先使用轻量级算法（如 RLE）对列数据进行编码，然后将编码后的数据页（Page）再用一个通用的重量级压缩算法（如 LZ4、Snappy）进行二次压缩。原始的 IoTDB 在读取数据时，会一次性将整个数据块（Chunk）的两层压缩全部解开，即使查询可能只需要其中的一小部分数据，这造成了大量的 CPU 资源浪费。

图 6：后期减压策略示意图

·解决方案：CompressIoTDB 的延迟解压策略彻底改变了这一流程。如图 6 所示，当从磁盘读取数据块时，系统只在内存中保留其经过通用压缩（LZ4 压缩）的状态。在查询执行的系列扫描（Series Scan）阶段，系统会逐页（Page by Page）迭代。只有当某个特定的页面真正被访问到时，系统才会对其进行通用的 LZ4 解压。更关键的是，解压出的数据（此时仍是 RLE 等轻量级编码格式）会直接被用于构建 CompColumn，完全跳过了第二层轻量级解压的步骤。这一优化确保了只有被查询所需的数据才会被解压，并且只解压必要的层次，极大地降低了 CPU 开销，尤其是在高选择性（只查询少量数据）的查询中效果显著。

这两项优化体现了系统设计者对 IoTDB 底层架构的深刻理解，它们通过精巧的设计，将同态压缩的理念与现有存储格式的特性完美结合，实现了性能的进一步飞跃。

八、实验评估：验证 CompressIoTDB 的性能优势

为了全面验证 CompressIoTDB 的性能，论文进行了一系列详尽的实验评估。实验设计覆盖了真实世界数据集和多种变化的合成数据集，并与多个基线进行了对比。

实验设置

·基线方法：

1.Uncompressed：数据不进行任何压缩，直接存储和查询。

2.IoTDB：原始的 Apache IoTDB，采用“先解压、后查询”模式。

3.CompressIoTDB-NoLate：禁用了延迟解压优化的 CompressIoTDB 版本，用于评估该项优化的具体贡献。

·数据集：使用了五个来自不同领域的真实世界数据集（天气、电力、智能电网等）以及由标准测试工具 IoT-benchmark 生成的具有不同数据特征（重复率、数据规模）的合成数据集。

·查询负载：设计了 10 个代表真实应用场景的查询，涵盖了过滤、聚合、表达式计算和窗口函数等多种操作。

表 2：数据集

表 3：查询

核心实验结果

·真实世界数据集上的总体性能

图 7：真实世界数据集上的延迟情况

图 8：真实世界数据集的 CPR

在五个真实数据集上，CompressIoTDB 表现出色，与原始 IoTDB 相比，平均查询延迟降低了 33.1%，即吞吐量提升了 53.4%。与完全不压缩的基线相比，也获得了 20.3%的延迟降低。实验还发现，性能提升的幅度与数据集的压缩率（CPR）正相关（如图 8 所示），数据压缩得越好，同态查询的优势越明显。此外，延迟解压优化本身就贡献了平均 14.5%的延迟降低，证明了其有效性。

·宏基准测试（IoT-benchmark）

图 9：不同重复率下的吞吐量

图 10：不同序列长度数据集上的加速比

图 11：多选择性查询的性能

注：数值表示相对于基线方法的加速比；“--” 表示超时情况。

表 4：不同序列长度数据集的微观分析

通过控制变量，实验深入分析了系统在不同条件下的表现：

1.不同重复率：如图 9 所示，随着数据重复率的提高，RLE 编码效率增加，CompressIoTDB 的性能优势也随之急剧增长，最高可比 IoTDB 快 75.5%。

3.不同查询选择率：如图 11 所示，在低选择率（只查询少量数据）的查询中，CompressIoTDB 的优势最为明显，最高可比 IoTDB 快 42.9%。这主要归功于延迟解压策略，它避免了为获取少量数据而解压整个数据块的巨大浪费。

·微观分析与消融研究

图 12：HintIndex 的影响

图 13：执行时间细分

表 5：CompColumn 的内存使用量（GB）

为了探究性能提升的根本原因，实验还进行了更细粒度的分析：

1.执行时间分解：如图 13 所示，CompressIoTDB 在“数据块读取”阶段（得益于传输压缩数据）和“算子执行”阶段（得益于同态计算）都取得了数量级的加速。虽然“系列扫描”阶段因承担了延迟解压的任务而耗时占比增加，但其绝对时间仍远低于 IoTDB 的总解压时间。

2.HintIndex 的有效性：如图 12 所示，消融研究证实，HintIndex 这一看似简单的优化平均带来了 11.7%的性能提升，证明了其在加速顺序扫描中的重要作用。

3.内存使用：如表 5 所示，CompColumn 的内存表示比 IoTDB 中解压后的数据平均节省了 20%的内存空间，在数据重复率高时节省效果尤为显著。

综合所有实验结果，论文从宏观到微观，从真实场景到极限测试，全方位地证明了 CompressIoTDB 框架在提升查询性能、降低资源消耗和增强系统可扩展性方面的巨大优势。

九、结论与启示

本文对《Improving Time Series Data Compression in Apache IoTDB》进行了深入解读。该论文通过将同态压缩理论创造性地应用于时间序列领域，成功地解决了长期困扰 TSDB 的压缩效率与查询性能之间的内在矛盾。

核心贡献总结

1.提出时序同态查询理论：首次为在压缩时间序列数据上进行查询构建了形式化的理论模型，为系统的正确性和有效性提供了数学保证。

2.设计并实现 CompressIoTDB 框架：在 Apache IoTDB 中实现了一个端到端的同态查询框架，展示了该理论在真实系统中的可行性与巨大潜力。

3.创造 CompColumn 数据结构：设计了 CompColumn 这一高效、模块化的压缩数据抽象，它成功地解耦了查询逻辑与底层压缩细节，是整个系统得以实现的关键。

4.实现系统级优化：通过动态辅助信息管理和延迟解压等优化，解决了空值、懒删除、双层压缩等实际工程挑战，使系统在真实场景中表现稳健。

这项工作的影响深远。它不仅为 Apache IoTDB 带来了显著的性能提升（平均 53.4%的吞吐量增长和 20%的内存节省），更重要的是，它为构建新一代“压缩感知”数据库系统提供了一份宝贵的蓝图。论文中展示的架构模式，特别是 CompColumn 的设计思想，具有很强的普适性，可以被借鉴到其他列式存储或分析型数据库中。

通过在理论、系统和工程实践三个层面上的全面创新，CompressIoTDB 描绘了一个未来，在这个未来中，数据可以始终以其最紧凑、最高效的形式存在于存储、传输和计算的每一个环节，从而将大规模数据分析的性能和效率推向一个新的高度。