一種面向工業互聯網的云存儲方法

孟祥曦， 張凌, 郭皓明， 郭黎敏， 夏乾臣， 呂江花， 馬世龍

(1. 北京航空航天大學 計算機學院, 北京 100083； 2. 中國地震應急搜救中心, 北京 100049；3. 中國科學院軟件研究所, 北京 100190)

信息化是工業發展的重要階段，信息化的出現不但大大增強了工業生產活動中數據與信息的處理能力。同時，還深刻地影響了生產的管理與組織模式。隨著工業信息化發展不斷深入，信息系統與數據資源逐漸成為重要的生產要素，在管理、組織、決策等活動中發揮越來越重要的作用。在工業信息化發展的初期，信息化的目的在于解決生產、生活活動中的確定性問題(例如：質量控制、過程管理、數據采集和狀態監控等)。因此，信息系統構建的數據模型具有確定性的結構定義與語義表達。在這一階段，以關系數據庫為代表的數據管理系統發揮重要作用。

隨著信息技術與制造業的不斷融合，工業互聯網[1-4]成為最受關注的發展熱點之一。工業互聯網將感知設備、計算機網絡和云平臺等現有的物聯網技術融入進工業生產的各個環節，用以解決工業生產流程參數獲取問題，從而實現對工業生產的數字化、精細化與智能化管理[5-8]。

與傳統的工業信息化系統相比，工業互聯網進一步強調解決非確定性問題的能力(例如：對象狀態評估、風險預測、價值判斷等)。工業互聯網應用場景具有以下特點：

1) 云端服務化。互聯網的成熟改變了工業軟件的傳統架構。云端服務成為工業軟件的主要架構模式。在這一模式中，工業軟件脫離原有的局域環境部署的方式，將終端的功能弱化，形成較為單一數據采集與結果呈現工具。在云端，實現終端數據的處理、存儲、查詢與分析等功能。通過網絡實現云端-終端之間的數據交換。由于業務承載量的膨脹，云端需要具有高效的數據讀寫機制。一方面保證平臺并發性能。另一方面，避免云端的數據處理負擔，簡化數據的各種格式清洗與預處理等操作。

2) 數據泛化。結合大數據，工業互聯網的發展改變了生產活動的商業與服務模式。這一趨勢導致傳統的數據生產-消費關系發生顛覆性的變化。云平臺結合大數據手段，在對象全壽命周期的基礎上，從多個維度開展知識挖掘圍繞對象行為導向、價值判斷、決策支撐等開展分析與支撐。這就需數據管理系統能夠支撐上層復雜挖掘分析的多值查詢、布爾查詢等復雜操作。

從數據的角度出發，工業互聯網中數據具有一定的實時性。同時，與傳統的信息系統中數據相比，其具有以下特點：

1) 數據價值具有時效性。在云平臺日常數據增量過程中，為了支撐對象分析、知識提取以及事件回溯等需要實現全壽命周期的數據存儲管理。另一方面，在大多數應用場景中，數據自身的信息承載價值隨著時間變化。整體而言，在數據產生的初期，其信息承載價值較高，隨著時間的變化，這一價值逐漸降低。從數據存儲管理的角度出發，應圍繞時間-價值的關系建立數據組織機制，保證數據整體有效存儲管理，避免大量價值不均數據無差別管理導致的效率降低。

2) 數據不是強事務性。在云平臺形成生態圈中，所產生的大量數據用于記錄對象的操作行為、客觀事物的監測記錄、對象狀態變更等。這一類數據以時間序列的方式增量，在數據生產-消費過程中，不存在復雜、頻繁的變更。同時，也不具備回滾等強事務性處理的需求。因此，在數據存儲管理過程中，數據庫系統的內部存儲管理模型較為簡單，無需復雜的鎖等控制機制。

在工業互聯網環境中，信息系統的架構、組織與應用模式發生巨大變化。這一變化導致云平臺在非結構化數據統一存儲管理、高性能檢索查詢等方面提出較高要求。同時，與傳統的應用系統相比，數據在價值分布、一致性、事務性等方面管理需求不同。這些因素疊加導致傳統的數據庫系統面臨一定的局限性。工業互聯網需要解決以下幾個核心問題：

