現代MRO系統的可擴展數據管理策略研究

湯小春, 周佳文

(西北工業大學 計算機學院, 陜西 西安 710072)

現代MRO[1-3](maintenance, repair, overhaul)是在借鑒航空維修MRO[4]概念的基礎上,增加了產品的狀態監視及運行控制等業務內容。它的最大特點是支持產品的全生命周期管理[5-6],即涵蓋產品的設計、生產、運行以及回收等全部階段。因此,與傳統MRO比較,現代MRO系統的數據管理特點是:①數據量大。產品的設計、生產、運行以及報廢的整個生命周期,每個產品都會產生大量的數據;②數據處理任務數量快速增長。產品數量的增加使得實時處理負荷變大;③數據類型多樣化。系統中有實時數據、基礎數據、業務知識數據以及用戶交互數據,這些數據的類型不一樣。④共享性高。終端用戶、制造商、銷售商以及相關零部件的供應商都參與到產品中,信息共享性要求大幅提高。

現代MRO系統的一個重要特點是歷史數據龐大,并且這些歷史數據能夠被反復利用,進行產品運行中的預測和評估計算,例如,最佳維護時間的計算等,因此,既需要海量的存儲空間亦需要好的計算能力。目前,有關現代MRO系統的數據管理文獻中,有些專注于如何滿足海量數據存儲的要求[2-3],另外一些則只考慮計算能力問題[6],而綜合考慮全生命周期中數據存儲和數據分析計算的則較少。現有的MRO系統以采用傳統的關系數據庫和NoSql數據存儲為主,文獻[7]利用實時數據庫系統保存數據,它只支持對動態采樣數據的處理;文獻[8]針對MRO系統中數據的多源、異構、海量、動態等特點,提出了一種綜合運用云計算技術解決這一問題的思路,它很好地解決了存儲問題,但是對于數據操縱問題卻沒有涉及。文獻[9]針對數據模型、數據預處理與集成和數據查詢等幾個方面進行了分析,提出了基于云平臺的數據管理框架,但是其核心在于數據模型方面。文獻[10]針對傳感器采樣數據管理中所面臨的數據海量性、異構性、時空敏感性、動態流式特性等問題,提出了使用數據庫集群來管理采樣數據,但是沒有涉及事務數據的管理。

鑒于現存系統中的不足,提出了一個可擴展鍵值存儲[11-12]系統來滿足現代MRO系統的數據處理要求。通過本地化實時應用和數據緩存的特點,在應用程序和KV存儲之間增加一個中間層,實時更新的數據被緩存到內存的不同組中;收到讀取數據請求,直接返回內存中的數據,避免過多的I/O操作。對于需要多個數據經過融合才能進行實時分析計算的請求,按照應用要求對數據分組,一起工作的鍵緩存在同一個計算節點中,避免了分布式帶來的風險。由于以鍵值存儲為基礎,系統允許用戶靈活地建立分組,實現不同的計算要求,所以滿足了可擴展性[12]。

1 現代MRO的實時數據存儲模型

現代MRO系統的數據存儲模型需要實現實時數據更新、實時數據分析處理以及實時數據狀態顯示功能。實時數據更新負責獲得設備中各個部件的傳感器的最新狀態參數,然后保存。實時分析根據產品的最新狀態數據,再利用歷史數據,及時準確地判斷產品的狀態。實時狀態顯示負責從數據存儲中心獲得產品的最新數據及狀態,向終端用戶展示。

為了有效利用二級存儲設備,降低磁盤I/O次數,將數據存儲功能分為分組存儲層和數據存儲層。分組存儲層以內存為主,用于實時數據的計算;數據存儲層采用KV存儲模型,可以滿足海量存儲。當系統啟動一個實時處理業務時,將業務需要的數據從KV存儲中取出,分組存儲層進行匯聚后,再執行計算。

為了與傳統的關系數據庫融合,KV存儲中的鍵由多個部分組合形成,按照樹模型組織起來,而每個部分可以對應關系中的屬性。

定義1父子關系是指有序對集合{(p,q1),(p,q2),…,(p,ql)}上,p與 {q1,q2,…,ql}之間是一對多的聯系,集合中的任何一個有序對稱為父子關系,其中p叫父鍵,q1,q2,…,ql都叫子鍵,個數為l。

定義2層次模型是由一組鍵和鍵之間的父子關系構成的一棵有向樹T=(V,E)。其中V和E定義為:①V是鍵的集合;②如果(v1,v2)∈E,當且僅當存在一個從v1到v2的父子關系。

現代MRO系統中,產品、部件以及零件等之間的裝配關系是樹狀的,所以實時處理鍵組可以很好地描述產品中每個零部件的信息。例如產品是根,產品與部件是父子關系,部件和零件是父子關系,零件的運行狀態與時間戳是父子關系,其鍵表示為/sid/cid/qid/timestamp。因此,對于每一個具體的產品,可以用層次模型表示。

現代MRO系統計算產品的指定狀態時,需要將涉及到的零部件信息組合在一起,形成一個計算單元。

定義3實時處理鍵組是一組層次模式的集合。

