韓文軍, 余春生
(1. 國網經濟技術研究院有限公司 工程數據中心, 北京 102209; 2. 德信東源智能科技(北京)有限公司 科技研發中心, 北京 100088)
隨著計算機與大數據技術的快速發展,數據管理系統已逐步向電子化存儲、集中管理、大數據整合及全方位應用方向轉變[1].但由于技術水平的參差不齊,管理模式存在較大差異,我國輸變電工程數據管理系統仍停留在初步的電子化檔案存儲及基本信息查詢階段[2],缺乏專業技術支撐輸變電工程數據管理,并累積了大量有待挖掘其深層次價值的數據[3].
為了有效描述和管理各種數據,國內外研究者和機構提出了諸多數據存儲技術,如使用RDBMS數據庫管理系統存儲關系型數據[4];使用Key-Value數據庫、Redis、Tokyo Cabinet和Tokoy Tyrant等NoSQL數據庫存儲非關系型數據[5];使用MongoDB和CouchDB數據庫存儲具有海量存儲需求和訪問需求的文檔數據[6];Cassandra與Voldemor數據庫存儲具有高可擴展性及可用性的特點[7].然而這些方法并不適用于多源、異構的輸變電工程數據,且需要浪費大量的存儲空間,降低了計算分析效率.
輸變電工程數據包括文檔資料、三維設計模型及工程地理信息數據3類[8-10],根據對現有輸變電工程數據的調研,每個工程項目移交數據的數據量及其形態表述如下:
1) 文檔資料數據包括初步設計階段、施工圖設計階段和竣工階段的變電站與架空線路數據,約占30~50 Gbit,以非結構化的PDF和圖片文件為主,基本沒有結構化數據;
2) 三維設計模型數據包括工程模型(CBM)、物理模型(DEV)、組合模型(PHM)和幾何模型單元(MOD)4大類,約占0.5~5 Gbit,其中,10%~30%為結構化數據,70%~90%為GIM格式的三維模型文件;
3) 工程地理信息數據包括影像數據、數字高程模型數據、基礎矢量數據、電網專題數據、電網空間數據和輸電線路通道數據等,約占0~10 Gbit,其數據格式以非結構化的圖片文件為主,包括img、tif、grd、asc和shape等.
按照此數據量,平均每個工程項目包含結構化數據500 Mbit,非結構化數據50 Gbit,而我國各省擁有存量的輸變電工程項目約為1 000~10 000個,每年新增項目為幾十到幾百個[11-12].包含存量項目在內的所有輸變電工程項目總數約在5萬個以上,工程數據總量有可能超過50 Tbit結構化數據和2.5 Pbit非結構化數據.然而,傳統的單主機、單數據庫的簡單存儲模式無法滿足海量數據存儲的需求[13],必須采用陣列式或分布式的數據存儲模式來提升整個存儲體系的容量和性能.
基于上述分析,本文針對輸變電工程數據的多源、異構、迭代更新和集成應用等特性,提出了一種分布式數據存儲架構來存儲各種輸變電數據.首先基于元模型設計了輸變電工程數據的數據模型,然后提出了一種面向輸變電工程數據存儲管理的分布式數據存儲模式,并設計了一種數據完整性分析方法以保證完整、準確地存儲各種數據,最后,基于Hadoop分布式存儲平臺對提出方法進行了仿真實現與分析.
輸變電工程數據具有“多源、異構”特點,即每個工程物理實體在時空中均是唯一存在的,從不同角度出發可以得到不同的數字化描述.本文在元數據模型框架基礎上,按照輸變電工程的數據種類和特性,對相關對象類型作進一步細化后得到適用于輸變電工程組織與管理的數據模型.按照如圖1所示的元數據模型,從以下5個方面對輸變電工程數據模型進行細化:1)物理對象分類細化;2)工程結構化描述,即數據的上、下文信息;3)數據結構化描述,即對數據對象、數據屬性和數據值集合的統計分析;4)元數據結構,即用數據來源、數據對象、數據屬性和數據值表示數據信息;5)文件結構化,即數據的來源和數據包的結構化信息.
物理對象代表在工程中所形成的、具有一定物理特性的相關對象.本文根據輸變電工程的特點,將物理對象細分為以下3種對象:

