鮑麗山 何金陵 唐灝 朱朝強 陳立政

摘 要 作為一種面向列的、分布式的、高容錯的數(shù)據(jù)庫，HBase由于其容量大、隨機讀取快和優(yōu)良的批量處理的性能，逐漸被制造業(yè)所采用。電網(wǎng)通常從多元數(shù)據(jù)源中產(chǎn)生大量的數(shù)據(jù)。與服務(wù)于關(guān)系查詢的傳統(tǒng)關(guān)系數(shù)據(jù)庫不同，HBase中JOIN操作性能很低。在HBase的應(yīng)用中，如何存儲數(shù)據(jù)以保證JOIN運算和隨機讀取的充分性能是必須解決的關(guān)鍵問題。在本文中，我們提出了一種事件驅(qū)動型的HBase數(shù)據(jù)模型來解決這個問題。在我們的數(shù)據(jù)模型中，每一條數(shù)據(jù)記錄都被定義為發(fā)生在電網(wǎng)中的唯一事件。來自各數(shù)據(jù)源的各類數(shù)據(jù)都可以在數(shù)據(jù)庫中加以區(qū)分。因此，我們的數(shù)據(jù)模型可以存儲由電網(wǎng)設(shè)備產(chǎn)生的多源數(shù)據(jù)。此外，我們通過在表中設(shè)計一個特定的RowKey，提高了集成在我們的數(shù)據(jù)模型中的JOIN運算操作從多個數(shù)據(jù)源讀取數(shù)據(jù)的性能。我們還提出了一種包含了新型虛擬列族的方案，它解決了存儲多源數(shù)據(jù)的兼容性問題。通過設(shè)計特定的限定符來實現(xiàn)虛擬列族。為了驗證我們數(shù)據(jù)模型的有效性，我們在Hadoop平臺上進(jìn)行了實征性研究以比較我們的優(yōu)化方案和原始方案。實驗結(jié)果表明，我們的數(shù)據(jù)模型確保了優(yōu)化后的方案比基于原始數(shù)據(jù)模型的方案更好。

【關(guān)鍵詞】數(shù)據(jù)庫 數(shù)據(jù)模型 電網(wǎng)

1 引言

在大數(shù)據(jù)時代，人類產(chǎn)生的數(shù)據(jù)量迅速接近ZB（ZeraByte），數(shù)據(jù)量如此之大，超過了傳統(tǒng)關(guān)系數(shù)據(jù)庫的處理能力，例如Oracle和SQLServer。 為了克服傳統(tǒng)數(shù)據(jù)庫的容量問題，谷歌設(shè)計并實現(xiàn)了GFS和BigTable來支持它們的事務(wù)。之后，Apache 軟件基金會開發(fā)了開源軟件Hadoop。Hadoop是一種用于處理分布式數(shù)據(jù)集的框架。Hadoop Common、HDFS（Hadoop Distributed File System）、Hadoop YARN和Hadoop MapReduce都是其中的模塊。在Hadoop框架的基礎(chǔ)上，開發(fā)了許多軟件，如Ambari、Avro、Cassandra、Hive、HBase、Spark等，以處理不同類型的計算需求。 HBase是運行在HDFS之上的一種由BigTable建模的一個分布式的、可擴展的、基于列的數(shù)據(jù)庫。HBase的數(shù)據(jù)文件存儲在HDFS上。因為HBase的容量很容易擴展，故HBase的容量達(dá)到可以存儲數(shù)十億行數(shù)據(jù)。 并且通過添加更多節(jié)點，然后配置集群，可以很容易地擴展HBase的容量。隨著大數(shù)據(jù)的開發(fā)和工具的改進(jìn)，越來越多的企業(yè)將Hadoop作為其分布式計算框架并且將HBase作為其交易數(shù)據(jù)庫。Facebook采用HBase作為消息基礎(chǔ)設(shè)施。Twitter在其整個Hadoop集群上運行HBase。Hadoop和HBase也被應(yīng)用于云計算的基礎(chǔ)架構(gòu)。 隨著越來越多的公司使用HBase來支持他們的交易，我們可以看出HBase可以滿足大多數(shù)應(yīng)用程序的容量和隨機讀寫或大量讀寫要求。

