一種時序數據模式演化的跟蹤與查詢方法

趙 鑫 萬英格 劉英博,2

1(清華大學軟件學院 北京 100084)

2(工業大數據系統與應用北京市重點實驗室(清華大學) 北京 100084)

(zhao-x19@mails.tsinghua.edu.cn)

在物聯網與大數據廣泛應用的背景下，各類感知設備每分每秒都會產生海量的時間序列數據，存儲、查詢和統計分析這些數據的需求使時序數據庫的重要性日益凸顯.在敏捷開發等軟件工程的工業實踐中，智能設備主控軟件版本頻繁變更，其所產生的數據模式也會形成多種版本.在實際應用中，一個時序數據庫經常需要同時維護數量眾多且版本多樣的傳感器數據，這就引出了時序數據模式演化的問題.

數據模式演化(schema evolution)[1]在數據庫領域有多年的研究歷史，一般指不會導致數據丟失的模式變更過程.目前已有的數據庫對數據模式演化的功能實現各有側重，本文對歷史模式支持方式分為3類：

第1類是支持離線模式演化的數據庫，具體包括使用DeltaSQL[2]等工具直接記錄引起模式變更的語句，以及LiquiBase[3]，Rails Migrations[4]等以數據庫變更記錄的形式跟蹤模式版本演化過程.以LiquiBase為例，在根據變更記錄主動切換模式版本時，將通過自動化方式嚴格順序執行一系列的SQL腳本.在這類數據庫中，數據往往只存在單一的數據模式，且在執行腳本期間，模式演化功能也會受到影響.因此，這一類研究很難滿足工業物聯網場景中實時讀寫數據的需求.

第2類是支持在線模式演化的數據庫，如Bull-Frog[5]，Ratchet[6]等.這一類數據庫在支持模式演化的同時，不會影響數據讀寫功能，且在模式變更期間，可以通過新舊模式訪問數據.以BullFrog為例，在模式變更時實現了數據懶遷移的基礎上，還通過同步鎖機制支持并發情況下的懶遷移.在工業物聯網場景中，對歷史模式的數據進行查詢與分析是十分常見的需求，顯然這一類研究也不能滿足實際需求.

第3類是支持多模式版本管理的數據庫，例如InVerDa[7]，LESSQL[8]等.這一類數據庫可以支持應用同時訪問多個歷史版本模式下的數據，功能最為全面，也是最受關注的一類模式演化方法.這一類方法在數量較少的關系表上實現多模式版本管理方面有較多研究，而對于維護大量設備、時間序列的時序庫中的模式演化問題少有研究，對于時序數據及其模式演化的過程也缺少形式化表述.

時序數據庫的關鍵是能夠快速地讀寫和分析數據[9]，在時序數據庫的發展中，有3種不同的構建方式：第1種時序數據庫是在關系型數據庫的基礎上，對SQL語言進行時序相關的擴展來實現的，例如Vertica[10]等.第2種時序數據庫會選擇HBase[11]和Cassandra[12]等列式存儲數據庫來管理時間序列數據，如OpenTSDB[13]，KairosDB[14]等.這些方案不可避免地受到列式存儲數據庫自身問題的限制.第3種時序數據庫是自底向上全部面向時序數據搭建的，例如InfluxDB[15]，Apache IoTDB[16]等.這一類數據庫根據時序數據庫的特點作了針對性設計，查詢性能和存儲壓縮等方面的表現顯著優于第1種和第2種構建方式的時序數據庫[16].以清華大學發起的開源工業物聯網時序數據庫Apache IoTDB(以下簡稱為IoTDB)項目為例，其數據模型是從工業物聯網實踐中抽象出的樹型結構，有助于簡化工業物聯網中常見的建模需求.

隨著工業信息化的高速發展，時序數據庫維護的軟硬件設備會發生滾動升級，這對時序數據模式變更的跟蹤及控制提出了要求.以某工程機械生產商的控制器程序為例，一個于2008年上市的工程設備，當前在役數量超20 000臺，在這些設備上部署的控制器主控程序多達72個版本.管理這些設備，需要收集并無損地存儲不同版本的數據.選取其中任意一個或若干個版本的數據模式作為存放數據的標準模式，然而都會有大量設備的數據因為模式不兼容而需要進行有損轉換后才能存儲.即使采用最常見的20個版本作為標準模式進行存儲，也只能覆蓋不到90%的設備，即仍有數千臺設備數據無法在無損情況下保存.

通過人工干預或簡單的啟發式方法很難滿足時序數據采集設備在實際應用場景下不斷滾動升級的需求，因此擬引入智能化控制方法結合模式演化研究應對時間序列數據模式演化的挑戰.如何保存不同模式的時序數據，跟蹤各設備模式的演化過程，對不同設備、不同模式的數據進行查詢與分析，是該項智能化控制中的重要問題.

