徐 丹，夏 晨，黃金龍，秦小元

（1. 南京南瑞繼保電氣有限公司研究院數(shù)據(jù)平臺部，江蘇 南京 211102；2. 向家壩水力發(fā)電廠，四川 宜賓 644612）

0 引言

大型水力發(fā)電站前期建立了大量的監(jiān)控、監(jiān)測和管理系統(tǒng)來滿足日常運維工作的需要和解決特定的管理問題。這些系統(tǒng)功能各有側重，管理的信息既有交集、也存在差異和互補的內(nèi)容。由于建設時間、供應商和采用技術的不同，各系統(tǒng)的業(yè)務模型、信息描述、數(shù)據(jù)含義等自成體系，雖然系統(tǒng)之間也有一些點對點的數(shù)據(jù)交互，但總體上形成了信息單獨存放、共享困難、無法綜合分析利用的信息孤島[1]。

隨著水電站的發(fā)展和管理要求的提高，各個專業(yè)應用之間、水電站和上級管理部門之間的信息共享和協(xié)作要求越來越高。當前各業(yè)務系統(tǒng)的信息孤島形態(tài)使得數(shù)據(jù)難以得到綜合利用，無法為多業(yè)務系統(tǒng)數(shù)據(jù)協(xié)同分析提供支持，也無法為現(xiàn)場一線技術人員提供業(yè)務優(yōu)化的平臺。

為適應水電站運行精細化管理的要求，迫切需要一個能整合水電廠現(xiàn)有各業(yè)務系統(tǒng)的實時數(shù)據(jù)、歷史數(shù)據(jù)、視頻、波形文件等各種信息，滿足水電站各級部門進行實時綜合監(jiān)視、高效應用分析、支撐各專業(yè)持續(xù)優(yōu)化改進的水電站一體化數(shù)據(jù)中心[2，3]。數(shù)據(jù)中心通過對大量業(yè)務子系統(tǒng)實時數(shù)據(jù)的采集和存儲，為企業(yè)建立了全業(yè)務全景模型，也為企業(yè)保留了極為重要的歷史數(shù)據(jù)。在對歷史數(shù)據(jù)和實時數(shù)據(jù)分析的基礎上，可以對企業(yè)設備資源實施監(jiān)控及管理，如設備維護、故障預警、應急響應等，在計劃管理和生產(chǎn)管理之間架起一座橋梁，成為大中型水電企業(yè)信息系統(tǒng)中數(shù)據(jù)的“存儲中心”，在整個“智慧電廠”建設中起著關鍵作用[4]。

數(shù)據(jù)中心最迫切需要解決的問題是數(shù)據(jù)怎么存和怎么取，也就是數(shù)據(jù)的存儲和服務問題。本文針對大型水電站機房可容納服務器數(shù)量少、數(shù)據(jù)類型多和實時數(shù)據(jù)量大等情況，提出了一種基于混合數(shù)據(jù)庫的水電數(shù)據(jù)中心存儲服務平臺[5]，有效解決了當前面臨的不同數(shù)據(jù)類型和不同頻率數(shù)據(jù)的存儲和服務問題[6]。本文給出了基于混合數(shù)據(jù)庫的水電數(shù)據(jù)中心存儲服務平臺的設計與實現(xiàn)，包括詳細的模塊設計，不同層次間的協(xié)作機制，平臺不同數(shù)據(jù)庫間數(shù)據(jù)的管理機制，并在此基礎上詳細介紹了混合數(shù)據(jù)庫存儲服務平臺各模塊的功能。最后分析了基于混合數(shù)據(jù)庫的水電數(shù)據(jù)中心存儲服務平臺的性能和經(jīng)濟優(yōu)勢，對比分析數(shù)據(jù)，并給出進一步研究工作。

1 基于混合數(shù)據(jù)庫的數(shù)據(jù)中心存儲服務平臺

一體化水電數(shù)據(jù)中心需要整合水電站所有子業(yè)務系統(tǒng)，將會面對海量數(shù)據(jù)和各種數(shù)據(jù)類型兩大難題。