雖然HBase由于其巨大的容量而被像電網(wǎng)這樣的企業(yè)所采用，但是HBase在復(fù)雜的數(shù)據(jù)類型中處理多源數(shù)據(jù)的效率并不高，尤其是在查詢需要JOIN操作的時候。眾所周知，電網(wǎng)是一個龐大而復(fù)雜的網(wǎng)絡(luò)，由各種設(shè)備組成，如電線、輸變電設(shè)備、監(jiān)控設(shè)備、溫度傳感器等。即使只是EMS的電線，參數(shù)也很多，數(shù)據(jù)量也很大。每種設(shè)備都有許多參數(shù)來代表它的特征。為了使電網(wǎng)正常工作，避免設(shè)備異常引起的巨大損失，電網(wǎng)中設(shè)備的狀態(tài)需要被定期監(jiān)測。在監(jiān)測數(shù)據(jù)的基礎(chǔ)上，電網(wǎng)公司可以對設(shè)備狀態(tài)進(jìn)行評估，預(yù)測潛在異?；?qū)崿F(xiàn)電網(wǎng)異常檢測工作。

然而，在電網(wǎng)中有大量的設(shè)備，每個設(shè)備都有許多指示其狀態(tài)的參數(shù)。因此，電網(wǎng)產(chǎn)生的數(shù)據(jù)數(shù)據(jù)量大，種類多，速度快。 考慮到容量和可擴展性需求的前提下，HBase是存儲電網(wǎng)數(shù)據(jù)的最佳選項。但是HBase有一個本征缺陷，即HBase不支持JOIN操作，因此其在不同的表之間執(zhí)行JOIN操作的性能很差。但JOIN操作是一個通用操作。這是HBase的主要缺陷。與舊數(shù)據(jù)源的兼容性是HBase實現(xiàn)多源數(shù)據(jù)遷移的另一個問題。電網(wǎng)數(shù)據(jù)可以來自不同的平臺，比如以前存儲在MySQL、SQLServer、Oracle等傳統(tǒng)數(shù)據(jù)庫中的數(shù)據(jù)需要遷移到新的大數(shù)據(jù)平臺。而且EMS（Energy Management System）、QX（Weather）、WQX（Miccro climate）和YSP（Oil Chromatographic）是電網(wǎng)系統(tǒng)中普遍和關(guān)鍵的數(shù)據(jù)源。若要存儲多源數(shù)據(jù)，必須考慮到在 HBase 系統(tǒng)的儲存兼容性問題。

從電網(wǎng)數(shù)據(jù)中存儲多源數(shù)據(jù)到HBase的主要問題有兩個：HBase問題不支持JOIN操作，以及多源數(shù)據(jù)兼容性方面的問題。為了解決HBase不支持JOIN操作的缺陷，已經(jīng)有大量的研究工作圍繞其展開。但這些工作主要集中于JOIN操作在HIVE或MapReduce方面的優(yōu)化。為了適應(yīng)使用HBase的多數(shù)據(jù)源的數(shù)據(jù)，有人對此做了許多研究，并提出了一些HBase數(shù)據(jù)模型。但在這些方法中沒有討論JOIN操作因此，并沒有一個通用的HBase數(shù)據(jù)模型，使其不僅支持連接操作，而且對多源數(shù)據(jù)也具有良好的兼容性。在本文中，我們將提出一種通用的HBase數(shù)據(jù)模型，支持JOIN操作，并具有多源數(shù)據(jù)的兼容性，從而解決上述問題。為了提高查詢性能，我們進(jìn)一步提出了一個虛擬列族機制。通過使用事件驅(qū)動型數(shù)據(jù)模型，使電網(wǎng)生成的所有數(shù)據(jù)只能存儲在一個大表中。JOIN操作被集成到表中，該方法提高了從多數(shù)據(jù)源讀取數(shù)據(jù)的性能。在虛擬列族機制中，我們解決了將多源數(shù)據(jù)存儲到一個大表中的兼容性問題。本文里，首先第一章介紹了大數(shù)據(jù)的背景、大數(shù)據(jù)技術(shù)的發(fā)展、電網(wǎng)大數(shù)據(jù)的特點、面臨的問題和本文的主要工作論文的其余部分組織如下。第二章我們對相關(guān)工作進(jìn)行了調(diào)查，并確定了我們想要解決的問題在第三章我們提出了一種RowKey設(shè)計方案和虛擬列族機制的概念來解決這個問題，并分析了HBase的讀取數(shù)據(jù)和HBase的存儲層次以及我們方案的優(yōu)勢 在第四章，我們建立并實施實驗驗證了我們的方案。實驗結(jié)果保證了我們推論的合理性。所以在第五章 我們證明了我們的方案是正確和有效的。

