時序數據庫 IoTDB 2.0 的樹模型與表模型分別有哪些特點與能力？

樹/表模型如何實現平滑轉換與融合查詢？

在未來的聯邦查詢場景中，IoTDB 又將扮演怎樣的角色？

如果你也好奇這些問題的答案，我們將基於 2025 時序數據庫技術創新大會上，天謀科技數據庫內核研發工程師、Apache IoTDB PMC Member 田原的分享，為您系統解讀 IoTDB 在時序數據建模、雙模型融合與跨源分析方面的最新進展。

01 時序模型關鍵概念及 IoTDB 雙模型介紹

時序數據是反映機器實時運行狀態的監測數據，有兩個關鍵要素：一是設備的概念，即實際場景中的物理設備，例如每部手機都有其唯一的序列號作為設備 ID；二是測點的概念，即設備上的具體採集點位，例如手機的陀螺儀可以記錄高度或傾斜角。

如果將某個採集點位的數值與對應的時間戳以二維表格形式列出，便構成了時序數據的基本結構。在可視化展示時，通常以時間軸為 x 軸、數值軸為 y 軸進行呈現，其形態類似於醫院中的心電圖。因此，時序數據在某種程度上可以視為設備的心電圖，用以直觀反映其運行狀態。

IoTDB 在設計之初就選擇了貼近工業採集場景的工業測點模型，這一模型與以 PI 系統為代表，在 SCADA、DCS 等系統使用的核心數據管理範式一致。該模型的主要優勢在於其直觀的層級結構，上下層之間具有天然的包含關係，能夠很好地映射現實世界中許多數據本身所具有的層次化組織方式，從而方便用户進行建模。

此外，為了配合這套樹形模型，IoTDB 還設計了相應的簡潔 SQL 語法。例如，在 1.X 版本中常用的 select from root.db 查詢，正是基於樹形結構設計的。這種樹模型與簡潔 SQL 的搭配，為用户的數據採集和使用提供了很大便利。

新推出的表模型與樹模型的核心差異在於數據結構從樹形轉變為二維表形式，這使得數據模型更接近常見的關係型數據庫，IT 領域用户更容易接受和理解，學習門檻也更低。

然而，與標準關係表有所不同的是，傳統關係型數據庫需要先創建表才能寫入數據，而 IoTDB 支持在工業場景中常見的寫入時自動建表需求。同樣，傳統關係表新增列需執行 ALTER TABLE 操作，而 IoTDB 表模型支持在寫入時自動擴展列，包括 TAG、ATTRIBUTE、FIELD 等類型的列均可動態擴充。

在建模視圖方面，樹模型能夠清晰展示“集團—工廠—設備”的層級包含關係，而在表模型中，這種關係只能依賴建模時預設的列順序來隱含表達。如果建模時列順序設置不當，就無法依賴列序正確表達層級包含邏輯。

IoTDB 表模型中包含幾個核心概念。首先是數據庫，用於管理多種類型的設備。其次是時序表，每一張時序表對應一類具有相同測點和相似採集頻率的設備。在 IoTDB 表模型中，主鍵由所有標籤（TAG）列與時間（TIME）列共同組成，作為每一行數據的唯一標識。

時序表中的列分為測點（FIELD）列、標籤（TAG）列、時間（TIME）列和屬性（ATTRIBUTE）列。測點列對應設備上的採集點位；標籤列用於唯一定位一個設備；時間列則記錄採集時的時間戳；屬性列用於對設備進行補充描述，其內容不隨時間變化，但也無需放入標籤列。例如，一輛車的 car_id 足以唯一定位該車輛，而顏色、型號等屬於附加的、相對穩定的描述信息，歸為屬性列，後續也可能發生變更（如車輛改色）。

在數據篩選效率方面，由於在時間列和標籤列上建有稀疏索引，篩選效率較屬性列更高。屬性列的篩選效率則比測點列更高，因為測點列僅在文件內具有 block 級別的稀疏索引，因此其過濾條件是最嚴格的。

在不同建模場景下，IoTDB 的建模方式可根據實際需求靈活調整。以三種建模場景為例，第一種場景涉及多種類型設備的管理。在 IoTDB 樹模型中，需要手動將不同類型的設備分配至不同前綴路徑下，例如將風機設備置於某一前綴路徑，電機設備置於另一前綴路徑，以此實現對不同類數據的分層建模管理。

