邊麗娟，韓 兵，李金陽

(國電南京自動化股份有限公司，江蘇 南京 210003)

0 前 言

水電站計算機監(jiān)控系統(tǒng)在電站自動化控制中發(fā)揮著非常重要的作用，其監(jiān)控數(shù)據(jù)為電站的運行分析、趨勢判斷和事故處理提供了有力手段。傳統(tǒng)的監(jiān)控數(shù)據(jù)的存儲一般采用MySQL等關(guān)系型數(shù)據(jù)庫，監(jiān)控數(shù)據(jù)具有數(shù)據(jù)采集頻次高，依照時間序列排序等特點，大量使用關(guān)系型數(shù)據(jù)庫存儲時會帶來諸多問題[1]。

(1)存儲成本大，寫入吞吐低。洪家渡水電站大約有1萬個測點，如果每秒采集一次，一天占用大約10～20 GB的磁盤存儲空間，而對于大型水電站，則遠不止1萬個測點。普通磁盤陣列的容量很難滿足上述海量數(shù)據(jù)的存儲需求，且關(guān)系庫對于時序數(shù)據(jù)壓縮不佳，隨著時間的推移會造成存儲成本的不斷提升。海量數(shù)據(jù)在寫入關(guān)系數(shù)據(jù)庫時耗費時間較長，很難滿足時序數(shù)據(jù)千萬級的寫入需求。

(2)查詢性能差。為了提高關(guān)系型數(shù)據(jù)庫使用效率，一般采用分庫分表、優(yōu)化索引等技術(shù)，但隨著存儲空間的不斷增長，其查詢效率也會不斷降低，難以在秒級甚至毫秒級獲取所需要的數(shù)據(jù)[2]。同時，分表策略會增加查詢業(yè)務(wù)的復(fù)雜性，如果按月分表，那么查詢跨月數(shù)據(jù)需要通過多條SQL或聯(lián)合查詢才能獲得所需結(jié)果。

針對水電廠監(jiān)控系統(tǒng)中存儲的數(shù)據(jù)大部分是時序數(shù)據(jù)的特點，本文提出了一種新的時序庫BonitaDB，并實現(xiàn)了基于BonitaDB時序庫存儲的水電站計算機監(jiān)控系統(tǒng)。實踐表明，相比于關(guān)系型數(shù)據(jù)庫，BonitaDB在存儲數(shù)據(jù)和查詢方面，尤其是聚合查詢方面具有明顯的性能優(yōu)勢。

1 計算機監(jiān)控系統(tǒng)總體結(jié)構(gòu)

洪家渡水電站位于貴州西北部黔西、織金兩縣交界處的烏江干流上，是烏江水電基地11個梯級電站中唯一對水量具有多年調(diào)節(jié)能力的“龍頭”電站。電站安裝3臺立軸混流式水輪發(fā)電機組，裝機總?cè)萘?0萬kW。為了保證水電站健康安全運行，需要實時監(jiān)測電站運行情況，國電南自自主研發(fā)了SD8000C水電站監(jiān)控系統(tǒng)(系統(tǒng)軟件架構(gòu)見圖1)，底層主要基于中標(biāo)麒麟等國產(chǎn)化操作系統(tǒng)，數(shù)據(jù)庫層包括自主研發(fā)的時序數(shù)據(jù)庫以及實時數(shù)據(jù)庫，接口層包括歷史數(shù)據(jù)庫查詢接口、圖形界面應(yīng)用接口、SCADA系統(tǒng)應(yīng)用接口以及第三方接口中間件，數(shù)據(jù)處理層部分包括數(shù)據(jù)處理、數(shù)據(jù)存儲、數(shù)據(jù)監(jiān)視、數(shù)據(jù)報警、數(shù)據(jù)統(tǒng)計、數(shù)據(jù)傳輸?shù)饶K，上位機監(jiān)控系統(tǒng)軟件系統(tǒng)包括人機界面、一覽表、順控流程、歷史庫、報表、光字牌等模塊，高級應(yīng)用部分主要包括AGC/AVC、智能報警、數(shù)據(jù)挖掘等模塊。各層之間相互關(guān)聯(lián)、相互支撐，從而構(gòu)成功能強大、性能穩(wěn)定的水電站監(jiān)控系統(tǒng)軟件[3]。

圖1 SD8000C計算機監(jiān)控系統(tǒng)軟件架構(gòu)

2 基于時序庫監(jiān)控數(shù)據(jù)存儲系統(tǒng)