以上背景引出了本文進行的時序數據模式演化跟蹤與查詢方法的研究.本文工作的主要貢獻有3個方面：

1) 提出了時序數據模式特征的形式化定義，將時序數據庫的模式演化過程進行形式化表達.

2) 設計了多模式版本的存儲與查詢方案，并以非侵入方式，在IoTDB上擴展了多模式存儲與跨模式查詢功能.

3) 通過實驗驗證和評估了本系統的正確性、性能表現、可擴展性，為本系統未來擴展應用到其他時序數據庫提供了借鑒方向.

1 時序數據及其模式的形式化定義

本文中設計的時序數據模式演化跟蹤及查詢方法是在時序數據庫IoTDB基礎上實現的，因此本節將在1.1節中簡要介紹IoTDB的數據模型及架構，在1.2節與1.3節中分別提出時序數據及其模式的形式化表述.

1.1 時序數據庫IoTDB簡介

在工業物聯網背景下，時序數據的使用場景豐富.為了提高面向工業應用的數據處理能力，清華大學發起研發工業物聯網時序數據庫IoTDB，其技術架構如圖1所示.由圖1可知，在IoTDB內部，時序數據以樹型結構組織，從樹的根節點到葉子節點涉及3個基本概念：

1) 存儲組(storage group).一個存儲組下可管理多個設備，同類的設備往往存儲在同一個存儲組中.

2) 設備(device).一個工業設備實例，設備上往往部署了多個傳感器用于采集時間序列數據，同時設備也可以標注一些無關時間序列的信息即“屬性”.

3) 測點(measurement).每組測點對應一個傳感器采集的時序數據.傳感器是IoTDB中存儲的數據及路徑組織的最小單元.存儲組、設備和測點名稱組成的路徑可以唯一確定一個時間序列.

在IoTDB的查詢語言中，描述設備、傳感器和時間序列的表達式稱為路徑(path).查詢語句也支持在路徑中使用通配符“*”，例如“root.vehicle.*.status”代表分布在root.vehicle節點下、包含名為status的傳感器的所有設備.

Fig. 1 Architecture of IoTDB圖1 IoTDB架構

IoTDB的每個測點中存儲著一系列時間戳-數據對(時間戳，數據)，測點的每個時間戳都是唯一的.用戶在創建時間序列時可以定義其數據類型和編碼方式，以提高存儲效率.

IoTDB采用如圖2所示的客戶端-服務器架構，由客戶端將查詢請求發送給服務端后，由服務端將查詢請求進行解析、執行直至最后返回結果集.

Fig. 2 Client-server architecture of IoTDB圖2 IoTDB客戶端-服務器架構

Fig. 3 Query engine of IoTDB圖3 IoTDB查詢引擎

IoTDB的查詢引擎架構如圖3所示，這與第3節密切相關.查詢引擎收到原始查詢語句后，使用ANTLR 4[17]將其解析成抽象語法樹，并在ANTLR語法解析樹監聽器中構建邏輯計劃.查詢引擎對邏輯計劃進行優化，并生成物理計劃交給執行器執行，最后構造查詢結果集.

相比基于關系型、列式存儲的時序數據庫和以InfluxDB為代表的原生時序數據庫，IoTDB在高壓縮、高吞吐、高效查詢方面表現更優[18]，易于分布式部署，可對接多種開源工具，便于學習和開發測試，因此本文選擇以IoTDB為基礎展開相關研究.

1.2 時序數據的特征與形式化定義

時序數據是帶有時間戳的數據序列，其基本單元是帶有時間戳的數據點.根據時序數據實踐經驗，可以定義時序數據.

定義1.ts=(c,{(ti,vi)}),i∈|{(ti,vi)}?T×V,i∈為時間序列，其中：

2)c表示該時序數據的元數據，在時序數據庫中體現為該時間序列的路徑及該序列的屬性等；

3) {(ti,vi)}是時間戳與數據構成的序列，滿足{(ti,vi)}?T×V,i∈，其中T是所有時刻的取值范圍，V是所有數據的取值范圍.

如果把一個時間序列看作是關系型數據庫中的一張表，那么可以把c理解為表名與列名，把(ti,vi)理解為1行數據，把{ti}理解為表的主鍵，把{vi}理解為表中的1列數據.

時序數據具有時序特征，即具有時間上的先后順序關系，因此，集合T上應定義有一種全序關系，即任意2個時刻t1,t2都可以比較大小，事實上幾乎所有時序數據庫的設計都應用了這個性質.在使用滑動窗口對時間序列進行分析時，還需要時刻間隔的概念.因此可以在集合T上定義一種二元運算，±：T×T→T，因而我們同樣可以比較時刻間隔的大小關系等.一般地，時刻和時間間隔可以統稱為“時間”，在時序數據庫中一般用“Unix時間戳”表示.