1) 在工業互聯網環境中，對于各種不同的工業傳感器采集的數據，如何實現異構數據的統一存儲管理?

2) 在問題1)的場景中，如何圍繞非結構化數據建立有效的基本讀寫控制機制，保證存儲空間的利用效率?

3) 在問題1)和2)的場景中，如何圍繞數據建立有效的索引機制，滿足海量數據中多值查詢、布爾查詢等復雜查詢操作的效率?

針對上述問題，本文提出了一種面向工業互聯網的云存儲方法——StoreCDB。StoreCDB采用并行架構，在多點協同的基礎上實現多源、異構的JSON(JavaScript Object Notation)數據統一存儲管理。在這一架構中，首先根據業務建立統一表達模型，來自不同數據源的異構JSON數據與該模型進行結構映射，形成統一表達映射索引，利用索引實現異構數據的統一檢索。該索引具有查詢執行效率受數據集規模影響較小的特點，且支持多維與布爾查詢。原始數據記錄以SN(Share-Nothing)的原則分布存儲在底層節點的分頁中，避免大量格式清洗以及后處理的負載，滿足工業互聯網的要求。

本文首先對數據管理方面的相關工作進行了調研；其次闡述了StoreCDB的系統架構，并分別介紹了StoreCDB的數據存儲模型和數據寫入操作方法及如何利用這一架構實現海量、異構數據的多值查詢與布爾查詢；最后討論了系統的實現與實驗結果。

1 相關工作

在海量異構數據存儲與查詢處理方面，目前主要有2種方法：典型的數據集中式管理方法和采用云數據管理及其相關技術的大數據管理。

1.1 數據集中式管理方法

在集中式數據管理系統中，由數據中心對數據進行統一的存儲管理。感知層接收采樣數據，首先將其按照一定的規則轉換成為標準格式并上傳至數據中心，然后再利用數據中心強大的存儲與計算能力直接完成查詢處理。

典型的數據集中式管理方法有關系數據庫、并行數據庫和數據庫集群。并行數據庫通過將多個關系數據庫組織成數據庫集群來支持海量結構化數據的處理，但這種方法在處理關鍵字查詢時的性能要遠低于“鍵-值”(K-V)數據庫，無法快速地檢索到所需要的數據。而且由于采用了嚴格的分布式事務處理機制[9]，在采樣數據頻繁上傳和更新的情況下，數據處理的效率十分低下[10]。所以傳統的并行數據庫技術主要針對通用的數據類型，尚不能有效地支持海量異構數據的并行存儲與查詢處理。

另一方面，由于關系數據庫系統的出發點是追求高度的數據一致性和容錯性，根據CAP(Consistency, Availability, tolerance to network Partitions)理論[11-13]，在分布式系統中，一致性、可用性和分區容錯性三者不可兼得，因而并行關系數據庫無法獲得較強的擴展性和良好的系統可用性。

1.2 云數據管理及其相關技術

云計算是最近幾年新興的一個技術領域，其核心特點是通過一種協同機制，動態管理幾萬臺、幾十萬臺甚至上百萬臺計算機資源所具有的總處理能力，并按需分配給全球用戶，使它們可以在此之上構建穩定而快速的存儲以及其他IT服務[14]，因此云計算為海量數據處理提供了一種可能。大數據存儲的形式包括分布式的文件系統、分布式的K-V對存儲以及分布式數據庫存儲。當前的研究也集中在這3個方面，并依據應用的需求進行相關的優化。