面對海量數(shù)據(jù)難題，采用自研實時數(shù)據(jù)庫作為前端采集和后端存儲的緩沖池，從而使得前后端異步存儲，相互獨立。實時數(shù)據(jù)庫采用面向對象的數(shù)據(jù)模型，支持類之間的繼承、聚集關系以及對象標識等面向對象的特性，能夠構造復雜的結構模型，支持用戶自定義數(shù)據(jù)類型和方法。面向對象的數(shù)據(jù)模型，不僅易于描述水電相關系統(tǒng)及其拓撲關系，更能直接定義類結構，不需要任何映射和模型轉換，是最容易接納標準，并適應其版本變化的數(shù)據(jù)模型。在面向對象數(shù)據(jù)模型中，每個對象都有一個在系統(tǒng)內(nèi)唯一不變的標識符，稱為對象標識符，簡稱OID。OID的生成和管理既是面向對象數(shù)據(jù)庫不可缺少的重要組成部分，也是開放系統(tǒng)中數(shù)據(jù)交換的需要。實時數(shù)據(jù)庫的OID采用物理對象標識符與邏輯對象標識符相結合的表示方法，OID結構及其索引是高效的對象訪問基礎。

實時數(shù)據(jù)庫支持不同程序對實時庫內(nèi)的同一數(shù)據(jù)集進行并發(fā)訪問。其中與實時庫的連接對應用而言是透明的，應用通過連接管理可以與分布于系統(tǒng)中任何結點的實時庫建立連接，從而實現(xiàn)了對實時庫的透明訪問。并采用先進的連接池技術對連接進行動態(tài)管理， 實現(xiàn)了實時庫連接的復用，大大降低系統(tǒng)的開銷。在實時庫服務器故障情況下，系統(tǒng)將根據(jù)連接分發(fā)策略自動重連到負載較輕的服務器；一旦本地服務器恢復可用，連接又將轉至本地，保持高的數(shù)據(jù)訪問速度。在以上技術的支撐下，單個實時庫的數(shù)據(jù)處理能力達到100萬條/s，通過分布式擴展方式，最多可支持1 000萬條/s。

另一個難題是水電數(shù)據(jù)中心需要存儲的類型包括標準化編碼后的全景模型數(shù)據(jù)、各業(yè)務系統(tǒng)抽取的結構化低頻數(shù)據(jù)(秒和分鐘級數(shù)據(jù))、業(yè)務系統(tǒng)直接轉發(fā)的結構化高頻數(shù)據(jù)(毫秒級數(shù)據(jù))、經(jīng)過統(tǒng)計分析后結果數(shù)據(jù)、視頻和文件等非結構化數(shù)據(jù)。水電數(shù)據(jù)中心綜合考慮各種數(shù)據(jù)類型的特性和數(shù)據(jù)量，設計了數(shù)據(jù)混合存儲框架，用于滿足不同業(yè)務數(shù)據(jù)的存儲要求，如圖1所示。

圖1 數(shù)據(jù)混合存儲分類圖

元數(shù)據(jù)和模型數(shù)據(jù)相對穩(wěn)定，后期數(shù)據(jù)增、刪、改等操作較少，且沒有實時更新和改寫的要求，但是對數(shù)據(jù)的可靠性要求較高，數(shù)據(jù)都是結構化類型，因此傳統(tǒng)的關系型數(shù)據(jù)庫更適合，能滿足性能和可靠性要求。

各業(yè)務系統(tǒng)抽取的生產(chǎn)數(shù)據(jù)，變化大、實時性要求高(秒級和分鐘級)，且隨著業(yè)務發(fā)生量的不斷增加而增大。用戶需要實時的對這部分數(shù)據(jù)進行交互查詢和統(tǒng)計分析，因此數(shù)據(jù)處理的響應時間需要在秒級以內(nèi)，在數(shù)據(jù)量不超過PB級別的情況下，傳統(tǒng)關系型數(shù)據(jù)庫集群就可以滿足存儲和查詢要求；但如果數(shù)據(jù)量增長到PB級以上時，關系型數(shù)據(jù)庫就有些力不從心了，需要引入大數(shù)據(jù)平臺技術來解決海量數(shù)據(jù)的存儲、查詢、統(tǒng)計和分析等工作。