而在表模型下，只需為不同類型的設備分別創建對應的時序表，例如建立風機設備表和電機設備表即可。這種區分是必要的，因為不同類型設備採集的測點往往不同，通過分表建模能夠更清晰、有效地組織和管理數據。

第二種建模場景不具備明確設備概念，這在電力監測或場站監控等場景中較為常見。此類場景中，數據僅通過測點 ID 進行唯一標識，而無法對應到物理意義上的具體設備。

針對該場景，在 IoTDB 樹模型中，可以直接在數據庫（db）層級下建立測點，無需設置設備層。表模型同樣支持這種建模方式，由於設備標籤（TAG）列的數量可以是 0 到多列，因此在該場景下可以完全不使用標籤列，僅依靠時間（TIME）列和測點（FIELD）列即可完成數據建模。

需要特別強調的是，測點列的數量在 IoTDB 表模型中沒有限制，可支持數十萬甚至更多，與傳統關係型數據庫通常存在列數限制（如 1024 列上限）不同，這也是 IoTDB 在設計上的一個重要差異。

第三種建模場景為設備包含子設備與測點，如儲能系統中的監控體系可能包含電站、電池倉、電池堆、電池簇、電芯等主體，每一主體都需要監控其電壓、電流等參數。

在 IoTDB 樹模型中，這種層級關係可以直觀呈現，每一層既可以包含下級子設備，也可以擁有自身的葉子節點（即具體的採集測點，如電壓、電流）。

對於表模型來説，儘管電池倉、電池堆、電池簇和電芯採集的測點可能相同，但它們屬於不同類型的設備實體。因此，建議將其拆分為四張獨立的時序表，通過分表實現清晰的結構化組織。

樹、表兩種模型各有其適用的場景，這也是為什麼 IoTDB 2.0 採用了雙模型並行的策略。樹模型的優勢在於其 SQL 語法較為簡潔，因此在簡單的查詢場景，尤其是短查詢中，目前其查詢性能仍優於表模型。而表模型則提供了更豐富的高階分析函數，並且由於兼容標準 SQL，對用户而言學習門檻相對更低，更易於上手。

在實際部署中，同一個 IoTDB 集羣實例可以同時使用兩種模型，兩種模型可以使用不同的語法且彼此隔離，用户可以在同一套實例中根據需求選擇更適合的模型進行體驗與應用。

IoTDB 表模型的一個主要特點是兼容標準 SQL，因此特別補充標準 SQL 的相關概念。

標準 SQL 是一種專門用於管理關係型數據庫的編程語言，於 1986 年由美國國家標準組織（ANSI）標準化，隨後在 1987 年被國際標準化組織（ISO）標準化，最為廣泛認知的是 1992 年發佈的 SQL-92 版本。目前市面上尚無關係型數據庫能夠聲稱完整實現某一版 SQL 標準，通常僅表明“兼容標準 SQL”，即實現了標準 SQL 中的部分功能。

就 IoTDB 而言，SQL-92 中大部分與查詢相關、非事務性的語法均已得到支持。同時，IoTDB 也持續跟進並支持後續標準 SQL 版本的重要功能，包括 SQL:2003 中的窗口函數和表函數、SQL:2016 中的行模式匹配及多態表函數，以及 SQL:2023 中的 GREATEST、LEAST、TRIM 等函數。目前 IoTDB 尚未支持的功能主要為 Common Table Expression（CTE）中的遞歸 WITH 子句，但該功能已被列入後續的迭代計劃中。

02 表模型分析能力介紹

IoTDB 2.0 所支持的表模型增強了分析能力，能夠實現一些在樹模型中難以覆蓋的分析場景。以下通過七個典型例子進行具體説明。

第一個功能是統計已錄入的數據行數。在表模型中，使用 count() 可以直觀地查詢表中共有多少行，這完全符合標準 SQL 的語義。而在樹模型中，count() 的定義則有所不同。由於樹模型在設計之初就將 count() 定義為對匹配到的每個測點列分別統計非空值的數量，因此執行後會返回多列結果，每一列對應一個測點的非空計數。對比之下，表模型的 count() 結果更加直觀高效。

第二個功能是結果集去重。表模型中，去重功能遵循標準 SQL 定義，通過 select distinct 或 count(distinct) 來實現，用於統計特定時間段內某個指標在去重後的所有行數或值。