在分布式文件系統研究方面，傳統的分布式文件系統——NFS應用最為廣泛[15]。為了應對搜索引擎數據，谷歌公布了其能夠用于存儲網頁數據的分布式文件系統技術——GFS[16]。開源社區據此開發了適合部署在廉價機器上的Hadoop分布式文件系統——HDFS[17]。微軟開發的Cosmos[18]支撐著其搜索、廣告等業務。Facebook推出了專門針對海量小文件的文件系統Haystack[19]，以降低對磁盤尋道速度的要求。K-V對存儲也是一大類重要的存儲系統。亞馬遜提出的Dynamo以K-V為模式，是一個真正意義上的去中心化的完全分布式存儲系統，具有高可靠性、高可用性且具有良好的容錯機制[20]。由于模型的簡單性，K-V對存儲在應用模型不是很復雜的情況下能夠獲得更好的性能。Bigtable是谷歌開發的基于GFS和Chubby的非關系數據庫，是一個稀疏的、分布式的、持久化存儲的多維度排序映射表[21]。為克服其缺乏一致性支持的缺點，谷歌將其改進為Megastore系統[22]，但是改進后的系統性能不是很高。隨后谷歌進一步開發了Spanner系統，能夠進一步加強一致性，將數據分布到了全球的規模，性能有了一定提高[23]。Spanner是第1個可以實現全球規模擴展并且支持外部一致事務的數據庫。

然而，目前的絕大多數云數據存儲系統及Map/Reduce主要面向關鍵詞處理及靜態的海量數據，在面向數據的多維邏輯、數值邏輯時，受到諸多的局限與制約，并不適用于復雜的大規模異構數據的存儲與分析處理。例如MongoDB雖然廣泛應用于云計算數據存儲管理中，但是其索引采用B+樹機制，面對多維度數據查詢時，索引規模快速擴張，進而影響海量數據查詢效率。

通過上述分析可以看出，工業互聯網數據的存儲技術目前還相當的不成熟。為了解決上述問題，本文針對工業互聯網數據存儲管理的核心問題進行研究，提出了面向工業互聯網數據管理的存儲管理方法及系統框架。

2 StoreCDB系統架構

本節將描述StoreCDB的系統架構與工作機理，StoreCDB的系統結構如圖1所示。

如圖1所示，StoreCDB是以并行架構為基礎組成的數據存儲管理系統，由一個Master節點和一組Worker節點構成。Master節點主要負責統一表達建模與異構數據映射、數據分發以及全局分頁存儲映射管理等；Worker節點實現原始數據記錄在本地存儲、索引維護以及查詢執行等。整個架構由資源協同層、網絡連接層和節點存儲層構成的。

資源協同層利用抽象表達模型對采樣數據進行統一的表達。通過模型實現數據的結構語義映射與互操作，并對多源異構大數據存儲與管理過程進行統一表達，其中數據模型和映射關系的定義將在數據模型中詳細介紹。在這一基礎上，根據統一表達模型定義的主鍵取值實現定向分發，同時維護全局的分頁存儲映射信息。

網絡連接層在Master與Worker節點之間建立網絡連接。同時，在這一網絡連接內部建立通道資源，為不同任務分配通信資源并維護會話狀態。

圖1 StoreCDB的系統結構Fig.1 System structure of StoreCDB

節點存儲層由Worker節點構成。Worker節點在分頁的基礎上，實現原始數據的本地存儲。同時，在統一表達模型的基礎上對原始JSON數據記錄的結構進行映射并提取屬性取值，維護本地索引。通過本地的SQL(Structured Query Language)引擎提供檢索支持。

StoreCDB在上述存儲管理的基礎上，發揮并行架構優勢，面向工業互聯網中的上層應用提供高性能K-V、多值以及布爾查詢操作支撐。

3 StoreCDB數據存儲模型

本節將討論數據存儲模型，并重點從數據模型和存儲結構2 個方面對StoreCDB的存儲模型進行描述。

3.1 StoreCDB數據模型

在StoreCDB中，異構采樣數據需要進行統一的數據模型表示。下面將從原始采樣數據以及屬性映射關系對StoreCDB的數據模型進行描述。

定義1數據記錄sensorData是由數據標簽和數據內容構成，可表示為

sensorData=(sName,sTagName,sData,sTime)

其中：sName表示傳感器名稱；sTagName表示傳感器采樣數據的類型標簽；sData表示該標簽的采樣值；sTime表示采樣時間。

表1給出了在高速列車監控系統中各種傳感器采樣值的示例。

定義2采樣數據序列srcData是由同一監控對象的所有傳感器的采樣值按照時間序列組織而成的，可表示為

其中：sTimej表示第j個采樣時間；sensorDataij表示第j個采樣時間下第i個傳感器采樣值。

