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

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

0 引言

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

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

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

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

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

1 相關(guān)工作

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

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

1.2 Hadoop

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

HBase[16]建立在 HDFS 之上，提供高可靠性、高性能、列存儲(chǔ)、可伸縮、實(shí)時(shí)讀寫(xiě)的數(shù)據(jù)庫(kù)系統(tǒng)。它介于NoSQL和RDBMS之間，僅能通過(guò)主鍵（RowKey）和主鍵的Range來(lái)檢索數(shù)據(jù)，僅支持單行事務(wù)，主要用來(lái)存儲(chǔ)非結(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ù)的云存儲(chǔ)架構(gòu)和實(shí)現(xiàn)方法

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

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

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

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

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

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

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

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

電力設(shè)備采樣數(shù)據(jù)具有類似的格式，如圖3所示。包含設(shè)備節(jié)點(diǎn)物理地址（唯一）、初始時(shí)標(biāo)、產(chǎn)生通道、微氣候記錄（包括環(huán)境溫度、濕度等）以及若干個(gè)周期長(zhǎng)度的數(shù)據(jù)（默認(rèn)值，在采樣率固定的情況下每個(gè)采樣點(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ì)的存儲(chǔ)系統(tǒng)可以對(duì)來(lái)自多臺(tái)電力設(shè)備的采樣數(shù)據(jù)進(jìn)行同步存儲(chǔ)（要求各采集設(shè)備的系統(tǒng)時(shí)鐘進(jìn)行同步），所設(shè)計(jì)的HBase表整體邏輯視圖如表1所示。RowKey表示行關(guān)鍵字，用于采樣數(shù)據(jù)檢索，由Mac地址與路號(hào)的字符串連接構(gòu)成。一個(gè)采集設(shè)備有可能采集多個(gè)通道，Mac地址唯一表示了采集設(shè)備，路號(hào)則表示了通道號(hào)。HBase表中每行數(shù)據(jù)都帶有時(shí)標(biāo)，表明了該數(shù)據(jù)的采集時(shí)間。與關(guān)系數(shù)據(jù)庫(kù)表結(jié)構(gòu)不同，HBase表的列定義由多個(gè)列族構(gòu)成，每個(gè)列族又可以包含多個(gè)列，且列可以動(dòng)態(tài)增加。設(shè)計(jì)了2個(gè)列族，分別描述采集時(shí)刻的微氣候值（溫度、相對(duì)濕度）以及采樣數(shù)據(jù)采樣點(diǎn)的值，分別對(duì)應(yīng)表2中的Climate 和 leakage currents。

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

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

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

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

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

查詢過(guò)程分為2個(gè)步驟，如圖4所示。

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

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

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

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

3.1 平臺(tái)搭建

所搭建的Hadoop集群由20個(gè)節(jié)點(diǎn)組成，每個(gè)節(jié)點(diǎn)的配置為4核CPU（Intel Core i5），主頻2.60GHz，4 GB RAM 內(nèi)存，1 TB SATA 7 200 r／min 硬盤(pán)（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ì)算平臺(tái)，使用 TestDFSIO[5]對(duì)集群的整體 I／O 性能進(jìn)行了基準(zhǔn)測(cè)試。測(cè)試程序用一個(gè)MapReduce作業(yè)對(duì)HDFS進(jìn)行高強(qiáng)度的I／O操作，測(cè)試集群整體的并行寫(xiě)入以及讀取數(shù)據(jù)的性能。

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

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

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

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

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

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

圖6 文件數(shù)量變化對(duì)運(yùn)行時(shí)間的影響（寫(xiě)操作）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ù)存儲(chǔ)性能測(cè)試

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

實(shí)驗(yàn)a：數(shù)據(jù)導(dǎo)入測(cè)試。根據(jù)所設(shè)計(jì)的HBase存儲(chǔ)模式（表1），將100萬(wàn)條絕緣子泄漏電流數(shù)據(jù)（82.38 GB）導(dǎo)入HBase數(shù)據(jù)庫(kù)?？傮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ù)讀、寫(xiě)測(cè)試。對(duì)已存儲(chǔ)的絕緣子泄漏電流數(shù)據(jù)，定制YCSB客戶端對(duì)HBase執(zhí)行10000次讀寫(xiě)操作，包括50%的讀指令和50%的寫(xiě)指令，用于驗(yàn)證當(dāng)客戶端產(chǎn)生非常頻繁的數(shù)據(jù)更新請(qǐng)求時(shí)系統(tǒng)的性能。

實(shí)驗(yàn)b應(yīng)用場(chǎng)景：在惡劣天氣條件下，短時(shí)間內(nèi)需要快速寫(xiě)入大量絕緣子泄漏電流數(shù)據(jù)，同時(shí)，對(duì)每條數(shù)據(jù)進(jìn)行快速并行讀取分析。重復(fù)進(jìn)行5次實(shí)驗(yàn)，讀寫(xiě)平均延遲變化情況如圖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)用場(chǎng)景對(duì)存儲(chǔ)系統(tǒng)數(shù)據(jù)讀、寫(xiě)性能的要求。

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

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

對(duì)已存儲(chǔ)的100萬(wàn)條絕緣子泄漏電流數(shù)據(jù)，定制YCSB客戶端執(zhí)行10000次讀寫(xiě)操作，包括95%的讀指令和5%的寫(xiě)指令。重復(fù)進(jìn)行5次實(shí)驗(yàn)，圖9描述了5次實(shí)驗(yàn)的單條指令執(zhí)行的平均延遲。各次實(shí)驗(yàn)結(jié)果略有差異，主要原因是讀、寫(xiě)指令操作的數(shù)據(jù)是隨機(jī)選取的，如果隨機(jī)讀取數(shù)據(jù)的分布性較強(qiáng)，則讀取時(shí)并行化程度較高，讀取延遲較短；否則，若數(shù)據(jù)較集中，影響并行程度，則讀取延遲較長(zhǎng)。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)小于寫(xiě)入操作平均延遲。

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

目前的電力設(shè)備的狀態(tài)監(jiān)測(cè)尚處于起步階段，系統(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)用場(chǎng)景對(duì)存儲(chǔ)系統(tǒng)數(shù)據(jù)讀取性能的要求。

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

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

在實(shí)驗(yàn)過(guò)程中，也遇到一些問(wèn)題。如在首次數(shù)據(jù)導(dǎo)入過(guò)程中，當(dāng)執(zhí)行至60萬(wàn)條數(shù)據(jù)插入時(shí)（3831 s時(shí)），出現(xiàn)單個(gè)數(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)象的主要原因是沒(méi)有對(duì)Java虛擬機(jī)進(jìn)行垃圾收集（GC）的優(yōu)化處理，以及Zookeeper（用于負(fù)載均衡）的配置問(wèn)題。在測(cè)試10000條數(shù)據(jù)的讀寫(xiě)性能的幾個(gè)實(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)的過(guò)程中，集群完成數(shù)據(jù)讀寫(xiě)后還有后續(xù)的內(nèi)部操作，性能并不是最佳，一段時(shí)間后，集群的性能才達(dá)到最佳。

5 結(jié)語(yǔ)

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