除了支持標準 SQL 定義的 FULL OUTER JOIN、INNER JOIN、LEFT JOIN 和 RIGHT JOIN 外，IoTDB 表模型還提供了具有時序語義特色的 ASOF JOIN。這一函數引用源於 Python 的 Pandas 庫中，主要用於處理時序數據在採集時間上存在細微偏差時的對齊問題。

例如，兩列時序數據可能都以一秒為週期採集，但各自採集的起始時刻存在毫秒或微秒級別的差異。若使用標準 SQL 的 JOIN 操作，通常要求時間戳嚴格相等才能匹配，這會導致大部分行因時間不完全一致而無法對齊。ASOF JOIN 則允許忽略微小的時間誤差，按照最近的時間戳進行匹配對齊、關聯成一張表，更貼合時序數據分析的實際需求。

第四個功能是子查詢。樹模型在設計初期主要面向 OT 領域用户，他們的應用場景較少涉及複雜的查詢分析需求。因此，樹模型將 FROM 子句定義為基於樹形結構的前綴路徑模式，查詢結果無法作為另一個查詢的輸入直接嵌套到 FROM 中，難以實現子查詢。

而在表模型中，由於採用了標準表結構和 SQL 語法，因此能夠支持包括關聯子查詢、非關聯子查詢中的標量子查詢等多種子查詢形式，滿足了更復雜的數據分析需求。

第五、六個功能是窗口函數和多態表函數，這兩者都屬於標準 SQL 中的函數分類。標準 SQL 函數分類主要包含標量函數、聚合函數、窗口函數、表函數、多態表函數等類型。其中，多態表函數是表函數的增強版本，因此 IoTDB 選擇直接支持多態表函數。

窗口函數是一種基於多行數據對當前行進行計算的函數，其結果為每一行輸出一個值。在時序數據場景中，窗口函數應用十分廣泛，例如計算累計平均值或移動平均值等需求，均可通過窗口函數方便地實現。

多態表函數是 SQL:2016 引入的一項里程碑式功能，它為 SQL operator 提供了一種通用的實現方式。傳統 SQL 操作受限於 FROM、PROJECTION、ORDER BY、HAVING、GROUP BY 等固定算子，難以自定義業務處理邏輯並將其融入 SQL 生態。多態表函數的出現打破了這一限制，使用户能夠擴展 SQL 處理邏輯。

這一特性也推動了 SQL 在更廣泛場景中的應用。例如，2019 年 SIGMOD 會議上提出的“one SQL to rule them all”理念，正是基於表函數定義了一套流處理的時態語法，使流處理場景也能用標準 SQL 表達。類似地，IoTDB 引入表模型，正是為了將時序場景中的時序語義通過標準 SQL 的方式實現，原有的樹模型也可視為對標準 SQL 的一種擴展，共同構建多樣的時序數據處理生態。

以重疊時間分窗為例，在 IoTDB 樹模型中需使用特定的自定義語法，而在表模型中，則可通過 HOP 表函數來實現。該函數命名遵循業界標準，與 Flink 等大數據組件保持一致，方便使用集成。

最後一個功能例子是行模式識別，該功能同樣在 SQL:2016 中被引入，但目前僅有少數數據庫支持實現。IoTDB 2.0 版本已實現行模式識別，使用户能夠通過自定義的模式對時間序列進行匹配。

以股價分析場景為例，如果需要識別價格先上升後下降的模式，可以通過行模式識別功能實現。首先定義模式變量：設定 START AS TRUE，表示從起始點開始統計；定義 UP 為當前值大於前值，DOWN 為當前值小於前值。然後，使用類似正則語法的表達式 UP+、DOWN+ 來描述“先連續上升、再連續下降”的序列模式。

根據此模式進行匹配，即可從數據中找出符合條件的段落。例如，在示例數據中能夠識別出兩段滿足先上升後下降條件的數據，之後可進一步對這些數據進行聚合或計算分析。

另一個使用行模式識別的案例為：需要將海拔超過 500、再降低 500 的區間標記為一個事件，並在該事件內計算最高海拔及其開始與結束時間。這不僅要求定義事件模式，還需要對匹配到的序列片段進行計算，在 IoTDB 2.0 版本中同樣可以實現。

由此也可見，標準 SQL 正在逐漸貼近時序場景的需求，希望涵蓋以往難以用 SQL 直接表達的時序語義與事件邏輯，從而擴展其在複雜時序數據分析中的表達能力。

03 樹表雙模型融合能力介紹

