精品久久一区,污黄啪啪网,16女下面流水不遮视频,色婷五月天

智能電網(wǎng)是電網(wǎng)的智能化, 通過將信息技術(shù)、通信技術(shù)、計算機(jī)技術(shù)與原有的電網(wǎng)高度緊密地集合到一起的新型電網(wǎng), 實現(xiàn)電網(wǎng)的可靠、安全、經(jīng)濟(jì)、高效、環(huán)境友好和使用安全的目標(biāo)。但是隨著電網(wǎng)智能化的不斷提高, 其數(shù)據(jù)量也隨之以指數(shù)級的增長。面對這海量數(shù)據(jù)的存儲的難題, 國內(nèi)已有電力調(diào)度系統(tǒng)的建設(shè)大多采用常規(guī)的解決方案, 即采用昂貴的大型服務(wù)器為基礎(chǔ), 通過傳統(tǒng)的關(guān)系數(shù)據(jù)庫的方式管理, 并且以數(shù)據(jù)庫分片的方式存放到磁盤陣列中的形式[1]。這導(dǎo)致系統(tǒng)的擴(kuò)展升級較為困難, 費(fèi)用十分高昂, 且整個系統(tǒng)模塊間耦合性較強(qiáng), 難以滿足電網(wǎng)智能化所要求的高效、可靠、經(jīng)濟(jì)的目標(biāo)[2]。

云存儲能夠解決智能電網(wǎng)對海量數(shù)據(jù)的存儲的難題, 最大限度地整合系統(tǒng)的存儲能力, 減少電網(wǎng)智能化的成本, 大幅提高當(dāng)前系統(tǒng)的整體性能, 對智能電網(wǎng)的發(fā)展起到巨大的推動作用。云計算雖然在智能電網(wǎng)方面未見成型的系統(tǒng)[3,4], 但已經(jīng)在其他領(lǐng)域得到了大量的應(yīng)用[7,8], 而且智能電網(wǎng)方面的云計算系統(tǒng)也在架構(gòu)設(shè)計開發(fā)階段了[9], 但是Hadoop集群在處理電網(wǎng)大數(shù)據(jù)上具有巨大的優(yōu)勢[1,12]。

Hadoop作為一個開源的云計算基礎(chǔ)框架, 一個分布式系統(tǒng)基礎(chǔ)架構(gòu), 可以使用戶充分利用集群的威力高速運(yùn)算和存儲, 具有可靠的數(shù)據(jù)存儲和處理能力、易于擴(kuò)展的計算機(jī)集群、以高容錯性的多數(shù)據(jù)副本、以軟件開源及廉價計算機(jī)集群帶來的低成本等優(yōu)勢, 正成為信息領(lǐng)域研究的熱點(diǎn)。

HBase (Hadoop Database) , 是一個在HDFS系統(tǒng)基礎(chǔ)上的高可靠性、高性能、面向列、可伸縮的分布式No SQL數(shù)據(jù)庫, 是谷歌公司Big Table技術(shù)的開源項目[15], 利用HBase技術(shù)可在廉價PC服務(wù)器集群上搭建起大規(guī)模非關(guān)系結(jié)構(gòu)化快速讀寫的存儲倉庫。

Map Reduce作為并行處理大數(shù)據(jù)集的軟件框架, 在Hadoop上得到了實現(xiàn)[7]。它負(fù)責(zé)分配工作以及與用戶程序進(jìn)行通信, 通過把對數(shù)據(jù)集的大規(guī)模操作分發(fā)給網(wǎng)絡(luò)上的每個節(jié)點(diǎn)上, 實現(xiàn)數(shù)據(jù)的分布式處理。

智能電網(wǎng)環(huán)境下電力數(shù)據(jù)具有:規(guī)模大、類型多、價值密度低和變化快的特點(diǎn)[5], 按照數(shù)據(jù)的產(chǎn)生源大致分為三類:一是電網(wǎng)運(yùn)行和設(shè)備檢測或監(jiān)測數(shù)據(jù);二是電力企業(yè)營銷數(shù)據(jù), 如交易電價、售電量、用電客戶等方面的數(shù)據(jù);三是電力企業(yè)管理數(shù)據(jù)[5]。因此隨著時間的增長, 存儲電網(wǎng)數(shù)據(jù)所需的空間將越來越大, 同理在查詢數(shù)據(jù)時也將更為費(fèi)時費(fèi)力。

圖1 云存儲系統(tǒng)結(jié)構(gòu)   

