基于HBase的配用電海量時序數據存取研究

張福錚+黃文琦+陳華軍+郭曉斌+陳承志

摘 要： 針對配用電海量時間序列數據，目前南方電網普遍采用關系型數據庫進行存儲，在技術上使用分庫、分區、分表、聯合索引等方式進行優化，靈活性、可擴展性、存儲量等方面都存在問題。為滿足配用電海量時間序列數據的存儲要求，分析了關系型數據庫優缺點，提出采用分布式數據庫HBase構建電力系統數據中心以提高系統性能，并重點分析了HBase數據存儲機制及實現方法，最后通過仿真實驗進行對比。實驗結果表明，基于HBase的配用電海量時間序列數據存取技術在存儲及查詢操作上具有較大的性能優勢。

關鍵詞： 配用電； 時間序列數據； 南方電網； 分布式數據庫； 存儲機制； 仿真實驗

中圖分類號： TN911?34； TP333 文獻標識碼： A 文章編號： 1004?373X（2017）13?0159?05

Abstract： The relational database is widely used in the Southern Power Grid to store the massive time series data of distribution grid， and the technology modes of sub?library， zoning， sub?table and unified index used for optimization have the problems in the aspects of flexibility， scalability and storage capacity. To meet the requirements of massive time series data storage of distribution grid， the advantages and disadvantages of the relational database are analyzed， and a distributed database HBase is presented to construct the data center of the electric power system to improve the system performance. The HBase data storage mechanism and implementation method are analyzed emphatically. The simulation experiments are carried out to compare the performance. The experimental results show that the HBase?based massive time series data storage technology of distribution grid has great performance advantages in storage and query operation.

Keywords： distribution grid； time series data； China Southern Power Grid； distributed database； storage mechanism； simulation experiment

0 引 言

近幾年，智能化伴隨著電子信息技術的發展逐步深入電網，智能電網成為電力行業研究和應用的熱點[1]。智能電網的重要特征之一便是電網的信息化，為應對電網工作中的各種變化，需逐步推進信息獲取、傳送與存儲利用的變革，從而形成供電網絡的全面自動化[2]。在南方電網范圍內，基于配網自動化、計量自動化、實時數據中心的配用電海量時間序列數據，目前還是運用關系型的數據庫進行數據存儲管理。

傳統關系型數據庫如MySQL，Oracle等得到了較為廣泛的傳播和應用，海量數據的存儲解決方案也主要使用關系型數據庫。傳統關系型數據庫基于關系和對象模型，對復雜數據存儲有較高的表現力。然而隨著用電信息采集、配電自動化等系統不斷完善，配用電環節產生的數據逐漸呈現出海量、數據項復雜、處理邏輯復雜、存儲周期長、計算頻度高等大數據特征，因此對于數據量的存儲技術要求不斷提高，關系型數據庫漸漸無法滿足海量數據存儲對可擴展性的要求[3?4]。

隨著HBase技術的不斷發展，為解決電力設備數據存儲遇到的各種問題提供了新的解決思路。結合配用電海量時間序列數據的特點和國內電網公司的應用需求，本文用HBase構建一個分布式、可伸縮的時間序列數據庫。首先介紹了HBase數據存儲技術及應用優勢，隨后對系統架構及系統存儲實現等進行分析和設計，最后，對設計的存儲系統進行性能測試，驗證了本文所提方案在智能電網海量時間序列數據處理上的性能優勢。

1 HBase分布式數據庫

1.1 HBase技術

關系型數據庫在20世紀70年代提出，由于基礎訪問簡單，操作便捷，在之后便迅速發展成主流架構模型，其中包括關系數據結構、關系操作集合以及關系完整性約束。關系型數據庫經過長久發展已相當成熟，如：Informix，Oracle，access，DB2，MySQL，SQLServer，Sybase等均在系統應用中被廣泛使用，這些數據庫對操作權限都有很好的控制能力[5]。在電網業務中，時間序列數據往往被抽象為結構化的數據模型，存儲在關系型數據庫中，而關系型數據庫的行列模式在存儲不同采樣周期的時間序列數據時，會造成存儲空間的極大浪費，查詢效率也隨著數據規模的增大而降低。

