适用于电网多元数据的通用事件驱动型数据模型

鲍丽山 何金陵 唐灏 朱朝强 陈立政

摘 要 作为一种面向列的、分布式的、高容错的数据库，HBase由于其容量大、随机读取快和优良的批量处理的性能，逐渐被制造业所采用。电网通常从多元数据源中产生大量的数据。与服务于关系查询的传统关系数据库不同，HBase中JOIN操作性能很低。在HBase的应用中，如何存储数据以保证JOIN运算和随机读取的充分性能是必须解决的关键问题。在本文中，我们提出了一种事件驱动型的HBase数据模型来解决这个问题。在我们的数据模型中，每一条数据记录都被定义为发生在电网中的唯一事件。来自各数据源的各类数据都可以在数据库中加以区分。因此，我们的数据模型可以存储由电网设备产生的多源数据。此外，我们通过在表中设计一个特定的RowKey，提高了集成在我们的数据模型中的JOIN运算操作从多个数据源读取数据的性能。我们还提出了一种包含了新型虚拟列族的方案，它解决了存储多源数据的兼容性问题。通过设计特定的限定符来实现虚拟列族。为了验证我们数据模型的有效性，我们在Hadoop平台上进行了实征性研究以比较我们的优化方案和原始方案。实验结果表明，我们的数据模型确保了优化后的方案比基于原始数据模型的方案更好。

【关键词】数据库 数据模型 电网

1 引言

在大数据时代，人类产生的数据量迅速接近ZB（ZeraByte），数据量如此之大，超过了传统关系数据库的处理能力，例如Oracle和SQLServer。 为了克服传统数据库的容量问题，谷歌设计并实现了GFS和BigTable来支持它们的事务。之后，Apache 软件基金会开发了开源软件Hadoop。Hadoop是一种用于处理分布式数据集的框架。Hadoop Common、HDFS（Hadoop Distributed File System）、Hadoop YARN和Hadoop MapReduce都是其中的模块。在Hadoop框架的基础上，开发了许多软件，如Ambari、Avro、Cassandra、Hive、HBase、Spark等，以处理不同类型的计算需求。 HBase是运行在HDFS之上的一种由BigTable建模的一个分布式的、可扩展的、基于列的数据库。HBase的数据文件存储在HDFS上。因为HBase的容量很容易扩展，故HBase的容量达到可以存储数十亿行数据。 并且通过添加更多节点，然后配置集群，可以很容易地扩展HBase的容量。随着大数据的开发和工具的改进，越来越多的企业将Hadoop作为其分布式计算框架并且将HBase作为其交易数据库。Facebook采用HBase作为消息基础设施。Twitter在其整个Hadoop集群上运行HBase。Hadoop和HBase也被应用于云计算的基础架构。 随着越来越多的公司使用HBase来支持他们的交易，我们可以看出HBase可以满足大多数应用程序的容量和随机读写或大量读写要求。

虽然HBase由于其巨大的容量而被像电网这样的企业所采用，但是HBase在复杂的数据类型中处理多源数据的效率并不高，尤其是在查询需要JOIN操作的时候。众所周知，电网是一个庞大而复杂的网络，由各种设备组成，如电线、输变电设备、监控设备、温度传感器等。即使只是EMS的电线，参数也很多，数据量也很大。每种设备都有许多参数来代表它的特征。为了使电网正常工作，避免设备异常引起的巨大损失，电网中设备的状态需要被定期监测。在监测数据的基础上，电网公司可以对设备状态进行评估，预测潜在异常或实现电网异常检测工作。

然而，在电网中有大量的设备，每个设备都有许多指示其状态的参数。因此，电网产生的数据数据量大，种类多，速度快。 考虑到容量和可扩展性需求的前提下，HBase是存储电网数据的最佳选项。但是HBase有一个本征缺陷，即HBase不支持JOIN操作，因此其在不同的表之间执行JOIN操作的性能很差。但JOIN操作是一个通用操作。这是HBase的主要缺陷。与旧数据源的兼容性是HBase实现多源数据迁移的另一个问题。电网数据可以來自不同的平台，比如以前存储在MySQL、SQLServer、Oracle等传统数据库中的数据需要迁移到新的大数据平台。而且EMS（Energy Management System）、QX（Weather）、WQX（Miccro climate）和YSP（Oil Chromatographic）是电网系统中普遍和关键的数据源。若要存储多源数据，必须考虑到在 HBase 系统的储存兼容性问题。