以表1為例，與其對應的采樣數據序列為srcData = (((s08, 運行速度, 215,t1), (s401, 轉向架軸溫, 83,t1)),t1), (((s10, 行駛速度, 216,t2), (s401, 轉向架軸溫, 85,t2))，t2)。

在原始采樣數據中，由于數據的多源異構性，同一種傳感器類型的表述可能千差萬別。例如在表1中，傳感器類型同樣是行駛速度，但s08的描述是運行速度，而s10的描述是行駛速度。為了統一管理，在StoreCDB中有一個屬性映射表，即

表1 傳感器采樣值的示例Table 1 Examples of sensor sample values

f: sTagName → tagName

其中：sTagName表示原始采樣數據中傳感器類型標簽；tagName是StoreCDB中與sTagName對應的統一表示的屬性名稱。一個tagName可以對應多個sTagName，通過屬性映射表，StoreCDB可以為不同標準的采樣數據類型提供統一的表示。

在StoreCDB中，為了對異構數據進行統一表示，在主節點接收采樣數據之前，需要將采樣數據序列轉換為統一的數據格式。為了更好地描述數據轉換格式，本文先給出了如下定義：

data=(content,sTime)

定義4給定原始數據的數據內容content，其中的采樣屬性集合propertySet可表示為

其中：tagNamei表示從content中提取的第i個傳感器類型；posi表示該類型在content中對應的位置。

通過上述定義，在StoreCDB中可以將采樣數據轉換成為統一的數據格式，如定義5所示。

定義5統一數據格式D由三元組構成，可表示為

D=(data,propertySet,timeStamp)

其中：timeStamp表示數據接收時間。

以表1為例，假設ts1時刻接收到t1時刻的采樣數據，統一數據格式D1= ((((運行速度, 215), (轉向架軸溫, 83)),t1),((速度, 1), (軸溫, 2)),ts1)，其中data項直接保存了原始采樣數據內容，propertySet中的“速度”則是data中的“運行速度”在StoreCDB中的屬性映射，同樣“軸溫”是“轉向架軸溫”的屬性映射，ts1則是數據接收時間。

3.2 StoreCDB數據存儲結構

在StoreCDB中，存儲管理層采用主從結構進行分布式管理，由一個主節點(Master)和多個從節點(Worker)構成，其中主節點在統一表達模型的基礎上負責增量數據分發、全局存儲分頁映射維護、高性能數據查詢任務調度，從節點存儲實際的采樣數據、維護本地索引、執行查詢任務。StoreCDB的存儲管理結構如圖2所示。

圖2 StoreCDB的存儲管理結構Fig.2 Storage management structure of StoreCDB

如3.1節所述，多源異構采樣數據轉換成統一的數據格式之后封裝為數據D，主節點接收到數據D之后，首先根據D中的定義為主鍵的屬性取值，映射到對應的分頁存儲空間，再根據數據劃分方式找到對應的存儲頁，最后主節點將數據D發送給相應的從節點。

從節點接收到數據之后，首先將數據添加到對應的存儲頁，然后更新相應的頁索引，再依據屬性集propertySet中的屬性值更新屬性索引。

頁索引記錄了數據與存儲位置之間的映射關系，實現了快速檢索數據的一級索引，定義如下：

定義6頁索引mapIdx可表示為

其中：rowIdi表示第i個數據的行號；idxi表示第i個數據對應的存儲位置指針。

屬性索引記錄了屬性集propertySet中各屬性值與頁索引mapIdx之間的映射關系，實現了快速檢索數據的二級索引，定義見定義7。

定義7屬性索引comIdx可表示為

其中：pTagMapi為第i個屬性的值域分布的映射向量集合，形式如下：

其中：tagName表示屬性的標識；valueArrayi表示該屬性第i個屬性值的索引映射集合，可表示為

其中：pValue表示一個屬性值。rowIdi為第i個包含該屬性值的數據行號，與頁索引中的行號對應。

依據不同的劃分方式，采樣數據存放在一系列存儲頁中，記為dataPage。每個存儲頁對應一個從節點，而一個從節點可以包含多個存儲頁，定義如下：

定義8存儲頁dataPage表示為