不同于傳統面向行存儲的關系數據庫，HBase（Hadoop Database）[6?7]是一種面向列存儲的非關系型數據庫，具有高可擴展性、高可靠性等特性，是一種高性能的分布式數據庫，設計之初便是針對海量數據（TB或PB級別）的存儲和高速讀寫，用以解決關系型數據庫在處理海量數據時的理論和實現上的局限性。HBase在非結構化、大數據存儲、分析方面具有較強性能，相比關系型數據庫更適合配用電海量時間序列數據的存取實現。文獻[8]在電力系統中證明了HDFS，HBase分布式計算的效率高于Oracle集中存儲式傳統計算的效率。文獻[9]提出了基于Hadoop和HBase的輸電線路綜合數據的存儲方案，有效地解決了非結構化數據難以存儲的問題。文獻[10]借鑒當今較為成熟的開源分布式NoSQL列式數據庫HBase，面向電網大數據設計并研發了分布式實時數據庫管理系統。HBase存儲技術得到了飛快的應用。

1.2 HBase架構

HBase居于NoSQL[11]和關系數據庫之間，HBase的系統架構如圖1所示。

系統采用主/從（Master/Slave）的體系結構，由客戶端庫（Client），分布式協調服務組件（Zookeeper），主服務器（HMaster，HBase Master Server），多臺Region服務器（Region Server），以及底層文件系統（HDFS）構成。HDFS是建立在大型集群上可靠存儲大數據的文件系統，是分布式計算的存儲基石[12]?；贖FDS的HBase能夠很好地支持海量數據的存儲。

HBase存儲的是一張物理表，實質是一個分布式的多維度排列的持久化映射，HBase中的數據依靠行關鍵字（Row Key）、列關鍵字（Column）、時間戳（Timestamp）進行檢索并生成索引實現映射[13]。HBase以列為基本單位，一列或者多列構成行，行和列的交叉點為一個單元格（Cell），其內容是不可分割的字節數組，由時間戳來標識。

HBase概念視圖如表1所示。在HBase中數據存儲時，行數據的存儲和管理是嚴格按照字典順序進行，當Table數據量不斷增大時，會自動分裂形成多個HRegion，不同的HRegion可以用StartKey和EndKey來標識，并分配給相應的HRegionServer管理。

2 基于HBase配用電海量時間序列數據存儲技術

2.1 配用電海量時間序列數據存儲技術

在電網業務中，數據采集的對象多且復雜，包括變電站設備、配電饋線設備、用戶用電設備以及各類計量裝置等各類設備的運行參數和狀態信息。時間序列數據是指按照時間順序取得的一系列觀測值，是一種重要的非結構化數據類型，在營銷、生產、調控、運行監控等多方面有著深入而廣泛的應用[14]。隨著該類數據量的急劇增長，存儲空間需求越來越大，傳統數據庫處理能力逐漸無法滿足要求。

2.2 HBase數據表的設計

HBase作為一種列存儲數據庫，數據的排序和檢索都依靠Row Key進行，它關系到以后數據存取的效率問題。因為是非關系型數據庫，Row Key中不僅要包含對應數據各種屬性信息，而且要用最合理的方式進行組合。為了提高數據導入效率和查詢效率，提出配用電數據的行關鍵字生成規則。

為方便數據查詢，表2設計行鍵為采集設備所在路號、采集時間的字符串組合，共有一個列族Info，該列族下只有一個列，用以存儲采集設備的MAC地址，便于構建設備信息與采集設備MAC之間的映射。表3存儲了現場采集設備的采樣數據信息，行鍵為采集設備的MAC地址加電表ID的組合MAC：ID，HBase表中每行數據都帶有時間戳，插入數據的時候由HBase自動生成，表明該數據的采集時間。本文為了測試功能，僅僅設計了一個列族Current，Current下共有100列，即V1，V2，…，V100，表示一個工頻周期內采集的100個數據點，用于描述采樣點的采集數據信息。完成相應的HBase表的設計后，接下來釆集點的信息就可以經過一定的轉換寫入HBase中。

3 HBase配用電時間序列數據存儲實現