2 相關(guān)工作和問題的確立

2.1 相關(guān)工作

大數(shù)據(jù)技術(shù)已被廣泛應(yīng)用于電網(wǎng)系統(tǒng)。Hadoop和HBase是電網(wǎng)數(shù)據(jù)中心的基礎(chǔ)設(shè)施。存儲這些詳細(xì)數(shù)據(jù)的主要目的是評估設(shè)備的狀態(tài)，避免設(shè)備異常引起的損壞。在這種情況下，從HBase讀取數(shù)據(jù)是很常見的。然而，從HBase讀取的數(shù)據(jù)量也許很小，但大多數(shù)情況下，閱讀數(shù)據(jù)的頻率都很高。HBase集成了一些優(yōu)化閱讀特性的方法。Bloom Filter 被集成到HBase中以加快查詢速度，但它只能加速Get操作，這意味著從HBase表中隨機讀取的性能可以用布隆過濾器進(jìn)行改進(jìn)，但布隆過濾器不能改善掃描操作的性能。由于HBase是一個非關(guān)系型數(shù)據(jù)庫，由于HBase是一個非關(guān)系型數(shù)據(jù)庫，因此，除了無法加速掃描操作之外，HBase還不支持JOIN操作，這是它的一個主要缺陷。但數(shù)據(jù)之間的關(guān)系是普遍而重要的，需要通過分析多源多維數(shù)據(jù)揭示一些隱藏的有價值的信息。要找到潛在的有價值的關(guān)系或信息，查詢多源數(shù)據(jù)是一個普遍的需求。為了解決這個問題或優(yōu)化JOIN操作，已經(jīng)做了很多工作。Hive是一個提供類似SQL的接口的成熟而流行的工具，它支持JOIN操作。但是，Hive JOIN的查詢性能很差，執(zhí)行JOIN操作的其他部分是在MapReduce環(huán)境中完成的。在MapReduce環(huán)境中，JOIN是在Map過程或Reduce過程中實現(xiàn)的，或者是二者共同實現(xiàn)的。由于MapReduce是一個并行的計算框架，所以并行性能提高了JOIN的性能。但MapReduce方法的缺點是，結(jié)果必須被寫入HDFS或HBase。而MapReduce 的設(shè)置過程非常耗時。因此MapReduce JOIN不適用于在線分析過程，而只適用于大批量的線下的分析。另一方面，多源數(shù)據(jù)的兼容性是大多數(shù)應(yīng)用程序的共同要求。兼容性的概念不能從索引中分離出來。HBase兼容性的概念與傳統(tǒng)數(shù)據(jù)庫不同。這是因為HBase旨在存儲非結(jié)構(gòu)化的異構(gòu)數(shù)據(jù)，以便任何類型的數(shù)據(jù)都可以存儲到HBase中。容量不是HBase的缺點，而是優(yōu)點。但讀取HBase的性能主要由表的索引決定。HBase的兼容性是基于數(shù)據(jù)可以很快從HBase查詢到的條件之上。在此前提下HBase的兼容性才是有意義的。于是索引的設(shè)計變得非常重要。適應(yīng)多源數(shù)據(jù)已經(jīng)實現(xiàn)：一種方法是從MySQL、SqlServer和Oracle中清除數(shù)據(jù)，然后將數(shù)據(jù)轉(zhuǎn)換成JSON和XML的格式。但在本文中，我們并沒有對該方法的性能進(jìn)行分析，而是提出了一種混合模型。該方法的主要貢獻(xiàn)在于提高了Hive Delete和Put 的性能。但其兼容性概念也沒有被考慮到。因此，應(yīng)該對HBase的兼容性概念進(jìn)行說明。

2.2 問題描述