針對上述智能電網(wǎng)數(shù)據(jù)的特點(diǎn), 結(jié)合Hbase分布式數(shù)據(jù)庫稀疏存儲、自動切分?jǐn)?shù)據(jù)、提供高并發(fā)讀寫操作等特點(diǎn), 構(gòu)建出智能電網(wǎng)數(shù)據(jù)云存儲系統(tǒng)。

如圖1所示為云存儲系統(tǒng)的結(jié)構(gòu)圖, 整個系統(tǒng)由存儲客戶端、Hadoop服務(wù)器集群、查詢客戶端三部分組成。數(shù)據(jù)源包括智能電網(wǎng)中的發(fā)電、變電、輸電、用電、調(diào)度、銷售、財政等數(shù)據(jù), 由各類監(jiān)控管理設(shè)備或終端經(jīng)由以太網(wǎng)等網(wǎng)絡(luò)傳輸, 并經(jīng)由存儲客戶端存儲到集群當(dāng)中。系統(tǒng)核心是以大量廉價的PC機(jī)為基礎(chǔ), 通過Hadoop分布式框架搭建的服務(wù)器集群, 由少量的Name Node (負(fù)責(zé)維護(hù)文件系統(tǒng)命名空間) 和大量的Data Node (負(fù)責(zé)存儲數(shù)據(jù)塊) 組成。圖1左邊是存儲客戶端, 負(fù)責(zé)將上傳的數(shù)據(jù)映射成Hbase數(shù)據(jù)庫Htable表項, 并且存儲到Hbase數(shù)據(jù)庫中;右邊為查詢服務(wù)器, 負(fù)責(zé)處理海量數(shù)據(jù)的查詢, 為數(shù)據(jù)分析應(yīng)用提供海量數(shù)據(jù)基礎(chǔ)。

通過虛擬化技術(shù), 在安裝Windows 7操作系統(tǒng)的PC機(jī)上, 安裝VMware Workstation 10, 虛擬Linux環(huán)境, 形成一個處于10.10.11.0段的局域網(wǎng)絡(luò)。在各機(jī)上安裝JDK、SSH、Hadoop-0.20.2以及Hbase-0.90.5, 完成搭建一個完全分布模式下的Hadoop集群, 最后再在各機(jī)上安裝Zookeeper-3.3.4來管理Hadoop集群。

創(chuàng)建Hbase表時需要確定表的結(jié)構(gòu)和表的屬性。表的結(jié)構(gòu)有三種基本類型包括:行關(guān)鍵字 (Row Key) 、時間戳 (Time Stamp) 和列族 (Column Family) 。其中行關(guān)鍵字由用戶ID (類型為32位二進(jìn)制) 、數(shù)據(jù)存入時間 (Datatime類型) 、數(shù)據(jù)類型 (String類型) 、數(shù)據(jù)行ID (類型64位二進(jìn)制) 四個部分組成的字節(jié)數(shù)組, 由Row Key生產(chǎn)器生成。時間戳根據(jù)輸入數(shù)據(jù)的時間戳而定, 若數(shù)據(jù)為靜態(tài)數(shù)據(jù)本身無時間戳則由存入數(shù)據(jù)庫時間為時間戳的值。列族, 利用其稀疏和動態(tài)創(chuàng)建列的特性, 根據(jù)輸入文件描述的對象動態(tài)創(chuàng)建列并且把數(shù)據(jù)存到對應(yīng)列中。而表的屬性主要用到的有:數(shù)據(jù)行最大版本數(shù), Hbase通過保留舊版本以預(yù)防誤操作, 在這由于數(shù)據(jù)被修改的可能性較小故設(shè)為3;壓縮算法, 使用snappy算法, 其壓縮效率與lzo相近但解壓效率遠(yuǎn)高于Izo, 使數(shù)據(jù)查詢速度加快。

實驗以調(diào)度系統(tǒng)向云存儲系統(tǒng)進(jìn)行數(shù)據(jù)上傳為例, 將一臺PC機(jī)作為調(diào)度系統(tǒng)數(shù)據(jù)發(fā)生端, 將滿足國標(biāo)DLT890[12]標(biāo)準(zhǔn) (轉(zhuǎn)化自IEC系列標(biāo)準(zhǔn)) [6,11]的數(shù)據(jù)上傳到集群。其中數(shù)據(jù)包含了地理 (GIS) 信息、電力設(shè)備和線路信息、財政信息、負(fù)載信息、量測信息、電力保護(hù)信息、設(shè)備儲備與損耗信息、預(yù)測及計劃信息等[14], 這些信息數(shù)據(jù)以通用信息模型及其拓展模型為模板形成, 并且通過RDF (Resource Description Framework) 網(wǎng)絡(luò)資源描述語言[10]的方式描述, 如圖2所示。

