導讀：本文将介紹Apache IoTDB，它是一個基于開放數據格式的數據庫。

今天的介紹會圍繞下面四點展開：

• Apache IoTDB 簡介
• 時序文件格式 TsFile
• 基于開放文件的數據庫架構
• 開源社區建設

01

Apache IoTDB 簡介

IoT是物聯網的縮寫，DB是數據庫的縮寫，IoTDB的名字直接說明了它物聯網數據庫的定位。物聯網場景下時序數據主要來自傳感器的采集，如風力發電機上用于探測風速的傳感器，每秒采集一條數據，随着時間推移，這些數據就會形成時間序列，時間序列數據就反映了當時風力的變化情況。圖中的綠色部分展示了草帽風的現象。由于形狀類似草帽因此稱之為草帽風，此類風會對風機葉片産生負面影響，進而降低風機壽命。

物聯網時序數據是工業設備物理量的數字化記錄，在軌道交通、能源管控、智能制造等領域有廣泛應用。

① 軌道交通

在軌道交通領域，通過将大橋安裝傳感器、對傳感器數據進行采集和分析，可以檢測橋梁的狀态，如撓度、應變、振動、支座位移情況等，從而可以進行有針對性的健康檢測和加固，避免橋梁坍塌，保障人民出行安全。IoTDB已有該領域的用戶案例。

② 能源管控

一些IoTDB的開源用戶對化工廠進行能耗監測、報警管理、預測優化，實現節能、減排、增效，響應“碳達峰、碳中和”政策。

• 能耗監測：通過監控工廠的實時用水流量，查找供水系統的跑、冒、滴、漏以及水力平衡等問題，如果出現工廠停工後用水量依然不斷增加的情況，及時進行排查。
• 報警管理：根據測點值進行異常判斷，及時進行聲、光、電話報警，降低能源系統故障所造成的影響。
• 預測優化：建立能源預測模型，優化生産排期，達到降低污染的目标。

③ 智能制造

以煙廠對IoTDB的應用為例，煙廠通過對設備狀态監控和統計過程控制，提高生産效率，實現制造業升級。

• 設備運行監控：收集設備關鍵數據，檢查某時刻設備生産過程關鍵數據（嘴棒數、卷煙紙、水松紙）。
• 制絲質量評價：根據實時監測數據（煙絲整絲率、碎絲率等），對煙絲質量進行判定。
• 統計過程控制(SPC)：根據葉絲含水率、出料溫度等工藝質量數據，區分産品質量的随機波動、異常波動與發展趨勢，根據趨勢判斷是否需要加料、減料，保證生産過程穩定。

以上應用都是在各種設備上加裝了大量傳感器，而如何加，是每家工業企業需要結合業務特點進行确定的。在設計數據采集的同時，也需要設計如何對數據進行存儲。通常采集的數據越多、粒度越細越好。一台高端設備，如飛機有8萬個傳感器；一台挖掘機上會裝配四五百個傳感器，但挖掘機數量衆多，一家用戶有兩萬台挖掘機，就有千萬級時間序列數據；兩萬台風力發電機，每年能産生120PB數據。時序數據在物聯網領域的體量是龐大的。

飛機、挖掘機、風電機離我們的日常生活遙遠，但對于飛行員、挖掘機駕駛員和電廠監控平台管理人員來說，每台設備都是有生命的個體，時序數據就是設備的心電圖。時序數據是重要的資産，為了更好地管理時序數據，我們在2011年受到國家863計劃支持下發起了物聯網時序數據庫——Apache IoTDB項目。

接觸工業物聯網用戶、為用戶管理時序數據，是清華大學軟件學院在2011年開始的一個方向。随着我們對産業和時序數據相關的研究與思考的深入，我們開始自研時序數據庫，在2017年推出了IoTDB第一個版本并在Github公開源碼。2018年我們将項目捐贈給Apache基金會。經過兩年的摸索，IoTDB在2020年9月成為了Apache頂級項目。至此，IoTDB是首個入選Apache的工業物聯網時序數據庫項目，也是首個中國高校發起的Apache頂級項目。IoTDB被來自德國、美國、中國的工業互聯網廠商和智能制造廠商使用和打磨，産品和功能在開源社區中不斷成熟。