从电网数据中存储多源数据到HBase的主要问题有两个：HBase问题不支持JOIN操作，以及多源数据兼容性方面的问题。为了解决HBase不支持JOIN操作的缺陷，已经有大量的研究工作围绕其展开。但这些工作主要集中于JOIN操作在HIVE或MapReduce方面的优化。为了适应使用HBase的多数据源的数据，有人对此做了许多研究，并提出了一些HBase数据模型。但在这些方法中没有讨论JOIN操作因此，并没有一个通用的HBase数据模型，使其不仅支持连接操作，而且对多源数据也具有良好的兼容性。在本文中，我们将提出一种通用的HBase数据模型，支持JOIN操作，并具有多源数据的兼容性，从而解决上述问题。为了提高查询性能，我们进一步提出了一个虚拟列族机制。通过使用事件驱动型数据模型，使电网生成的所有数据只能存储在一个大表中。JOIN操作被集成到表中，该方法提高了从多数据源读取数据的性能。在虚拟列族机制中，我们解决了将多源数据存储到一个大表中的兼容性问题。本文里，首先第一章介绍了大数据的背景、大数据技术的发展、电网大数据的特点、面临的问题和本文的主要工作论文的其余部分组织如下。第二章我们对相关工作进行了调查，并确定了我们想要解决的问题在第三章我们提出了一种RowKey设计方案和虚拟列族机制的概念来解决这个问题，并分析了HBase的读取数据和HBase的存储层次以及我们方案的优势 在第四章，我们建立并实施实验验证了我们的方案。实验结果保证了我们推论的合理性。所以在第五章 我们证明了我们的方案是正确和有效的。

2 相关工作和问题的确立

2.1 相关工作

大数据技术已被广泛应用于电网系统。Hadoop和HBase是电网数据中心的基础设施。存储这些详细数据的主要目的是评估设备的状态，避免设备异常引起的损坏。在这种情况下，从HBase读取数据是很常见的。然而，从HBase读取的数据量也许很小，但大多数情况下，阅读数据的频率都很高。HBase集成了一些优化阅读特性的方法。Bloom Filter 被集成到HBase中以加快查询速度，但它只能加速Get操作，这意味着从HBase表中随机读取的性能可以用布隆过滤器进行改进，但布隆过滤器不能改善扫描操作的性能。由于HBase是一个非关系型数据库，由于HBase是一个非关系型数据库，因此，除了无法加速扫描操作之外，HBase还不支持JOIN操作，这是它的一个主要缺陷。但数据之间的关系是普遍而重要的，需要通过分析多源多维数据揭示一些隐藏的有价值的信息。要找到潜在的有价值的关系或信息，查询多源数据是一个普遍的需求。为了解决这个问题或优化JOIN操作，已经做了很多工作。Hive是一个提供类似SQL的接口的成熟而流行的工具，它支持JOIN操作。但是，Hive JOIN的查询性能很差，执行JOIN操作的其他部分是在MapReduce环境中完成的。在MapReduce环境中，JOIN是在Map过程或Reduce过程中实现的，或者是二者共同实现的。由于MapReduce是一个并行的计算框架，所以并行性能提高了JOIN的性能。但MapReduce方法的缺点是，结果必须被写入HDFS或HBase。而MapReduce 的设置过程非常耗时。因此MapReduce JOIN不适用于在线分析过程，而只适用于大批量的线下的分析。另一方面，多源数据的兼容性是大多数应用程序的共同要求。兼容性的概念不能从索引中分离出来。HBase兼容性的概念与传统数据库不同。这是因为HBase旨在存储非结构化的异构数据，以便任何类型的数据都可以存储到HBase中。容量不是HBase的缺點，而是优点。但读取HBase的性能主要由表的索引决定。HBase的兼容性是基于数据可以很快从HBase查询到的条件之上。在此前提下HBase的兼容性才是有意义的。于是索引的设计变得非常重要。适应多源数据已经实现：一种方法是从MySQL、SqlServer和Oracle中清除数据，然后将数据转换成JSON和XML的格式。但在本文中，我们并没有对该方法的性能进行分析，而是提出了一种混合模型。该方法的主要贡献在于提高了Hive Delete和Put 的性能。但其兼容性概念也没有被考虑到。因此，应该对HBase的兼容性概念进行说明。

2.2 问题描述

通过以上的调查和分析，我们可以看出当前研究工作的主要问题是他们没有考虑JOIN操作和其与HBase的兼容性。在这种情况下，缺乏一个统一的数据模型，使其在支持连接操作的同时考虑到多源数据的兼容性。所以主要的问题是如何设计一个数据模型既支持HBase环境下的JOIN操作也能兼容多源数据。

3 基于数据模型的HBase方案的设计与分析

3.1 方案设计

