電力設(shè)備狀態(tài)高速采樣數(shù)據(jù)的云存儲技術(shù)研究

宋亞奇，劉樹仁，朱永利，2，王德文，李 莉

（1.華北電力大學(xué) 控制與計(jì)算機(jī)工程學(xué)院，河北 保定 071003；2.華北電力大學(xué) 新能源電力系統(tǒng)國家重點(diǎn)實(shí)驗(yàn)室，北京 102206）

0 引言

智能電網(wǎng)的安全可靠，離不開對組成電網(wǎng)的設(shè)備的健康狀況進(jìn)行在線監(jiān)測、數(shù)據(jù)搜集和評估。智能電網(wǎng)需要監(jiān)測的設(shè)備眾多，甚至包括線路的每串絕緣子的泄漏電流等動態(tài)信號。為了能對絕緣子放電等狀態(tài)進(jìn)行診斷，信號的采樣頻率必須在200 kHz以上。變電站內(nèi)設(shè)備狀態(tài)監(jiān)測，要求數(shù)據(jù)采樣率可達(dá)MHz級，變壓器超高頻局部放電信號的頻率均在300 MHz以上，甚至超過1 GHz。因此，采集的數(shù)據(jù)量非常巨大[1]。

目前，受存儲容量以及網(wǎng)絡(luò)帶寬等限制，對電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)的處理方式大多采用就地計(jì)算的方式，原始采樣數(shù)據(jù)經(jīng)過分析后，表征設(shè)備狀態(tài)的相關(guān)數(shù)據(jù)接入到狀態(tài)監(jiān)測系統(tǒng)中，原始采樣數(shù)據(jù)并未保存，這種就地處理的方式會導(dǎo)致如放電波形等重要信息丟失，影響電力設(shè)備狀態(tài)評估的準(zhǔn)確率。例如，在利用變壓器局部放電信號進(jìn)行故障診斷和狀態(tài)評估時(shí)，已有方法大都利用波形宏觀特征（熟數(shù)據(jù)）進(jìn)行評估，而非常重要的放電過程波形（微觀特征）被丟棄，影響診斷或評估的結(jié)果準(zhǔn)確率。伴隨設(shè)備硬件（存儲容量和網(wǎng)絡(luò)帶寬）的改善，采集、傳輸并保存完整電力設(shè)備狀態(tài)高速采樣數(shù)據(jù)成為可能，因此，有必要研究電力設(shè)備狀態(tài)高速采樣數(shù)據(jù)的高效存儲方法，為下一代數(shù)據(jù)中心存儲電網(wǎng)設(shè)備的動態(tài)信號提供理論支持和技術(shù)儲備。

常規(guī)的數(shù)據(jù)存儲與管理方法，基礎(chǔ)架構(gòu)大多采用價(jià)格昂貴的大型服務(wù)器，存儲硬件采用磁盤陣列，數(shù)據(jù)庫管理軟件采用關(guān)系數(shù)據(jù)庫，緊密耦合類業(yè)務(wù)應(yīng)用采用套裝軟件，因此系統(tǒng)擴(kuò)展性較差、成本較高。傳統(tǒng)的超級計(jì)算機(jī)[2-3]主要用于“計(jì)算密集型”的應(yīng)用，如量子力學(xué)、天氣預(yù)報(bào)等。超級計(jì)算機(jī)擁有多個處理器，通過精良的設(shè)計(jì)，達(dá)到高度并行的目的，實(shí)現(xiàn)快速計(jì)算，但是其計(jì)算需要的數(shù)據(jù)通常采用磁盤陣列進(jìn)行集中式存儲（RAID）。在 Yahoo！ 集群[4]上的性能測試表明，Hadoop分布式文件系統(tǒng)（HDFS）讀寫吞吐量在Girdmix測試中顯示比RAID快 30%[5]。另外，超級計(jì)算機(jī)交互性較差，所采用并行編程方法（MPI等）也難以掌握，對用戶要求很高[6]；系統(tǒng)的擴(kuò)展性差，且成本高，不適用于智能電網(wǎng)環(huán)境下信息平臺的建設(shè)。