IoTDB産品易用、好用，部署靈活，能開箱即用一鍵部署，具有高寫入吞吐和低查詢延遲，支持豐富的時間序列操作，與現有大數據生态系統集成比較完善。

IoTDB能夠支持複雜負載。傳統數據庫應對簡單負載更加友好，但對複雜負載的處理表現不理想。簡單負載中，設備測點少，采樣頻率低、幾秒一個點甚至幾分鐘一個點，這種情況下表數據量小，一張表就可以滿足設備一周到一個月的存儲。但設備數據量大時需要進行分表，用戶的使用上會造成不便。關系表也更加适用于管理規整的數據，例如一個設備的多個傳感器采集時間相同，則表中不需要存儲空值；但當每個設備上維護各自的時鐘，獨立地上報數據，此時時間難以對齊，表的數據稀疏，空值多。

複雜負載單體設備可能會産生上千甚至數萬的點，如飛機采樣頻率比較高，轉動傳感器每秒鐘采集幾十甚至幾百個數據點，或者人工去分表都難以滿足需求。但IoTDB會針對這些複雜負載進行優化。

IoTDB允許設備定義數據模式。使用傳統關系型數據庫時，用戶首先要定義表結構，然後才能寫入數據。IoTDB允許用戶不預先定義表結構，直接寫入數據，這個特性降低了用戶使用負擔，也更加适應物聯網設備快速叠代升級的場景。假如一個設備裝了3、4個傳感器，随後又新增了其他感應器收集測點，這時使用傳統數據庫需要Alter Table修改表結構，但使用IoTDB即可不用修改表結構直接向數據庫内寫入數據，寫入過程中自動完成數據模式的創建。

IoTDB支持端雲同步。端雲同步是物聯網領域中常見的場景。終端設備采集數據，一條條地發送數據到雲端數據庫。該過程中需要在端側對數據編碼為二進制流，在雲數據庫側解碼數據後寫入數據庫。終端數據大量增長時，存在雲端壓力不斷增加，網絡帶寬消耗大的現象。

對此我們提出了基于文件的數據同步方法，在終端把數據寫為壓縮的文件，再把文件同步到雲端。由于網絡傳輸的是壓縮好的文件而不是原始數據，網絡流量消耗降低。雲端也不需要在解析數據後一條條地寫入數據，隻需要加載上傳的文件即可，降低了雲端CPU消耗。

IoTDB專注于數據的存儲管理，為了支持更多對數據的全生命周期處理，我們與衆多開源項目進行了集成。IoTDB支持PLC4X等工業采集協議，也适配了Kafka、Flink、Spark，還對數據交互軟件和可視化工具做了支持如Grafana, zeppelin等。用戶可以自由地利用開源軟件滿足自己的數據采集、處理、分析的需求。

IoTDB産品形态分為三部分：

① 部署在嵌入式終端設備的時序“數據文件”

在端上，數據存儲為時序數據zip文件，支持高性能寫入，高壓縮比存儲，支持簡單查詢。

② 部署在邊緣計算設備的時序“數據庫”

邊緣計算設備上，可以支持高效豐富的時間序列查詢引擎，提供增删改查，以及聚合查詢時序對齊等高級功能。

③ 部署在雲端數據中心的時序“數據倉庫”

IoTDB可以與大數據分析框架無縫集成，支持時序數據處理、挖掘分析、機器學習。

IoTDB與傳統數據庫不同，IoTDB把文件作為重要的概念，是系統的底層基石。

--

02

時序文件格式 TsFile

1. 文件vs數據庫

文件不是一個長活服務，不會丢失；而數據庫作為長活服務，需要保持在線，為此需要為數據庫設計高可用、保活等策略，需要檢查數據庫運行狀态是否正常。文件的運維負擔會比數據庫的運維負擔輕。寫入模式方面文件是追加寫入的方式，數據庫提供了增删改查功能。寫入文件的數據需要在文件關閉後進行查詢，而數據庫數據寫入後即可進行查詢。文件的查詢流程和管理需要自己實現，而數據庫使用SQL即可完成數據的查詢。