在實驗里, 存儲客戶端根據(jù)用戶信息和相關(guān)配置信息創(chuàng)建配置信息并且初始化Row Key工廠以及創(chuàng)建數(shù)據(jù)行上傳緩沖區(qū)HTable Pool, 然后將上傳文件中的數(shù)據(jù)映射為數(shù)據(jù)行存放到上傳緩沖區(qū)中, 當(dāng)緩沖區(qū)存放的數(shù)據(jù)行達(dá)到一定的行數(shù)再提交實行稀疏的磁盤存儲, 如表1所示, 且數(shù)據(jù)項中可以含有空的列項, 并且為空的數(shù)據(jù)項不占用任何存儲空間。由于HTable是有序的且Hbase具有自動切分?jǐn)?shù)據(jù)的能力, 故只需控制存儲數(shù)據(jù)行的Row Key不連續(xù)遞增, 就能把數(shù)據(jù)行均勻的存到集群機(jī)器上, 保持機(jī)器負(fù)載的均衡, 避免了新數(shù)據(jù)扎堆存儲到相同的機(jī)器上降低整個存儲系統(tǒng)的I/O性能的現(xiàn)象。

圖2 智能電網(wǎng)CIM/RDF數(shù)據(jù)   

上述數(shù)據(jù)上傳的詳細(xì)過程如圖3所示, 其中上傳緩沖區(qū)通過HTable Pool類對上傳的數(shù)據(jù)行進(jìn)行緩沖和管理, 除此之外通過建立上傳文件流隊列實現(xiàn)用戶的多文件上傳操作。

Hbase輕量化地集成了Hadoop中的Map Reduce并行運(yùn)算模型[9], 并且根據(jù)自身的特點(diǎn)突出優(yōu)化了其表查詢的效率以及提出了基于Map Reduce的表查詢函數(shù)。因此用戶在查詢時主要設(shè)計的是Table Input Format、Table Mapper、Table Reducer、Table Output Format四個函數(shù)[8], 其整體查詢過程如圖4所示。

1) Table Input Format函數(shù), 負(fù)責(zé)將數(shù)據(jù)以表的形式通過表分割成為Splits, 然后提交給Map函數(shù)。

2) Table Mapper函數(shù), 負(fù)責(zé)處理Table Input Format函數(shù)提交的Splits, 配置Row Key值的范圍、該數(shù)據(jù)項的版本、過濾器等設(shè)置, 確定數(shù)據(jù)查找的條件并創(chuàng)建掃描讀入對象Scan, 最后將查詢到的數(shù)據(jù)交給Table Reducer函數(shù)。

3) Table Reducer函數(shù), 負(fù)責(zé)對查詢到的數(shù)據(jù)進(jìn)行分析處理。實驗中由于無特殊應(yīng)用需求, 只對查詢數(shù)據(jù)進(jìn)行了排序, 提交到Table Output Format函數(shù)。

4) Table Reducer個數(shù)配置, 通過配置Table Reducer個數(shù)能夠調(diào)節(jié)H a d o o p集群的負(fù)載以及該Map Reduce任務(wù)的處理速度, Table Reducer個數(shù)在很大程度上影響整個Map Reduce任務(wù)的效率。

5) Table OutputFormat函數(shù), 除了負(fù)載匯總Table Reducer函數(shù)處理完的數(shù)據(jù)以外, 還提供了底層刷新的機(jī)制, 大大地增加了大量數(shù)據(jù)在相界面呈現(xiàn)時的速度。

表1 Hbase數(shù)據(jù)行     下載原表

圖3 存儲過程   

圖4 查詢過程   

本文的所有實驗均在實驗室搭建的Hadoop平臺上運(yùn)行。平臺有9個節(jié)點(diǎn)組成, 均為廉價PC機(jī), 每個節(jié)點(diǎn)的物理配置為雙核CPU, 主頻為2.0MHz, 內(nèi)存為2G, 網(wǎng)絡(luò)帶寬100Mbps局域網(wǎng), 硬盤為100G, Hadoop版本為0.20.205, Hbase版本為0.90.5, 數(shù)據(jù)行最大版本數(shù)為3。

實驗是在集群無其他任務(wù)的條件下, 使用測試客戶端以不同的配置測試Hbase的I/O性能, 以得到Hbase的I/O性能最優(yōu)時Hbase的配置。其中影響Hbase的I/O性能的主要因素是要在集群上開多少個并行進(jìn)程來處理查詢和分析處理任務(wù)。

1) 實驗中只改變Map Reduce的并行進(jìn)程個數(shù) (即改變每個Input Split的大小) , 保持其他條件不變, 創(chuàng)建查詢170萬行數(shù)據(jù)的任務(wù)并獲取任務(wù)運(yùn)行時間, 結(jié)果如圖5所示。