圖1 電力工程數據細化流程Fig.1 Refining process of power engineering data
1) Project工程對象,代表某個輸變電工程的整體,對應GIM模型中的project.cbm信息,根據工程類型的不同,可進一步細分為Substation-Project變電工程和TransmissionProject輸電工程;
2) FunctionalObject功能對象,代表輸變電工程的某個組成部分,體現該組成部分的功能特性,對應GIM模型中的*.cbm信息;
3) Device設備對象,代表某個能實現一定功能特性的物理實體,廣義上包含組合設備、子設備、設備部件等衍生對象,對應GIM模型中的.dev信息.
通過FunctionalObject功能對象,對每個Project工程項目建立了一套層次結構.對功能層次結構中的每一個設備節點設置一個Device設備對象,并根據對設備技術參數的設定,將設備對應到具體的物料項上.同時隨著采購和施工的進行,將設備對應到具體的產品項上.
每一個PhysicalObject物理對象可以具有多組設計數據,即對應多個DesignData設計數據對象.每個數據對象可以具有一組PropertyValues結構化數據和一組KeyValues半結構化數據,其中,PropertyValues可通過ValueObject值對象來管理復雜值.每個數據對象根據其數據來源可歸屬于某一個數據包,在數據包上進行版本控制與來源跟蹤.
將元數據細化為ObjectType、ObjectProperty、ValueType和PackageType這4種類型.ObjectType定義了物理對象和數據對象的類型,重點是根據物理對象的設備分類,結合數據種類劃分來對數據對象進行細分;ObjectProperty定義了每種數據對象的屬性集合,對應PropertyValues屬性值集合;ValueType對復雜值進行分類和定義,對應ValueObject值對象;PackageType定義了DataPackage數據包的分類.
通過Folder文件夾來構建一個用于存儲文件的層次結構,每個File文件均位于特定的Folder文件夾節點中.每個File文件根據其數據來源可歸屬于某一個數據包,在數據包上進行版本控制及來源跟蹤.
對于輸變電工程數據而言,每個工程項目均具有較強的整體性.在同一個工程項目內部,不同數據之間存在緊密的關聯,不同環節的工作開展也通常依賴于其他環節所產生的數據.而在不同的工程項目之間,該種關聯性相對較弱,對于工作的影響一般是在參考、借鑒、引用等方面.本文根據工程項目數據的整體性和海量數據分散存儲的需要,提出了如圖2所示的面向輸變電工程數據存儲管理的分布式數據存儲架構.

圖2 輸變電工程數據分布式存儲架構
Fig.2 Distributed storage architecture for power transmission and transformation engineering data
在該數據存儲管理架構中,輸變電工程數據被抽象為數據單元、數據包和工程項目3個層級.數據單元是數據管理中的最小單位,每個數據單元代表一個數據對象及其附屬的數據屬性集、值對象以及鍵值對集;數據包用于承載數據管理信息,每個數據包一般由一組或多組數據對象按照一定規則進行排列或組合而成,對數據的存儲與管理活動一般會被對應到數據包對象上;工程項目是數據存儲管理中的基本單位,對每個工程項目的所有數據進行集中存儲.
整個數據存儲體系采用分布式存儲、集中式管理的實現方式,包含一組全局管理器和多個并列的數據存儲器.每個數據存儲器可以管理多個工程項目、數據包和數據單元,將其持久化到數據庫或數據文件中,并建立數據緩存以改善數據存取性能.全局管理器集中管理所有的元數據、主數據以及工程數據的索引信息.同時使用分布式存儲平臺可以便于數據的統一加密和處理,本文使用HDF5編碼對存儲的數據進行加密處理.
從便于數據管理和使用的角度進行考慮,結合數據量估算與典型硬件性能等因素,本文按網省和年份來組織輸變電工程數據存儲體系,并設計了如圖3所示的數據管理架構.該管理架構以工程項目的歸屬網省和啟動日期為依據,將某個網省在某一年所有工程項目的數據集中存儲在一個數據存儲器中,并統一注冊到全局管理器中.在應用數據時,用戶或第三方應用可通過全局管理器提供的統一查詢接口進行全局的數據檢索,或者連接特定的數據存儲器進行本地數據的檢索及存取.
基于上述數據存儲和管理架構分別設計了不同類型數據的存儲模式:
1) 工程地理信息數據.本文將與輸變電工程相關的地理區域作為物理對象,將該區域的各種地理信息作為數據對象,按時間、精度、級別、坐標系等方面進行組織,并將所包含的DEM、DOM文件通過文件庫進行集中管理,再通過GIS系統進行使用.工程地理信息數據存儲模式如圖4所示.