通過以上的調(diào)查和分析，我們可以看出當(dāng)前研究工作的主要問題是他們沒有考慮JOIN操作和其與HBase的兼容性。在這種情況下，缺乏一個統(tǒng)一的數(shù)據(jù)模型，使其在支持連接操作的同時考慮到多源數(shù)據(jù)的兼容性。所以主要的問題是如何設(shè)計一個數(shù)據(jù)模型既支持HBase環(huán)境下的JOIN操作也能兼容多源數(shù)據(jù)。

3 基于數(shù)據(jù)模型的HBase方案的設(shè)計與分析

3.1 方案設(shè)計

為了解決HBase不支持JOIN操作并特定了其兼容性的問題，我們提出了一個通用的數(shù)據(jù)模型。表的設(shè)計方案如圖1所示。從圖1我們可以看到，在表的層次結(jié)構(gòu)中添加了一個虛擬列族層。我們的表設(shè)計方案是從RowKey、Column Family和Qualifier三個方面實現(xiàn)的，而Qualifier由虛擬列族和ColumnName組成。

3.1.1 RowKey 的設(shè)計

Rowkey主要由4個固定字節(jié)數(shù)組組成，詳見圖2。 設(shè)備id是第一個部分。

它由設(shè)備類型和和設(shè)備號組成。設(shè)備id編碼為6個字節(jié)。 事件類型是RowKey的第二部分，它編碼為2個字節(jié)。事件類型表示何種據(jù)源。事件時間是事件發(fā)生的時間。這是1970年1月1日（1/1/1970）的相對時間。事件時間是RowKey的第三部分，編碼為4字節(jié)。監(jiān)控設(shè)備id是RowKey的第四部分，由設(shè)備類型和設(shè)備號組成。監(jiān)視設(shè)備id編碼為6個字節(jié)。所有的索引段寬度都被編碼成固定的以減少數(shù)據(jù)量。這也有利于掃描操作，因為RowKey中的每個部分都可以是篩選索引。比較寬度固定的未知數(shù)組比非寬度固定的數(shù)組更好。

3.1.2 Column Family 設(shè)計

從圖3我們可以看到每個表只有一個Column Family。根據(jù)文獻(xiàn)[20]的說法，ColumnFamily的數(shù)量應(yīng)該不超過10個，并且一個表的ColumnFamily的總數(shù)不能超過1000。讀取超過十個ColumnFamilys 時性能很差。太多的ColumnFamilys會降低Scan操作的性能，因為它還需要時間查找指定的ColumnFamily。

3.1.3 限定符設(shè)計

從圖3我們可以看到，概念上的HBase表的層次結(jié)構(gòu)不同于原始的HBase表的層次結(jié)構(gòu)。在我們的設(shè)計中，我們添加了一個虛擬列族層。這是我們提出的一個全新的概念： 虛擬列族。虛擬列族的內(nèi)容是事件類型，可以是EMS、QX或WQX等。限定符由虛擬列族和Column Name組成。具有相同事件類型的列屬于相同的虛擬列族。

3.2 方案分析

我們從兩個方面分析了我們方案的優(yōu)勢：一個方面是使用掃描操作讀取數(shù)據(jù)程序，另一方面是HBase的內(nèi)在存儲器體系。

3.2.1 HBase讀取過程分析

本文首先對HBase的數(shù)據(jù)讀取過程進(jìn)行了研究，找出了哪些步驟最耗時從而進(jìn)行優(yōu)化。HBase支持兩種查詢操作：獲?。℅et）和掃描（Scan）。為用戶提供了Get和Scan的應(yīng)用程序接口。Get操作查詢表中有相同RowKey的多個特定版本的數(shù)據(jù)。它是在Scan操作基礎(chǔ)上實現(xiàn)的。Scan操作查詢大量大規(guī)模的數(shù)據(jù)。我們主要關(guān)注的是Scan操作的性能，因為在電網(wǎng)的設(shè)備狀態(tài)評估工作中需要頻繁讀取大量數(shù)據(jù)?；赟can操作表的HBase讀取數(shù)據(jù)的過程是：客戶端調(diào)用Read請求到主節(jié)點，然后在主節(jié)點上運行的ZooKeeper進(jìn)程查找HMaster以獲取表數(shù)據(jù)庫meta的位置。在表數(shù)據(jù)庫meta中我們可以找到存儲我們查詢的數(shù)據(jù)區(qū)域的位置。一旦確定了區(qū)域的位置，并將位置信息發(fā)送回客戶端，客戶端就直接與存儲所需數(shù)據(jù)的從節(jié)點進(jìn)行通信。 不同于之前將0.96作為ROOT-table并從HBase片狀定位層級結(jié)構(gòu)中刪除的版本，HRegionServer進(jìn)程在從屬節(jié)點上處理讀取請求，并將數(shù)據(jù)返回給客戶端。

