基于混合數據庫的水電數據中心存儲平臺研究

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

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

0 引言

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

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

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

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

1 基于混合數據庫的數據中心存儲服務平臺

一體化水電數據中心需要整合水電站所有子業務系統，將會面對海量數據和各種數據類型兩大難題。

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

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

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

圖1 數據混合存儲分類圖

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

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

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

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

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

2 混合數據庫存儲服務平臺的設計與實現

2.1 混合數據庫存儲設計與實現

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

圖2 混合數據庫存儲架構

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

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

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

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

2.2 混合數據庫對外服務設計與實現

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

圖3 統一數據服務平臺架構

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

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

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

3 混合數據庫存儲服務平臺實驗驗證

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

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

表1 數據寫入實驗對照表

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

表2 多表級聯實驗數據對照表

表3 統計數據實驗數據對照表

上述實驗充分證明了在大型水電站數據中心系統中，當存儲服務器規模小于10臺，采集數據量在30萬點以內時，混合存儲服務平臺是有性能和經濟優勢的，具備應用推廣前景，主要體現在：

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

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

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

4 小結

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

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

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

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

（4）結合實驗驗證數據，分析了混合數據庫存儲服務平臺的性能和經濟優勢，解決了水電站數據中心系統數據存儲和對外服務的難題；

（5）設計并實現了原型系統，并應用到實際的項目中，提升了數據中心系統的核心競爭力。

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