為了支持多源異構數據，StoreCDB依據不同的應用場景分為若干個不同的源數據集，并為每一類源數據集定義了一個存儲倉庫，記為dataStore，如定義9所示。

定義9分頁存儲空間dataStore可表示為

其中：storeID表示分頁的編號；dataPagei表示劃分的第i個存儲頁。

3.3 StoreCDB 中的索引結構

StoreCDB的Worker節點采用兩級索引結構：頁索引和屬性索引。其結構如圖3所示。

頁索引采用行號(rowId)和存儲位置指針(idx)的方式記錄了每一條原始數據在分頁中的存儲位置，即通過數據所在行號便可直接定位到物理存儲位置。在頁索引中，行號并不是基于順序查找，而是通過散列完成，索引中的行號即為該散列的主鍵，而其指針指向數據存儲的物理位置，即對應的從節點及其上的存儲頁。頁索引具體結構如圖4所示。

屬性索引用于記錄一條數據記錄在不同屬性上取值與該數據記錄頁索引的映射關系。屬性索引將屬性集propertySet中的各屬性分別進行單維投影，按照屬性分類，將屬性值與對應的頁索引關聯起來，實現多值與布爾查詢。屬性索引具體結構如圖5所示。

圖3 StoreCDB的索引結構Fig.3 Index structure of StoreCDB

圖4 StoreCDB的頁索引結構Fig.4 mapIdx structure of StoreCDB

圖5 StoreCDB的屬性索引結構Fig.5 comIdx structure of StoreCDB

本文結合實例來討論屬性索引的結構，在圖5中，對應于StoreCDB中的屬性映射表，屬性集propertySet=(“velocity”,“temperature”,“operation”)，屬性索引對其中各屬性進行單維投影，投影結果如表2所示，其中數據行號對應于頁索引中的行號，通過頁索引mapIdx和行號rowId即可獲得數據的存儲位置，從而實現快速檢索。

當要查找滿足“運行速度135 km/h，轉向架溫度83℃并且操作記錄為c”的數據時，首先根據屬性值(velocity=135 km/h，temperature=83℃和operation=c)找出對應的行號，如表3所示。由于行

表2 屬性索引的單維投影范例Table 2 Example of a one-dimensional projection of comIdx

表3 屬性索引的查詢實例Table 3 Query instance of comIdx

號390是所有屬性值共同的取值，可以得出“運行速度135 km/h，轉向架溫度83℃并且操作記錄為c”的數據存放在390行，從頁索引中找出390行的存儲位置，便可以獲得查詢結果。

4 StoreCDB中數據寫入操作

4.1 數據寫入操作過程

在StoreCDB中，主節點在接收到數據寫入請求后，需要根據寫入數據D的主鍵(primeKey)確定分發的dataPage和對應的從節點。從節點接受到數據D之后，寫入對應的分頁中。然后根據返回的rowId和D的propertySet維護本地頁索引和屬性索引。算法1給出了數據寫入操作過程。

算法1數據寫入算法。

輸入：數據D、頁索引mapIdx、屬性索引comIdx。

輸出：寫入完成標記R。

1 /*主節點接到寫入數據請求*/

2 primeKey←getPrimeKey(D)；

3 propertySet←getPropertySet(D)；

4 dataPage←hashPage(primeKey)；

5 Worker←hashNode(dataPage)；

6 /*數據D被分發到從節點*/

7 將數據D寫入對應的dataPage；

8 mapIdx←updataMapIdx(D,mapIdx)；

9 comIdx←updataComIdx(D,dataPage,comIdx)；

10R←createR(dataPage,primeKey,propertySet)；

11 return(R)

算法中，getPrimeKey(D)函數返回數據D中的主鍵primeKey；getPropertySet(D)函數返回數據D中的屬性集合；hashPage(primeKey)函數返回與primeKey對應的dataPage；hashNode(dataPage)函數返回與dataPage對應的從節點；updataMapIdx(D,mapIdx)函數返回寫入數據D之后更新的頁索引mapIdx;updataComIdx(D,dataPage,comIdx)返回更新后的屬性索引comIdx;create-R(dataPage,primeKey,propertySet)函數返回的是數據寫入成功返回值R。

