鮑麗山 何金陵 唐灝 朱朝強(qiáng) 陳立政

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

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

1 引言

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

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

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

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

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

2.1 相關(guān)工作

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

2.2 問(wèn)題描述

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

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

3.1 方案設(shè)計(jì)

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

3.1.1 RowKey 的設(shè)計(jì)

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

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

3.1.2 Column Family 設(shè)計(jì)

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

3.1.3 限定符設(shè)計(jì)

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

3.2 方案分析

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

3.2.1 HBase讀取過(guò)程分析

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

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

Ttotal=Tpreparation+Ttransmission （1）

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

Tbig table=Tpreparation+Ttransmission

（2）

對(duì)于N個(gè)分離表：

Tseparated tables=N+Tpreparation+Ttransmission （3）

故大表的時(shí)間消耗比分離表的要小

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

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

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

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

3.2.3 優(yōu)點(diǎn)

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

4 實(shí)驗(yàn)

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

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

4.2 實(shí)驗(yàn)設(shè)計(jì)

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

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

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

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

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

5 結(jié)果和討論

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

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

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

6 結(jié)論

在本文中，我們針對(duì)電網(wǎng)多源數(shù)據(jù)，提出了一種基于HBase數(shù)據(jù)庫(kù)中事件驅(qū)動(dòng)型的多源數(shù)據(jù)模型?；诖四Ｐ偷姆桨附鉀Q了多源數(shù)據(jù)的兼容性問(wèn)題。我們進(jìn)一步提出了一個(gè)新的虛擬列族機(jī)制來(lái)提高查詢性能?；贖adoop 平臺(tái)的HBase實(shí)驗(yàn)表明：

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

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

（3）通過(guò)將所有數(shù)據(jù)存儲(chǔ)到一個(gè)大表中，因?yàn)椴恍枰獊?lái)自不同表的聯(lián)合數(shù)據(jù)，故將JOIN操作集成到事件驅(qū)動(dòng)型的數(shù)據(jù)模型中。此方案與將數(shù)據(jù)存儲(chǔ)在分離表中相比，JOIN操作更容易得到數(shù)據(jù)模型的支持。

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

參考文獻(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.國(guó)網(wǎng)江蘇省電力公司信息通信分公司 江蘇省南京市 210000

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

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