云計(jì)算是分布式計(jì)算、并行計(jì)算和網(wǎng)格計(jì)算發(fā)展的結(jié)果，目前主要應(yīng)用于“數(shù)據(jù)密集型”應(yīng)用[7]，通過虛擬技術(shù)、海量分布式數(shù)據(jù)存儲技術(shù)、MapReduce并行編程模型等技術(shù)，為用戶提供高可靠性、高安全性的海量數(shù)據(jù)存儲平臺，這為智能電網(wǎng)信息平臺的建設(shè)提供了全新的解決思路。

本文提出使用面向列的數(shù)據(jù)庫HBase在開源的云計(jì)算平臺Hadoop集群上實(shí)現(xiàn)海量電力設(shè)備狀態(tài)高速采樣數(shù)據(jù)的云存儲方案，是采用云計(jì)算技術(shù)搭建智能電網(wǎng)信息平臺的一次有益嘗試。使用TestDFSIO和YCSB對集群整體輸入、輸出性能以及讀取、插入、數(shù)據(jù)更新進(jìn)行了性能測試，實(shí)驗(yàn)結(jié)果表明，Hadoop和HBase在存儲容量、吞吐量以及查詢延遲上提供了足夠高的性能，能夠滿足智能電網(wǎng)環(huán)境下電力設(shè)備狀態(tài)高速采樣數(shù)據(jù)可靠性及實(shí)時(shí)性要求。

1 相關(guān)工作

1.1 采樣數(shù)據(jù)存儲

電力設(shè)備狀態(tài)高速采樣數(shù)據(jù)是一種典型的時(shí)間序列數(shù)據(jù)。已有對時(shí)間序列數(shù)據(jù)的研究多基于內(nèi)存數(shù)據(jù)庫，主要關(guān)注分析和提取時(shí)間序列數(shù)據(jù)的模式，用于匹配或預(yù)測[8]。在時(shí)間序列數(shù)據(jù)的存儲方面，傳統(tǒng)的基于單機(jī)關(guān)系數(shù)據(jù)庫管理系統(tǒng)受硬件的限制，存儲性能無法滿足高頻率的采樣數(shù)據(jù)存儲速度要求，文獻(xiàn)[9] 提出建立3層文件系統(tǒng)，以特定格式文件的形式存儲高速采樣數(shù)據(jù)，在存儲速度上達(dá)到了要求，但并未解決存儲容量的問題。文獻(xiàn)[10] 針對光傳輸網(wǎng)管系統(tǒng)數(shù)據(jù)量急劇增長導(dǎo)致的網(wǎng)管數(shù)據(jù)庫更新查詢效率極低，甚至出現(xiàn)系統(tǒng)崩潰的問題，提出了一種分布式數(shù)據(jù)庫存儲方案，但其分布式系統(tǒng)采用的是MYSQL集群，其可擴(kuò)展性較差，也沒有涉及系統(tǒng)可靠性問題。有些文獻(xiàn)采用壓縮的方法實(shí)現(xiàn)時(shí)間序列數(shù)據(jù)的存儲。文獻(xiàn)[11] 研究了時(shí)域和頻域下時(shí)間序列數(shù)據(jù)的壓縮方法，用于大規(guī)模數(shù)據(jù)存儲，并支持對壓縮數(shù)據(jù)的關(guān)聯(lián)關(guān)系查詢，但在查詢性能方面無法滿足在線監(jiān)測系統(tǒng)實(shí)時(shí)性要求；文獻(xiàn)[12] 提出絕緣子泄漏電流的自適應(yīng)SPIHT數(shù)據(jù)壓縮，允許采樣完一個工頻周期的數(shù)據(jù)后就進(jìn)行壓縮，更適合實(shí)時(shí)或在線的場合，但其壓縮目的主要是降低網(wǎng)絡(luò)傳輸數(shù)據(jù)量，且無法對壓縮數(shù)據(jù)直接進(jìn)行查詢；文獻(xiàn)[13] 研究了天文望遠(yuǎn)鏡采集的TB級天文數(shù)據(jù)分布式存儲方法以及在該數(shù)據(jù)集上實(shí)現(xiàn)的特征監(jiān)測算法，但并未討論數(shù)據(jù)存儲的細(xì)節(jié)以及查詢性能；文獻(xiàn)[14] 研究了大規(guī)模電能質(zhì)量時(shí)間序列數(shù)據(jù)的存儲與處理方法，但其采用的方法是通過降低采樣率的方式實(shí)現(xiàn)的，只適合對采樣率要求較低的系統(tǒng)。針對電力設(shè)備采樣數(shù)據(jù)采樣率高、數(shù)據(jù)量巨大，要求可靠性高、快速數(shù)據(jù)查詢等特點(diǎn)，已有存儲方案無法滿足存儲容量、數(shù)據(jù)寫入速度、查詢效率以及系統(tǒng)擴(kuò)展性方面的要求。本文提出將Hadoop平臺和HBase數(shù)據(jù)庫用于電力設(shè)備采樣數(shù)據(jù)的云存儲方案以及基于MapReduce的并行查詢方法，并通過一系列實(shí)驗(yàn)，驗(yàn)證了方法的可行性。