4.2 頁索引更新操作

在Worker節點本地數據寫入過程中，完成原始數據記錄在分頁存儲后，需要更新頁索引中行號順序增加并記錄映射地址。通過這一頁索引可以行號從分頁中提取原始數據記錄。算法2給出了頁索引的更新過程。

算法2頁索引的更新算法。

輸入：數據D、頁索引mapIdx。

輸出：更新結果mapIdx。

1 rowId←getRowId(D)；

2 idx←hash(rowId)；

3 dataPage←getDataPage(idx)；

4 鎖定數據頁dataPage的寫操作；

5 將D寫入dataPage的尾部；

6 mapIdx←updataIdx(rowId, idx)；

7 解鎖數據頁dataPage的寫操作；

8 return(mapIdx)

算法2中，getRowId(D)函數返回數據D中的數據行號；hash(rowId)函數返回rowId對應的哈希地址，即數據D應該存儲的從節點及其上的存儲頁；getDataPage(idx)函數獲取idx指向的從節點中的存儲頁dataPage；然后鎖定dataPage的寫操作；將D存入指定位置后，通過函數updataIdx(rowId, idx)更新mapIdx，然后解鎖dataPage的寫操作。

4.3 屬性索引更新操作

從節點接收到數據后，首先獲取數據D的屬性集合、行號，并從dataPage中取出屬性索引comIdx，若comIdx不存在則創建新的屬性索引，否則對于每個屬性的每個屬性值，更新其對應的索引映射集合valueArray，并將其寫入comIdx進行更新。算法3給出了屬性索引的更新過程。

算法3屬性索引的更新算法。

輸入：數據D、數據所需存儲頁dataPage、屬性索引comIdx。

輸出：更新結果R。

1 propertySet←getPropertySet(D)；

2 rowId←getrowId(dataPage)；

3 comIdx←getComIdx(dataPage)；

4 if comIdx不存在then

5 創建屬性索引comIdx；

6 for each tagName∈propertySet do

7 for each pValue∈tagName do

8 valueArray←addArray(pValue,rowId)；

9 將valueArray存入tagName對應的pTagMap；

10 comIdx←upcomIdx(pTagMap)；

11 return(comIdx)

算法3中，getPropertySet(D)函數返回數據D中的屬性集合；getrowId(dataPage)函數獲取存儲頁中的行號；getComIdx(dataPage)函數從dataPage中獲取屬性索引comIdx；addArray(pValue, rowId)函數更新索引映射集合valueArray；upcomIdx(pTagMap)函數更新comIdx。

5 StoreCDB中數據查詢操作

在上述索引技術的基礎上，StoreCDB系統通過查詢引擎實現全局范圍內的數據查詢。這一過程由2個步驟完成：

1) 查詢分解。主節點接收到查詢后，將其分解為二叉任務樹，其中葉節點為單值查詢任務，中間節點為操作連接符，連接2個單值查詢任務。

2) 查詢處理。主節點將二叉任務樹分發至相應的從節點進行查詢，從節點對操作連接符兩邊的單值查詢進行交叉過濾，形成局部查詢結果，全部任務完成后形成最終的查詢結果返回主節點。

定義10查詢query可以表示為

其中：tagNamei表示第i個屬性；pValuei表示第i個屬性值；f(tagNamei,pValuei)表示該屬性與屬性值之間的關系；opi表示操作連接符，取值為AND，OR，NOT，?，?表示沒有操作連接符。

以表3中的查詢為例，“運行速度135 km/h，轉向架溫度83℃并且操作記錄為c”的查詢可以表示為query=(velocity=135 km/h)∧(temperature=83℃)∧(operation=c)。當主節點接收到查詢任務query后，將其分解為多個單值查詢任務，并通過操作連接符將其轉換為一棵二叉任務樹，二叉任務樹結構如圖6所示。