2.1 時序庫數(shù)據(jù)存儲系統(tǒng)

洪家渡水電站計算機監(jiān)控系統(tǒng)采用BonitaDB作為時序庫存儲引擎，BonitaDB是作為 PostgreSQL 的擴展實現(xiàn)的?；谠赟QL標(biāo)準(zhǔn)上增加一些針對時序數(shù)據(jù)的優(yōu)化UDF，也可以很方便地在SQL關(guān)系代數(shù)的基礎(chǔ)上處理時序數(shù)據(jù)。監(jiān)控系統(tǒng)數(shù)據(jù)應(yīng)用服務(wù)主要包括實時數(shù)據(jù)服務(wù)、歷史數(shù)據(jù)服務(wù)、故障診斷預(yù)警服務(wù)、設(shè)備管理服務(wù)等。其中，實時、歷史數(shù)據(jù)由時序庫提供數(shù)據(jù)支持，通過C程序?qū)⒈O(jiān)控數(shù)據(jù)發(fā)送給時序庫存儲。

2.2 時序庫數(shù)據(jù)模型

BonitaDB支持靈活的數(shù)據(jù)模型，可以同時支持寬表和窄表模型，能夠針對不同的用例進行優(yōu)化。

在NoSQL時序數(shù)據(jù)庫中，數(shù)據(jù)模型通常如圖2所示，即一條數(shù)據(jù)中既包括了時間戳以及采集的數(shù)據(jù)，還包括設(shè)備的元數(shù)據(jù)(通常以Tagset體現(xiàn))。

圖2 NoSQL時序庫數(shù)據(jù)模型

在BonitaDB中，數(shù)據(jù)模型必須以1個二維表的形式呈現(xiàn)，洪家渡水電站監(jiān)控數(shù)據(jù)的二維表大致分為以下3種(見表1～3)：

表1 項目配置project_cfg

表2 測點配置point_cfg

表3 時序數(shù)據(jù)htsdb_data_${point_cfg.vtype}

2.3 BonitaDB的特性

時序數(shù)據(jù)庫的數(shù)據(jù)通常每秒記錄一次，這導(dǎo)致數(shù)據(jù)增長很快。而對于PostgreSQL來說，由于大量地使用B+tree索引，當(dāng)數(shù)據(jù)量到達一定量級后其寫入性能就會出現(xiàn)明顯的下降。而BonitaDB最核心的自動分區(qū)chunk完美地解決了這個問題。圖3展示了BonitaDB的自動分區(qū)機制，用戶創(chuàng)建一張普通的時序表后，隨著不斷地寫入數(shù)據(jù)，以時序數(shù)據(jù)的時間戳為分區(qū)鍵自動分區(qū)，將時序數(shù)據(jù)表的數(shù)據(jù)分區(qū)存放，保證每一個分區(qū)的索引維持在一個較小規(guī)模，從而維持住寫入性能。每次創(chuàng)建新的chunk時會計算這個chunk預(yù)計覆蓋的時間戳范圍(默認是1 d)。并且考慮到不同應(yīng)用場景下時序數(shù)據(jù)寫入速度及密度都不相同，當(dāng)創(chuàng)建新chunk時，新chunk的時間戳范圍會經(jīng)過自適應(yīng)算法進行計算，逐漸計算出應(yīng)用場景下最適合的時間戳范圍。查詢時也可以快速定位到所需的數(shù)據(jù)分區(qū)，保證查詢性能。因此，雖然BonitaDB的索引數(shù)據(jù)和表數(shù)據(jù)的存儲都是沿用的PostgreSQL的存儲機制，但上述自動分區(qū)特性完美解決了海量數(shù)據(jù)插入后表和索引增大的問題[4]。

圖3 BonitaDB的自動分區(qū)機制概要

2.4 BonitaDB壓縮機制

BonitaDB的壓縮可以節(jié)省91%～96%的存儲空間，極大節(jié)省了硬盤空間[5]。BonitaDB 的低級存儲使用 PostgreSQL 的面向行的存儲格式，數(shù)據(jù)經(jīng)過壓縮后轉(zhuǎn)變成列式存儲。構(gòu)建列式存儲的方法是每列都存儲了一組有序數(shù)據(jù)，將這些數(shù)據(jù)轉(zhuǎn)換為單行“數(shù)組”形式的數(shù)據(jù)。然后針對其數(shù)據(jù)類型，使用特定壓縮算法對每個數(shù)組進行單獨壓縮。目前主要采用以下算法——floats：Gorilla壓縮算法；timestamps和integer：Delta-of-delta壓縮算法和run-length encoding 壓縮算法；重復(fù)值很少的列:基于字典的LZ壓縮算法；其他類型：LZ-based array壓縮算法。