除了支持樹模型與表模型的豐富功能，IoTDB 2.0 版本也建立了兩種模型的融合機制，支持將已有的樹模型建模映射為表模型視圖。該機制可行的根本前提是兩種模型共享統一的底層存儲，即均基於 TsFile 這一物聯網場景下的統一數據文件。

TsFile 存儲僅識別設備和測點這兩個核心概念，樹模型和表模型只是用户側不同的建模視圖，因此 IoTDB 可以在兩種模型的語義之間建立映射關係，從而使原有樹模型的用户無需遷移數據，即可直接使用表模型提供的分析能力。

樹模型轉表模型的語法較為簡明，其核心是通過 CREATE VIEW 語句建立邏輯視圖，與關係型數據庫中的標準語法一致。用户需在視圖中定義樹模型各層與表模型 TAG 列之間的映射關係。

在 AS 子句後，若為表模型邏輯視圖，則需接一段 SQL 查詢語句。而將樹模型映射為表模型時，AS 後指定的則是原樹結構中的一個子樹前綴。例如，如果需要將“風機”這棵子樹映射為一張風機表，則指定其對應前綴路徑至風機層級。

對於結構更為複雜的樹模型，例如設備同時包含子設備和測點，同樣可以通過相應的語法將其映射為多張表。如圖中右側所示，可通過定義四個邏輯視圖，分別將不同的設備層級映射為對應的時序表，從而實現從樹形結構到表模型的轉換。

沒有設備的建模中，樹模型與表模型之間依然可以進行映射。由於兩者在語義上是等價的，即使數據僅通過測點 ID 進行組織，也能通過相應的視圖定義實現模型間的轉換。

如果用户在樹模型的每個測點下添加了 value 這一層級，通過相應的映射語法，此類結構同樣可以轉換為包含三列（如時間列、測點列與 value 列）的窄表形式，並支持對測點名的模糊匹配，例如“查找測點路徑中以 ‘DCS’ 開頭、以 ‘A’ 結尾的所有測點數據”。

在樹模型中，FROM 子句無法使用通配符實現特定層級的正則語法匹配，只能對特定層級進行通配匹配。而映射為表模型後，用户可直接使用 LIKE 等標準 SQL 語法對測點名進行靈活匹配，從而實現對複雜路徑的查詢需求。

04 融合查詢展望

IoTDB 未來計劃進一步強化聯邦查詢能力，旨在實現將 IoTDB 作為工業場景下的統一查詢入口。

工業場景中，許多具備事務性需求的結構化數據通常存儲於關係型數據庫中。為支持跨源分析，IoTDB 提供了多種數據庫連接器（Connector），能夠將外部數據轉換為關係視圖。基於此，用户可在 IoTDB 中直接對外部關係數據與內部時序數據進行統一操作，如執行 JOIN、FILTER、PROJECTION、GROUP BY、ORDER BY 等計算，實現異構數據的融合分析與一站式查詢。

類似的轉換邏輯也應用於樹/表模型的融合。樹模型可視為一種異構數據源，可以通過 IoTDB 內置的類似連接器的機制，將其映射為表視圖，再執行 TableScan 等操作。因此，在 IoTDB 系統內部，樹與表被視作兩種異構視圖，二者通過連接器進行轉換與集成，最終在統一的查詢框架下實現對多模型數據的靈活處理。

以一個具體例子説明：假設 MySQL 數據庫中存儲了一張名為 car_info 的關係表，記錄了車型、顏色等結構化的靜態信息。這些數據雖然物理上存儲在 MySQL 中，但用户可以在 IoTDB client 直接編寫 SQL 進行查詢。通過 IoTDB 內置的 MySQL Connector，MySQL 存儲的數據可以在 IoTDB 中呈現為一張可查詢的表。

在這個例子中，IoTDB 通常存儲的是車輛的動態時序信息，例如行駛過程中的速度、温度等實時監測數據。IoTDB 可以通過聯邦查詢對來自不同數據源的表進行關聯與分析。例如，可以將存儲在 IoTDB 的 CAR 018 的行駛時序數據與存儲在 MySQL 中的車輛靜態屬性表通過 car_id 進行關聯（JOIN），從而獲得該車輛對應的車型、顏色等靜態信息。進一步地，IoTDB 可以基於 JOIN 後的查詢結果，按照車輛的靜態屬性進行分組聚合，實現諸如統計各顏色車輛銷售數量的分析需求。

IoTDB 將持續深化對異構數據源的融合查詢支持，致力於演進成為面向工業場景的一體化查詢基座。