在數據存儲的過程中，預寫日志（Write?Ahead Log，WAL）和實際存儲數據文件是HBase存儲數據的主要形式。這兩種文件主要由HRegionServer進行管理。數據到達HDFS后可能會以更小的塊的方式進行存儲，由于HBase的?ROOT?表的相關信息存儲在Zookeeper里， Client首先聯系Zookeeper集群查找行鍵（Row Key），客戶端獲取存儲?ROOT?表的對應Region節點，從?ROOT?表中獲取.META.表的信息，其中包含請求的行鍵信息，.META.表所在服務器的信息在本地得以緩存，每次通過.META.服務器即可獲取客戶端查詢的行鍵數據所在Region的服務器名。

3.1 HBase數據上傳

數據上傳HBase過程如圖2所示。為模擬實際場景里的數據產生網絡，實驗中使用一臺PC機當做數據生成發送端。每條數據包括采樣數據的各個采樣點，各個數據之間用逗號隔開。數據接收端也是存儲客戶端，完成從發送端接收實時數據并上傳到HBase的功能。

3.2 HBase寫數據流程

現在的HBase數據庫都是通過WAL保證HBase的可靠性，當數據在寫入到HRegion前都將封裝各WAL，并被寫入到HLog，HLog會被同步到所在文件系統，保證HBase的可用性以及遭遇故障后的可恢復性。圖3大致描述了HBase寫操作時的執行流程。具體步驟為：

（1） Client發起數據寫請求給HRegionServer，并將請求匹配到將被寫入的HRegion上面；

（2） 將數據寫入到MemStore中，并同時檢查MemStore狀態；

（3） 封裝相應的WAL，并將日志同步到底層的文件系統；

（4） 判斷MemStore是否滿，是，則將MemStore中的數據Flush到文件系統；

（5） Flush請求被HRegionServer處理，數據被寫成HFile文件并存到HDFS，寫操作基本完成。

3.3 HBase讀數據流程

HBase數據庫是嚴格按照HTable的Row Key進行存儲的，并且HBase還會為Row Key建立索引。所以可以運用這一機制，把經常作為條件進行查找的列組合到Row Key設計中，這樣就相當于給這些列建立了相關的索引。本文只研究以二維表的方式建立索引。讀取一條完整的數據記錄的過程如圖4所示。

在使用HBase的存儲模型來存儲索引表時，由于HBase的特性索引表同樣會被分Region進行存儲，因此訪問索引表的過程也會存在一個定位操作。

由圖4可以看出，當用戶讀取數據時，要對HBase進行兩次查找。由于索引表也是HTable，所以運用HTable的特性，把要查找的列定為索引表的Row Key，而索引表對應的數據表的Row Key和Time Stamp設計為索引表的Value?？梢钥闯?，HBase讀取一次數據需要進行兩次訪問，兩次均以Row Key方式訪問，而非全表掃描，所以當數據量很大時，這種二級索引的方式非常有效。

4 仿真試驗對比

4.1 實驗環境

硬件環境：3臺服務器，1個Namenode，2個Datanode，其中Namenode為CPU四核八線程，內存4 GB，硬盤1 TB，Datanode為CPU雙核四線程，內存2 GB，硬盤500 GB；軟件環境：操作系統為Ubuntu 10.10，相關軟件版本：Hadoop分布式安裝Hadoop 1.0.3，HBase版本為0.96.2，Zookeeper版本為3.4.5，JDK 1.6.0，MySQL版本為5.5。

4.2 存儲性能測試

測試用例設計的目的是為了通過模擬用戶的行為，對系統在實際應用中的情況進行性能測試。設計完整個系統后，為了評價基于HBase的海量時間序列數據存儲的性能，要對HBase集群的性能進行測試，具體到HBase集群中就是對數據的存儲及查詢操作。為對比HBase 0.96.2和MySQL 5.5的存儲、查詢等性能指標，由三臺配置相同的Hadoop集群組成分布式文件系統，構成一個邏輯HBase集群，同時由一臺機器測試MySQL。所設計測試平臺具有存儲、查詢和顯示等常用功能，并記錄了測試數據和測試日志，為以后進一步的比對測試提供依據。

在前面搭建的HBase集群上，采用固定單個文件大小且增大文件數量的方法進行測試，單個文件大小約為5 MB，文件數量由2個增至200個。每次測試都重復三次，采取取平均值的方式確定最后的測試結果。測試結果如圖5所示。圖6顯示的是對數據進行寫入操作過程中的延時性能情況。