特殊業(yè)務系統(tǒng)的毫秒級采樣數(shù)據(jù)結構簡單，對精度和速度的要求非常高，關系數(shù)據(jù)庫和大數(shù)據(jù)平臺無法支持如此高頻的數(shù)據(jù)插入，需引入時間序列數(shù)據(jù)庫針對性處理。時間序列數(shù)據(jù)庫省去了關系庫的復雜校驗和關聯(lián)性檢查，大大縮短了具有時間序列數(shù)據(jù)的處理時間，且通過壓縮技術降低了所需的存儲空間。

對于文件和視頻類非結構化數(shù)據(jù)，例如序列化記錄文件、報表、報告、結算單等，文件數(shù)量巨大，需要引入Redis等高速緩存數(shù)據(jù)庫來解決數(shù)據(jù)量大、實時性強的數(shù)據(jù)文件檢索功能，通過將索引信息存儲在高速緩存中，通過索引快速定位文件存儲路徑，從而達到快速獲取文件的要求。

每種數(shù)據(jù)庫都有各自的特性和適用范圍，對于水電數(shù)據(jù)中心這種數(shù)據(jù)類型復雜的系統(tǒng)，沒有哪種數(shù)據(jù)庫可以通吃，因此我們設計了混合存儲平臺，時序庫、關系庫、自研實時庫、文件服務器等組件可以通過自由組合的方式，部署所需的組件，滿足水電各類數(shù)據(jù)中心的建設要求。

2 混合數(shù)據(jù)庫存儲服務平臺的設計與實現(xiàn)

2.1 混合數(shù)據(jù)庫存儲設計與實現(xiàn)

為了屏蔽底層各種不同類型數(shù)據(jù)庫的差異，設計開發(fā)了歷史接口平臺和歷史采樣集群，以保證上層應用調(diào)用的透明性。具體如圖2所示。

圖2 混合數(shù)據(jù)庫存儲架構

歷史采樣集群采用分布式架構設計，可根據(jù)采集的數(shù)據(jù)量進行彈性擴展，每個實例負責一部分數(shù)據(jù)采樣。歷史采樣集群在自研實時庫中維護一張“測點-數(shù)據(jù)庫”映射表，自動從前置庫中同步測點模型，并可通過手動配置每個測點的采樣頻率和存儲數(shù)據(jù)庫類型。當需要存歷史的數(shù)據(jù)從彈性消息隊列獲取后，歷史采樣集群通過查詢“測點-數(shù)據(jù)庫”映射表，獲取存儲數(shù)據(jù)庫種類(時序數(shù)據(jù)庫、關系數(shù)據(jù)庫、文件服務等)，調(diào)用歷史接口平臺封裝的通用數(shù)據(jù)庫接口，進行數(shù)據(jù)的存儲。

為了保證歷史數(shù)據(jù)存儲的可靠性，歷史采樣集群在自研實時庫中建立了歷史緩沖區(qū)，用于保存插入失敗的記錄，以便在故障恢復后補錄數(shù)據(jù)，保證數(shù)據(jù)不丟失。對于數(shù)據(jù)插入失敗的情況有很多種，歷史接口平臺會對各種錯誤碼進行判斷，除數(shù)據(jù)庫連接失敗由底層歷史接口平臺直接處理外，其他都將反饋給歷史采樣集群，歷史采樣服務判斷錯誤碼，將失敗的記錄存入歷史緩沖區(qū)。歷史采樣集群有一個專用線程，用于負責判斷對應數(shù)據(jù)庫服務是否恢復，并嘗試補錄數(shù)據(jù)，補錄成功的記錄將從歷史緩沖區(qū)清除，當歷史緩沖區(qū)滿時，將采用覆蓋最早記錄的方式寫入。

