久久精品国产69国产精品亚洲_日韩欧美亚洲一区_免费观看污网站_欧美在线一

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

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

Hadoop作為一個開源的云計算基礎框架, 一個分布式系統基礎架構, 可以使用戶充分利用集群的威力高速運算和存儲, 具有可靠的數據存儲和處理能力、易于擴展的計算機集群、以高容錯性的多數據副本、以軟件開源及廉價計算機集群帶來的低成本等優勢, 正成為信息領域研究的熱點。

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

Map Reduce作為并行處理大數據集的軟件框架, 在Hadoop上得到了實現[7]。它負責分配工作以及與用戶程序進行通信, 通過把對數據集的大規模操作分發給網絡上的每個節點上, 實現數據的分布式處理。

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

圖1 云存儲系統結構   

針對上述智能電網數據的特點, 結合Hbase分布式數據庫稀疏存儲、自動切分數據、提供高并發讀寫操作等特點, 構建出智能電網數據云存儲系統。

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

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

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

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

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

圖2 智能電網CIM/RDF數據   

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

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

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

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

3) Table Reducer函數, 負責對查詢到的數據進行分析處理。實驗中由于無特殊應用需求, 只對查詢數據進行了排序, 提交到Table Output Format函數。

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

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

表1 Hbase數據行     下載原表

圖3 存儲過程   

圖4 查詢過程   

本文的所有實驗均在實驗室搭建的Hadoop平臺上運行。平臺有9個節點組成, 均為廉價PC機, 每個節點的物理配置為雙核CPU, 主頻為2.0MHz, 內存為2G, 網絡帶寬100Mbps局域網, 硬盤為100G, Hadoop版本為0.20.205, Hbase版本為0.90.5, 數據行最大版本數為3。

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

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

圖5 Map Reduce個數對Hbase性能的影響   

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

圖6 數據處理量對Hbase性能的影響   

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

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

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

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

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