在壓縮過程中，需要指定“order by”列和可選的“segment by”列，對于每個“order by”列，指定需壓縮行的排序方式，BonitaDB會自動創(chuàng)建額外的列來存儲該列的最小值和最大值，并且可以按特定列“segment by”列分割壓縮行，以便每個壓縮行對應(yīng)某單個主鍵的數(shù)據(jù)，洪家渡水電站計算機監(jiān)控系統(tǒng)中的時序表的“segment by”列是id列。這種機制能夠確保只讀取指定的壓縮列，明顯提高了查詢的性能。

2.5 BonitaDB性能對比結(jié)果與分析

選取關(guān)系型數(shù)據(jù)庫MySQL和時序數(shù)據(jù)庫BonitaDB，對時序數(shù)據(jù)的寫入和讀取速度以及相同數(shù)據(jù)量下占用的存儲空間進行對比。測試時，每次插入數(shù)據(jù)量統(tǒng)一為5 000，使用上文提及的時序數(shù)據(jù)表結(jié)構(gòu)，并在id和time上建立索引，查詢采用查詢同一時間段內(nèi)的均值。測試環(huán)境為：銀河麒麟V10，HUAWEI，Kunpeng 920，內(nèi)存256 GB。測試結(jié)果如表4所示。

表4 BonitaDB與MySQL，PostgreSQL性能比較

測試結(jié)果表明，針對時序數(shù)據(jù)來說，BonitaDB數(shù)據(jù)庫在磁盤占用和數(shù)據(jù)讀取方面優(yōu)勢明顯，而且隨著數(shù)據(jù)規(guī)模的擴大，查詢速度沒有明顯的下降。雖然BonitaDB與PostgreSQL具有相同的存儲機制，但BonitaDB的壓縮機制使得它的磁盤空間占用約為 PostgreSQL的6%，因此使用BonitaDB作為系統(tǒng)的數(shù)據(jù)存儲工具，能夠滿足水電站計算機監(jiān)控系統(tǒng)中對海量數(shù)據(jù)存儲的需求，保證系統(tǒng)的實時穩(wěn)定性。

3 基于時序庫的數(shù)據(jù)服務(wù)

洪家渡水電站監(jiān)控系統(tǒng)的時序庫主要用于曲線查詢、報表查詢等服務(wù)，根據(jù)相關(guān)的查詢請求到時序庫中查詢相應(yīng)的數(shù)據(jù)，生成相應(yīng)的結(jié)果集返回。

3.1 報表查詢

主要開發(fā)了時序數(shù)據(jù)采樣、輸出可選間隔時序數(shù)據(jù)的平均值、最大值、最小值、均值、越復(fù)限統(tǒng)計等功能，通過配置界面配置所需要的測點統(tǒng)計功能。

前端頁面能夠展示所需要的統(tǒng)計值，BonitaDB提供的聚合查詢函數(shù)完全能夠滿足水電站監(jiān)控系統(tǒng)的所需要的統(tǒng)計功能，并且請求時間均在1 s內(nèi)。

3.2 曲線查詢

系統(tǒng)可由時間序列數(shù)據(jù)庫提供任意歷史時間段的實時數(shù)據(jù)，供電站人員查詢實時曲線，最多可同時查詢12個測點的曲線，以便進行分析比較。

4 結(jié) 語

根據(jù)水電站監(jiān)控系統(tǒng)海量數(shù)據(jù)分析的需求，文章分析了時序數(shù)據(jù)庫在監(jiān)控系統(tǒng)中作為數(shù)據(jù)存儲平臺的可行性，并以時序數(shù)據(jù)庫BonitaDB為數(shù)據(jù)存儲引擎，構(gòu)建了一套時序庫監(jiān)控系統(tǒng)，實現(xiàn)了水電站監(jiān)控系統(tǒng)數(shù)據(jù)的存儲、實時數(shù)據(jù)采樣，統(tǒng)計值查詢等基本功能。該系統(tǒng)已經(jīng)在洪家渡水電站投入實際運用，運行效果良好，為水電站的長期穩(wěn)定運行提供了有效的支撐。