歷史接口平臺采用插件化和動態(tài)加載方式運行，針對時序數(shù)據(jù)庫、關系數(shù)據(jù)庫、文件服務器等不同種類的存儲服務，定義一套統(tǒng)一的對外接口，歷史采集服務就是根據(jù)配置信息，調(diào)用對應存儲服務的對外接口，不需要關心該存儲服務下加載的具體數(shù)據(jù)庫類型，底層差異性都將由歷史接口平臺來屏蔽。

歷史接口平臺針對每種具體數(shù)據(jù)庫類型，都開發(fā)一個數(shù)據(jù)庫插件，繼承統(tǒng)一的對外服務接口類，在插件內(nèi)部處理數(shù)據(jù)類型、SQL語句、內(nèi)置函數(shù)、錯誤碼和元數(shù)據(jù)等的差異性。以關系數(shù)據(jù)庫為例，數(shù)據(jù)中心內(nèi)部定義了18種數(shù)據(jù)結構，每種關系數(shù)據(jù)庫類型都需定義18種數(shù)據(jù)結構的映射關系，上層應用直接存儲和獲取數(shù)據(jù)中心定義結構，不需要關心底層關系庫數(shù)據(jù)存儲類型轉換，轉換工作都在接口插件中完成。另外，為了方便獨立監(jiān)視等應用查詢和統(tǒng)計關系數(shù)據(jù)庫性能指標，在每類關系數(shù)據(jù)庫中創(chuàng)建類似Oracle的元數(shù)據(jù)視圖，簡化應用程序開發(fā)。

2.2 混合數(shù)據(jù)庫對外服務設計與實現(xiàn)

一體化水電數(shù)據(jù)中心不僅要解決混合數(shù)據(jù)庫存儲問題，還要對第三方應用提供透明化的數(shù)據(jù)服務。在IEC61850全景模型的基礎上，設計開發(fā)了Rest風格的微服務化的統(tǒng)一數(shù)據(jù)服務平臺。每一個數(shù)據(jù)服務都基于Rest風格的SpringBoot架構開發(fā)，數(shù)據(jù)交互采用標準的Json格式，同時結合了基于Oauth2技術的權限校驗模塊，對訪問歷史數(shù)據(jù)的微服務用戶權限進行控制。統(tǒng)一數(shù)據(jù)服務平臺整體架構如圖3所示。

圖3 統(tǒng)一數(shù)據(jù)服務平臺架構

根據(jù)上層應用的開發(fā)需求，抽象和剝離出高復用的數(shù)據(jù)微服務：實時數(shù)據(jù)微服務、智能預警數(shù)據(jù)微服務、模型數(shù)據(jù)微服務、設備巡檢微服務、文件數(shù)據(jù)微服務和權限微服務等，按照統(tǒng)一的接口規(guī)范，給第三方應用提供數(shù)據(jù)接口支撐。所有類型的數(shù)據(jù)微服務，都會在統(tǒng)一數(shù)據(jù)服務總線和網(wǎng)關上進行注冊，應用在發(fā)起數(shù)據(jù)請求時，微服務網(wǎng)關首先根據(jù)應用的鑒權信息調(diào)用權限微服務進行權限鑒定，權限鑒定通過后，按照負載均衡策略，將請求路由到注冊在總線上的指定數(shù)據(jù)微服務，該微服務處理請求后返回Json格式的結果數(shù)據(jù)。

每個數(shù)據(jù)微服務以統(tǒng)一編碼為唯一關鍵字，對外提供實時和歷史數(shù)據(jù)的查詢和訂閱功能。微服務內(nèi)部接收到請求后，根據(jù)編碼信息查詢“測點-數(shù)據(jù)庫”映射表，獲取測點存儲數(shù)據(jù)庫類型，再將編碼、數(shù)據(jù)庫類型、數(shù)據(jù)服務類型等關鍵信息發(fā)送給對應的后端處理進程，后端進程根據(jù)需求執(zhí)行相關操作后，將結果封裝成標準Json格式，返回給前端微服務，由微服務將Json返還給對應的第三方應用。