为了解决HBase不支持JOIN操作并特定了其兼容性的问题，我们提出了一个通用的数据模型。表的设计方案如图1所示。从图1我们可以看到，在表的层次结构中添加了一个虚拟列族层。我们的表设计方案是从RowKey、Column Family和Qualifier三个方面实现的，而Qualifier由虚拟列族和ColumnName组成。

3.1.1 RowKey 的设计

Rowkey主要由4个固定字节数组组成，详见图2。 设备id是第一个部分。

它由设备类型和和设备号组成。设备id编码为6个字节。 事件类型是RowKey的第二部分，它编码为2个字节。事件类型表示何种据源。事件时间是事件发生的时间。这是1970年1月1日（1/1/1970）的相对时间。事件时间是RowKey的第三部分，编码为4字节。监控设备id是RowKey的第四部分，由设备类型和设备号组成。监视设备id编码为6个字节。所有的索引段宽度都被编码成固定的以减少数据量。这也有利于扫描操作，因为RowKey中的每个部分都可以是筛选索引。比较宽度固定的未知数组比非宽度固定的数组更好。

3.1.2 Column Family 设计

从图3我们可以看到每个表只有一个Column Family。根据文献[20]的说法，ColumnFamily的数量应该不超过10个，并且一个表的ColumnFamily的总数不能超过1000。读取超过十个ColumnFamilys 时性能很差。太多的ColumnFamilys会降低Scan操作的性能，因为它还需要时间查找指定的ColumnFamily。

3.1.3 限定符设计

从图3我们可以看到，概念上的HBase表的层次结构不同于原始的HBase表的层次结构。在我们的设计中，我们添加了一个虚拟列族层。这是我们提出的一个全新的概念： 虚拟列族。虚拟列族的内容是事件类型，可以是EMS、QX或WQX等。限定符由虚拟列族和Column Name组成。具有相同事件类型的列属于相同的虚拟列族。

3.2 方案分析

我们从两个方面分析了我们方案的优势：一个方面是使用扫描操作读取数据程序，另一方面是HBase的内在存储器体系。

3.2.1 HBase读取过程分析

本文首先对HBase的数据读取过程进行了研究，找出了哪些步骤最耗时从而进行优化。HBase支持两种查询操作：获取（Get）和扫描（Scan）。为用户提供了Get和Scan的应用程序接口。Get操作查询表中有相同RowKey的多个特定版本的数据。它是在Scan操作基础上实现的。Scan操作查询大量大规模的数据。我们主要关注的是Scan操作的性能，因为在电网的设备状态评估工作中需要频繁读取大量数据。基于Scan操作表的HBase读取数据的过程是：客户端调用Read请求到主节点，然后在主节点上运行的ZooKeeper进程查找HMaster以获取表数据库meta的位置。在表数据库meta中我们可以找到存储我们查询的数据区域的位置。一旦确定了区域的位置，并将位置信息发送回客户端，客户端就直接与存储所需数据的从节点进行通信。 不同于之前将0.96作为ROOT-table并从HBase片状定位层级结构中删除的版本，HRegionServer进程在从属节点上处理读取请求，并将数据返回给客户端。

将数据从服务器返回到客户端的过程前要进行Scan操作的准备过程。对一个特定的集群来说，Scan操作的准备时间约为一个定值同时，数据传输过程也会造成一定程度的时间损耗。查询数据的时间损耗可以分为两个部分：查询准备时间和数据传输时间。

Ttotal=Tpreparation+Ttransmission （1）

正如我们在第二节中提到的，JOIN操作不像RDBMS那样支持HBase。在这种情况下，需要由用户自己进行JOIN操作。实现JOIN操作有两种方法： 通过将JOIN操作集成到表中以整合所有数据到一个大表中，或将每种类型的数据存储到相应的表中，这样就可以使用HIVE、MapReduce或编程拆分表并实现JOIN操作。如果我们传输相同数量的数据，大表和分离表的时间消耗是不同的。例如：

Tbig table=Tpreparation+Ttransmission

（2）

对于N个分离表：

Tseparated tables=N+Tpreparation+Ttransmission （3）

故大表的时间消耗比分离表的要小

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

从等式（4）中 我们可以得出：将JOIN操作集成到表中的性能要优于在客户端实现JOIN操作。

3.2.2 HBase中存储和索引的层次结构