對數據時效性和查詢負載不複雜的場景中，數據存儲到文件的模式更加輕便、簡單。數據庫更适用于數據應用逐漸豐富、對查詢要求高的場景。

2. 常見文件結構

Spark、Hive、Presto廣泛使用了CSV、ORC、Parquet這些文件結構。ORC和Parquet是支持嵌套的列式存儲文件結構。當使用這些文件結構存儲數據時也需要進行建模，包括定義每列的數據類型和名稱等。

3. 建模方式

數據有多種建模方式。

一種建模方式是把所有設備數據都存到一個文件裡面，此時文件中表結構第一列是時間戳，第二列是設備名，後面是這個設備的所有的測點數據。可以看到這種建模方式下，一個文件可以管理多個設備的數據，但設備名字是被重複存儲的。當查詢一個設備的一個測點的時間序列時，下圖中建模方式1的藍色部分需要全部讀出來進行過濾後才能得到結果。

第二種建模方式也是可以在一個文件裡管理多個設備的，整個文件隻有四列，其中設備名和測點名是重複存儲的，查詢時就需要讀取更多的數據，基本上需要把所有數據都查找一遍才能拿到需要的數據。

第三種建模方式是每一個設備一個文件。這種模式沒有重複存儲的數據，但在一個應用裡設備數量較多、達到上千萬量級，而上千萬個文件同時寫入是不能實現的方式，此外大量文件對文件系統也是負擔。

第四種建模方式是一個時間序列存儲為一個文件。這種方式相比第三種在實際應用中更不可行。

幾種建模方式從文件數的角度，建模方式一和二的文件數可控，一個文件就可以存儲所有數據，在文件大小超過阈值後再寫入新的文件。建模三的文件數就是設備數，建模四文件數是序列數。在一個應用中希望文件數比較可控，我們更傾向使用建模一和二，整個系統的穩定性是最重要的。在存儲方面，建模三和四沒有冗餘的數據，在一些設備數比較少時會使用建模三。建模二的冗餘數據又比建模一的更多。

為什麼會出現空值？一個設備假如有一萬個傳感器，這一萬個傳感器的采集時間都是一樣的，此時可以存成一行，且這一行沒有任何的空值。但是一旦多個傳感器的采集時間不同，就無法按時間對齊，存儲時會出現空值的情況，空值也會影響文件的壓縮比。建模一和三都會存儲空值。

由于建模方式三、四都可以規避冗餘數據，因此定位速度應該是最快的。建模方式一能夠避免掉一些測點的讀取，建模二需要讀出所有數據，所以建模二的定位速度最慢。

可見，在壓縮比、查詢性能和海量序列管理幾個維度上，前面的幾個建模方式都不是完美的。是否有一種文件結構在管理時序數據時，文件數可控、無冗餘數據、查詢性能和寫入性能比較高呢？它就是TsFile。

4. 針對時序數據的文件結構——TsFile

TsFile全稱是Time Series File。它的數據模型是為了物聯網領域設計的，包括設備、物理量（測點）、時間和值，用TsFile管理數據時隻有這四個概念。存儲優化方面，TsFile采用列式存儲，編碼和壓縮可選多種方式，時間列可選是否由多列共享，TsFile提供了列式寫入接口。查詢優化方面，TsFile存儲了預聚合信息、樹形索引、向量化查詢等。

① TsFile數據模型

TsFile有設備、物理量（測點）、時間和值這四個狀态，圖中是兩個TsFile的典型模型。

圖中左側是一個車輛有兩個傳感器，這兩個傳感器采集的時間是不對齊的，這時我們叫它非對齊的序列。那這種建模方式會把每一個時間序列裡都存一列時間，這種方式是最節省空間的，沒有存儲任何空值。這種方式适合一個設備的不同傳感器是獨立采集的場景。