計算機中的數據都有其特定的數據類型，即可以將時間序列中的度量值v展開為vi=(di,ui)，其中di是數值部分，ui是數據類型部分，即有定義2.

定義2.時間序列中的度量值vi=(di,ui),di∈D,ui∈U，即有V?D×U，其中：

1)D是時序數據庫中可以表示的所有數值的集合，在時序數據庫中一般為一個字節數組；

2)U是時序數據庫中所有數據類型的集合，在時序數據庫中一般包含bool,uint32,float32等類型.

在時間序列數據中，還有一些與時間信息不直接相關的信息，例如時間序列在數據庫中的路徑、屬性等信息，可以用c來表示，即有定義3.

定義3.時間序列中的c=(c0,c1,c2,…,cn,c*)，其中：

1)c0,c1,c2,…,cn為時序數據在數據庫中的路徑，c0一般為時序數據庫根節點“root”，cn一般為時序數據測點名稱；

2) 一般來說，時序數據的路徑也表征了測點傳感器設備在物理空間的歸屬關系，一般有ci+1∈ci，例如某省市區某站某傳感器的時序數據路徑可以表述為“root.省.市.區.站.傳感器”；

3)c*為時序數據自身的屬性信息，例如標簽、別名等，屬于與時間無關的元信息.

1.3 時間序列模式的特征與形式化定義

數據模式是一種描述數的結構的形式化表述[6]，因此時序數據的模式可以從一個簡單的時間序列來考慮.對于時間序列ts=(c,{(ti,vi)}),i∈|{(ti,vi)}?T×V,i∈，其中vi=(di,ui),di∈D,ui∈U，集合T及其運算決定了時間的定義，集合V?D×U決定了取值的范圍和單位，符號c決定了時間序列的物理含義.因此，三元組(c,T,V)決定了一個時間序列的結構和意義，是時間序列的模式.

定義4.對于時間序列ts=(c,{(ti,vi)})，其模式s有s(c,T,V).

其中，c定義了時間序列在時序數據庫中的路徑及其物理含義，T定義了時間序列的采樣頻率，V定義了時序數據數值的范圍與類型.在IoTDB中，c與V中的信息都可以被改變，但采樣頻率精確度限定到毫秒，因此本文中的模式演化跟蹤主要記錄c與V中信息的變化.

在時序數據應用中，一個工業設備上經常配備多個傳感器，在設備滾動升級的過程中，每個設備上時序數據的模式也需要進行跟蹤管理，因此也需要對單個設備產生的時序數據模式進行定義.

定義5.如果時間序列tsa=(ca,{(ta,i,va,i)})與tsb=(cb,{(tb,j,vb,j)})，滿足ca,k=cb,k,0≤k

定義6.一個時間序列組TS的模式可以定義為ds{C(n-1),m,V′,mv}，其中：

1)C(n-1)是這些同設備時間序列中元數據相同的部分；

2)m是該時間序列組下各時間序列cn及c*的并集；

3)V′是所有時間序列的數據及其類型的集合；

4)mv是各時間序列名稱與其數據及其類型的對應關系.

例如，對于某地氣象站某氣候傳感設備，可能存在溫度傳感器與濕度傳感器，那么其時間序列的元數據可以分別表示為：

因為對于k=0,1,2,3滿足ca,k=cb,k，且k=4時，ca,4=temp,cb,4=humidity即ca,4≠cb,4，所以可稱tsa與tsb屬于同一個時間序列組TS={tsa,tsb}.按照定義6，對于時間序列組TS，其數據模式ds可以表述為

這也是本文對模式版本表進行建模的理論基礎.

2 時序數據模式演化的定義與特征

2.1 時間序列模式演化的定義

時序數據演化的本質是時間序列的模式發生了變化.因此對于時間序列ts=(c,{(ti,vi)})，其模式三元組s(c,T,V)中的任一項發生變化時，即認為發生了時間序列模式變更.將時間序列模式變更發生的時刻，以及變化前后的模式作為時間序列數據模式的變更記錄，其形式化定義如定義7所示.

定義7.時間序列模式的變更記錄scn+1(t,sn,sn+1),n∈是模式發生變化的時刻t及變化前后模式sn,sn+1組成的三元組.特別地，對時間序列最初的模式取s0.

研究時間序列模式演化的過程中，經常涉及時間序列模式多個變更記錄.每一次變更前后的模式存在前驅與后繼關系，即有定義8.