1.2 Hadoop

Hadoop[15]是 Apache開源組織的一個分布式計(jì)算框架，支持在大量廉價(jià)的硬件設(shè)備組成的集群上運(yùn)行數(shù)據(jù)密集型應(yīng)用，具有高可靠性和良好的可擴(kuò)展性。Hadoop的系統(tǒng)架構(gòu)如圖1所示。

HBase[16]建立在 HDFS 之上，提供高可靠性、高性能、列存儲、可伸縮、實(shí)時(shí)讀寫的數(shù)據(jù)庫系統(tǒng)。它介于NoSQL和RDBMS之間，僅能通過主鍵（RowKey）和主鍵的Range來檢索數(shù)據(jù)，僅支持單行事務(wù)，主要用來存儲非結(jié)構(gòu)化和半結(jié)構(gòu)化的松散數(shù)據(jù)。

圖1 Hadoop系統(tǒng)架構(gòu)Fig.1 System architecture of Hadoop

2 電力設(shè)備狀態(tài)高速采樣數(shù)據(jù)的云存儲架構(gòu)和實(shí)現(xiàn)方法

2.1 系統(tǒng)架構(gòu)

本文參照云計(jì)算技術(shù)的體系結(jié)構(gòu)，并結(jié)合電力設(shè)備采樣數(shù)據(jù)的存儲與業(yè)務(wù)應(yīng)用需求，提出了如圖2所示的基于云計(jì)算的電力設(shè)備采樣數(shù)據(jù)存儲系統(tǒng)。

圖2 基于云計(jì)算的電力設(shè)備采樣數(shù)據(jù)存儲系統(tǒng)Fig.2 Storage system based on cloud computing for sampled data of power equipment

存儲系統(tǒng)分為以下3層。

a.存儲層為Master管理下的Hadoop集群，用于數(shù)據(jù)的物理存儲。集群中的普通PC通過Visual Box虛擬化技術(shù)建立同質(zhì)的Linux系統(tǒng)，并使用Hadoop平臺建立HDFS文件系統(tǒng)。

b.應(yīng)用層包括基于HDFS文件系統(tǒng)的HBase和MapReduce編程模型，依據(jù)所提供的存儲接口和并行編程接口完成數(shù)據(jù)存儲以及應(yīng)用開發(fā)。

c.管理與接口層由數(shù)據(jù)產(chǎn)生區(qū)域、客戶端和Master組成，可以通過客戶端完成電力數(shù)據(jù)的云存儲和實(shí)時(shí)訪問。

2.2 電力設(shè)備采樣數(shù)據(jù)描述

電力設(shè)備采樣數(shù)據(jù)具有類似的格式，如圖3所示。包含設(shè)備節(jié)點(diǎn)物理地址（唯一）、初始時(shí)標(biāo)、產(chǎn)生通道、微氣候記錄（包括環(huán)境溫度、濕度等）以及若干個周期長度的數(shù)據(jù)（默認(rèn)值，在采樣率固定的情況下每個采樣點(diǎn)的時(shí)間都可計(jì)算）。根據(jù)設(shè)備物理地址可映射為具體的物理設(shè)備。