實時鍵組的操作主要包括:鍵組的建立和刪除;鍵組元素的增減操作。

約束規則為:①進行插入時,如果沒有相應的父鍵存在,子鍵不能插入;②進行刪除操作時,如果刪除父鍵,則子鍵記錄必須被全部刪除;③只有一個鍵沒有父鍵,其為根鍵;沒有子鍵的鍵稱為葉子鍵。除根鍵外,每個鍵有且只有一個父鍵;除葉子鍵外,每個鍵至少存在一個子鍵。

例如,當分析采摘定的狀態時,需要將轉速、油壓、風管參數組合在一起,形成一個計算單元,其包含的鍵形成實時處理鍵組。但是由于這些參數可能來自不同的物理節點,也有可能一些鍵被其他計算單元使用,因此實時處理鍵組是動態組合的,因此需要進行實時鍵組的管理。

2 實時處理鍵組的管理

2.1 實時處理鍵組軟件結構

如圖1所示,每個物理節點包含一個協調器、一個實時應用管理器以及實時處理鍵組。

圖1 實時處理鍵組存儲模型

應用管理器主要調度該節點上的實時計算程序,協調器執行用戶實時處理鍵組的建立和撤銷請求。當需要執行實時計算時,協調器從各個KV存儲節點獲取指定的鍵值,然后形成一個實時處理鍵組,最后由應用管理器調度執行。一旦計算結束,撤銷對應的鍵組。

2.2 實時處理鍵組注冊和撤銷過程

實時處理鍵組的注冊是由實時計算發起的,它指定一組需要更新的成員鍵,然后向實時處理鍵組管理器發送注冊請求,實時處理鍵組管理器就開始一個實時處理鍵組的注冊過程。注冊過程采用原子方式,要么注冊成功,形成一個實時處理鍵組,要么注冊失敗,實時處理鍵組無法產生。

算法: 注冊過程。

輸入: 新收到的鍵K={k1,k2,…,km}

輸出: 新鍵組t

過程:

T={t1,t2,…,tn}/*已經存在的鍵組*/

while(k∈K){

if((k?ti.k)∧(?ti∈T)){

if(!t)t=mg(k)

elset.k=∪{k}

}else

returnφ

T=T∪{t}/*t與T合并*/

}

returnt

實時處理鍵組注冊時,應用管理器向協調器發送建立命令,協調器并發地向各個鍵所在的數據存儲節點(參與者)發送消息(C),參與者收到消息后,將成員鍵的值發送到協調器(CA),若有錯誤發生則返回錯誤(A)。協調器根據所有參與者的回復決定實時處理鍵組的建立或者中止。如果存在成員鍵的值無法取得,協調器負責通知管理器建立失敗。如果成功取得所有成員鍵的值,協調器負責通知管理器建立成功。

當應用程序不再需要某個實時處理鍵組時,首先向管理器發送解散實時處理鍵組的命令,此時,管理器向協調器發送釋放消息,實時應用存儲節點上的鍵值即為不可用狀態。若實時處理鍵組中某個鍵值的變更未被提交,在發送解除消息之前,協調器必須保證數據提交到各個成員節點。

2.3 實時數據分析處理的實現

圖1中的分組管理器為每一個實時處理鍵組設置一個對象標識,稱之為應用對象。圖2展示了系統的數據處理過程。

圖2 實時數據處理應用的提交

①根據實時處理鍵組建立應用對象;②buffer取得鍵值并處理;③處理完的數據寫入應用對象;④分組管理器采用put2new策略檢查③中的數據是否全部得到,若是,則向異步更新服務發送commit請求;⑤異步更新服務采用put方法將數據回寫到數據存儲系統;⑥異步更新服務也將其他備份進行commit更新,分組管理器檢查③提交的數據,若發現有數據未到達,則應用程序顯示分析處理失敗。

實時處理鍵組的數據存儲在內存中,既提高了響應速度,又提高了故障發生時執行失效接管的速度。

2.4 可擴展性

在圖2中,當某個節點的負荷較大時,系統可以增加新的計算節點,并且將部分實時處理鍵組轉移到新的節點,從而提高系統計算能力。另外,由于采用分布式KV存儲策略,擴展數據存儲節點非常容易,從而滿足海量數據存儲的要求。

3 實 現

系統組成如圖3所示,用戶的實時處理請求到達后,實時處理服務建立實時處理鍵組,從數據存儲服務器中取得數據,數據的更新寫入分組對象。分析處理完的數據定期更新到鍵值存儲系統中,實現持久化。由于內存中數據容易丟失,所以采用先寫日志的方式(WAL)將數據寫入日志中。

圖3 系統實現結構

實時處理業務執行時,必須保證分組中的鍵值是最新的,否則不能進行處理。如果應用不需要訪問分組內的全部鍵值,而僅僅需要訪問組內的一個鍵,那么就不使用分組管理。

在實時處理鍵組的生命周期內,實時鍵組管理器負責實時處理鍵組內鍵的訪問,它獨占訪問鍵組內鍵的權利。雖然實時處理鍵組內的鍵可能來自不同的數據存儲節點,但是實時處理鍵組服務可以緩存實時處理鍵組內的鍵值,從而避免了代價高昂的磁盤I/O,減少了延遲時間。