定義9.時間序列模式的前驅與后繼關系具有傳遞關系，即若存在si→sj∧sj→sk,{i,j,k}?，則si與sk之間也存在前驅與后繼關系，記為si→→sk.

類似地，對于時間序列組的模式也可以定義其變更記錄及前驅后繼關系.

定義10.時間序列組的模式變更記錄SCn+1(t,ds,n,ds,n+1),n∈是時間序列組模式變更的時刻t及變更前后時間序列組模式ds,n,ds,n+1組成的三元組.

定義11.時間序列組的模式變更記錄間也存在前驅、后繼與直接前驅、直接后繼的關系.

結合定義4～11，時序數據或時間序列組的模式演化過程，可以用一系列時間序列組的模式變更記錄描述.作為形式化表述，考慮到應與具體的時序數據庫設計無關，本節中對時間序列組變更記錄的具體變更內容并不作限定，但在后續內容中會根據IoTDB的實現對本文研究的時間序列組模式變更記錄進行具體描述.圖4用本文定義的形式語言描述了一個時間序列組的模式變更的過程.

Fig. 4 Example of schema evolution on timeseries group圖4 時間序列組模式演化示例

2.2 時序數據模式演化的特征與問題

與關系型數據庫中模式演化需要解決的問題類似，時序數據模式演化帶來的問題主要集中在存儲與數據庫當前模式不同的數據(跨模式存儲)及查詢存在多個模式版本的數據(跨模式查詢).本節將對這2個問題進行建模與分析.

2.2.1 跨模式存儲

本文研究的問題模型中，需要區分時序數據庫與工業設備2個概念，前者是用于存儲數據的虛擬概念，后者是產生數據的物理概念，所以需要考慮數據庫模式變更與設備產生數據的次序關系．在考慮數據庫模式變更與設備模式變更時間關系的條件下，數據模式演化的各類情況，可以簡化到從一個“時間戳-數據對”的角度進行討論.一個時間戳-數據對(t,v)，稱其在傳感器中產生的時刻為tval(valid time)，一般地有t=tval.這個時間戳-數據對被存儲到時序數據庫中的時刻為ttra(transaction time)，其在數據庫中被外部應用查詢或更新的時刻為tque(query time).同時，記錄時序數據庫中對應時間序列組發生模式變更的時刻為tevo(evolution time).

Fig. 5 Relation between data lifetime and schema evolution圖5 模式演化時間關系

對于一個時間戳-數據對，其讀寫過程與數據庫模式變更的關系可以用時段邏輯[19]建模，并用圖5來描述.圖5中標記有tval,ttra,tque的橫線描述了數據產生、記錄及查詢更改的時間區間，即滿足tval

情況③與情況④中，數據庫模式變更發生在數據完成存儲之后，即ttra

情況①與②中，數據產生模式變更時刻tevo在數據存儲到數據庫時刻ttra之前，即tevo

Fig. 6 Relation between schema evolution of database and device and timeseries data圖6 數據庫和設備的模式演化與時序數據的關系

情況①中，因為滿足tevo

情況②③④中，因為存在tval

2.2.2 跨模式查詢

跨模式版本查詢的應用需求，來自工業物聯網中滾動升級導致的同類設備模式不統一、設備與數據庫模式不統一等情況時，對不同設備、不同模式的各個時間段進行統一查詢與分析要求.從功能上來說，跨模式查詢系統的內容主要包括3種情形：

1) 對同一設備生命周期中多個模式版本的數據進行統一查詢，如圖7所示；

2) 對指定時間范圍內多個設備的歷史模式數據進行同時查詢，如圖8所示；

3) 以歷史或當前的模式版本定義查看指定時間范圍的數據，如圖9所示.

Fig. 7 Crossing schema version query on single device圖7 同一設備跨模式版本查詢

Fig. 8 Designated time interval crossing schema version query on multiple device圖8 多設備指定時間范圍跨模式版本查詢

Fig. 9 Crossing schema version query on designated result schema and time interval圖9 指定結果模式版本與查詢時間范圍的跨模式版本查詢

在滿足3種情形要求的同時，本系統也兼容IoTDB原生各類查詢命令，并擴展支持部分語法，如統計設備下的時間序列計數等，保證了本系統功能的一致性.

本文用關系代數語言對跨模式版本查詢進行了形式化描述.首先定義在時序數據庫中進行跨模式版本查詢的若干運算符號：

2) 查詢語句中SELECT關鍵字可進行投影運算∏；

3) 查詢語句中WHERE關鍵字可進行選擇運算σ；

4) 查詢語句中聚類關鍵字如GROUP BY，SUM，AVG等聚合運算G.

