基于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]。基于HFDS的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%，优势明显。基于HBase开源系统，由于频繁触发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.