圖中右側這種設備GPS，有經度和緯度兩個物理量，那這種數據一般都是同時采集的，會共享一列時間戳。這種方式兩個列隻存一列時間，我們稱之為對齊序列。可以看到對齊還是不對齊應該是一個設備的屬性，所以在設備層面有一個屬性來做控制，在寫入時也可以設置這個設備的屬性。這個數據模型的特點是在0.13版本去引入的，3月會發布0.13版本。

在場景和模型的選擇方面，非對齊序列更适合多物理量獨立采集場景，對齊序列更适多物理量同時采集的場景。可以根據不同場景選擇不同存儲引擎。

② 數據存儲結構

TsFile數據存儲結構如圖。ChunkGroups存儲一個設備一段時間寫入的數據。Chunk是一個物理量一段時間的數據，分為三種Chunk：（1）TSChunk，時間 值；（2）TimeChunk，時間；（3）ValueChunk，值。在Chunk基礎上我們又把數據劃分成Page，Page是一個物理量一段時間的數據，有三種Page：（1）TSPage，時間 值；（2）TimePage，時間；（3）ValuePage，值。通過這種方式，TsFile采用分級的數據存儲結構進行管理。

③ Page 編碼壓縮算法

Page是數據最小粒度，可以對Page進行編碼和壓縮。圖中展示了幾種編碼和壓縮算法，紅色的是數據類型的默認壓縮編碼與使用的算法。

④ TsFile索引結構

TsFile有豐富的索引結構。

TsFile序列内索引是三級統計信息（Page、Chunk、文件級），作用是過濾數據塊（減少 IO 和物化）和支持聚合查詢（直接返回結果）。

序列間索引是樹形元數據索引，作用是管理海量序列更高效。

Parquet、ORC需要一次加載全量元數據，查詢複雜度是O(N)；TsFile隻加載查詢路徑的元數據，時間複雜度O(log(N))。TsFile複雜度會比Parquet、ORC低很多。

⑤ 向量化寫入接口、查詢引擎

在向量化的寫入接口和查詢引擎方面，我們引用了一個Tablet的概念。Tablet結構就是管理了一個小的子表。下圖中右側是它的具體的數據定義方式，可以看到它是一個列式的存儲，采用了一些原生數據類型的數組，沒有封裝更多對象。這個結構也保持了IoTDB的高效的讀寫性能。

⑥ 讀寫性能

下圖中是在公開的數據集合上TsFile的寫入速度、磁盤占用、單列查詢耗時三個指标與Parquet、ORC、CSV格式在四個公開數據集上的對比。

--

03

基于開放文件的數據庫架構

我們基于TsFile做IoTDB引擎，做數據庫的目的是因為文件無法提供實時查詢，而IOT有實時查詢數據的監控的需求；文件難以處理亂序數據、數據更新困難，工業場景中常見亂序數據，也經常有更新數據需求；多文件管理、分析需要應用層處理。

開放的數據架構指的是IoTDB是由“時序文件 數據庫引擎 分析引擎”三部分組裝起來的松耦合、模塊化的架構，類似于“存算分離”架構模式。這與傳統數據庫的黑盒子模式不同，這一架構對用戶透明可見。

IoTDB具體架構如圖所示。

最左面是數據的來源，有設備數據、系統狀态等。

數據可以通過圖中藍色部分的時序文件導入。我們提供了文件級的API，API和Parquet、ORC類似，可以對單個TsFile進行讀寫操作。我們把數據通過API寫成TsFile文件格式後，可以通過TsFile的一些加載模塊把文件加載到數據庫中。此時數據文件層的TsFile是被數據庫的引擎所索引的，它其實在磁盤上隻是換了一個目錄，我們還是能夠看到這些文件。這裡的文件可以加載進去再卸載出來，文件管理非常靈活。

文件層之上是數據庫的引擎層。數據庫的引擎能夠管理多個數據文件，它還負責提供給用戶更多訪問數據庫的接口，包括原生的讀寫接口session以及命令行，交互工具，還有可視化的平台。

分析引擎方面，我們開發了各種對接開源數據處理平台的連接器，IoTDB 和底層的數據文件，都可以和分析引擎進行對接。