對于時間序列組TS={tsi}，可以定義某個設備為Dts1ts2…tsn，用Di表示第i個設備，用Di,j表示第i個設備的第j個版本.因此對于一個原生的跨設備查詢可以表述為Q=G(∏(σ(D1D2…Dn)))，對于單設備查詢可以取n=1，對所有相關設備可取D={D1,D2,…,Dn}.可以用符號簡化表述為O(·)=G(∏(σ(·)))，此時一個原生的多設備查詢可以表述為Q=Q(D,O).

對于跨模式版本查詢，用戶還需要指定查詢模式版本范圍R、結果集投影模式S，因此一個跨模式版本查詢可以記為Q=Q(D,O,R,S).實際應用中可以在模式版本表中通過R確定D，例如在圖8中可以得出D={D1,0,D1,1,D1,2,D2,0,D2,1}.特別地，如果用戶沒有指定結果集投影模式S，本文系統中將默認取所有模式中各字段的并集S0作為結果集投影模式.

在實際執行跨模式版本查詢時，系統會將Q=Q(D,O,R,S)分解為Q={q1,0,q1,1,…,q1,j,…,qm,n}對每個設備、每個模式版本的查詢，其中qi,j是對第i個設備第j個模式版本的查詢的投影結果，即有qi,j=∏S(σ(Di,j)).在跨模式版本查詢最后，將這些子查詢進行合并得到結果，即有Q=∪Di,j∈DO(Di,j).

3 模式演化系統設計與實現

為了擴展時序數據庫對模式演化的支持能力，驗證第1節中相關形式化定義及討論的正確性，本文在IoTDB基礎上實現了一套模式跟蹤系統，并在不同場景下設計了跨模式版本查詢的支持方案.本節將依次介紹模式跟蹤系統及跨模式版本查詢的設計與實現.

3.1 模式跟蹤系統設計與架構

在時序數據庫IoTDB中，時間序列模式的演化主要在存儲結構中的設備層進行研究.一個設備上可配多個傳感器測點，這些測點的數據一般在數據庫中存儲為一個時間序列組.參照關系數據庫中模式演化的基本類型[20]，時序數據模式演化中的基本類型主要包括設備的創建和刪除，設備中時間序列的創建和刪除，設備或時間序列的重命名，時間序列定義與別名、標簽、屬性等元信息的修改等.由于IoTDB自身不支持設備、時間序列的重命名和時間序列的數據類型、編碼方式和壓縮方式等屬性的修改，模式跟蹤系統要重點設計實現3個模塊.

1) 監聽時序數據模式變更操作，包括：①設備的創建與刪除；②時間序列的創建與刪除；③時間序列元信息的修改；

2) 自動記錄所監聽操作產生的模式版本信息；

3) 追溯歷史模式版本、切換指定模式版本等版本控制相關功能.

Fig. 10 Architecture of schema tracing modules圖10 模式跟蹤模塊架構

圖10中，監聽功能通過解析IoTDB查詢語句實現.版本自動記錄可在IoTDB中存儲，也可以在外部文件、數據庫中存儲.追溯歷史模式版本、切換指定模式版本等功能涉及模式與數據的映射關系，需要對數據庫存儲結構中的邏輯模式或物理模式進行修改.本文將邏輯模式和物理模式進行分離，邏輯模式是用戶直觀接觸的數據模式，也是模式演化與版本控制的呈現結果；物理模式是數據庫服務端具體實現的存儲結構，本文中是IoTDB實際存儲文件結構的模式.在需要將本系統擴展到其他時序數據庫上時，與邏輯模式的定義相似，主要修改與物理模式相關的模塊即可適配應用.

本文系統采用非侵入式設計，以IoTDB命令行接口客戶端為基礎進行擴展，將查詢語句監聽與解析的過程、用戶可見的邏輯模式在IoTDB數據服務系統以外實現，系統結構如圖10所示.用戶在使用本系統時的體驗與原生IoTDB客戶端接近，易于上手且不影響IoTDB原生SQL語法與查詢、處理數據功能的使用.

模式版本表記錄了物理模式和邏輯模式之間的映射，以及模式的前驅后繼關系.該表可以描述模式演化的過程，記錄了版本號、變更內容等追溯歷史模式版本、切換指定模式版本所必須的信息，以及邏輯模式與物理模式的對應關系、當前版本與歷史模式數據的聯系等.模式版本表的具體定義如表1所示，表1中的每行數據對應一個設備(時間序列組)的一個模式版本.

對照本文對時間序列組模式的定義，即ds{C(n-1),m,V′,mv}，表1中存儲的virtual_device與physical_path實際存儲了C(n-1)中的信息，schema_delta與schema_snapshot存儲了m,V′,mv的信息，timestamp,version_id,parent_version中存儲的信息可以便于代碼檢索實現.

