12一15女人a毛片,国产香蕉Aⅴ,午色婷婷,91丨九色丨国产丨PORNY精品

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

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

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

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

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

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

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

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

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

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

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

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

在實(shí)驗(yàn)里, 存儲(chǔ)客戶(hù)端根據(jù)用戶(hù)信息和相關(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ù)再提交實(shí)行稀疏的磁盤(pán)存儲(chǔ), 如表1所示, 且數(shù)據(jù)項(xiàng)中可以含有空的列項(xiàng), 并且為空的數(shù)據(jù)項(xiàng)不占用任何存儲(chǔ)空間。由于HTable是有序的且Hbase具有自動(dòng)切分?jǐn)?shù)據(jù)的能力, 故只需控制存儲(chǔ)數(shù)據(jù)行的Row Key不連續(xù)遞增, 就能把數(shù)據(jù)行均勻的存到集群機(jī)器上, 保持機(jī)器負(fù)載的均衡, 避免了新數(shù)據(jù)扎堆存儲(chǔ)到相同的機(jī)器上降低整個(gè)存儲(chǔ)系統(tǒng)的I/O性能的現(xiàn)象。

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

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

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

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

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

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

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

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

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

圖3 存儲(chǔ)過(guò)程   

圖4 查詢(xún)過(guò)程   

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

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

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

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

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

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

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

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

表2 Oracle與Hbase查詢(xún)時(shí)間對(duì)比表     下載原表

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

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