將數(shù)據(jù)從服務(wù)器返回到客戶端的過程前要進(jìn)行Scan操作的準(zhǔn)備過程。對一個特定的集群來說，Scan操作的準(zhǔn)備時間約為一個定值同時，數(shù)據(jù)傳輸過程也會造成一定程度的時間損耗。查詢數(shù)據(jù)的時間損耗可以分為兩個部分：查詢準(zhǔn)備時間和數(shù)據(jù)傳輸時間。

Ttotal=Tpreparation+Ttransmission （1）

正如我們在第二節(jié)中提到的，JOIN操作不像RDBMS那樣支持HBase。在這種情況下，需要由用戶自己進(jìn)行JOIN操作。實現(xiàn)JOIN操作有兩種方法： 通過將JOIN操作集成到表中以整合所有數(shù)據(jù)到一個大表中，或?qū)⒚糠N類型的數(shù)據(jù)存儲到相應(yīng)的表中，這樣就可以使用HIVE、MapReduce或編程拆分表并實現(xiàn)JOIN操作。如果我們傳輸相同數(shù)量的數(shù)據(jù)，大表和分離表的時間消耗是不同的。例如：

Tbig table=Tpreparation+Ttransmission

（2）

對于N個分離表：

Tseparated tables=N+Tpreparation+Ttransmission （3）

故大表的時間消耗比分離表的要小

Tgain = （N-1）+Tpreparation （4）

從等式（4）中 我們可以得出：將JOIN操作集成到表中的性能要優(yōu)于在客戶端實現(xiàn)JOIN操作。

3.2.2 HBase中存儲和索引的層次結(jié)構(gòu)

我們研究了HBase表的層次結(jié)構(gòu)（見圖2）。鄰域是HBase表的基本存儲元素， 每個表由幾個鄰域組成，每個鄰域包含一個或多個ColumnFamilys。表中的數(shù)據(jù)以分層的方式進(jìn)行索引層次結(jié)構(gòu)是：RowKey、ColumnFamily、Qualifier、timestamp和value。所有這些索引段都是按字母順序排序的。表中的數(shù)據(jù)格式都是未知字節(jié)，故RowKey，Value等的長度可以是任意的。RowKey是最常用的索引段。限定詞可以隨意更改，可以隨時添加、刪除或修改。限定符索引表的指定列。RowKey和Qualifier是最合適的索引段。

3.2.3 優(yōu)點

根據(jù)HBase表的讀取過程和層次結(jié)構(gòu)分析，可以看出事件驅(qū)動型數(shù)據(jù)模型的優(yōu)點。首先，在我們的方案中，數(shù)據(jù)模型是由事件驅(qū)動的，因此我們可以將所有數(shù)據(jù)存儲在一個大表中。任何事件發(fā)生在任何一段時間內(nèi)，任何設(shè)備都可以通過篩選RowKey的索引段來確定HBase。然后，通過對大表進(jìn)行Scan操作，可以從表中查詢多源數(shù)據(jù)，這相當(dāng)于實現(xiàn)了將JOIN操作應(yīng)用到多個分離的表中以得到相同的數(shù)據(jù)。結(jié)合對上述讀取程序的分析，我們可以看出，JOIN操作被集成到了HBase表中。這是我們數(shù)據(jù)模型的一個主要優(yōu)點。更重要的是，由于 虛擬列族的內(nèi)容是事件類型，舊平臺上的數(shù)據(jù)可以被容納并加以區(qū)分。RowKe和數(shù)據(jù)模型能很好地解決兼容性問題。這是數(shù)據(jù)模型的另一個優(yōu)點。

4 實驗

4.1 實驗環(huán)境設(shè)置