圖3 電力設(shè)備采樣數(shù)據(jù)信息格式Fig.3 Message format of sampled data

2.3 HBase表結(jié)構(gòu)設(shè)計(jì)

設(shè)計(jì)的存儲系統(tǒng)可以對來自多臺電力設(shè)備的采樣數(shù)據(jù)進(jìn)行同步存儲（要求各采集設(shè)備的系統(tǒng)時(shí)鐘進(jìn)行同步），所設(shè)計(jì)的HBase表整體邏輯視圖如表1所示。RowKey表示行關(guān)鍵字，用于采樣數(shù)據(jù)檢索，由Mac地址與路號的字符串連接構(gòu)成。一個采集設(shè)備有可能采集多個通道，Mac地址唯一表示了采集設(shè)備，路號則表示了通道號。HBase表中每行數(shù)據(jù)都帶有時(shí)標(biāo)，表明了該數(shù)據(jù)的采集時(shí)間。與關(guān)系數(shù)據(jù)庫表結(jié)構(gòu)不同，HBase表的列定義由多個列族構(gòu)成，每個列族又可以包含多個列，且列可以動態(tài)增加。設(shè)計(jì)了2個列族，分別描述采集時(shí)刻的微氣候值（溫度、相對濕度）以及采樣數(shù)據(jù)采樣點(diǎn)的值，分別對應(yīng)表2中的Climate 和 leakage currents。

表1 采樣數(shù)據(jù)HBase存儲邏輯視圖Tab.1 Logical diagram of HBase storage for sampled data

2.4 基于MapReduce的并行關(guān)聯(lián)查詢設(shè)計(jì)

HBase索引只支持主索引（即RowKey），而電力設(shè)備狀態(tài)監(jiān)測系統(tǒng)很多應(yīng)用場景中，采樣數(shù)據(jù)的查詢條件通常為多條件關(guān)聯(lián)查詢（如根據(jù)線路、桿塔、絕緣子ID查詢絕緣子泄漏電流數(shù)據(jù)），這需要自行設(shè)計(jì)復(fù)合RowKey來滿足多條件查詢。本文設(shè)計(jì)了基于MapReduce的復(fù)合RowKey并行查詢方法。

設(shè) Term1、Term2、…、Term N表示 N個查詢條件，將這N個條件連接在一起作為RowKey，用于唯一標(biāo)識采樣數(shù)據(jù)來源的Mac地址（采樣數(shù)據(jù)存儲表中的RowKey）。Mac地址為infor列族下的唯一一列，構(gòu)建HBase表如表2所示。根據(jù)這些信息映射出采集設(shè)備的Mac地址以及路號id，進(jìn)行采樣數(shù)據(jù)表的查詢。

表2 Mac地址映射表Tab.2 Mac address mapping table

查詢過程分為2個步驟，如圖4所示。

圖4 基于MapReduce的泄漏電流并行關(guān)聯(lián)查詢Fig.4 Parallel relational leakage current query based on MapReduce

步驟1：Mac地址查詢。首先根據(jù)查詢信息組合成RowKey查找出在HBase表中對應(yīng)的Mac，考慮到該部分的數(shù)據(jù)屬于靜態(tài)信息，數(shù)據(jù)量較少，因此查詢過程直接使用HBase的API進(jìn)行，未進(jìn)行并行化處理。

步驟2：采樣數(shù)據(jù)查詢。使用hbase.mapreduce包中的類，接收HBase表（電力設(shè)備采樣數(shù)據(jù)表）和步驟1中查找到的Mac地址作為MapReduce作業(yè)的輸入。HBase表在行方向上分成了多個Region，每個Region包含了一定范圍內(nèi)的數(shù)據(jù)。使用TableInput-Format類完成在Region邊界的分割，Splitter（MapReduce框架的分割器）會給HBase表的每個Region分配一個Map task，完成RowKey在所屬Region內(nèi)的查詢。在Reduce階段，多個Map task查詢的結(jié)果交由Reduce任務(wù)進(jìn)行匯總，并根據(jù)設(shè)定的格式（Table-OutputFormat類）對數(shù)據(jù)進(jìn)行拆分，將結(jié)果寫入Output里（可以是HBase表或者是文件等）。