圖5 Map Reduce個數(shù)對Hbase性能的影響   

2) 控制Map Reduce的并行進(jìn)程個數(shù) (Map和Reduce任務(wù)均為18個) 及其他條件不變, 只改變查詢數(shù)據(jù)行的數(shù)量, 從10萬行到350萬行, 并獲取任務(wù)運(yùn)行時間, 結(jié)果如圖6所示。

圖6 數(shù)據(jù)處理量對Hbase性能的影響   

由上述兩組實驗可以看出, 每個Map Reduce任務(wù)的并行進(jìn)程個數(shù)太少時集群資源沒用充分地利用查詢速度降低;而并行進(jìn)程個數(shù)太多時, 雖然數(shù)據(jù)處理的速度有所增加, 但卻浪費(fèi)了大量的時間在進(jìn)程創(chuàng)建和節(jié)點(diǎn)通訊上, 反而得不償失;除此之外如果每個進(jìn)程處理的數(shù)據(jù)過多會大量占用節(jié)點(diǎn)內(nèi)存, 導(dǎo)致該節(jié)點(diǎn)無法處理別的進(jìn)程, 降低了效率。因此根據(jù)上述兩個實驗得出在集群用18個進(jìn)程且每個進(jìn)程生命周期為20秒 (即處理約170行數(shù)據(jù)) 時得到較好的效率。故對于本集群, Map Reduce的并行進(jìn)程個數(shù)應(yīng)設(shè)置為[查詢數(shù)據(jù)行數(shù)/90000]+1。這樣設(shè)置雖然犧牲了集群的小部分任務(wù)處理速度, 但是卻使集群在多任務(wù)高負(fù)載運(yùn)行下保證每個任務(wù)的處理速度。

實驗是在集群無其它任務(wù)運(yùn)行且Map Reduce配置相同的條件下, 使用測試客戶端對Hbase進(jìn)行寫入數(shù)據(jù)和查詢數(shù)據(jù), 將同樣的數(shù)據(jù)放到Oracle系統(tǒng) (四核CPU, 8GB內(nèi)存, 硬盤650GB) 里查詢并統(tǒng)計時間。

表2 Oracle與Hbase查詢時間對比表     下載原表

由上表2可以看出, 當(dāng)數(shù)據(jù)量低于80萬行時, 單機(jī)服務(wù)的傳統(tǒng)Oracle數(shù)據(jù)庫有很大的優(yōu)勢;但是隨著查詢數(shù)據(jù)量的增大, 集群Hbase數(shù)據(jù)庫的優(yōu)勢越來越明顯。但是當(dāng)在大量數(shù)據(jù)入庫時, 兩種數(shù)據(jù)庫系統(tǒng)寫入速度都不太理想, 不過針對這一問題, Hbase也提供了一種與數(shù)據(jù)庫文件導(dǎo)入類似的以Hfile (按照Hbase數(shù)據(jù)格式存儲的文件格式) 的方式入庫, 其寫入速度與HDFS速度一樣[13], 并且在文件格式轉(zhuǎn)換時, 還能通過Map Reduce的方式利用集群的整體性能快速地將數(shù)據(jù)轉(zhuǎn)換為Hfile。綜上, 該集群非常適合存儲大規(guī)模的存儲次數(shù)頻繁但每次數(shù)據(jù)量不多的智能電網(wǎng)大數(shù)據(jù), 且在電網(wǎng)大數(shù)據(jù)處理上具有快速、可靠、廉價的優(yōu)勢。

本文研究了基于Hadoop的智能電網(wǎng)數(shù)據(jù)云存儲系統(tǒng), 首先分析智能電網(wǎng)數(shù)據(jù)的特點(diǎn), 利用Hbase分布式數(shù)據(jù)庫的特點(diǎn), 設(shè)計并實現(xiàn)了智能電網(wǎng)數(shù)據(jù)云存儲系統(tǒng)。搭建了具有9個節(jié)點(diǎn)的廉價PC機(jī)組成的Hadoop集群, 然后開發(fā)了基于Hbase以及Map Reduce的存儲和查詢客戶端, 并且對集群進(jìn)行了大量的實驗, 包括Map Reduce配置實驗和與HDFS性能比較實驗, 表明了本集群適合應(yīng)用于智能電網(wǎng)大數(shù)據(jù)的存儲, 并且提供了快速處理大數(shù)據(jù)的能力, 在行業(yè)電網(wǎng)數(shù)據(jù)分析中具有快速、有效、可靠、廉價的優(yōu)勢。