從圖5中可以看出，當文件個數較小時，HBase數據中心與MySQL數據中心的性能相差不大，但當插入文件數持續增大時，MySQL的存儲耗時出現較大波動，而HBase耗時變化幅度相對較小，數據寫入HBase數據庫的時間遠小于MySQL數據庫的時間。寫入文件個數為200時，MySQL消耗時間75.3 min，而HBase數據中心消耗時間約39.7 min，數據寫入時間縮短約47.3%，優勢明顯?；贖Base開源系統，由于頻繁觸發Split和Compaction會造成數據讀寫延遲，圖6是數據進行寫入操作過程中的延時性能情況，可知，HBase的延時性能隨著數據的增多不會出現較大的波動，而MySQL波動則相對較大，隨著時間的推移愈加明顯。

4.3 查詢性能實驗測試

對HBase集群進行查詢性能測試，測試兩種解決方案在讀取數據量為1 000～100 000的查詢性能，見圖7。

從圖7可以看出，在數據量較少時，HBase比MySQL耗時稍多。隨著數據量的增大，HBase耗時增加，但幅度變化不大，而MySQL查詢耗時隨數據量的增長上升很快，在100 000數據條數時的耗時是HBase的2.8倍。

圖8是數據延時情況對比，從圖8中可以看出，在數據查詢時，兩種情況下的時間延時均沒有較大波動，HBase相較MySQL延時時間的變化更加平緩，系統運行更加穩定。

5 結 語

本文從智能電網的要求出發，針對傳統的數據存儲方法在處理海量時間序列數據上存在的不足，提出一種基于HBase的數據存儲方案，適合于配用電海量時間序列數據的存儲，并且給出了存儲方案實現的具體系統架構及存儲原理，最后與傳統關系數據庫MySQL在存儲與查詢效率方面做了對比測試。結果表明，本文方法在配用電海量時間序列數據的數據存儲與查詢等方面具有顯著優勢。

參考文獻

[1] DIAMANTOULAKIS P D， KAPINAS V M， KARAGIANNIDIS G K. Big data analytics for dynamic energy management in smart grids [J]. Big data research， 2015， 2（3）： 94?101.

[2] 陳春霖，陳琰.信息化服務“智能電網”的初步探索[J].華東電力，2009，37（6）：895?898.

[3] 宋亞奇，周國亮，朱永利.智能電網大數據處理技術現狀與挑戰[J].電網技術，2013，37（4）：927?935.

[4] 任凱，鄧武，俞琰.基于大數據技術的網絡日志分析系統研究[J].現代電子技術，2016，39（2）：39?41.

[5] 喬曉明， 陳有為.基于SQL Server構建數據挖掘應用[J].現代電子技術，2011，34（4）：35?37.

[6] 葛微，羅圣美，周文輝，等.HiBase：一種基于分層式索引的高效HBase查詢技術與系統[J].計算機學報，2016，39（1）：140?153.

[7] 雷曉鳳，李強，孫功星.基于HBase的高能物理數據存儲及分析平臺[J].計算機工程，2015，41（6）：49?56.

[8] 張明，王瑋，施建華，等.電力大數據調度云的優化[J].計算機仿真，2014，31（11）：123?126.

[9] 于恒友，劉波，彭子平.基于HBase的輸電線路綜合數據存儲方案設計[J].電力科學與技術學報，2014，29（2）：58?64.

[10] 崔文順，張芷怡，袁力哲，等.基于云計算的日光溫室群物聯網服務平臺[J].計算機工程，2015，41（6）： 294?299.

[11] 吳燕波，薛琴，向大為，等.云平臺下的NoSQL分布式大數據存儲技術與應用[J].現代電子技術，2016，39（9）：44?47.

[12] 孟海東，肖銀龍，宋宇辰.基于Hadoop的Dirichlet樸素貝葉斯文本分類算法[J].現代電子技術，2016，39（4）：29?33.

[13] CHANG V， WILLS G. A model to compare cloud and non?cloud storage of big data [J]. Future generation computer systems， 2016， 57： 56?76.

[14] 劉博，郭建勝.改進的多元時間序列符號化表示方法研究[J].計算機仿真，2015，32（1）：314?317.