3 Hadoop云計(jì)算平臺搭建與基準(zhǔn)測試

3.1 平臺搭建

所搭建的Hadoop集群由20個節(jié)點(diǎn)組成，每個節(jié)點(diǎn)的配置為4核CPU（Intel Core i5），主頻2.60GHz，4 GB RAM 內(nèi)存，1 TB SATA 7 200 r／min 硬盤（64 MB緩存），配備千兆以太網(wǎng)用于集群節(jié)點(diǎn)的互聯(lián)。虛擬機(jī)采用 ORACLE VirtualBox（Version 4.1.8），配備操作系統(tǒng)Ubuntu（Version 10.04 LTS）。在集群上安裝 Apache Hadoop（Version 0.20.2）云計(jì)算平臺，使用 TestDFSIO[5]對集群的整體 I／O 性能進(jìn)行了基準(zhǔn)測試。測試程序用一個MapReduce作業(yè)對HDFS進(jìn)行高強(qiáng)度的I／O操作，測試集群整體的并行寫入以及讀取數(shù)據(jù)的性能。

3.2 集群基準(zhǔn)測試

為驗(yàn)證數(shù)據(jù)總體規(guī)模、讀寫文件數(shù)量以及文件大小對集群I／O性能的影響，進(jìn)行了2組實(shí)驗(yàn)，分別改變數(shù)據(jù)規(guī)模、文件大小、文件數(shù)量，獲取運(yùn)行時(shí)間，進(jìn)行比較。

實(shí)驗(yàn)1逐漸增大數(shù)據(jù)規(guī)模（固定單個文件大小為1000 MB，文件數(shù)量由5個增至40個），進(jìn)行讀、寫操作，系統(tǒng)執(zhí)行時(shí)間增長趨緩，平均訪問時(shí)間有效降低，測試結(jié)果如表3所示。圖5、6分別描述了文件數(shù)量變化對讀、寫操作運(yùn)行時(shí)間的影響。由于數(shù)據(jù)處理規(guī)模增大，系統(tǒng)Map task數(shù)量有效增加，系統(tǒng)并行程度明顯提高，節(jié)點(diǎn)間通信延遲所占比重降低，使得數(shù)據(jù)平均訪問時(shí)間有效降低。因此，Hadoop集群適合處理大數(shù)據(jù)量的讀寫。

實(shí)驗(yàn)2控制文件總量大小為5 GB，文件數(shù)量從5個到5000個（文件大小從1000 MB到1 MB）進(jìn)行變化，圖7描述了文件總量大小不變時(shí)文件數(shù)量與運(yùn)行時(shí)間關(guān)系。當(dāng)文件規(guī)模大于1塊數(shù)據(jù)塊（64 MB）時(shí)，總體訪問時(shí)間隨文件數(shù)量增加而減?。辉L問性能在文件大小與數(shù)據(jù)塊（64 MB）相當(dāng)時(shí)達(dá)到峰值；當(dāng)文件數(shù)量繼續(xù)增多時(shí)，訪問時(shí)間隨文件數(shù)量增長而增長。造成這種情況的主要原因是NameNode把文件系統(tǒng)的元數(shù)據(jù)放置在內(nèi)存中，文件系統(tǒng)所能容納的文件數(shù)目由NameNode的內(nèi)存大小決定。每一個文件、文件夾和Block需要占據(jù)150 B左右的空間，當(dāng)文件數(shù)量增多時(shí)，會消耗較多的NameNode內(nèi)存，系統(tǒng)性能下降。另外，因?yàn)镸ap task的數(shù)量是由Splits來決定的，所以用MapReduce處理數(shù)量較多的文件時(shí)，就會產(chǎn)生過多的Map task，線程管理開銷增大，作業(yè)運(yùn)行時(shí)間增長。因此，HDFS不適合存儲大量的小文件。在設(shè)計(jì)數(shù)據(jù)存儲時(shí)，在考慮具體計(jì)算需求的基礎(chǔ)上，應(yīng)盡量使單個文件的大小和HDFS設(shè)置的塊大小相近，減少整體文件數(shù)量，能夠有效提升系統(tǒng)性能。