主節點將二叉任務樹分發給相應的從節點后，等待所有從節點完成查詢任務后，匯集全部查詢結果。從節點接收到二叉任務樹后，通過遍歷二叉任務樹對本地存儲頁進行匹配和篩選，首先從當前二叉任務樹的最左葉節點開始，提取該左葉節點與右節點對應的屬性取值映射索引pTagMap，經過篩選得到局部結果集合。將該結果作為當前子樹的查詢結果與上一級的右葉節點繼續篩選，直到完成全部葉節點的屬性取值映射索引的篩選。算法4給出了從節點的查詢處理過程。

圖6 二叉任務樹的實例Fig.6 Instance of task binary tree

算法4從節點查詢處理算法。

輸入：二叉任務樹qtree、頁索引mapIdx、屬性索引comIdx。

輸出：查詢結構R。

1 while true do

2 lNode←getLNode(qtree);

3 if lNode = op then /*左節點是操作符*/

4 rNode ← getRNode(qtree);

5 /*獲取左右節點的屬性及取值和操作符*/

6fR← getQuery(rNode);

7 (fL, op) ← getFOp(rNode);

8 query ←(fL, op,fR);

9 else then

10 op←getFOp(lNode);

11 /*獲取父節點的操作符*/

12 rNode←getRNode(qtree);

13fL←getQuery(lNode);

14fR←getQuery(rNode);

15 query←(fL, op,fR);

16 /*通過頁索引和屬性索引執行查詢*/

17R←exeQuery(query, mapIdx, comIdx);

18 /*裁剪qtree的左右子節點，將結果存放當前op中*/

19 qtree←remove(lNode, rNode,R);

20 if qtree全部裁剪 then

21 return (R)

在算法4中，getLNode(qtree)(getRNode(qtr-ee))函數返回qtree的左節點(右節點)；getQuery(node)函數獲取節點的屬性及取值；fL與fR分別表示當前查詢中左側節點和右側節點的屬性與取值；getFOp(rNode)函數獲取父節點的操作符；exeQuery(query, mapIdx, comIdx) 利用頁索引mapIdx和屬性索引comIdx執行查詢query；remove(lNode, rNode,R)裁剪當前任務樹的左右子節點，并將結果集存放在當前op節點中。

6 系統實現及性能分析

本節在模擬數據集的基礎上，采用StoreCDB實驗系統，旨在對StoreCDB的查詢效率以及可擴展性進行了一系列實驗驗證。其中StoreCDB實驗系統是在分布式集群上進行部署，形成一個協同工作的StoreCDB系統。

本實驗中，主節點的處理器為Intel(R) Xeon(R) CPU E5-2620，主頻2.0 GHz，內存大小為2 GB；從節點的處理器為Intel(R) Xeon(R) CPU E5-2620，主頻2.0 GHz，內存大小為3 GB。

實驗所用的數據為基于實車采集數據的模擬數據集，其由數據格式為不同的CRH3和CRH5動車組軸溫采樣模擬數據(Src1)和CRH3和CRH5動車組運行狀態數據(Src2)組成。表4列出了實驗中的主要參數。

在實驗中，本文將StoreCDB與MySQL Cluster和HBase數據庫進行對比測試。重點針對StoreCDB的查詢響應時間及加速比進行了分析。

為了全面評估StoreCDB對K-V查詢以及數據關系庫(RDB)查詢的支持，實驗的測試用例采用了如下2種查詢：

1) K-V查詢

Select * From table Where date=“2017-05-01”。其中：table表示不同的數據源，分別為Src1或Src2；date表示關鍵字，查找所有與“2017-05-01”相關的數據。

2) RDB查詢

Select * From table Where velocity=135 AND temperature=83 AND (operation=‘c’ OR operation=‘rw’)。

圖7給出了StoreCDB、MySQL Cluster和HBase處理K-V和RDB查詢的響應時間。圖7(a)展示了K-V查詢時間與數據集規模的關系，圖7(b)是RDB查詢時間與數據集規模的關系。隨著數據集的增加，K-V查詢和RDB查詢的時間都逐漸增加。StoreCDB在海量數據情況下，K-V查詢效率高于MySQL Cluster，低于HBase。由于HBase不支持多條件查詢，故圖7(b)中僅有MySQL Cluster和StoreCDB的實驗結果。