IoTDB是一個比較開放的架構，架構的設計也是我們在不斷地使用開源系統的過程中總結出來的。針對文件靈活的設計簡化了數據庫的運維，讓我們可以随時從一個數據庫裡把數據文件拿來做分析。文件也可以從這個設備側寫完後再加載到數據庫裡去。

端側應用的監控通常不需要非常及時，文件足夠滿足需求；端側文件上傳到邊側進行分析，也可以放到數據庫中進行查詢；雲側文件可以将文件對接Spark、Flink做數據分析，可以作為時序數據倉庫使用。邊側和雲測可以部署IoTDB數據庫。

基于TsFile兩層設備和物理量模型，我們在數據庫層面擴展了豐富的樹形結構的物聯網數據模型。樹形結構對應了層級管理設備資産的方式，即設備歸屬的區域、設備的類型、設備号。從root到倒數第二層節點的全路徑來定位設備ID。這種建模方式可以把一個應用的所有時間序列都統一到一棵樹中進行管理。

樹形結構的數據模型與TsFile通過存儲組進行連接。存儲組可以讓用戶指定哪些序列可以存儲到一個文件裡，一個存儲組一段時間的數據會形成一個TsFile。

接下來我們看一些實際數據模型轉化在IoTDB中建模的案例。圖中是OPC Server采樣的點位，這些點位是一個個Name，按點分割。這個結構和樹形結構有天然的映射關系，我們可以在數據前面加一個root，按點進行樹形模型拆解後構造成一棵樹，映射非常自然。

InfluxDB數據模型有Tag和Field，我們把Tag value當作樹裡的節點，Field name作為物理量。我們不重複存儲Tag name，可以快速定位數據。

--

04

開源社區建設

1. 核心理念

開源社區建設方面，我們運營了兩年開源社區，愈發感受到開源社區核心理念的重要性。

平常在公司和團隊内工作與開源社區不同，開源社區需要更多地把溝通開放出來。IoTDB是一個基于文件的開放架構，思想也要對應地開放。清華軟件學院團隊的工作流程都需要文檔化，向社區開放，同步項目進度。

作為開源貢獻者，我們每個人都希望我們提的一件被尊重，對于開源社區來說這也是一個對待貢獻者的基本态度。

有些貢獻者除了提一些建議外還能給貢獻代碼，小的修改提一個pr社區就可以審閱合并，但更大的功能模塊開發就需要分布式協作了。

我們建設開源社區的思路是通過開放架構、開放思想，尊重每個人的建議和分布式協作，達到為用戶提供好用的開源軟件的核心目标。

2. 建立了活躍的開源社區

IoTDB社區目前有160多位開發者，上千人的用戶群。IoTDB經常舉辦培訓會和開發者、用戶見面會。

3. 社區影響力日益凸顯

社區在軟件開發過程中的影響力逐漸增加，工業PLC數據采集系統已經與IoTDB進行了對接和集成，巴西的一些開發者貢獻了IoTDB作為Prometheus的底層存儲。國内龍頭企業也設置了IoTDB相關的工作崗位。

4. 應用案例

在應用方面：上海地鐵運行了兩年半，管理了100萬時間序列數據。湖南湘潭和耒陽電廠數據管理系統應用IoTDB運行了20個月，管理1萬條序列。東莞東城環衛管理系統中管理的各種環衛車的數據，運行兩年多時間中管理着數千條序列。

今天的分享就到這裡，謝謝大家。

分享嘉賓：喬嘉林博士 清華大學

編輯整理：張德通 Treelab

出品平台：DataFunTalk

分享嘉賓：

活動推薦：

關于我們：

DataFun：專注于大數據、人工智能技術應用的分享與交流。發起于2017年，在北京、上海、深圳、杭州等城市舉辦超過100 線下和100 線上沙龍、論壇及峰會，已邀請超過2000位專家和學者參與分享。其公衆号 DataFunTalk 累計生産原創文章700 ，百萬 閱讀，14萬 精準粉絲。

歡迎轉載分享評論，轉載請私信。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!