表3 節(jié)點(diǎn)數(shù)為20時(shí)HDFS讀寫時(shí)間Tab.3 Reading／writing time for 20 nodes

圖5 文件數(shù)量變化對運(yùn)行時(shí)間的影響（讀操作）Fig.5 Influence of file number on running time（reading）

圖6 文件數(shù)量變化對運(yùn)行時(shí)間的影響（寫操作）Fig.6 Influence of file number on running time（writing）

圖7 文件大小不變時(shí)文件數(shù)量與運(yùn)行時(shí)間關(guān)系圖Fig.7 Relationship between file number and running time when total file volume is fixed

4 基于YSCB的數(shù)據(jù)存儲性能測試

本文以輸電線路上采集的絕緣子泄漏電流數(shù)據(jù)為例，在所搭建的Hadoop集群平臺上，使用YCSB[17]對所提存儲系統(tǒng)進(jìn)行寫入數(shù)據(jù)、讀取數(shù)據(jù)的性能測試，驗(yàn)證所提存儲方案的存儲性能、查詢性能。用于存儲與查詢測試的絕緣子泄漏電流數(shù)據(jù)采集自河北省某110 kV輸電線路，線路包含60基監(jiān)測桿塔。使用采集設(shè)備246個，對246個絕緣子以200 kHz采樣率進(jìn)行數(shù)據(jù)采集，并使用16 bit模數(shù)轉(zhuǎn)換保存為物理量。共采集絕緣子泄漏電流數(shù)據(jù)163 840條，累計(jì)5 120 MB。為驗(yàn)證大規(guī)模數(shù)據(jù)查詢，對所采集數(shù)據(jù)進(jìn)行了復(fù)制，總體規(guī)模達(dá)到100萬條。

實(shí)驗(yàn)a：數(shù)據(jù)導(dǎo)入測試。根據(jù)所設(shè)計(jì)的HBase存儲模式（表1），將100萬條絕緣子泄漏電流數(shù)據(jù)（82.38 GB）導(dǎo)入HBase數(shù)據(jù)庫?？傮w運(yùn)行時(shí)間為5004.155 s、系統(tǒng)吞吐量達(dá)到每秒操作數(shù)199.83，單條記錄導(dǎo)入平均時(shí)延49.311 ms。

實(shí)驗(yàn)b：數(shù)據(jù)讀、寫測試。對已存儲的絕緣子泄漏電流數(shù)據(jù)，定制YCSB客戶端對HBase執(zhí)行10000次讀寫操作，包括50%的讀指令和50%的寫指令，用于驗(yàn)證當(dāng)客戶端產(chǎn)生非常頻繁的數(shù)據(jù)更新請求時(shí)系統(tǒng)的性能。

實(shí)驗(yàn)b應(yīng)用場景：在惡劣天氣條件下，短時(shí)間內(nèi)需要快速寫入大量絕緣子泄漏電流數(shù)據(jù)，同時(shí)，對每條數(shù)據(jù)進(jìn)行快速并行讀取分析。重復(fù)進(jìn)行5次實(shí)驗(yàn)，讀寫平均延遲變化情況如圖8所示。5次實(shí)驗(yàn)的運(yùn)行時(shí)間及吞吐量變化平緩，系統(tǒng)運(yùn)行較穩(wěn)定。5次實(shí)驗(yàn)平均運(yùn)行時(shí)間為2851.167 ms，吞吐量為每秒操作數(shù)351.5176，單條數(shù)據(jù)平均插入時(shí)間小于0.3 ms，可以滿足所提應(yīng)用場景對存儲系統(tǒng)數(shù)據(jù)讀、寫性能的要求。