我们研究了HBase表的层次结构（见图2）。邻域是HBase表的基本存储元素， 每个表由几个邻域组成，每个邻域包含一个或多个ColumnFamilys。表中的数据以分层的方式进行索引层次结构是：RowKey、ColumnFamily、Qualifier、timestamp和value。所有这些索引段都是按字母顺序排序的。表中的数据格式都是未知字节，故RowKey，Value等的长度可以是任意的。RowKey是最常用的索引段。限定词可以随意更改，可以随时添加、删除或修改。限定符索引表的指定列。RowKey和Qualifier是最合适的索引段。

3.2.3 优点

根据HBase表的读取过程和层次结构分析，可以看出事件驱动型数据模型的优点。首先，在我们的方案中，数据模型是由事件驱动的，因此我们可以将所有数据存储在一个大表中。任何事件发生在任何一段时间内，任何设备都可以通过筛选RowKey的索引段来确定HBase。然后，通过对大表进行Scan操作，可以从表中查询多源数据，这相当于实现了将JOIN操作应用到多个分离的表中以得到相同的数据。结合对上述读取程序的分析，我们可以看出，JOIN操作被集成到了HBase表中。这是我們数据模型的一个主要优点。更重要的是，由于 虚拟列族的内容是事件类型，旧平台上的数据可以被容纳并加以区分。RowKe和数据模型能很好地解决兼容性问题。这是数据模型的另一个优点。

4 实验

4.1 实验环境设置

实验环境基于部署配置了Hadoop和HBase的分布式集群。Hadoop集群的版本是2.6.0 64位。HBase的版本是1.1.2 64位。结果表明，该集群工作正常。集群的网络条件对其性能的影响是非常大的。因为数据是通过网络传输的，网络带宽越大，扫描操作时间就越短。因此把网络适配器的带宽和集群电线配置到 Gitgabyte，使得从HBase表查询数据的性能由表本身控制而不受传输带宽的限制。

4.2 实验设计

（1）针对我们的数据模型，HBase表设计方案和我们关注的问题，我们设计了如下实验：我们从电网中选择了EMS、WQX、QX、YSP四种作为我们实验的数据源。在电网分析系统中，从多个数据源查询数据是一个非常普遍的请求，此情景下，JOIN操作将会十分频繁。

（2）比较模式是设计四张分开的表。每个表包含一个数据源的数据。大表的数据都由四个分开的表组成。

（3）数据源EMS、QX、WQX和YSP的记录数量均与监控设备同时记录的参数数据相同。我们在6个条件下进行了测试，在每个条件下，EMS、QX、WQX和YSP的分离表分别包含100，1000，2000，5000，8000和10000条指定设备的记录。表1中比较了表的设计。

（4）将Scan操作执行到大表中以获取所需的数据，并且JOIN操作执行在相应的分离表上。每一种试验都记录并计算时间消耗。

（5）为了消除物理环境的干扰，每一种大表的Scan操作和分离表的Scan操作分别执行了20次每个实验的最终结果都是这20个数字的平均值。

5 结果和讨论

在图5（a）中， 每个数据点都显示了执行Scan操作到大表和四个分离表的时间消耗。我们可以看到，大多数情况下，扫描大表的时间消耗比扫描四张分开的表要小（等于执行JOIN操作的时间）。在图5（b）中，每一栏显示了在不同指定数据采集条件下分别对大表和四个分离表执行Scan操作的平均时间消耗。这也表明，大表的平均时间消耗小于分离表。

在图6（a），我们可以看到，在大多数情况下，扫描大表和分离表的时间消耗的差值是负的。

图6（b）显示每种类型表的平均时间消耗差值，它们都是负的。

6 结论

在本文中，我们针对电网多源数据，提出了一种基于HBase数据库中事件驱动型的多源数据模型。基于此模型的方案解决了多源数据的兼容性问题。我们进一步提出了一个新的虚拟列族机制来提高查询性能。基于Hadoop 平台的HBase实验表明：

（1）虚拟列族 是电网从旧平台和多信源存储数据的解决方案。可压缩问题由虚拟列族解决。

（2）事件驱动型数据模型中，每一块数据都可以与大表区分开来，是将电网所有数据存储在一个大表中的有效解决方案。

（3）通過将所有数据存储到一个大表中，因为不需要来自不同表的联合数据，故将JOIN操作集成到事件驱动型的数据模型中。此方案与将数据存储在分离表中相比，JOIN操作更容易得到数据模型的支持。

此后，我们将根据所提出的数据模型，探索基于HBase存储的调度问题。我们下一步的工作是将额外的限定符加入下一版的虚拟列族。

参考文献

[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.”OReilly 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.国网江苏省电力公司信息通信分公司 江苏省南京市 210000

2.国网江苏省电力公司 江苏省南京市 210000

3.北京友友天宇系统技术有限公司 北京市 100022