工業物聯網資料庫管理系統Apache IoTDB新特性與實踐

Apache IoTDB時序資料庫是面向工業物聯網領域的、由我國自主研發並開源給Apache的頂級開源專案。隨著觸發器、UDF等功能不斷引入，IoTDB的應用場景越來越豐富。本文重點分享IoTDB的新特性，以及在工業物聯網應用解決方案中的技術選型思考，希望對相關從業人員在做技術選型和整體架構設計有所幫助。

▲清華大學軟體學院助理研究員黃向東

嘉賓介紹：黃向東，清華大學軟體學院助理研究員，中國科協青年託舉人才，CCF資料庫專委會通訊委員，中國通訊學會開源技術專委會委員，Apache國際開源軟體基金會委員，Apache IoTDB專案V.P.。主要研究領域為大資料管理技術，聚焦工業大資料管理。獲國家發明專利授權30餘項。參與研製了我國新一代氣象大資料平臺，負責研製了工業物聯網時序資料庫管理系統軟體IoTDB，開源版成為我國高校發起的首個Apache頂級專案。主持國家自然科學基金專案、中國博士後科學金金各一項。獲2018年教育部技術發明一等獎，2018年中國氣象學會科技進步一等獎。

以下是黃向東老師在DTCC2021大會現場的演講實錄：

IoTDB專案介紹

工業物聯網時序資料是工業裝置物理量的數字化記錄，是帶時間戳的資料，蘊含豐富的工業語義。IoTDB是清華大學發起研發的一款聚焦工業物聯網、高效能輕量級的時序資料管理系統，提供資料採集、儲存、分析的功能。

國際工業網際網路領導者通用電氣(GE)公司2012年指出：“充分利用海量時序資料驅動工業創新、競爭和成長，是大資料技術為新工業革命帶來的歷史性機遇。”

大家可以觀察資料庫領域的西雅圖報告，指出未來五年會形成一個資料庫的發展前景。有報告專門提到，IoT會給資料庫的寫入查詢，都帶來一些新的挑戰，包括：海量序列儲存、複雜後設資料管理、豐富的查詢需求、邊雲協同等。這樣一來，在產業界和學術界，時序資料都變得更加受關注。

如果把圖中工業物聯網時序資料的縱座標刪掉，改成“值”。那麼，它就會從工業物聯網時序資料變成時序資料。可見，其實時序資料是非常普遍的，人、軟體、機器的行為，都在不斷產生時序資料。

關於TSDB，維基百科上的解釋是，時序列資料庫用來儲存時序列(time-series)資料並以時間(點或區間)建立索引的軟體。它的主要應用場景分為APM監控、物聯網應用、資料分析三種。目前，時序資料管理系統的選型多種多樣，包括ClickHouse、Druid、HBase、OpenTSDB、Parquet on HDFS/S3、PG/MySQL、TimeScaleDB、MatrixDB、InfluxDB、M3DB、TDengine、Apache IoTDB、Skywalking EMQx等。所以，在面向不同的系統時，會有不同的選型解決方案。

Apache IoTDB新特性

IoTDB在Apache社群走開源模式，和一系列開源軟體做適配整合，最終目標是打造時序資料全生命週期管理的開源解決方案，包含從資料的採集、儲存、處理，到分析、應用，所有的環節進行打通。

在採集階段，有很多開源的軟體，像EDGENT、PLC4X。在分析階段，可以用Spark、Hive來做大資料分析。在應用階段，可以選擇Grafana、calcite、karaf等開源程式。

從發行歷史來看，IoTDB來自於清華大學軟體學院。2017年，我們對它進行開源。2018年，Apache社群很多有經驗的夥伴一起協助改善IoTDB，從demo形式逐漸變到產品形式。2019年，發行第一個Apache IoTDB版本。其實可以看到，IoTDB的發版速度並不是很快，但是基本上每年都會有一兩個版本在發行，每個版本在寫入、查詢、穩定性方面都做了改進。2019年，IoTDB最佳化了亂序資料整理的功能。2020年，IoTDB的查詢效能大幅提升，提供全新記憶體控制功能。2021年，社群正式推出了IoTDB 0.12系列版本，並在0.12版本上維護了0.12.0 - 0.12.4共計5個小版本。

特性1：資料模式從後臺定義到邊緣裝置定義

近幾年，傳統工業企業的裝置零部件升級頻率越來越高。在升級系統的過程中，資料的採量方式也在發生變化，新增或者減少測點。最後會形成這樣的表結構。但真正讀資料的時候會發現，一張表的列是需要經常變的。

特性2：從規則負載到複雜負載

由於裝置的測點過多，在關係型資料庫模式下，這樣一張表會被迫要縱向拆掉。因為如果一個資料庫不設定表的列數，就無法分配記憶體，還會對系統造成一定的影響。