歷史模式數據包含了各設備各版本模式下的數據，包括因為模式變更而刪除的數據(如刪除某時間序列).這些數據與當前版本模式的數據分別存放在不同存儲組，確保命名空間不沖突，同時支持歷史版本模式數據的恢復.

Table 1 Definition of Schema Version表1 模式版本表定義

本文系統將模式版本表和歷史模式數據(下稱“系統數據”)與一般的時序數據(下稱“用戶數據”)存放在同一個IoTDB中，在具體實現上對系統數據加以屏蔽，使用戶無法通過IoTDB原生語句直接訪問系統數據，避免了系統數據與用戶數據之間的沖突.

3.2 模式跟蹤系統實現

3.2.1 系統實現的關鍵問題

本文所設計系統的目標是自動記錄、跟蹤時間序列模式演化，同時存儲各版本模式的數據.在實現系統的過程中，有3個關鍵問題需要進行說明：

1) 非侵入式模式變更命令監聽與解析.除在數據庫服務端進行的解析語句過程之外，在客戶端額外對查詢語句進行了一次解析，得到抽象語法樹，獲取各個語義節點.相比侵入式地在數據庫服務端進行解析或在客戶端簡單地進行關鍵詞過濾，本文的方案雖然需要額外的語法解析時間開銷，但正確性高且維護成本低，擴展性也更強.在遇到路徑中含有通配符時，本文方案需要額外執行查詢來確定對應的時間序列和設備，但大多數時候不用額外查詢即可確定模式變更的范圍.

2) 用戶數據虛擬映射，提高系統效率.進行模式變更時，有3個步驟：①翻譯用戶命令中的邏輯模式至物理模式；②在模式版本表中增加新記錄；③將當前用戶數據移入歷史模式數據.當數據量較大時，步驟③的運行將成為系統性能的瓶頸，因此本系統在所有時序數據寫入時就存入歷史模式數據，用戶數據中僅保留相應模式定義，如圖11所示.這種策略帶來的額外復雜度是對操作數據點的語句也要進行改寫，但與移動某模式版本下所有時序數據相比，該方案運行開銷更小.

3) 將邏輯設備各模式版本數據分別存儲到系統數據的物理設備中.歷史模式的定義存儲在模式版本表的模式快照列，結合模式變更內容列中的語句，用戶可以將指定設備手動恢復到歷史模式定義中.對于每個邏輯設備，其各模式版本的數據分別存儲在不同的物理設備數據中，跨模式版本查詢時從對應的物理設備中分別取出結果，再進行結果集合并.該方案使多模式版本查詢的過程較為復雜，但可以完整地保留歷史數據，是一個初步可行的解決方案，實際結構如圖12所示.

Fig. 11 Reflection from user StorageGroup to system StorageGroup圖11 用戶存儲組與系統存儲組映射關系

Fig. 12 Relationship of storage between logical device and physical device圖12 邏輯設備與物理設備的存儲關系

除上述3個關鍵問題以外，本文系統設計實現中還解決了屏蔽系統數、版本號命名空間定義等問題.

3.2.2 系統實現功能描述

本文系統的模式跟蹤功能是在IoTDB原生客戶端基礎上擴展實現的，即在客戶端增加了一套語法解析代碼，并在解析樹中增加了模式跟蹤相關的邏輯，以達到支持模式演化且向用戶屏蔽系統數據的目的.為了使用戶可以使用查看模式歷史版本信息、修改歷史版本模式中的數據等功能，本系統在語法解析樹中擴展了一套語法規則，具體規則內容及含義如附錄A表A1所示.

3.3 跨模式版本查詢設計與架構

跨模式版本查詢架構如圖13所示.跨模式版本查詢是在模式跟蹤的基礎上擴展實現的.相比于模式跟蹤系統，跨模式查詢功能只需訪問而不需要對已有數據進行修改，但對查詢結果需要合并投影，這些功能實際在客戶端-服務器通信的雙向過程中分別加以實現.

Fig. 13 Architecture of crossing schema version query圖13 跨模式版本查詢架構

3.4 跨模式版本查詢系統實現

3.4.1 系統實現的關鍵問題

實現跨模式版本查詢的關鍵是對數據查詢的拆分與合并，并對IoTDB中其他相關查詢的功能進行兼容支持.在實現的過程中，有3個關鍵問題需要說明：

1) 自動推斷并缺省填充時間序列在某些模式版本不存在的數據點.對于某些時間序列，可能在某些模式版本中被刪除或尚未創建，當這些時間序列相關模式版本被查詢時，本文系統將進行自動推斷并缺省填充.具體在返回包含該時間序列的結果集中，對不存在的時間戳-數據對補充空值NULL.出于效率考慮，對于在任何模式版本中都不存在的時間序列不予展示.

