丁琳琳, 王智涵, 顾英豪, 王凯璐, 包鑫阳
(1.辽宁大学 信息学院, 辽宁 沈阳 110036; 2.辽宁煤电产业控股有限公司红阳三矿, 辽宁 辽阳 110101)
随着智慧矿山相关技术的发展,煤矿中众多微震传感器产生的时序数据呈现出爆炸式增长的态势。在时序数据规模逐渐增大的背景下,海量煤矿数据微震波形时序数据如何高效、合理地存储成为了大数据领域的亟待解决的问题,即煤矿微震波形时序大数据存储问题。时序数据具有时间序列化、时段密集化、单条数据高权重、数据产生高并发、数据总量巨大的特点[1]。煤矿微震时序波形数据作为工业时序数据中的一种,通常是由上百台工业设备的上万个传感器产生,并且各传感器之间存在着较为复杂的依赖关系,具有采样周期密集和强关联的特点[2]。
当前煤矿微震时序大数据的存储方案,通常可采用传统文件系统存储、关系数据库存储以及分布式存储三种方案。对于传统的文件系统存储方式,尽管操作简便,但需重复进行对齐操作和读取传感器波形文件操作以满足后续计算部分的数据需求,导致重复操作占据程序执行的大部分时间,并且无法对数据进行有效管理以及对数据的快速检索。对于关系型数据库存储方式,在存储煤矿微震波形时序数据时存在高并发事务场景下性能较差、扩展性差等缺点。对于分布式存储在存储时序大数据方面,尽管相对于关系型数据库已经有了一定的优化,但也存在一些缺陷,在煤矿微震波形时序大数据的存储场景下,需要考虑数据的特征关联问题、存储热点数据问题、存储分散以及海量数据存储数据阻塞问题,现有存储策略均无法较好解决。
因此,针对上述诸多问题,本文采用基于Hadoop分布式平台[3]的NoSQL非关系型数据库HBase[4]作为底层存储介质,因为其在可扩展性、并发度、分布式以及面向列存储等方面均较为突出。并结合煤矿微震波形时序数据的高并发、时间序列化以及海量数据的特点,采用适用于煤矿微震波形时序数据的表结构设计策略、预分区策略以及行键优化策略对存储性能进行优化。同时,采用Netty[5]网络通信框架编写的中间件集群作为数据中转层,对数据接收层流转而来的海量数据进行分流处理,有效避免数据阻塞问题。使用Redis内存数据库[6]的有序集合数据结构实现负载均衡算法的最小连接法[7],使Netty中间件集群中的每个节点都能够被合理地分配。最终,采用真实的传感器离线数据对实验进行了验证。
基于HBase数据库实现的开源时序数据库OpenTSDB[8]具有优秀的扩展性和伸缩性,可以轻松地水平扩展集群规模来处理大量数据。此外,文献[9]以时间序列数据的特点为中心,实现了分布式数据库存储海量时间序列数据的方法和应用。InfluxDB是一个开源时序数据库,用于处理时序数据的高性能读写操作,InfluxDB具有高性能、易扩展、数据可视化等优点[10]。基于Cassandra[11]数据库构建的开源时序数据库KairosDB支持高效存储和查询时间序列数据,Kairos还具有支持多种数据类型、提供丰富的查询接口、易于使用和部署等优点[12]。结合Logstash和Elasticsearch同样可以实现对时序数据的高效存储和查询,并具有良好的扩展性和灵活性[13]。
在HBase分布式数据库底层存储原理方面,文献[14]利用JavaNIO技术设计了一种HBaseRPC客户端的非阻塞通信模型,文献[15]则提出了一种存储大规模空间向量数据的模型,适用于处理大规模数据的应用。另外,文献[16]基于HBase与Redis高性能缓存,为图片数据的查询和存档性能做出了客观的贡献。在存储优化架构方面,文献[17]提出了四层结构,并使用Netty网络通信框架作为数据缓存中间件,该架构在金融时序数据的高并发存储场景中得到了可观的优化效果。最后,文献[18]设计并实现了三层存储架构,并将数据缓存中间件集群化处理,有效避免了高并发场景下海量传感器数据阻塞的问题。
以上述研究工作为基础,本文设计并实现了一种基于HBase与Netty的煤矿微震时序数据存储优化方案。该方案综合了多个方面的优化措施,成功解决了煤矿微震时序数据存储分散以及存储热点等问题。同时,该方案在高并发事务处理方面也有可观的优化效果,大幅提升了存储效率,为煤矿微震时序数据的存储和处理提供了有力的支撑和保障。
本文设计并实现了一种基于HBase与Netty的煤矿微震时序波形数据存储优化框架。该框架针对煤矿微震时序波形数据的特征,解决了热点数据、存储分散以及存储过程中的高并发数据阻塞等问题,从而大幅提升了煤矿微震时序波形数据的存储效率和性能。
为了应对微震监测传感器分布广、数据总量大的特点,以及高并发处理、热点数据和存储分散的挑战,本文开发了一种名为CM2TS-HBase(Coal Mine Microquake Time Series data-HBase)的煤矿微震时序波形数据存储框架,该存储框架基于HBase与Netty技术实现。图1所示为该存储框架的详细架构图。
图1 CM2TS-HBase存储框架架构图
存储引擎整体分为以下四部分。
(1)数据收集层:该层分为离线和实时两部分。离线数据就是数据中心存储在硬盘的二进制原始波形文件;实时数据就是在实际应用环境下部署在矿区的众多传感器实时产生的时序微震波形数据。下面将离线状态中的每个工作线程以及实时状态中的每个传感器统称为客户端。
(2)数据预处理层:对于离线数据需要对原始波形文件进行对齐操作,找到众多文件中时间重叠的部分进行解析并序列化,最后在多线程并发环境下将数据通过Http/3传输至数据中转层;实时传感器数据则可以直接进行解析封装序列化操作然后同样通过Http/3传输至数据中转层。
(3)数据中转层:数据中转层是基于Netty与 Redis的数据转发中间件,可以对高并发事务进行优化处理,利用负载均衡思想将单一客户端承受的压力均衡地分布给所有承担存储任务的服务器。
(4)数据存储层:基于分布式数据库HBase作为存储体系的底层存储媒介。在实验环境下,数据存储层的HBase分布式存储节点被部署在云服务器的Docker虚拟化容器中。负责存储数据中转层传来的序列化数据。
HBase是一个由众多节点组成的集群架构。优秀的主键设计可以显著提升HBase的读写效率,而且可以将一段时间内存储的数据放置在连续的物理空间内,这样也能有效地解决数据分散的问题。
主键的设计原则有四点,分别是长度原则、唯一原则、排序原则以及散列原则。本文设计了适用于时序微震波形数据特点并结合主键设计四原则的主键优化策略。主键结构示意图如图2所示。
图2 主键结构示意图
基于主键长度原则,将主键长度设置为24位,由于目前大多数服务器是64位操作系统,其内存均按照8字节对齐。因此主键设置为24位可以提高寻址效率。其中主键高9位表示行政区划代码,最小可以精确到乡级行政区;低15位是数据的时间字段,单位可以精确到秒级,基于上述主键设计,HBase在存储时首先会按照高9位进行排序,此时具有相同地区编号的数据就会被存储在连续的物理空间中;若高9位相同,就会根据低15位的时间字段按照写入时间顺序进行存储。
HBase分布式数据库存储数据的基本单位被称为分区(Region),HBase默认建表时设置一个Region,并且这个Region的主键是无边界的,因此在数据写入时,所有数据都会写入到这个默认Region,但随着数据量的不断增加,HBase会进行Split操作分割成2个Region。在这个过程中就会出现两个问题:数据不停向一个Region写入会造成热点数据问题;Split操作会消耗宝贵的集群I/O资源。
因此本文在建表时就基于上述主键特点创建了多个空的Region,并确定了每个Region的起始和终止主键,这样可以使每条数据均匀地命中各个Region,从而避免了热点数据的产生并降低了Split的发生概率。
预分区的前提是有明确的主键结构,基于上述主键结构,根据高9位的行政区划代码进行分区操作。根据地区的不同进行分类,并按照各个地区的煤矿矿区数量动态分配Region数量,分区分类见表1。本表数据来源于中华人民共和国行政区划代码1 983版本,仅以东北、华北以及华东为例。
表1 分区分类表
根据上述预分区策略对HBase数据库进行预分区操作,可将数据均匀地进行分布式存储,基本解决了煤矿微震波形时序数据在HBase分布式数据库存储时的数据热点问题。
基于煤矿微震波形时序数据特点以及多传感器网络的场景,本文设计了一种适用于此类特殊场景的数据表结构,数据表结构示意图如图3所示。
HBase分布式数据库在进行查询操作时的规则是以主键为索引进行的,主键可以确定唯一一行数据,但无法确定一个具体的Cell。本文将列族设置为具体的煤矿矿区名称,以下不同的列分别表示部署在该煤矿中的传感器代号,这样在后续的计算任务中便可以进行多维度多条件的查询。
由图3可见数据行中存储的是序列化数据,序列化的定义是为了将数据对象转换为更易进行网络传输和保持格式的过程。在存储引擎当中客户端与Netty Server之间的通信在宏观的角度看就是两个进程之间的远程交互,客户端会根据时序波形的特征将解析后的原始数据封装成固定格式的数据对象,使序列化后的数据在空间上被大幅度压缩,提高双方在远程传输数据过程的通信效率。
本节使用了两个非常流行的组件,分别是Netty框架与Redis内存数据库。该模块的架构图如图4所示。
图4 基于Netty与Redis的异步数据缓存中间件架构图
客户端(Clients),在实时状态下,每个微震波形传感器都可以被认为是一个客户端;在离线状态下,线程池中的每个发起存储请求的线程任务也可以被设定为客户端。图中步骤2、3表示客户端在发起存储请求前会从Redis缓存中查找最小连接服务器节点。图中步骤4表示客户端根据查询到的结果向当前最小连接服务器发送存储请求。
Redis缓存,该部分用于实现对中间件服务器集群的负载均衡调度。本文采用负载均衡算法中最为流行的最小连接法,使用Redis数据库中的有序集合数据结构,基于所有当前正在运行服务器的连接数进行排序,使每个发起存储请求的客户端都能获取到当前压力最小的Netty Server。
Netty Server,基于Netty框架开发的中间件服务器,并以集群的形式分布式地向HBase发送待存储数据。
CM2TS-HBase数据存储过程如图5所示。
图5 数据存储过程
原始文件解析主机开启多线程并发解析原始波形文件,并在此过程中调用数据整理器对主键进行调整并对波形数据对象进行序列化整理,使其便于网络传输。
携带整理完毕的数据发起存储请求,在请求前需要根据Redis缓存存储的中间件服务器集群中各个服务器的实时连接状态,选取最优状态的服务器进行存储。同理,每当中间件服务器开启都会将本节点的信息存入Redis中向存储请求线程提供服务;同时服务器的关闭与宕机也会进行更新操作。
存储请求线程得到最优节点信息后尝试与服务器建立测试通信,如果成功便更新节点信息并携带序列化波形数据对象发送存储请求,中间件服务器接收到请求后根据预分区策略将数据存储到对应Region中,反之将报错信息返回给客户端并记录日志,最终所有存储请求传输完成后关闭连接,并更新对应节点信息。
CM2TS-HBase存储过程算法如算法1所示。该算法时间复杂度为O(n),空间复杂度为O(n)。
算法1:CM2TS-HBase存储过程算法
Input:待存储数据 data
OutPut:存储完成状态 R
Begin
1:nserver←zrangenserset0 0
2:booleanconnected←doConnected(nserver);
3:ifconnected=false
4:zremnsersetnserver;
5:else
6:zincrbynserset1nserver;
7:whiledata←hasNext()
8:R←doWrite(data);
9:if(R=False)
10:emitR;
11:endwhile
12:else
13:continue;
End.
算法第一行通过Redis命令zrange 0 0获取到当前Netty Server服务器集合中连接数最小的服务器nserver,算法第2行到第6行表示对选中的Netty Server进行连接测试,如果连接失败,通过Redis命令zrem nserset nserver删除该服务器,如果连接成功,则通过Redis命令zincrby nserset 1 nserver将nserver的连接数加一,算法中第7行到第13行表示进入存储循环过程,通过doWrite方法向HBase数据库写入数据,并实时返回存储状态R,如果存储出现问题,R将携带报错信息返回控制台,如果存储过程未出现报错问题,则存储过程将继续循环,存储下一条数据,直到此轮存储请求结束。
实验在HBase伪分布式环境下进行。硬件环境为一台2核4G云服务器,通过Docker虚拟容器化后的4台虚拟主机组成的伪分布式集群。原始数据解析主机为一台Intel酷睿i5 8250U 8核 1.6 GHz 16 GB RAM主机对历史微震数据文件进行多线程解析存储。
软件平台为CentOS 7.6-64位、JDK-1.8、HBase-2.3.6、Zookeeper-3.4.10、Hadoop-3.1.3。服务器节点信息见表2。
表2 服务器节点信息表
本文实验设计了3种存储方案,通过对比3种方案在存储煤矿微震波形时序数据的性能表现得出最终结论。3种方案分别为:通过HBase原生客户端Put方法存储HBase(HBaseAPI);基于HBase的金融时序数据存储系统思想存储煤矿微震波形时序数据(FTBase);基于HBase与Netty的煤矿微震时序大数据优化策略存储煤矿微震时序数据(CM2TS-HBase)。
实验所用数据为2019年辽宁某煤矿真实部署传感器监测到的历史微震波形文件,每条数据包含采集时间、波形空间坐标等内容。传感器数据采集频率为5 000条/s,实验设置3个组别,分别是6文件组、12文件组以及24文件组进行并发存储,每个文件大小约250 MB。
针对煤矿微震波形时序数据的存储性能优化实验,采用2项指标作为最终评估标准。分别是:根据固定存储文件数量统计存储耗时情况以及单位时间节点存储数据量的对比。
(1) 固定文件数量统计存储耗时情况,在离线状态下,可通过离线波形文件以多线程的方式模拟出煤矿微震传感器的实时存储数据场景。同时可以统计出高并发状态下各个实验方案的存储性能。因此在单位文件数量的前提下,存储耗时越小即表示存储性能更佳,即对高并发场景的存储性能进行了有效地提升。
(2) 单位时间节点存储数据量对比,实验根据单位文件数量下存储持续时间设置实验组,分别在各实验组的时间节点统计存储的数据量。存储数据量越大就说明性能更佳。
通过对比存储总耗时区分二者的性能差距,存储总耗时实验对比结果见表3。当实验设置文件数量为6个和12个时,3种方案的实验结果相差不大。当实验将文件数量提升至24个时,HBaseAPI的处理时间明显变长,延长至167 s;同时,CM2TS-HBase存储耗时为97 s,FTBase存储耗时为78 s。CT2MS-HBase存储耗时明显低于HBaseAPI与FTBase,存储耗时对比如图6所示。
表3 实验耗时结果表
图6 存储耗时对比图
单位时间节点存储数据量实验结果如图7所示。在实验过程中,HBaseAPI的每秒钟存储数据量由持续时间20 s时的31.6×104条/s提升至持续时间120 s时的86.2×104条/s,性能有大幅度的提升。同时,通过与FTBase的对比中也可以看出负载均衡算法的引入对中间件集群的资源分配进行了合理地调整,进而提升了整体存储系统的性能。因此,在高并发场景下,CM2TS-HBase的表现更好。
图7 单位时间存储数据量对比图
本文探讨了如何基于HBase分布式数据库、Netty网络通信框架以及Redis内存数据库等技术来存储煤矿微震时序大数据。在实践中发现,由于HBase分布式数据库的自身缺陷和煤矿微震时序大数据的特点,需要采取特殊的策略来进行预分区、主键优化和数据表结构的设计。通过本文提出的策略,可以有效地提高煤矿微震时序大数据的存储效率和查询性能。
本文所述的设计思想从实际问题出发,针对煤矿微震时序大数据的存储问题提供了有效的解决方案。这对于工业界使用传感器产生的时序数据进行生产或安全维护具有重要的参考价值和实用意义。此外,本文所介绍的技术和策略也可以为其他领域的时序数据存储问题提供一些借鉴和参考。