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

網路通訊頻道發表於2022-06-30

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將給大家提供越來越豐富的能力和更好的效能。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31545813/viewspace-2903547/,如需轉載,請註明出處,否則將追究法律責任。

相關文章