圖8 5次實(shí)驗(yàn)讀、寫平均延遲（數(shù)據(jù)讀寫測試）Fig.8 Average data reading／writing delay of five data reading and writing tests

實(shí)驗(yàn)c：數(shù)據(jù)讀取測試。輸電線路監(jiān)測系統(tǒng)中，大多數(shù)應(yīng)用場景都是對數(shù)據(jù)的多次讀取操作，而寫入操作通常只進(jìn)行一次，很少進(jìn)行數(shù)據(jù)更新。因此在電力設(shè)備狀態(tài)監(jiān)測系統(tǒng)中，存儲系統(tǒng)的并行讀取性能比寫入性能更加重要。

對已存儲的100萬條絕緣子泄漏電流數(shù)據(jù)，定制YCSB客戶端執(zhí)行10000次讀寫操作，包括95%的讀指令和5%的寫指令。重復(fù)進(jìn)行5次實(shí)驗(yàn)，圖9描述了5次實(shí)驗(yàn)的單條指令執(zhí)行的平均延遲。各次實(shí)驗(yàn)結(jié)果略有差異，主要原因是讀、寫指令操作的數(shù)據(jù)是隨機(jī)選取的，如果隨機(jī)讀取數(shù)據(jù)的分布性較強(qiáng)，則讀取時(shí)并行化程度較高，讀取延遲較短；否則，若數(shù)據(jù)較集中，影響并行程度，則讀取延遲較長。5次實(shí)驗(yàn)的運(yùn)行時(shí)間及吞吐量變化平緩，系統(tǒng)運(yùn)行較穩(wěn)定。5次實(shí)驗(yàn)平均運(yùn)行時(shí)間為1145 ms，吞吐量為每秒操作數(shù)836.9911，數(shù)據(jù)讀取操作平均延遲遠(yuǎn)小于寫入操作平均延遲。

圖9 數(shù)據(jù)讀測試5次實(shí)驗(yàn)讀、寫平均延遲Fig.9 Average data reading／writing delay of five data reading tests

目前的電力設(shè)備的狀態(tài)監(jiān)測尚處于起步階段，系統(tǒng)性能要求方面尚未形成統(tǒng)一標(biāo)準(zhǔn)，在衡量系統(tǒng)性能時(shí)，可將SCADA系統(tǒng)作為參照。但SCADA系統(tǒng)實(shí)時(shí)性要求更高，在正常狀態(tài)下窗口功能調(diào)用響應(yīng)時(shí)間小于3 ms，數(shù)據(jù)加載時(shí)間小于5 ms[18]。實(shí)驗(yàn)中，讀取10000條歷史數(shù)據(jù)在2 s內(nèi)完成，可以滿足所提應(yīng)用場景對存儲系統(tǒng)數(shù)據(jù)讀取性能的要求。

實(shí)驗(yàn)d：客戶端并發(fā)線程數(shù)量對存儲系統(tǒng)吞吐量以及訪問時(shí)延的影響測試。定制YCSB客戶端包含多個線程，線程數(shù)量由10個增至100個，對已存儲的100萬條絕緣子泄漏電流數(shù)據(jù)執(zhí)行10000次的讀取、更新請求，包括50%的讀指令和50%的寫指令。實(shí)驗(yàn)結(jié)果如圖10所示。實(shí)驗(yàn)數(shù)據(jù)表明，所提存儲系統(tǒng)吞吐量隨客戶端并發(fā)請求的線程數(shù)量增加而增長，當(dāng)線程數(shù)量增至30時(shí)，系統(tǒng)吞吐量達(dá)到每秒操作數(shù)為415.09的峰值，之后，便隨之下降，下降趨勢逐漸趨于平緩，線程數(shù)量為100時(shí)，系統(tǒng)吞吐量下降為每秒操作數(shù)為362.18。這反映出所搭建的存儲系統(tǒng)所能承受的并發(fā)訪問數(shù)量。據(jù)此可知所提存儲系統(tǒng)可以同時(shí)滿足的在線用戶數(shù)量。