實驗環(huán)境基于部署配置了Hadoop和HBase的分布式集群。Hadoop集群的版本是2.6.0 64位。HBase的版本是1.1.2 64位。結(jié)果表明，該集群工作正常。集群的網(wǎng)絡(luò)條件對其性能的影響是非常大的。因為數(shù)據(jù)是通過網(wǎng)絡(luò)傳輸?shù)模W(wǎng)絡(luò)帶寬越大，掃描操作時間就越短。因此把網(wǎng)絡(luò)適配器的帶寬和集群電線配置到 Gitgabyte，使得從HBase表查詢數(shù)據(jù)的性能由表本身控制而不受傳輸帶寬的限制。

4.2 實驗設(shè)計

（1）針對我們的數(shù)據(jù)模型，HBase表設(shè)計方案和我們關(guān)注的問題，我們設(shè)計了如下實驗：我們從電網(wǎng)中選擇了EMS、WQX、QX、YSP四種作為我們實驗的數(shù)據(jù)源。在電網(wǎng)分析系統(tǒng)中，從多個數(shù)據(jù)源查詢數(shù)據(jù)是一個非常普遍的請求，此情景下，JOIN操作將會十分頻繁。

（2）比較模式是設(shè)計四張分開的表。每個表包含一個數(shù)據(jù)源的數(shù)據(jù)。大表的數(shù)據(jù)都由四個分開的表組成。

（3）數(shù)據(jù)源EMS、QX、WQX和YSP的記錄數(shù)量均與監(jiān)控設(shè)備同時記錄的參數(shù)數(shù)據(jù)相同。我們在6個條件下進(jìn)行了測試，在每個條件下，EMS、QX、WQX和YSP的分離表分別包含100，1000，2000，5000，8000和10000條指定設(shè)備的記錄。表1中比較了表的設(shè)計。

（4）將Scan操作執(zhí)行到大表中以獲取所需的數(shù)據(jù)，并且JOIN操作執(zhí)行在相應(yīng)的分離表上。每一種試驗都記錄并計算時間消耗。

（5）為了消除物理環(huán)境的干擾，每一種大表的Scan操作和分離表的Scan操作分別執(zhí)行了20次每個實驗的最終結(jié)果都是這20個數(shù)字的平均值。

5 結(jié)果和討論

在圖5（a）中， 每個數(shù)據(jù)點都顯示了執(zhí)行Scan操作到大表和四個分離表的時間消耗。我們可以看到，大多數(shù)情況下，掃描大表的時間消耗比掃描四張分開的表要?。ǖ扔趫?zhí)行JOIN操作的時間）。在圖5（b）中，每一欄顯示了在不同指定數(shù)據(jù)采集條件下分別對大表和四個分離表執(zhí)行Scan操作的平均時間消耗。這也表明，大表的平均時間消耗小于分離表。

在圖6（a），我們可以看到，在大多數(shù)情況下，掃描大表和分離表的時間消耗的差值是負(fù)的。

圖6（b）顯示每種類型表的平均時間消耗差值，它們都是負(fù)的。

6 結(jié)論

在本文中，我們針對電網(wǎng)多源數(shù)據(jù)，提出了一種基于HBase數(shù)據(jù)庫中事件驅(qū)動型的多源數(shù)據(jù)模型。基于此模型的方案解決了多源數(shù)據(jù)的兼容性問題。我們進(jìn)一步提出了一個新的虛擬列族機制來提高查詢性能。基于Hadoop 平臺的HBase實驗表明：

（1）虛擬列族 是電網(wǎng)從舊平臺和多信源存儲數(shù)據(jù)的解決方案。可壓縮問題由虛擬列族解決。

（2）事件驅(qū)動型數(shù)據(jù)模型中，每一塊數(shù)據(jù)都可以與大表區(qū)分開來，是將電網(wǎng)所有數(shù)據(jù)存儲在一個大表中的有效解決方案。

（3）通過將所有數(shù)據(jù)存儲到一個大表中，因為不需要來自不同表的聯(lián)合數(shù)據(jù)，故將JOIN操作集成到事件驅(qū)動型的數(shù)據(jù)模型中。此方案與將數(shù)據(jù)存儲在分離表中相比，JOIN操作更容易得到數(shù)據(jù)模型的支持。