數(shù)據(jù)微服務支持多層次、不同粒度、面向應用的復合數(shù)據(jù)服務，包含請求/響應、訂閱/發(fā)布兩種服務形式。請求/響應模式，平臺提供基于Rest風格的Springboot微服務接口，由上層應用按照接口調(diào)用規(guī)范文檔，主動調(diào)用該數(shù)據(jù)服務接口，接口會返回對應的Json格式的結果數(shù)據(jù)。對于實時性要求較高的實時類、準實時類數(shù)據(jù)，則需要通過訂閱/發(fā)布的數(shù)據(jù)交互模型，將數(shù)據(jù)推送給應用。首先，各類型的數(shù)據(jù)微服務，將實時測點采集數(shù)據(jù)、告警數(shù)據(jù)等，通過數(shù)據(jù)發(fā)布接口，將數(shù)據(jù)實時發(fā)布至分布式數(shù)據(jù)總線，然后各應用程序按需訂閱，訂閱的數(shù)據(jù)會被實時推送至應用端，同時滿足數(shù)據(jù)的實時和準實時的時效要求。

3 混合數(shù)據(jù)庫存儲服務平臺實驗驗證

水電站機房和信息化規(guī)模有限，三區(qū)若采用大數(shù)據(jù)平臺，也只能配置4-8臺服務器的小型集群。本實驗搭建了2套環(huán)境進行對比：第1套為混合存儲平臺，采用2臺物理服務器+2臺虛擬機的模式，物理服務器配置為2顆共64核Intel CPU，主頻為2.5 GHz，256 G內(nèi)存；虛擬機為12虛核，128 G內(nèi)存?；旌洗鎯ζ脚_部署了Oracle RAC關系數(shù)據(jù)庫、毫秒級時序庫和文件服務器。第2套為4臺物理服務器的Hadoop大數(shù)據(jù)平臺，每臺服務器為2顆共64核Intel CPU，主頻為2.5 GHz，256 G內(nèi)存。真實的實驗環(huán)境導入了1年的歷史數(shù)據(jù)，目前分鐘級采樣點為102 669個，秒級采樣點為73 381個，毫秒級采樣點為5 306個，數(shù)據(jù)記錄每條固定為40字節(jié)。

以每次寫入5 000條記錄為例，混合存儲服務平臺最高支持每秒50次的采樣存儲，而大數(shù)據(jù)平臺在每秒10次采樣時，會偶爾出現(xiàn)寫出失敗情況，具體記錄如表1所示。

表1 數(shù)據(jù)寫入實驗對照表

數(shù)據(jù)查詢方面，從兩個維度進行比較，并采用兩種大數(shù)據(jù)平臺SQL引擎，全面反映大數(shù)據(jù)平臺性能。第一個維度是多表級聯(lián)查詢，每張表記錄條數(shù)都在200萬及以上，當進行8張表級聯(lián)查詢時，混合存儲服務平臺優(yōu)勢明顯，在1 s以內(nèi)返回，但大數(shù)據(jù)平臺最快的Impala也需要3 s多；第二個維度是統(tǒng)計記錄數(shù)，在1 000萬條記錄以內(nèi)時，混合存儲服務平臺有一定的優(yōu)勢，而當統(tǒng)計記錄超過1 000萬條后，混合存儲服務平臺性能下降明顯，而大數(shù)據(jù)平臺整體都比較穩(wěn)定，這個跟大數(shù)據(jù)平臺數(shù)據(jù)都加載入內(nèi)存的機制有關。具體如表2、表3所示。

表2 多表級聯(lián)實驗數(shù)據(jù)對照表

表3 統(tǒng)計數(shù)據(jù)實驗數(shù)據(jù)對照表

