基于ha和hssh的高速采樣數(shù)據(jù)存儲(chǔ)方案

基于ha和hssh的高速采樣數(shù)據(jù)存儲(chǔ)方案

0海量電力設(shè)備狀態(tài)高速采樣數(shù)據(jù)的云存儲(chǔ)方案網(wǎng)絡(luò)基礎(chǔ)設(shè)施的可靠性與網(wǎng)絡(luò)基礎(chǔ)設(shè)施的維護(hù)密切相關(guān)。它支持在線監(jiān)測、數(shù)據(jù)收集和評估。智能電網(wǎng)需要監(jiān)測的設(shè)備眾多,甚至包括線路的每串絕緣子的泄漏電流等動(dòng)態(tài)信號。為了能對絕緣子放電等狀態(tài)進(jìn)行診斷,信號的采樣頻率必須在200kHz以上。變電站內(nèi)設(shè)備狀態(tài)監(jiān)測,要求數(shù)據(jù)采樣率可達(dá)MHz級,變壓器超高頻局部放電信號的頻率均在300MHz以上,甚至超過1GHz。因此,采集的數(shù)據(jù)量非常巨大。目前,受存儲(chǔ)容量以及網(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ù)并未保存,這種就地處理的方式會(huì)導(dǎo)致如放電波形等重要信息丟失,影響電力設(shè)備狀態(tài)評估的準(zhǔn)確率。例如,在利用變壓器局部放電信號進(jìn)行故障診斷和狀態(tài)評估時(shí),已有方法大都利用波形宏觀特征(熟數(shù)據(jù))進(jìn)行評估,而非常重要的放電過程波形(微觀特征)被丟棄,影響診斷或評估的結(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)信號提供理論支持和技術(shù)儲(chǔ)備。常規(guī)的數(shù)據(jù)存儲(chǔ)與管理方法,基礎(chǔ)架構(gòu)大多采用價(jià)格昂貴的大型服務(wù)器,存儲(chǔ)硬件采用磁盤陣列,數(shù)據(jù)庫管理軟件采用關(guān)系數(shù)據(jù)庫,緊密耦合類業(yè)務(wù)應(yīng)用采用套裝軟件,因此系統(tǒng)擴(kuò)展性較差、成本較高。傳統(tǒng)的超級計(jì)算機(jī)主要用于“計(jì)算密集型”的應(yīng)用,如量子力學(xué)、天氣預(yù)報(bào)等。超級計(jì)算機(jī)擁有多個(gè)處理器,通過精良的設(shè)計(jì),達(dá)到高度并行的目的,實(shí)現(xiàn)快速計(jì)算,但是其計(jì)算需要的數(shù)據(jù)通常采用磁盤陣列進(jìn)行集中式存儲(chǔ)(RAID)。在Yahoo!集群上的性能測試表明,Hadoop分布式文件系統(tǒng)(HDFS)讀寫吞吐量在Girdmix測試中顯示比RAID快30%。另外,超級計(jì)算機(jī)交互性較差,所采用并行編程方法(MPI等)也難以掌握,對用戶要求很高;系統(tǒng)的擴(kuò)展性差,且成本高,不適用于智能電網(wǎng)環(huán)境下信息平臺(tái)的建設(shè)。云計(jì)算是分布式計(jì)算、并行計(jì)算和網(wǎng)格計(jì)算發(fā)展的結(jié)果,目前主要應(yīng)用于“數(shù)據(jù)密集型”應(yīng)用,通過虛擬技術(shù)、海量分布式數(shù)據(jù)存儲(chǔ)技術(shù)、MapReduce并行編程模型等技術(shù),為用戶提供高可靠性、高安全性的海量數(shù)據(jù)存儲(chǔ)平臺(tái),這為智能電網(wǎng)信息平臺(tái)的建設(shè)提供了全新的解決思路。本文提出使用面向列的數(shù)據(jù)庫HBase在開源的云計(jì)算平臺(tái)Hadoop集群上實(shí)現(xiàn)海量電力設(shè)備狀態(tài)高速采樣數(shù)據(jù)的云存儲(chǔ)方案,是采用云計(jì)算技術(shù)搭建智能電網(wǎng)信息平臺(tái)的一次有益嘗試。使用TestDFSIO和YCSB對集群整體輸入、輸出性能以及讀取、插入、數(shù)據(jù)更新進(jìn)行了性能測試,實(shí)驗(yàn)結(jié)果表明,Hadoop和HBase在存儲(chǔ)容量、吞吐量以及查詢延遲上提供了足夠高的性能,能夠滿足智能電網(wǎng)環(huán)境下電力設(shè)備狀態(tài)高速采樣數(shù)據(jù)可靠性及實(shí)時(shí)性要求。1相關(guān)工作1.1存儲(chǔ)方案研究電力設(shè)備狀態(tài)高速采樣數(shù)據(jù)是一種典型的時(shí)間序列數(shù)據(jù)。已有對時(shí)間序列數(shù)據(jù)的研究多基于內(nèi)存數(shù)據(jù)庫,主要關(guān)注分析和提取時(shí)間序列數(shù)據(jù)的模式,用于匹配或預(yù)測。在時(shí)間序列數(shù)據(jù)的存儲(chǔ)方面,傳統(tǒng)的基于單機(jī)關(guān)系數(shù)據(jù)庫管理系統(tǒng)受硬件的限制,存儲(chǔ)性能無法滿足高頻率的采樣數(shù)據(jù)存儲(chǔ)速度要求,文獻(xiàn)提出建立3層文件系統(tǒng),以特定格式文件的形式存儲(chǔ)高速采樣數(shù)據(jù),在存儲(chǔ)速度上達(dá)到了要求,但并未解決存儲(chǔ)容量的問題。文獻(xiàn)針對光傳輸網(wǎng)管系統(tǒng)數(shù)據(jù)量急劇增長導(dǎo)致的網(wǎng)管數(shù)據(jù)庫更新查詢效率極低,甚至出現(xiàn)系統(tǒng)崩潰的問題,提出了一種分布式數(shù)據(jù)庫存儲(chǔ)方案,但其分布式系統(tǒng)采用的是MYSQL集群,其可擴(kuò)展性較差,也沒有涉及系統(tǒng)可靠性問題。有些文獻(xiàn)采用壓縮的方法實(shí)現(xiàn)時(shí)間序列數(shù)據(jù)的存儲(chǔ)。文獻(xiàn)研究了時(shí)域和頻域下時(shí)間序列數(shù)據(jù)的壓縮方法,用于大規(guī)模數(shù)據(jù)存儲(chǔ),并支持對壓縮數(shù)據(jù)的關(guān)聯(lián)關(guān)系查詢,但在查詢性能方面無法滿足在線監(jiān)測系統(tǒng)實(shí)時(shí)性要求;文獻(xiàn)提出絕緣子泄漏電流的自適應(yīng)SPIHT數(shù)據(jù)壓縮,允許采樣完一個(gè)工頻周期的數(shù)據(jù)后就進(jìn)行壓縮,更適合實(shí)時(shí)或在線的場合,但其壓縮目的主要是降低網(wǎng)絡(luò)傳輸數(shù)據(jù)量,且無法對壓縮數(shù)據(jù)直接進(jìn)行查詢;文獻(xiàn)研究了天文望遠(yuǎn)鏡采集的TB級天文數(shù)據(jù)分布式存儲(chǔ)方法以及在該數(shù)據(jù)集上實(shí)現(xiàn)的特征監(jiān)測算法,但并未討論數(shù)據(jù)存儲(chǔ)的細(xì)節(jié)以及查詢性能;文獻(xiàn)研究了大規(guī)模電能質(zhì)量時(shí)間序列數(shù)據(jù)的存儲(chǔ)與處理方法,但其采用的方法是通過降低采樣率的方式實(shí)現(xiàn)的,只適合對采樣率要求較低的系統(tǒng)。針對電力設(shè)備采樣數(shù)據(jù)采樣率高、數(shù)據(jù)量巨大,要求可靠性高、快速數(shù)據(jù)查詢等特點(diǎn),已有存儲(chǔ)方案無法滿足存儲(chǔ)容量、數(shù)據(jù)寫入速度、查詢效率以及系統(tǒng)擴(kuò)展性方面的要求。本文提出將Hadoop平臺(tái)和HBase數(shù)據(jù)庫用于電力設(shè)備采樣數(shù)據(jù)的云存儲(chǔ)方案以及基于MapReduce的并行查詢方法,并通過一系列實(shí)驗(yàn),驗(yàn)證了方法的可行性。1.2系統(tǒng)架構(gòu)設(shè)計(jì)Hadoop是Apache開源組織的一個(gè)分布式計(jì)算框架,支持在大量廉價(jià)的硬件設(shè)備組成的集群上運(yùn)行數(shù)據(jù)密集型應(yīng)用,具有高可靠性和良好的可擴(kuò)展性。Hadoop的系統(tǒng)架構(gòu)如圖1所示。HBase建立在HDFS之上,提供高可靠性、高性能、列存儲(chǔ)、可伸縮、實(shí)時(shí)讀寫的數(shù)據(jù)庫系統(tǒng)。它介于NoSQL和RDBMS之間,僅能通過主鍵(RowKey)和主鍵的Range來檢索數(shù)據(jù),僅支持單行事務(wù),主要用來存儲(chǔ)非結(jié)構(gòu)化和半結(jié)構(gòu)化的松散數(shù)據(jù)。2云存儲(chǔ)結(jié)構(gòu)和電氣設(shè)備狀態(tài)的實(shí)現(xiàn)方法2.1基于高效存儲(chǔ)的應(yīng)用層本文參照云計(jì)算技術(shù)的體系結(jié)構(gòu),并結(jié)合電力設(shè)備采樣數(shù)據(jù)的存儲(chǔ)與業(yè)務(wù)應(yīng)用需求,提出了如圖2所示的基于云計(jì)算的電力設(shè)備采樣數(shù)據(jù)存儲(chǔ)系統(tǒng)。存儲(chǔ)系統(tǒng)分為以下3層。a.存儲(chǔ)層為Master管理下的Hadoop集群,用于數(shù)據(jù)的物理存儲(chǔ)。集群中的普通PC通過VisualBox虛擬化技術(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)用開發(fā)。c.管理與接口層由數(shù)據(jù)產(chǎn)生區(qū)域、客戶端和Master組成,可以通過客戶端完成電力數(shù)據(jù)的云存儲(chǔ)和實(shí)時(shí)訪問。2.2采樣點(diǎn)時(shí)間的確定電力設(shè)備采樣數(shù)據(jù)具有類似的格式,如圖3所示。包含設(shè)備節(jié)點(diǎn)物理地址(唯一)、初始時(shí)標(biāo)、產(chǎn)生通道、微氣候記錄(包括環(huán)境溫度、濕度等)以及若干個(gè)周期長度的數(shù)據(jù)(默認(rèn)值,在采樣率固定的情況下每個(gè)采樣點(diǎn)的時(shí)間都可計(jì)算)。根據(jù)設(shè)備物理地址可映射為具體的物理設(shè)備。2.3采集設(shè)備及列的選取設(shè)計(jì)的存儲(chǔ)系統(tǒng)可以對來自多臺(tái)電力設(shè)備的采樣數(shù)據(jù)進(jìn)行同步存儲(chǔ)(要求各采集設(shè)備的系統(tǒng)時(shí)鐘進(jìn)行同步),所設(shè)計(jì)的HBase表整體邏輯視圖如表1所示。RowKey表示行關(guān)鍵字,用于采樣數(shù)據(jù)檢索,由Mac地址與路號的字符串連接構(gòu)成。一個(gè)采集設(shè)備有可能采集多個(gè)通道,Mac地址唯一表示了采集設(shè)備,路號則表示了通道號。HBase表中每行數(shù)據(jù)都帶有時(shí)標(biāo),表明了該數(shù)據(jù)的采集時(shí)間。與關(guān)系數(shù)據(jù)庫表結(jié)構(gòu)不同,HBase表的列定義由多個(gè)列族構(gòu)成,每個(gè)列族又可以包含多個(gè)列,且列可以動(dòng)態(tài)增加。設(shè)計(jì)了2個(gè)列族,分別描述采集時(shí)刻的微氣候值(溫度、相對濕度)以及采樣數(shù)據(jù)采樣點(diǎn)的值,分別對應(yīng)表2中的Climate和leakagecurrents。2.4rowkey采樣數(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、…、TermN表示N個(gè)查詢條件,將這N個(gè)條件連接在一起作為RowKey,用于唯一標(biāo)識采樣數(shù)據(jù)來源的Mac地址(采樣數(shù)據(jù)存儲(chǔ)表中的RowKey)。Mac地址為infor列族下的唯一一列,構(gòu)建HBase表如表2所示。根據(jù)這些信息映射出采集設(shè)備的Mac地址以及路號id,進(jìn)行采樣數(shù)據(jù)表的查詢。查詢過程分為2個(gè)步驟,如圖4所示。步驟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表在行方向上分成了多個(gè)Region,每個(gè)Region包含了一定范圍內(nèi)的數(shù)據(jù)。使用TableInputFormat類完成在Region邊界的分割,Splitter(MapReduce框架的分割器)會(huì)給HBase表的每個(gè)Region分配一個(gè)Maptask,完成RowKey在所屬Region內(nèi)的查詢。在Reduce階段,多個(gè)Maptask查詢的結(jié)果交由Reduce任務(wù)進(jìn)行匯總,并根據(jù)設(shè)定的格式(TableOutputFormat類)對數(shù)據(jù)進(jìn)行拆分,將結(jié)果寫入Output里(可以是HBase表或者是文件等)。3ha云計(jì)算平臺(tái)的構(gòu)建與標(biāo)準(zhǔn)測試3.1pc機(jī)性能測試所搭建的Hadoop集群由20個(gè)節(jié)點(diǎn)組成,每個(gè)節(jié)點(diǎn)的配置為4核CPU(IntelCorei5),主頻2.60GHz,4GBRAM內(nèi)存,1TBSATA7200r/min硬盤(64MB緩存),配備千兆以太網(wǎng)用于集群節(jié)點(diǎn)的互聯(lián)。虛擬機(jī)采用ORACLEVirtualBox(Version4.1.8),配備操作系統(tǒng)Ubuntu(Version10.04LTS)。在集群上安裝ApacheHadoop(Version0.20.2)云計(jì)算平臺(tái),使用TestDFSIO對集群的整體I/O性能進(jìn)行了基準(zhǔn)測試。測試程序用一個(gè)MapReduce作業(yè)對HDFS進(jìn)行高強(qiáng)度的I/O操作,測試集群整體的并行寫入以及讀取數(shù)據(jù)的性能。3.2文件規(guī)模和sdbs對結(jié)果的影響為驗(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ī)模(固定單個(gè)文件大小為1000MB,文件數(shù)量由5個(gè)增至40個(gè)),進(jìn)行讀、寫操作,系統(tǒng)執(zhí)行時(shí)間增長趨緩,平均訪問時(shí)間有效降低,測試結(jié)果如表3所示。圖5、6分別描述了文件數(shù)量變化對讀、寫操作運(yùn)行時(shí)間的影響。由于數(shù)據(jù)處理規(guī)模增大,系統(tǒng)Maptask數(shù)量有效增加,系統(tǒng)并行程度明顯提高,節(jié)點(diǎn)間通信延遲所占比重降低,使得數(shù)據(jù)平均訪問時(shí)間有效降低。因此,Hadoop集群適合處理大數(shù)據(jù)量的讀寫。實(shí)驗(yàn)2控制文件總量大小為5GB,文件數(shù)量從5個(gè)到5000個(gè)(文件大小從1000MB到1MB)進(jìn)行變化,圖7描述了文件總量大小不變時(shí)文件數(shù)量與運(yùn)行時(shí)間關(guān)系。當(dāng)文件規(guī)模大于1塊數(shù)據(jù)塊(64MB)時(shí),總體訪問時(shí)間隨文件數(shù)量增加而減小;訪問性能在文件大小與數(shù)據(jù)塊(64MB)相當(dāng)時(shí)達(dá)到峰值;當(dāng)文件數(shù)量繼續(xù)增多時(shí),訪問時(shí)間隨文件數(shù)量增長而增長。造成這種情況的主要原因是NameNode把文件系統(tǒng)的元數(shù)據(jù)放置在內(nèi)存中,文件系統(tǒng)所能容納的文件數(shù)目由NameNode的內(nèi)存大小決定。每一個(gè)文件、文件夾和Block需要占據(jù)150B左右的空間,當(dāng)文件數(shù)量增多時(shí),會(huì)消耗較多的NameNode內(nèi)存,系統(tǒng)性能下降。另外,因?yàn)镸aptask的數(shù)量是由Splits來決定的,所以用MapReduce處理數(shù)量較多的文件時(shí),就會(huì)產(chǎn)生過多的Maptask,線程管理開銷增大,作業(yè)運(yùn)行時(shí)間增長。因此,HDFS不適合存儲(chǔ)大量的小文件。在設(shè)計(jì)數(shù)據(jù)存儲(chǔ)時(shí),在考慮具體計(jì)算需求的基礎(chǔ)上,應(yīng)盡量使單個(gè)文件的大小和HDFS設(shè)置的塊大小相近,減少整體文件數(shù)量,能夠有效提升系統(tǒng)性能。4實(shí)驗(yàn)應(yīng)用場景本文以輸電線路上采集的絕緣子泄漏電流數(shù)據(jù)為例,在所搭建的Hadoop集群平臺(tái)上,使用YCSB對所提存儲(chǔ)系統(tǒng)進(jìn)行寫入數(shù)據(jù)、讀取數(shù)據(jù)的性能測試,驗(yàn)證所提存儲(chǔ)方案的存儲(chǔ)性能、查詢性能。用于存儲(chǔ)與查詢測試的絕緣子泄漏電流數(shù)據(jù)采集自河北省某110kV輸電線路,線路包含60基監(jiān)測桿塔。使用采集設(shè)備246個(gè),對246個(gè)絕緣子以200kHz采樣率進(jìn)行數(shù)據(jù)采集,并使用16bit模數(shù)轉(zhuǎn)換保存為物理量。共采集絕緣子泄漏電流數(shù)據(jù)163840條,累計(jì)5120MB。為驗(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存儲(chǔ)模式(表1),將100萬條絕緣子泄漏電流數(shù)據(jù)(82.38GB)導(dǎo)入HBase數(shù)據(jù)庫?？傮w運(yùn)行時(shí)間為5004.155s、系統(tǒng)吞吐量達(dá)到每秒操作數(shù)199.83,單條記錄導(dǎo)入平均時(shí)延49.311ms。實(shí)驗(yàn)b:數(shù)據(jù)讀、寫測試。對已存儲(chǔ)的絕緣子泄漏電流數(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.167ms,吞吐量為每秒操作數(shù)351.5176,單條數(shù)據(jù)平均插入時(shí)間小于0.3ms,可以滿足所提應(yīng)用場景對存儲(chǔ)系統(tǒng)數(shù)據(jù)讀、寫性能的要求。實(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)中,存儲(chǔ)系統(tǒng)的并行讀取性能比寫入性能更加重要。對已存儲(chǔ)的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í)間為1145ms,吞吐量為每秒操作數(shù)836.9911,數(shù)據(jù)讀取操作平均延遲遠(yuǎn)小于寫入操作平均延遲。目前的電力設(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í)間小于3ms,數(shù)據(jù)加載時(shí)間小于5ms。實(shí)驗(yàn)中,讀取10000條歷史數(shù)據(jù)在2s內(nèi)完成,可以滿足所提應(yīng)用場景對存儲(chǔ)系統(tǒng)數(shù)據(jù)讀取性能的要求。實(shí)驗(yàn)d:客戶端并發(fā)線程數(shù)量對存儲(chǔ)系統(tǒng)吞吐量以及訪問時(shí)延的影響測試。定制YCSB客戶端包含多個(gè)線程,線程數(shù)量由10個(gè)增至100個(gè),對已存儲(chǔ)的100萬條絕緣子泄漏電流數(shù)據(jù)執(zhí)行10000次的讀取、更新請求,包括50%的讀指令和50%的寫指令。實(shí)驗(yàn)結(jié)果如圖10所示。實(shí)驗(yàn)數(shù)據(jù)表明,所提存儲(chǔ)系統(tǒng)吞吐量隨客戶端并發(fā)請求的線程數(shù)量增加而增長,當(dāng)線程數(shù)量增至30時(shí),系統(tǒng)吞吐量達(dá)到每秒操作數(shù)為415.09的峰值,之后,便隨之下降,下降趨勢逐漸趨于平緩,線程數(shù)量為100時(shí),系統(tǒng)吞吐量下降為每秒操作數(shù)為362.18。這反映出所搭建的存儲(chǔ)系統(tǒng)所能承受的并發(fā)訪問數(shù)量。據(jù)此可知所提存儲(chǔ)系統(tǒng)可以同時(shí)滿足的在線用戶數(shù)量。在實(shí)驗(yàn)過程中,也遇到一些問題。如在首次數(shù)據(jù)導(dǎo)入過程中,當(dāng)執(zhí)行至60萬條數(shù)據(jù)插入時(shí)(3831s時(shí)),出現(xiàn)單個(gè)數(shù)據(jù)節(jié)點(diǎn)崩潰,于是終止導(dǎo)入操作;同時(shí)發(fā)現(xiàn)HBase負(fù)載并不均衡,該節(jié)點(diǎn)被裝入的數(shù)據(jù)在崩潰前接近14GB,且在崩潰前,該節(jié)點(diǎn)CPU利用率達(dá)到1