此后，我們將根據(jù)所提出的數(shù)據(jù)模型，探索基于HBase存儲的調(diào)度問題。我們下一步的工作是將額外的限定符加入下一版的虛擬列族。

參考文獻(xiàn)

[1]Botta，Alessio， et al.“Integration of cloud computing and internet of things：a survey.”Future Generation Computer Systems 56 （2016）：684700.

[2]Chang F，Dean J，Ghemawat S，et al. Bigtable：A distributed storage system for structured data[J].ACM Transactions on Computer Systems （TOCS），2008，26（02）：4.

[3]http：//hadoop.apache.org/.

[4]http：//hbase.apache.org/.

[5]http：//hbase.apache.org/poweredbyhbase.html.

[6]Harter T，Borthakur D，Dong S，et al.Analysis of hdfs under hbase： A facebook messages case study[C].Proceedings of the 12th USENIX Conference on File and Storage Technologies （FAST 14）.2014：199-212.

[7]Khuc V N，Shivade C，Ramnath R，et al.Towards building large-scale distributed systems for twitter sentiment analysis[C].Proceedings of the 27th annual ACM symposium on applied computing.ACM，2012：459-464.

[8]Qiu M，Ming Z，Li J，et al.Phase-change memory optimization for green cloud with genetic algorithm[J].IEEE Transactions on Computers，2015，64（12）：3528-3540.

[9]Gai K，Qiu M，Zhao H.Cost-aware multimedia data allocation for heterogeneous memory using genetic algorithm in cloud computing[J].IEEE Transactions on Cloud Computing，2016.

[10]Ma Y，Guo Z，Chen Y，et al.Multi-sourced Data Storage and Index Construction for Equipment Condition Assessment[C].Computational Intelligence and Communication Networks （CICN），2014 International Conference on.IEEE，2014：681-685.

[11]Bloom B H.Space/time trade-offs in hash coding with allowable errors[J]. Communications of the ACM，1970，13（07）：422-426.

[12]https：//en.wikipedia.org/wiki/Bloom filter.

[13]Thusoo A，Sarma J S，Jain N，et al. Hive：a warehousing solution over a map-reduce framework[J].Proceedings of the VLDB Endowment，2009，2（02）：1626-1629.

[14]Pigul A.Comparative Study Parallel Join Algorithms for MapReduce environment[J]. Proceedings of the Institute for System Programming of Russian Academy of Sciences，2012，23.

[15]Dean J，Ghemawat S.MapReduce： simplified data processing on large clusters[J].Communications of the ACM，2008，51（01）：107-113.

[16]Dean J，Ghemawat S.MapReduce：a flexible data processing tool[J]. Communications of the ACM，2010，53（01）：72-77.

[17]George，Lars.HBase：the definitive guide.”O(jiān)Reilly Media，Inc.”，2011.

[18]MENG Xiangping1，ZHOU Lai2，WANG Hui1，JI Xiu1.Applications of Hbase for heterogeneous data synchronization in smart grid[J]. Power System Protection and Control，2015，V43（24）：122-128

[19]Hu S，Liu W，Rabl T，et al.Dualtable： A hybrid storage model for update optimization in hive[C].Data Engineering （ICDE），2015 IEEE 31st International Conference on.IEEE，2015：1340-1351.

[20]Carstoiu D，Lepadatu E，Gaspar M.Hbase-non sql database，performances evaluation[C].Computer Science （1986），Master in Computer Science （1990），and PhD in Computer Science. 2010.

[21]Ding H，Jin Y，Cui Y，et al.Distributed storage of network measurement data on Hbase[C].Cloud Computing and Intelligent Systems（CCIS），2012 IEEE 2nd International Conference on.IEEE，2012，2：716-720.

[22]Wasi-ur-Rahman M，Huang J，Jose J，et al.Understanding the communication characteristics in HBase：What are the fundamental bottlenecks？[C]. Performance Analysis of Systems and Software （ISPASS），2012 IEEE International Symposium on.IEEE，2012：122-123.

作者單位

1.國網(wǎng)江蘇省電力公司信息通信分公司 江蘇省南京市 210000

2.國網(wǎng)江蘇省電力公司 江蘇省南京市 210000

3.北京友友天宇系統(tǒng)技術(shù)有限公司 北京市 100022