分布式时序数据库的存储架构设计及实现方案

前言

伴随着工业4.0的持续推进,工业设备的智能化以及企业的信息化改造将快速推进,由此也带来了数据的爆发式増长,对传统的时序数据库在点数规模、数据分布、可靠性、扩展性等多个方面提出了巨大的挑战。对比研究目前国际领先的时序数据库产品PI、PHD,发现这些产品在面对工业时序大数据时都具有如下的局限性:

(1)数据存储服务未能实现分布式架构,当单机服务异常时将导致服务不可用,无法提供检索和存储功能;

(2)数据存储无多副本机制,数据的安全性需要用户自己备份,无法保证在磁盘损坏时所有的数据拥有可靠的备份;

(3)缺乏灵活的动态扩展能力,当存储性能或者存储容量达到瓶颈时难以做到动态的水平扩展;

(4)数据检索能力有限,仅仅支持按照时间戳的检索条件,对于按值范围或者模糊检索不支持;

(5)计算能力有限,仅仅能够根据其提供的有限的计算方法进行计算,无法有效地利用大数据分布式计算技术实现对海量数据的计算分析。

当前互联网大数据技术正在蓬勃发展,在存储领域,以Hadoop生态系统为基础构件的大数据存储平台在企业中不断地得到大规模应用;在实时计算领域,Storm、Flink、Spark-Streaming等分布式实时流处理引擎俨然成为实时计算的利剑,弥补了传统的定周期计算在实时性方面的不足;在大数据计算领域,MapReduce、Spark为离线批处理计算和内存计算提供了有效的计算分析手段,有效地解决了海量数据的计算问题,为数据价值的重塑奠定了坚实的基础。大数据平台正在不断成长为企业的基础设施,发挥着越来越大甚至无法替代的作用。

基于现有的大数据开放架构,充分利用企业大数据基础设施,设计并实现可融入用户现有大数据平台生态圈的时序数据库成为技术发展的主流趋势,可有效减少多个平台的系统运维工作,节约用户成本。本文依托Storm、Hbase和Redis等分布式计算和处理技术,设计并实现了时序数据的开放式存储架构,不仅可有效应对高频时序数据的存储,而且可有效对接Spark等主流计算引擎,实现对时序数据的计算分析,挖掘潜在的数据价值。

1整体架构设计

本文所描述的分布式时序数据库由分布式数据网关、分布式消息队列、分布式实时流计算服务、分布式缓存和分布式存储服务5个部分组成,其系统架构下图所示。

分布式时序数据库架构
分布式时序数据库架构

各功能模块组件功能介绍如下。

(1)分布式数据网关:分布式数据网关由负载均衡服务(LB)和多个数据网关构成(GW),通过分布式数据网关实现数据的接收与查询代理,该网关完全采用无状态设计模式,从而任何一台网关的异常都不会导致整个系统的异常;

(2)分布式消息队列:分布式消息队列采用开源的Kafka消息队列,由多个Broker节点组成,通过分布式消息队列实现数据的发布与订阅功能,该消息队列必须满足高吞吐量、高可靠性和持久化能力,从而实现数据的可靠传输;

(3)分布式实时流计算服务:基于分布式实时流处理框架Storm,实现了消息订阅(Notify Bolt)、内存快照存储(Memstore Bolt)和持久化存储(Persistent Bolt)3个服务,通过实时流计算服务,对于上传的数据进行计算、变化订阅通知、内存快照存储与持久化存储,该框架必须满足动态可扩展,高可用和实时性,任何一台节点的宕机不会影响数据的处理,确保数据可以被流式框架中的所有数据处理任务执行,同时可以动态地在流计算服务中新增任务,满足对实时流处理的动态需求;

(4)分布式缓存:基于NoSQL数据库Redis进行设计,通过分布式缓存存储数据快照,也就是数据的最新值,确保数据的实时检索性能;

(5)分布式存储服务:分布式存储服务是通过NoSQL数据库Hbase进行存储,通过分布式搜索引擎Solr实现数据的检索,分布式存储服务是用来做工业数据的持久化存储,其必须满足大容量、高可靠、高性能、数据副本安全、动态扩展和对基于
其上的分布式计算框架的支持,是整个分布式时序数据库的核心。

2数据存储架构设计

时序数据通常是由点名、值、时间戳、数据质量4个部分组成,其在分布式缓存服务和分布式存储服务中存储结构分别如下图所示。

分布式数据缓存服务数据存储格式
分布式数据缓存服务数据存储格式
分布式存储服务数据存储格式
分布式存储服务数据存储格式

缓存数据存储架构:分布式缓存服务采用Redis的hmset数据结构,存储Tag点对应的数据项。通过该设计,用户可以快速地查询一个点的实时值,无需迭代;