4 評 價

論文實現了一個現代MRO軟件中的數據管理系統。分布式鍵值存儲采用數據存儲服務,采用Voldemort和Berkeley DB實現數據存儲服務,對Voldemort封裝了一個接口,可以連接實時處理鍵組服務的內存存儲。

4.1 實時處理鍵組注冊和撤銷的模擬方法

假設有G個并發的實時處理鍵組,每個實時處理鍵組中包含K個鍵,則系統中至少包含n×G×K個鍵,其中n是可擴展因子,它表示沒有被包含到實時處理鍵組中的鍵數量。實時處理任務發出創建實時處理鍵組的請求,其中包含實時處理鍵組成員,實時處理鍵組的成員的選擇是隨機的,成員的平均個數是K,標準偏差是σk。實時處理鍵組創建成功后,每個實時分析處理程序獲得全部的鍵值,全部獲得后執行分析計算,等待數據的時間間隔為δ或者2δ,然后繼續重復以上的數據處理。

使用參數G,K,n,δ來評價系統各個方面的性能,前3個參數來說明可擴展性,而N用于評價實時處理鍵組建立和刪除時的系統開銷,δ則體現系統進行并發操作時的壓力測試。

4.2 實時處理鍵組的創建時間評價

通過將實時處理鍵組中的其他操作設置為0,從而使得創建過程的負載只包含創建操作,創建成功后立即執行刪除操作。評價了使用不同傳輸方式及實時處理鍵組成員選擇方法時的延遲和吞吐量,其中傳輸協議分為可靠傳輸協議和不可靠傳輸協議,選擇方法分為隨機選擇參與者鍵和順序選擇參與者鍵。

圖4 創建實時處理鍵組請求的延遲時間

隨著并發實時分析計算的請求增加,圖4描述了實時處理鍵組創建請求的延遲情況。延遲時間是指客戶發出創建請求與收到建立成功消息之間的時間。從圖中明顯可以看出,順序選擇參與者鍵優于隨機選擇參與者鍵,因為這些鍵存在于一個節點上,所以使用單個創建消息即可滿足;另外,實時處理鍵組中鍵的個數對延遲時間影響較小,因為請求是依照批處理方式發送的,假如有n個分布式節點,最多只發送n個消息,與參與者鍵的個數沒有關系。

圖5給出了一定時間內建立實時處理鍵組的個數,客戶數量從50增加到10 000的過程中,每秒鐘創建實時處理鍵組的個數也呈線性增長,但是隨著客戶數量的增大,增長停滯,其原因從圖4中也可以得到,客戶數量的增大,創建組的平均延遲時間增大,導致創建的組數量停滯。

圖5 創建組的吞吐量

4.3 實時處理鍵組的操作評價

本節評價實時處理鍵組操作的性能。實時處理鍵組建立后,從客戶端就模擬大量的操作,在評價中,主要比較論文中的系統與Voldemort、Berkeley DB、文獻[11]中的Megastore 以及文獻[12]中的ForestDB系統在操作上的平均延遲時間。論文中的系統延遲時間包括實時處理鍵組的建立、刪除時間以及附加的操作時間。對于Voldemort系統,不需要建立組,也不需要保證實時應用特性,因此它被作為性能基準來評價本系統的額外開銷。對于本系統,更新操作產生后,系統保證全部的鍵更新完成。在實驗中,針對不同的N值進行評價,每個實時處理鍵組中鍵的個數K設置為15和60,δ設置為10 ms。

圖6 每個實時處理鍵組中每個操作的平均延遲時間(ms)

圖6給出了N值不同時每個操作的延遲時間。延遲時間計算方法是:

式中,tc表示實時處理鍵組建立與刪除時間,to表示操作花費時間,No表示操作的數量。

對于Voldemort系統,延遲時間就是所有操作時間的平均時間。如圖6所示,由于Megastore以及ForestDB采用本文類似的技術,所以這3種系統與Voldemort比較,實時處理鍵組帶來的額外開銷大約有10%～30%,隨著實時處理鍵組中操作數量的增加,額外開銷占用的比例進一步降低。盡管鍵值的更新不是直接進行持久存儲,而是通過實時處理鍵組服務被異步地提交到持久存儲,但是這種方式并沒有影響鍵值的更新效率。由于Megastore以及ForestDB是針對大規模事務操作以及數據類型多樣,而本文對于實時要求相對較高,并且數據類型單一,所以,相比較而言,本文中的系統比Megastore以及ForestDB性能要好一些,大約有10%左右。故這種采用二級緩存來形成實時應用型可擴展大數據存儲系統的方式是一種有效的途徑。

5 結 論

隨著數據密集型計算的不斷增多,數據規模的不斷增大,可擴展性作為重要的特性被提出。本文提出的實時處理鍵組協議很好的滿足了可擴展性,系統已經在項目中應用,并得到評價,既可以滿足實時應用的需求,也不降低鍵值存儲的效率。