上述實驗充分證明了在大型水電站數(shù)據(jù)中心系統(tǒng)中，當存儲服務器規(guī)模小于10臺，采集數(shù)據(jù)量在30萬點以內(nèi)時，混合存儲服務平臺是有性能和經(jīng)濟優(yōu)勢的，具備應用推廣前景，主要體現(xiàn)在：

首先，混合存儲服務平臺最小化部署只需要2臺物理服務器和2臺虛擬機，在大型水電站數(shù)據(jù)中心這類應用場景下，性能可與6-10臺物理服務器組成的大數(shù)據(jù)平臺媲美。不僅節(jié)約了硬件成本，也節(jié)省了數(shù)據(jù)中心機房的空間，貼合水電站信息化機房空間有限的實際情況。

其次，大數(shù)據(jù)平臺組件多、運維復雜，需要配置專業(yè)的運維團隊進行日常管理，這對于水電站這種生產(chǎn)單位不太現(xiàn)實?；旌洗鎯Ψ掌脚_將時序數(shù)據(jù)庫、關系數(shù)據(jù)庫和文件服務器的狀態(tài)監(jiān)視集成到統(tǒng)一的運維監(jiān)視界面上，服務故障會發(fā)出告警，只需針對特定的模塊進行排查診斷，底層模塊間耦合度低，不需要關聯(lián)修復。

再次，不同的大數(shù)據(jù)平臺選配組件不同，無法做到接口兼容，對于上層應用開發(fā)者需要重新適配，增加了第三方廠家的開發(fā)難度。混合存儲服務平臺屏蔽了底層不同類型數(shù)據(jù)庫的差異性，不管是Oracle、Mysql，還是國產(chǎn)數(shù)據(jù)庫達夢、金倉，對應用提供的都是同一套接口，數(shù)據(jù)庫的更換通過配置和動態(tài)加載技術實現(xiàn)，應用完全透明，只需維護一套代碼。

4 小結

本文結合大型水電站數(shù)據(jù)中心的應用背景，提出了基于混合數(shù)據(jù)庫的水電數(shù)據(jù)中心存儲服務平臺架構，并闡述了詳細的設計框架和實驗驗證。本文主要做了以下幾方面工作。

（1）給出了混合數(shù)據(jù)庫存儲服務平臺中，各類數(shù)據(jù)的存儲原則，并對核心模塊自研實時庫的功能進行詳細描述；

（2）結合混合數(shù)據(jù)庫存儲架構圖，詳細介紹了混合數(shù)據(jù)庫存儲服務平臺中數(shù)據(jù)存儲的原理和特點，實現(xiàn)應用層透明訪問；

（3）結合統(tǒng)一數(shù)據(jù)服務平臺架構圖，給出了混合數(shù)據(jù)庫存儲服務平臺中數(shù)據(jù)對外服務的原理和特點，高度微服務化，在提供數(shù)據(jù)訪問便利的同時，進行權限鑒定，加強安全管控；

（4）結合實驗驗證數(shù)據(jù)，分析了混合數(shù)據(jù)庫存儲服務平臺的性能和經(jīng)濟優(yōu)勢，解決了水電站數(shù)據(jù)中心系統(tǒng)數(shù)據(jù)存儲和對外服務的難題；

（5）設計并實現(xiàn)了原型系統(tǒng)，并應用到實際的項目中，提升了數(shù)據(jù)中心系統(tǒng)的核心競爭力。

混合數(shù)據(jù)庫存儲服務平臺得到了初步的實現(xiàn)和應用，已部署于多個水電站數(shù)據(jù)中心系統(tǒng)，該平臺還在不斷的優(yōu)化和演進。但毋庸置疑的是，混合數(shù)據(jù)庫存儲服務平臺架構是適應當前大型水電站數(shù)據(jù)中心系統(tǒng)需要的，它在機房和硬件資源受限的情況下發(fā)揮巨大的性能優(yōu)勢，保證了上層應用便捷交互和高效運行，也為系統(tǒng)今后的擴容提供了更好的支持。