分布式存储架构:采用Hbase的无模式稀疏设计,将不同的Tag点数据放在同一行,通过时间作为主键,可快速地基于时间范围迭代查询历史记录,并且满足基于时间的数据分析的需求。

3数据处理流程设计

3.1时序数据存储流程

分布式时序数据库数据存储流程设计如下。

(1)系统初始化,分布式数据网关在分布式消息队列中创建数据存储Topic和数据变化订阅Topic,通过数据存储Topic实现数据的上传,通过数据变化订阅Topic接收数据变化,从而实现数据变化通知客户端的功能;
(2)第3方数据采集客户端调用分布式时序数据库客户端SDK传输数据;
(3)分布式数据网关的LB服务器接收到数据,将数据发送到负荷较小的数据网关节点,数据网关节点将数据发送到分布式消息队列中的数据存储Topic;
(4)分布式流式计算服务Spout从数据存储Topic中接收到订阅消息,传送给Notify Bolt;
(5)Notify Bolt判断数据是否变化以及该数据是否被客户端订阅,如果满足变化和被订阅的条件,将该数据通过数据变化订阅Topic发布出去,并同时将数据路由到Memstore Bolt;
(6)分布式流式计算服务Memstore Bolt将数据发送到分布式缓存服务进行快照的存储,并同时将数据路由到Persistent Bolt;
(7)分布式流式计算服务Persistent Bolt将数据发送到分布式存储服务进行数据的持久化存储;
(8)分布式存储服务接收数据,一方面通过Hbase的SEP处理器将数据传输到分布式搜索引擎Solr进行数据的异步索引,另一方面通过其Hbase自身机制将数据序列化存储到Hadoop的HDFS系统中。

通过该流程,可有效保证系统的可扩展处理能力,当数据量增加时,只需要增加节点即可实现弹性扩展。

3.2时序数据检索流程

分布式时序数据库数据检索流程如下。

(1)第3方服务通过SDK提交数据查询命令到分布式数据网关;
(2)分布式数据网关根据查询类型进行分类查询,具体如下:对于内存快照查询,其直接查询分布式缓存服务;对于时间查询,直接通过Hbase的行键查询;对于按值查询,直接提交给Solr查询。
(3)分布式网关返回查询结果。

4整体架构特性分析

(1)可靠性与扩展性。整个系统采用纯分布式架构无单点故障,分布式数据网关采用Haproxy加多个数据节点的分布式部署方式,分布式消息队列基于分布式消息队列Kafka,分布式流式计算框架采用Storm,分布式存储采用Hbase,对应的数据索引采用Solr分布式搜索引擎,采用这种分布式架构系统可方便地进行节点动态扩展。
(2)数据安全性。数据传输的安全性由Kafka消息序列化机制和副本机制保证,数据处理的安全性由Storm分布式框架的容错机制和数据被处理且仅被处理一次的机制保证,数据存储的安全性则由Hbase的数据存储副本机制保证,整个系统从数据的传输、处理到最后存储均安全可靠。
(3)性能。分布式数据网关采用Netty的纯异步RPC通信框架,采用分布式的部署方式,可实现性能的任意扩展,所采用的消息队列服务、流式计算服务、分布式内存服务和分布式存储服务均具有高性能和弹性扩展的能力,整个系统的性能可通过增加节点数得到快速的提升。
(4)支持分布式计算。对于实时计算我们采用了Storm流式计算框架,仅仅需要在Storm中增加对应的数据计算Bolt即可,对于并行分布式计算,由于我们采用了Hbase+HDFS的存储方式,可方便地采用Spark分布式计算框架对历史数据进行计算分析。
(5)支持多维度查询。采用HBase的行键索引和Solr索引相集合,可实现对于数值的多种复杂条件组合查询,例如正则表达式查询。

5总结

本设计方案给出了一种纯分布式时序数据库的架构设计和实现方法,可有效地解决传统的时序数据库在应对工业大数据在可靠性、扩展性、检索和其上的计算支撑能力的不足,能够有效提升企业的智能化和信息化水平,并利用大数据技术挖掘潜在的数据价值,为企业的转型发展提供坚实的数据基础。
目前该设计方案在普通的4台x86服务器(内存配置为128 GB,CPU 为 Intel Xeon E5-2660 v3,硬盘:SATA 7200RPM x 10)进行测试,实现了每秒400万条时序数据的存储能力,并且整个系统运行稳定,可有效节约用户成本,系统采用CDH作为基础Hadoop管理平台,可独立部署也可使用用户现有的Hadoop平台,有效减少多套平台运维工作。

0

发表评论

邮箱地址不会被公开。