圖10 客戶端線程數(shù)量變化對存儲系統(tǒng)吞吐量及訪問時(shí)間的影響Fig.10 Influence of client thread number on throughput and access time of storage system

在實(shí)驗(yàn)過程中，也遇到一些問題。如在首次數(shù)據(jù)導(dǎo)入過程中，當(dāng)執(zhí)行至60萬條數(shù)據(jù)插入時(shí)（3831 s時(shí)），出現(xiàn)單個數(shù)據(jù)節(jié)點(diǎn)崩潰，于是終止導(dǎo)入操作；同時(shí)發(fā)現(xiàn)HBase負(fù)載并不均衡，該節(jié)點(diǎn)被裝入的數(shù)據(jù)在崩潰前接近14 GB，且在崩潰前，該節(jié)點(diǎn)CPU利用率達(dá)到100%，而有的節(jié)點(diǎn)不到1 GB。造成這種現(xiàn)象的主要原因是沒有對Java虛擬機(jī)進(jìn)行垃圾收集（GC）的優(yōu)化處理，以及Zookeeper（用于負(fù)載均衡）的配置問題。在測試10000條數(shù)據(jù)的讀寫性能的幾個實(shí)驗(yàn)里，發(fā)現(xiàn)實(shí)驗(yàn)結(jié)果與2次實(shí)驗(yàn)間的時(shí)間間隔有關(guān)。比如實(shí)驗(yàn)b中，頻繁實(shí)驗(yàn)（間隔很短）的平均運(yùn)行時(shí)間為5493 ms，吞吐量為每秒操作數(shù)182；而有效增加2次實(shí)驗(yàn)的時(shí)間間隔后，平均運(yùn)行時(shí)間為2 966 ms，吞吐量為每秒操作數(shù)337.1?？梢钥闯觯l繁實(shí)驗(yàn)的過程中，集群完成數(shù)據(jù)讀寫后還有后續(xù)的內(nèi)部操作，性能并不是最佳，一段時(shí)間后，集群的性能才達(dá)到最佳。

5 結(jié)語

本文提出了基于Hadoop和HBase的電力設(shè)備狀態(tài)高速采樣數(shù)據(jù)的云存儲架構(gòu)和實(shí)現(xiàn)方法，有效地實(shí)現(xiàn)了海量數(shù)據(jù)存儲和快速并行查詢，是采用云計(jì)算技術(shù)搭建智能電網(wǎng)信息平臺的一次有益嘗試。搭建具有20個節(jié)點(diǎn)的Hadoop集群，對集群的基準(zhǔn)測試表明，隨著數(shù)據(jù)規(guī)模逐漸增大，系統(tǒng)吞吐量有效提升，讀、寫操作平均訪問時(shí)間有效降低，系統(tǒng)適合處理大數(shù)據(jù)量的讀寫。應(yīng)用HBase設(shè)計(jì)實(shí)現(xiàn)了電力設(shè)備狀態(tài)高速采樣數(shù)據(jù)的分布式存儲方法，以絕緣子泄漏電流數(shù)據(jù)為例，使用YCSB對所建存儲系統(tǒng)進(jìn)行了性能測試，測試結(jié)果表明，數(shù)據(jù)分布均勻，集群運(yùn)行狀況良好，沒有出現(xiàn)數(shù)據(jù)丟失現(xiàn)象；系統(tǒng)在導(dǎo)入數(shù)據(jù)、讀寫測試、讀測試中均提供了較高的吞吐量和較低的查詢延遲。應(yīng)用MapReduce編程模型設(shè)計(jì)實(shí)現(xiàn)了復(fù)合RowKey并行關(guān)聯(lián)查詢方法，解決了HBase目前的版本未實(shí)現(xiàn)多表關(guān)聯(lián)查詢的問題。本文所提存儲方案在存儲容量、查詢延遲、數(shù)據(jù)可靠性和可擴(kuò)展性等方面均顯示了較高的性能，能夠滿足智能電網(wǎng)狀態(tài)監(jiān)測數(shù)據(jù)可靠性及實(shí)時(shí)性要求。