2) 限制不同模式版本間數據類型的轉換.即對于某些時間序列，在不同模式版本中可能有不同的數據類型，在這些時間序列相關模式版本被查詢時，本文系統將不同類型數據轉換為本文類型數據.這一方案會對部分數據帶來精度損失，但針對設有不同數據類型的底層時序數據庫有更高的兼容性.同時，當結果集需從眾多不同模式版本的子結果集合并時，這一限制也可以提高合并效率.

3) 提前解析通配符路徑加速跨模式版本語法解析.對于存在通配符的路徑，本系統無法直接根據模式版本表進行改寫，需要在改寫前向時序數據庫讀取通配符匹配的完整邏輯路徑，即在用戶數據中執行一次通配路徑的查詢命令以確定符合條件的所有完整邏輯路徑，再將其應用到改寫過程中，以及早確定返回結果集的定義，方便構建結果集.

3.4.2 系統實現功能描述

跨模式版本查詢的功能主要基于SELECT語句進行擴展實現，以支持對多設備或單設備進行跨模式版本的查詢功能.擴展后的語法及功能說明見附錄A表A2.

此外，本系統對IoTDB中部分統計數據查詢語句也進行了相應的跨版本語法擴充支持，附錄A表A3對其語法代表的原生功能和本系統擴充后的功能進行了簡要介紹.

4 系統驗證與分析

本節將通過測試用例對本文所設計的系統進行正確性驗證，包括模式演化跟蹤功能及跨模式版本查詢功能等.時序數據模式的生命周期，可以分為創建、更新、查詢與刪除4個階段.其中，更新查詢又包括對數據模式自身的更新查詢以及對數據模式下數據點的更新查詢.針對時序數據模式的生命周期，可以設計一組較為完備的測試用例，具體來說包括6方面的內容：

1) 查看指定設備的模式演化歷史及其元信息；

2) 跟蹤并記錄創建、更新、刪除時間序列；

3) 切換設備模式到指定的歷史版本上，并同步切換對應設備的時序數據；

4) 創建、刪除某一模式下邏輯設備的數據點時，物理設備數據被相應地修改；

5) 在指定范圍的模式版本上查詢時序數據，系統能合并查詢結果；

6) 對IoTDB歷史上的設備及時間序列元信息進行查詢和統計，并按模式版本展示.

需要說明的是，本文中的驗證部分僅對功能的正確性及實現效率進行了測試與分析，并未對設計及實現的先進性進行分析，這是因為截至本文撰寫修訂期間，其他時間序列數據庫尚未發布模式演化相關的功能.而對于InVerDa[7]，LESSQL[8]等數據庫雖然實現了多模式版本的管理，但其設計本身基于關系型數據庫，對于標簽型或樹型結構模式的時序庫并不支持，因此本文并未進行對比實驗.

本節測試的硬件環境使用Intel?CoreTMi7-8565U處理器，內存規格為16 GB 2133 MHz，磁盤規格為WDC PC SN720 SDAQNTW-512G-1001.測試在Windows 10 Pro 64系統中開展，使用JDK 8u271開發測試，使用語法解析工具ANTLR 4.9.1，底層數據庫為IoTDB 0.11.0，系統所改造的客戶端也基于該版本擴展開發.

4.1 測試用例

附錄B中表B1和圖B1以創建時間序列的過程為例，檢查了設備模式定義發生改變時，本系統的模式演化跟蹤有關功能運行情況.

修改時間序列元信息與刪除時間序列時的模式版本控制功能，其測試步驟、相應的版本控制功能與創建時間序列類似，測試用例一致通過，受篇幅所限不在本文中詳細描述相應的測試用例和測試結果.

附錄B中表B2和圖B2中測試了檢出設備模式到指定版本的功能，檢查了新模式版本被正確創建和記錄，且與指定版本具有一致的模式定義，測試過程也驗證了查看模式版本命令能正常運行并返回正確的結果.

附錄B中表B3和圖B3中以刪除歷史版本中的時間序列數據點為例，檢查了指定版本數據記錄能準確地變更，且當前模式版本中的數據不受影響.另外，本系統進行了向歷史模式版本新增數據點的功能測試，其測試步驟、預期結果與刪除歷史模式版本中的數據點相似，測試用例通過，因篇幅所限本文不再贅述.

附錄B中表B4和圖B4中展示了測試跨模式版本查詢數據的結果，測試顯示各個模式版本中的數據均被正確地篩選，且正確地被合并展示.

