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

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

0 引言

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

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

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

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

1 基于混合數(shù)據(jù)庫(kù)的數(shù)據(jù)中心存儲(chǔ)服務(wù)平臺(tái)

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

面對(duì)海量數(shù)據(jù)難題，采用自研實(shí)時(shí)數(shù)據(jù)庫(kù)作為前端采集和后端存儲(chǔ)的緩沖池，從而使得前后端異步存儲(chǔ)，相互獨(dú)立。實(shí)時(shí)數(shù)據(jù)庫(kù)采用面向?qū)ο蟮臄?shù)據(jù)模型，支持類之間的繼承、聚集關(guān)系以及對(duì)象標(biāo)識(shí)等面向?qū)ο蟮奶匦裕軌驑?gòu)造復(fù)雜的結(jié)構(gòu)模型，支持用戶自定義數(shù)據(jù)類型和方法。面向?qū)ο蟮臄?shù)據(jù)模型，不僅易于描述水電相關(guān)系統(tǒng)及其拓?fù)潢P(guān)系，更能直接定義類結(jié)構(gòu)，不需要任何映射和模型轉(zhuǎn)換，是最容易接納標(biāo)準(zhǔn)，并適應(yīng)其版本變化的數(shù)據(jù)模型。在面向?qū)ο髷?shù)據(jù)模型中，每個(gè)對(duì)象都有一個(gè)在系統(tǒng)內(nèi)唯一不變的標(biāo)識(shí)符，稱為對(duì)象標(biāo)識(shí)符，簡(jiǎn)稱OID。OID的生成和管理既是面向?qū)ο髷?shù)據(jù)庫(kù)不可缺少的重要組成部分，也是開放系統(tǒng)中數(shù)據(jù)交換的需要。實(shí)時(shí)數(shù)據(jù)庫(kù)的OID采用物理對(duì)象標(biāo)識(shí)符與邏輯對(duì)象標(biāo)識(shí)符相結(jié)合的表示方法，OID結(jié)構(gòu)及其索引是高效的對(duì)象訪問(wèn)基礎(chǔ)。

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

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

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

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

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

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

對(duì)于文件和視頻類非結(jié)構(gòu)化數(shù)據(jù)，例如序列化記錄文件、報(bào)表、報(bào)告、結(jié)算單等，文件數(shù)量巨大，需要引入Redis等高速緩存數(shù)據(jù)庫(kù)來(lái)解決數(shù)據(jù)量大、實(shí)時(shí)性強(qiáng)的數(shù)據(jù)文件檢索功能，通過(guò)將索引信息存儲(chǔ)在高速緩存中，通過(guò)索引快速定位文件存儲(chǔ)路徑，從而達(dá)到快速獲取文件的要求。

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

2 混合數(shù)據(jù)庫(kù)存儲(chǔ)服務(wù)平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)

2.1 混合數(shù)據(jù)庫(kù)存儲(chǔ)設(shè)計(jì)與實(shí)現(xiàn)

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

圖2 混合數(shù)據(jù)庫(kù)存儲(chǔ)架構(gòu)

歷史采樣集群采用分布式架構(gòu)設(shè)計(jì)，可根據(jù)采集的數(shù)據(jù)量進(jìn)行彈性擴(kuò)展，每個(gè)實(shí)例負(fù)責(zé)一部分?jǐn)?shù)據(jù)采樣。歷史采樣集群在自研實(shí)時(shí)庫(kù)中維護(hù)一張“測(cè)點(diǎn)-數(shù)據(jù)庫(kù)”映射表，自動(dòng)從前置庫(kù)中同步測(cè)點(diǎn)模型，并可通過(guò)手動(dòng)配置每個(gè)測(cè)點(diǎn)的采樣頻率和存儲(chǔ)數(shù)據(jù)庫(kù)類型。當(dāng)需要存歷史的數(shù)據(jù)從彈性消息隊(duì)列獲取后，歷史采樣集群通過(guò)查詢“測(cè)點(diǎn)-數(shù)據(jù)庫(kù)”映射表，獲取存儲(chǔ)數(shù)據(jù)庫(kù)種類(時(shí)序數(shù)據(jù)庫(kù)、關(guān)系數(shù)據(jù)庫(kù)、文件服務(wù)等)，調(diào)用歷史接口平臺(tái)封裝的通用數(shù)據(jù)庫(kù)接口，進(jìn)行數(shù)據(jù)的存儲(chǔ)。

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

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

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

2.2 混合數(shù)據(jù)庫(kù)對(duì)外服務(wù)設(shè)計(jì)與實(shí)現(xiàn)

一體化水電數(shù)據(jù)中心不僅要解決混合數(shù)據(jù)庫(kù)存儲(chǔ)問(wèn)題，還要對(duì)第三方應(yīng)用提供透明化的數(shù)據(jù)服務(wù)。在IEC61850全景模型的基礎(chǔ)上，設(shè)計(jì)開發(fā)了Rest風(fēng)格的微服務(wù)化的統(tǒng)一數(shù)據(jù)服務(wù)平臺(tái)。每一個(gè)數(shù)據(jù)服務(wù)都基于Rest風(fēng)格的SpringBoot架構(gòu)開發(fā)，數(shù)據(jù)交互采用標(biāo)準(zhǔn)的Json格式，同時(shí)結(jié)合了基于Oauth2技術(shù)的權(quán)限校驗(yàn)?zāi)K，對(duì)訪問(wèn)歷史數(shù)據(jù)的微服務(wù)用戶權(quán)限進(jìn)行控制。統(tǒng)一數(shù)據(jù)服務(wù)平臺(tái)整體架構(gòu)如圖3所示。

圖3 統(tǒng)一數(shù)據(jù)服務(wù)平臺(tái)架構(gòu)

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

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

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

3 混合數(shù)據(jù)庫(kù)存儲(chǔ)服務(wù)平臺(tái)實(shí)驗(yàn)驗(yàn)證

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

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

表1 數(shù)據(jù)寫入實(shí)驗(yàn)對(duì)照表

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

表2 多表級(jí)聯(lián)實(shí)驗(yàn)數(shù)據(jù)對(duì)照表

表3 統(tǒng)計(jì)數(shù)據(jù)實(shí)驗(yàn)數(shù)據(jù)對(duì)照表

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

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

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

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

4 小結(jié)

本文結(jié)合大型水電站數(shù)據(jù)中心的應(yīng)用背景，提出了基于混合數(shù)據(jù)庫(kù)的水電數(shù)據(jù)中心存儲(chǔ)服務(wù)平臺(tái)架構(gòu)，并闡述了詳細(xì)的設(shè)計(jì)框架和實(shí)驗(yàn)驗(yàn)證。本文主要做了以下幾方面工作。

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

（2）結(jié)合混合數(shù)據(jù)庫(kù)存儲(chǔ)架構(gòu)圖，詳細(xì)介紹了混合數(shù)據(jù)庫(kù)存儲(chǔ)服務(wù)平臺(tái)中數(shù)據(jù)存儲(chǔ)的原理和特點(diǎn)，實(shí)現(xiàn)應(yīng)用層透明訪問(wèn)；

（3）結(jié)合統(tǒng)一數(shù)據(jù)服務(wù)平臺(tái)架構(gòu)圖，給出了混合數(shù)據(jù)庫(kù)存儲(chǔ)服務(wù)平臺(tái)中數(shù)據(jù)對(duì)外服務(wù)的原理和特點(diǎn)，高度微服務(wù)化，在提供數(shù)據(jù)訪問(wèn)便利的同時(shí)，進(jìn)行權(quán)限鑒定，加強(qiáng)安全管控；

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

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

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