圖3 數據管理架構Fig.3 Data management architecture

圖4 工程地理信息數據存儲模式Fig.4 Data storage mode for engineering geographic information
2) 三維設計模型.本文將與輸變電工程相關的系統或設備等功能設施作為物理對象,將該系統或設備的各種屬性集、幾何建模、層次結構、連接關系等作為數據對象,將所包含的工程模型、物理模型、組合模型、幾何模型單位等文件通過文件庫進行集中管理,并建立起物理對象與文件對象的對應關系.在數字化移交管理中,將獲取到的每個GIM模型文件作為一個數據包,而將其中的每個數據對象及其對應的文件作為一個數據單元,三維設計模型的數據存儲模式如圖5所示.

圖5 三維設計模型數據存儲模式Fig.5 Data storage mode for 3D design model
3) 文檔資料數據.本文將與輸變電工程相關的所有文檔資料作為文件對象,按文件內容、文件類型、文件夾等方面進行組織,并分別關聯到對應的系統/設備等功能對象上.將數字化管理中獲取到的每一套文件作為一個數據包,而其中的每個文件對象及其相關的關聯關系作為一個數據單元,數據存儲模式如圖6所示.
為了驗證本文所提分布式存儲架構的有效性,使用2017年某地的輸變電工程數據進行仿真測試.基于Hadoop平臺搭建和部署了輸變電數據存儲系統,該系統使用9臺普通PC機作為分布式存儲節點,各節點硬件配置為4 Gbit內存、Core i5 CPU@2.60 GHz,100 Mbit/s網絡帶寬,并為各節點安裝Ubuntu16.04系統和Java JDK,系統平臺示意圖如圖7所示.

圖6 文檔資料數據存儲模式Fig.6 Data storage mode for documents

圖7 測試系統平臺示意圖Fig.7 Schematic diagram of testing platform system
本文對比了不同大小數據時使用單機單數據庫架構存儲方式和使用Hadoop分布式存儲架構兩種情況下的效率,以驗證所提存儲架構的存儲效率,對比結果如圖8所示.

圖8 不同大小文件的存儲效率比較Fig.8 Comparison of file storage efficiency with different sizes
從圖8中可以看出,隨著數據塊的增大,本文架構產生標識的時間基本不變;而傳統存儲方法所需的時間隨著文件大小的變化呈線性增加.由此表明,本文存儲架構更適合存儲海量輸變電工程數據.
此外,文中比較了不同大小的輸變電數據,驗證其完整性的時間開銷,即系統解析不同類型的數據時,檢測算法所需的時間開銷.圖9為設置數據塊大小為2、4、8、16、32、64、128 kbit時,數據完整性檢測所需的時間與通信開銷.從圖9中可以看出,對本存儲架構所存儲的數據進行完整性檢測時,所需要的時間基本不隨數據塊大小的變化而變化.

圖9 完整性檢測所需時間開銷Fig.9 Time overhead required for integrity detection
本文存儲架構在保證存儲效率和數據完整性的同時,也需要保證數據的安全.圖10、11分別為本存儲架構存儲的原始數據與使用Storm平臺加密后的數據.從圖11中可以看出,本系統將數據以加密的形式進行分布式存儲.

圖10 原始數據Fig.10 Raw data

圖11 加密后的數據Fig.11 Encrypted data
本文在充分考慮輸變電工程數據的多源、異構、迭代更新及集成應用等特性的基礎上,提出了一種分布式數據存儲模式,實現輸變電工程數據的分散存儲、全面關聯與統一管理.文中先基于元數據模型框架對輸變電工程數據進行了細化,然后使用面向輸變電工程數據存儲管理的分布式數據存儲架構分別對工程地理信息數據、三維設計模型和文檔資料數據進行存儲設計.系統實現與仿真實驗結果表明,所提出的分布式存儲架構在保證存儲效率和數據完整性的同時,也能保證數據的安全.