附錄B中表B5和圖B5以模式演化歷史上時間序列的計數為例，測試了本系統在IoTDB上為歷史模式擴展的元信息查詢功能正常運行.歷史設備計數、歷史子節點查看等擴展功能與歷史時間序列計數測試邏輯類似，本文不再贅述.

4.2 性能分析

4.2.1 模式跟蹤系統性能分析

本文提及的系統基于非侵入式理念在IoTDB上擴展實現，因此本節中僅對IoTDB原生系統以外部分的開銷進行分析.具體來說，在創建時間序列時，本文系統根據所創建時間序列的新模式版本在物理存儲組上創建了一個模式定義一致的新設備，時間、空間上的額外開銷均為O(k)倍，其中k為該設備具有的傳感器數量.在刪除時間序列時，本文系統時間上的額外開銷為O(k)倍；空間上，本文系統為了實現歷史模式版本查詢，實際并未釋放存儲空間.修改時間序列元信息時，本文系統時間、空間上的額外開銷均為O(k)倍.

在真實的工業物聯網應用場景中，傳感器實時地產生大量的數據點，數據點插入是非常高頻的操作，這也可能是整個系統的性能熱點.對于向當前模式版本新增或刪除數據點的操作，本文還通過哈希表結構維護每一個設備與其當前版本的對應關系，此時本系統中新增或寫入數據點的時間開銷與IoTDB原生實現的差異可控制在O(1)，對內存的額外需求是O(n)，其中n是設備的數量.

4.2.2 跨模式版本查詢性能分析

本文實現的跨模式查詢功能，在查詢并不跨越模式版本的情況下，實際與IoTDB原生查詢在時間復雜度上的差異為O(1).在跨版本的情況下，本文系統需要對多個版本模式的查詢結果進行合并，時間復雜度與IoTDB原生查詢的差異為O(v)，其中v是查詢結果涉及模式的版本數量.為了最大限度保留原始數據的信息，本文系統將舊模式的數據在數據庫中直接保存，而并不進行格式轉換，對數據存儲空間的需求增加為O(v)；作為對比，在最大限度保留原始數據精度的前提下，如果將數據轉換到不同版本模式上進行保存，數據查詢的額外時間消耗可降低到O(1)，而對數據存儲空間的要求將增加O(mv)，m是模式的版本數量.因此，本文的實現方案在時空開銷的均衡上是較為合理的.

5 總結與展望

本文對時序數據庫出現的背景和發展過程進行了簡要的回顧，對不同類型模式演化跟蹤與跨模式查詢的方法進行了調研與綜述，對時序數據庫Apache IoTDB的架構、特點等進行了簡要介紹.在此基礎上，本文對時間序列及其模式的特點進行了分析，提出了形式化的定義.針對工業物聯網和相關時序數據庫中使用的“設備”概念定義了時間序列組及其模式.在此基礎上本文對時序數據模式演化的特點進行了分析，提出了形式化的定義，重點分析了時序數據的時序特點導致其模式演化與跨版本查詢中存在的主要積累情況.

為了驗證模式管理方法的可行性，本文基于IoTDB設計并實現了一套基于時間序列組的模式演化跟蹤、模式版本控制與跨模式查詢方案，分別對模式演化跟蹤方案、跨模式查詢方案進行了詳細的描述，對實現的方案進行了完善的功能測試，并對性能進行了評估.測試與評估表明，本文實現的系統能夠有效地拓展IoTDB的功能，為用戶提供了時序數據模式演化跟蹤與跨模式查詢的支持.

對于時序數據上的模式演化問題，未來的工作可在5個方面展開：

1) 完善時序數據上對模式演化形式化表述，在本文對時間序列、時間序列組形式化描述的基礎上，擴展到對海量類似模式的時間序列組間的關系進行描述.

2) 增強模式演化跟蹤功能，應對在工業物聯網中工業設備經常發生更換、升級的情況.這些情況下，理論上可以根據數據與模式的關系，推斷設備是否發送損壞或替換.

3) 提升跨模式版本查詢效率.當前系統的實現中，始終需要將查詢拆解為多個子查詢執行并合并，如設備及模式版本過多，將極大影響系統效率.

4) 支持更多時間序列數據庫命令語句，目前系統中主要對時間序列模式變更及查詢修改命令進行了擴展，但在權限管理、數據存活時間等方面仍有結合擴展的空間.

5) 在更多時間序列數據庫中適配模式演化功能.本系統設計時充分考慮了與底層數據庫的解耦問題，可以在不同時序數據庫中擴展適配模式演化功能，不斷驗證與完善相關形式化表述與方案設計.

作者貢獻聲明：趙鑫負責論文的撰寫及研究框架設計；萬英格負責系統實驗及測試；劉英博負責論文的研究方向理論及論文撰寫指導.