隨著數據集的增加，3種數據庫的K-V查詢時間都逐漸增加，HBase在進行列查詢時，響應時間始終小于StoreCDB和MySQL Cluster。在數據集規模較小的情況下，StoreCDB與MySQL Cluster響應時間基本相同，隨著數據集規模增大，StoreCDB響應時間增速逐漸小于MySQL Cluster。

表4 實驗參數Table 4 Parameters of experiment

圖7 查詢效率實驗Fig.7 Query efficiency experiment

在進行RDB查詢時，MySQL Cluster和StoreCDB響應時間均高于K-V查詢，這是因為K-V查詢只涉及頁索引，而RDB查詢同時需要頁索引和屬性索引的檢索。盡管如此，兩種查詢的效率相差并不大，且變化趨勢也較一致。可以看出，在數據量快速增長的情況下，StoreCDB依然能快速響應查詢，性能保持良好。

圖8給出了StoreCDB的可擴展性，為RDB的查詢響應時間與從節點個數的關系。

從圖8可以看出，隨著從節點個數的增加，StoreCDB查詢的性能明顯提升，RDB查詢與K-V查詢性能提升效果變化趨勢相似。StoreCDB具有良好的可伸縮性，并且保證在從節點增加的情況下有明顯的性能提升。

為了進一步分析StoreCDB中從節點規模對查詢的影響。本文在表5中分別給出StoreCDB在處理2×1010行和7×106行數據源中RDB查詢的加速比實驗結果。加速比Speedup定義為

(1)

圖8 可擴展性實驗Fig.8 Expandability experiment

NworkerNodes加速比Nsrc=2×1010行Nsrc=7×106行21.621.3341.791.4982.061.63162.642.10324.953.32

式中：ξSingle和ξStoreCDB分別為單數據庫節點和StoreCDB的查詢響應時間。

從表5可以看出，StoreCDB在處理查詢任務時，相比于單點數據庫，加速比隨著從節點數量的增加而上升，并且數據集規模越大，加速性能越明顯。

為了評估存儲空間的利用效率，本實驗采用32節點的StoreCDB和HBase在不同數據集規模時的空間利用率進行對比測試。

HBase是通過文件合并(compaction)的方式對小文件和文件刪改帶來的空間碎片進行整理以提高存儲空間利用效率。StoreCDB則采用虛擬行的方式，使得同一行數據可以存儲在不連續的位置來減少空間浪費。

詳細對比情況如圖9所示，圖9給出了空間利用率的對比實驗結果。

圖9 存儲空間利用率實驗Fig.9 Storage space utilization experiment

從圖9可以看出，隨著存儲數據集規模的增加，StoreCDB的空間利用率逐漸降低，這是因為虛擬行中的索引規模隨著數據集規模的增長造成的空間利用率下降。在數據集規模較小的情況下，HBase的空間利用率略高于StoreCDB。隨著數據集規模的增長，StoreCDB空間利用率降低程度略優于HBase。這是由于HBase的合并策略在提高讀寫性能時會減少參與合并的文件數量，從而導致空間利用率下降。

綜合上述分析，StoreCDB可以有效地支持K-V查詢和RDB查詢，提供了良好的工業互聯網海量異構數據接入與查詢處理能力，為工業互聯網的海量異構數據管理提供了一種可行的解決方案。

7 結 論

本文從工業互聯網數據管理角度出發，對工業互聯網在非結構化數據統一存儲管理，高性能檢索查詢等方面所面臨的挑戰進行了分析，提出了面向工業互聯網數據管理的云存儲方法——StoreCDB。

1) 提出了一種能夠應對海量多源異構數據統一管理的數據模型，實現了多源異構數據的統一表達，解決了不同服務系統的數據統一存儲問題。

2) 提出了一種能夠支持“鍵-值”查詢和普通SQL查詢的索引方法，通過頁索引和屬性索引的兩級索引結構，突破了目前云數據管理技術主要針對“鍵-值”查詢以及并行數據庫技術主要針對SQL查詢的局限。

3) 提出了基于兩級索引結構的全局查詢處理方法。

4) 采用StoreCDB實驗系統，對該方法的查詢效率及可擴展性進行了一系列實驗驗證。實驗結果表明，StoreCDB具有良好的異構數據存儲和檢索性能。