此外，複雜的工業裝置是由很多獨立的子裝置或零部件構成。從資料庫的角度來看，各測點獨立採集，採集頻率不一致，時間不齊。雖然在做查詢的時候，表的結構是最適合的，這時候使用者的表達能力最強。但是在寫入和管理的時候，不需要使用者看到這樣一張表。基於此，層次化結構來管理資料是工業企業的天然想法。在這個層次化結構上，裝置上的測點的採集頻率可以不一。

在應用的過程中，IoTDB一直堅持使用上圖的樹形結構，比較符合資產管理和資產排程的方式。

IoTDB定義了多個概念，面向工業物聯網的場景下，直接擁有物理量的裝置或裝置，會產生資料，所有物理量都有歸屬叫做實體。比如，一臺風力發電機、一輛車、一座橋等，都屬於實體。多個實體的集合，其資料在磁碟上物理隔離，稱為儲存組(Storage group)。

物理量(工況、欄位、測點、變數)可以度量裝置所記錄的測量資訊，它可以是一元的或者多元的。一元物理量可以獨立採集功率、電壓值、電流、支座位移、風速、車速、經度、緯度等。多元物理量可以同時採集GPS(經度、緯度)等。

由此，我們定義了時間序列(實體+物理量)，包括一元序列(實體+一元物理量)和多元序列(實體+多元物理量)。對於IoTDB來說，我們的儲存就變成了實體+物理量，如某颱風機的轉速，某車輛的GPS。

不同的建模方式會對系統產生怎樣的影響呢?顯而易見，每個一元序列會有自己的時間軸。如果多個一元序列的時間軸完全相同，那時間軸一定是重複的，會導致空間資源的浪費，此時應該將它儲存為多元序列。

IoTDB未來會嘗試著去識別，場景適用於一元序列還是多元序列。現階段，需要使用者自己去定義。

現實應用中，也會存在海量同型別、同型號的實體，每個實體有相同的物理量集合，比如一批相同型號的車，一批相同型號的風機，我們將其稱為物理量模版。使用物理量模板，可以大幅減少後設資料管理代價。

不同序列的型別有不同的編碼和壓縮方法選擇，來提供更好的壓縮率。其中，PLAIN適用於變化幅度較大，無規律，難預測的資料。RLE適用於大部分值相同的資料。TS_2DIFF適用於變化穩定的資料。GORILLA適用於資料變化較小的浮點數。DICTIONARY適用於基數較小的TEXT型別。

特性3：從時序資料查詢到時序資料處理

儲存資料對使用者來說是成本付出，而分析資料中的價值才能給使用者創造利益。所以說，要讓IoTDB具備分析能力，尤其是面向工業領域的分析。那麼，能否把分析任務，以及哪些處理分析任務，交給IoTDB來完成?

對於database，做資料分析有幾個時機。第一個時機是資料剛進來的時候，有可能會經過一次處理。噹噹資料到達時，IoTDB提供基於滑動視窗和單點的計算模型，來實現有狀態和無狀態的計算。同時，為了限制計算的複雜度，IoTDB只允許分析計算任務計算單條序列或者一個裝置下的多條序列。

第二個時機是，當資料已經儲存到資料庫中，但還沒有被查詢。這段時間，我們可以對資料提前進行分析計算，這部分可以用索引來表示，索引的目的是讓使用者更快地使用資料。

第三個時機是查詢時計算，例如把原始資料求平均值，或者絕對值。查詢時計算這一概念對映到資料庫中，就不得不提使用者自定義函式(UDF)。對於UDF來講，時序資料有兩種，一種是UDTF(使用者自定義時間序列函式)，即輸入n條序列，輸出1條序列;另外一種UDAF(使用者自定義聚合函式)，即輸入n條序列，輸出1個點。

過去幾年，我們一直在做時序資料的資料質量方面的研究。藉助UDF，把這些演算法與IoTDB整合，形成了一套IoTDB-Quality面向時序資料的資料質量演算法庫，當然這套演算法並不與IoTDB強繫結。

IoTDB支援使用者自定義降取樣。如果系統提供的降取樣能力或者功能與業務不滿足，比如，當資料密集時，選用平均值，當資料稀疏時，選用最大值最小值。這種情況下，DB的降取樣能力無法支援如此豐富的自定義，就可以用自定義函式來實現。

又如，時序資料的一個重要的工業應用是實時告警。一旦出現告警之後，就要快速的做出響應控制。但是在真實的應用中，觀測值低於指定閾值會導致大量的告警。如果想要在生產中可用，往往需要把虛警過濾掉。所謂虛警就是由於資料的波動形成的異常。

我們透過UDF來解決虛警的問題。對於這樣的告警，我們分為幾個步驟來走，跳變清除、閥值過濾、匹配真警、異常度計算、異常報警、人工確認。

寫在最後

從IoTDB 0.12、0.13的兩個版本里，我們一直在思考：隨著對資料的使用程度越來越高，IoTDB應該會有哪些新的特性隨之出現。所以我們一直在做UDF和觸發器的功能。同時，在分散式版本研發中，IoTDB也會不斷加強時間分割槽和虛擬儲存組的能力。未來，IoTDB將給大家提供越來越豐富的能力和更好的效能。