時序數據庫 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常用的輕量級壓縮方案深度集成。

三、理論框架：為時序數據定製的同態查詢模型

為了系統性地解決上述挑戰，論文首先構建了一個堅實的理論框架，為在壓縮時間序列數據上進行查詢提供了形式化的定義和性能保證。這個框架不僅證明了方法的正確性，更重要的是，它為後續的系統設計提供了原則性的指導。

然而，僅僅正確是不夠的，一個“好”的同態查詢還必須是高效的。為此，論文進一步提出了兩個關鍵性質：

• 直接同態查詢 (Direct HQ)：一個理想的同態查詢應該完全在壓縮數據上進行，不涉及任何中間解壓步驟。這是實現最高效率的目標。

表 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描繪了一個未來，在這個未來中，數據可以始終以其最緊湊、最高效的形式存在於存儲、傳輸和計算的每一個環節，從而將大規模數據分析的性能和效率推向一個新的高度。