作者:宁龙 华自科技

小 T 导读:华自科技专一于自动化、信息化和智能化技术,为能源、环保、工业管制、水利等畛域用户提供外围软硬件产品与零碎解决方案,是多能物联技术领航企业。公司在电站及泵站自动化管制设施市场占有率寰球当先,是联合国工业倒退组织国内小水电核心管制设施制作基地。

物联网数据平台是电站及泵站智慧运维平台的外围组成,其整体架构如下:

物联网数据平台的数据起源次要为电站、水厂、储能站,通过数据网关,将各场站端的设施运行数据传输至云平台的音讯队列(MQ)中,数据处理服务订阅MQ的音讯,依据设定的规定引擎,进行实时数据处理,之后将数据存储落盘。数据服务API则依据业务需要提供蕴含实时数据和历史数据在内的数据API。

一、现状及痛点

对于历史数据,目前咱们采纳的MySQL分库分表计划来存储;实时数据会存储在Redis中。在测点数较少或者集控需要不是很多的场景下,根本满足需要。

历史数据

历史数据用MySQL存储,一个站点对应一个数据库;一个测点对应一张表,建表语句大抵如下:

CREATE TABLE `yc_测点id` (  `ts` datetime NOT NULL,  `val` double NOT NULL);

实时数据

实时数据缓存到Redis中,以测点Id为key,同时缓存数据上报的工夫、测量值和品质值等信息。

数据计算查问

咱们利用MySQL的各种函数、多表连贯、应用程序内存计算等形式,计算出后果返回给前端,对于月、年等报表类的计算,则采纳定时工作生成。

痛点

随着平台业务的倒退,接入的站点越来越多,或者单站的测点数越来越多,问题逐步凸显进去了。具体能够演绎为如下几个方面:

运维难

  • 对于新接入的站点,首先得为这个站建设好数据库、数据表,减少了接站的工作量;
  • 因为一个站对应着一个数据库,随着平台接入的站点越来越多,数据库一直减少,数据库的治理和备份老本一直进步;
  • 随着测点的减少,缓存实时数据的单机Redis迟早有一天会撑不住,须要思考保护Redis集群。

开发难

随着平台的业务倒退,越来越多的站被接入平台,集控需要(跨站聚合剖析需要)减少,跨库跨表的查问操作越来越多,这就减少了零碎开发的难度,重大影响了零碎响应速度和稳定性。

老本高

老本次要有两个方面,一个是人力老本高,因为开发、运维的难度减少,造成员工工作量减少,工作效率变低,从企业经营角度看,人力老本变高;另一个是硬件资源老本高,因为服务节点泛滥,占用的主机、内存和磁盘空间也会很多,购买或租用这些硬件资源须要收入更多费用。

二、技术选型

为了解决目前这些问题,咱们决定从新进行技术选型,寻找代替计划,降级目前数据库存储计划。联合平台理论须要,咱们确定了几个选型要求:

  • 业务改变小:尽可能减少对现有业务的影响;
  • 开源收费:必须是开源的,并且容许收费商用,最好也有商业版;
  • 迭代更新:社区沉闷,一直在迭代更新和公布新版本;
  • 性能高:单机能反对每秒10万以上的插入效率;
  • 开销低:服务节点少,占用的内存、CPU和磁盘空间少;
  • 反对集群:可能集群部署,容量可程度扩大;
  • 装置保护简略: 数据量较小的状况下,反对单机部署,并且占用资源较少;

咱们理解了多款典型的时序数据库产品,最终InfluxDB、庚顿、麦杰、TimescaleDB、TDengine这几款进入了咱们的考查范畴。上面咱们来具体看一下:

1. InfluxDB
在开源时序数据库畛域长期霸榜,社区沉闷,生态也比拟丰盛,性能也算中规中距,惟一的缺点就是集群模块不开源。

2. 庚顿、麦杰

两者都是传统老牌工业畛域的时序数据库王者,性能、性能都十分不错,惟一的毛病就是不开源,只有商业版,而且价格昂贵。

3. TimescaleDB

它是在PostgreSQL之上开发的一个插件,是基于关系数据库的时序数据库,对于咱们现有的业务应用简直无感知,下层能够持续用MyBatis、JPA等ORM框架,但它不是一个纯正的时序数据库;另外,它对集群反对不好,不反对程度扩大。

4. TDengine

反对应用类SQL查询语言来插入或查问数据,内嵌音讯队列和缓存机制、无历史数据与实时数据之分、分布式架构,反对线性扩大、反对多正本,无单点故障。看到官网的这些介绍,霎时感觉TDengine就是为咱们筹备的,于是马上做了各种验证,结果表明,TDengine齐全符号咱们的选型要求。

为什么没有采纳传统Hadoop生态

提到大数据,人们可能第一反馈就会想到Hadopp生态。因而咱们后期也考查过腾讯云的TBDS数据套件。说实话那一套货色真的是太轻便了,Hadoop、HBase、HDFS、ZooKeeper、Hive、Spark\Flink这系列的货色搞下来,还真不是个别团队能玩得转的,另外我司的业务场景不止云端服务,还有可能会私有化部署在站内,硬件条件可能也就是一两台情况个别的服务器。

三、TDengine存储模型设计

因为TDengine能够设置将最新一条数据存储在内存中,因而咱们利用这个个性替换掉了用Redis存储实时数据这个环节,改成实时数据间接查问TDengine。

TDengine里有超级表的概念,每种设施对应一个超级表。这个超级表只负责存储这种类型的设施数据,数据存储采纳横表存储。然而,这显然不合乎咱们的场景,因为在咱们的场景里没有固定的某一设施对象,且每个测点的频率都可能不统一。

同时为了尽可能减少对现有业务的影响,咱们将超表设计成如下构造:

CREATE STABLE IF NOT EXISTS stb_站点id  (    ts timestamp,        val double        ) TAGS (测id nchar(64))

TDengine的子表,能够在插入数据时动态创建,这是TDengine的一个很好用的性能。这样能省去创立子表的业务环节,升高了业务复杂度。子表构造如下:

insert into 测点类型_测点id  USING stb_站点id (测点id) VALUES ( ts, val,q)    eg:  insert into yc_15143115161750995367 USING stb_站点id ('15143115161750995367') VALUES ( ts, val,q)

四、应用到的TDengine个性

  1. 缓存(Cache)

咱们间接应用TDengine提供的缓存(Cache)性能,替换了原有零碎中的Redis。创立数据库间接开启cachelast=1,将每张表的最初一条记录缓存,应用程序通过last_row函数疾速获取实时数据。

  1. 数据订阅(Publisher/Subscriber)

在咱们的业务场景中有一类数据叫SOE事件告警数据,这类数据要实时动静在前端页面上滚动。原有做法是通过页面轮训来实现的,当初间接应用taos的数据订阅性能,配合WebSocket,能够优雅地实现这一性能,大大晋升了用户体验。

  1. 其它一些很用的性能

比方降采样查问、多表聚合查问、各种规范函数等。

五、革新迁徙

因为TDengine采纳了类SQL的语法,反对MyBatis等ORM框架,因而对于老的业务,咱们在代码层面的改变非常少,改变最多的就是将原来的MySQL函数联合利用代码的一些计算逻辑间接用TDengine的函数替换掉。

在试运行阶段,因为咱们都是通过自研数据网关将数据通过TCP发送上来的,所以咱们利用tcp-copy,将数据复制一份存到TDengine集群,而后通过业务零碎察看和验证各项性能是否失常。

验证失常之后,就是历史数据的迁徙了。因为TDengine的表构造与原来的MySQL存储构造根本相似,因而咱们采纳DataX的TDengine插件,很不便就将历史数据迁徙过去了。

至此,咱们就用TDengine替换了原有的存储架构。

总结

初始接触一个新产品,难免会遇到一些艰难。好在方法总比艰难多,在共事们的反对下,在TDengine的工程师们的反对下,咱们总算是根本实现了这次实时数据存储查问的降级革新。

以后我的项目数据测点大略在18万左右,革新后数据存储周期由原来的5分钟缩小到1秒钟,存储的数据维度更精密了,能为平台的智能诊断、智能剖析服务提供更精确的数据反对,同时各业务场景下的计算查问性能也晋升了不少,数据库服务器由原来的6台缩小到目前的3个节点集群。

最初来个小广告

TD-Workbench 是一个基于Electron构建的,针对时序数据库TDengine的图形化管理工具。具备跨平台、易于应用、版本适应性强等特点。(gitee地址:https://gitee.com/bhdweb/tden...)

TD-Workbench是自己利用周末的工夫,参考开源社区局部优良代码设计并实现的,目前曾经开源。这个仅代表我自己的业余好爱,与公司或某个组织无关,欢送大家去star/fork。因为TDengine官网并未提供客户端GUI工具,社区目前能找到的两款工具都不是很欠缺。本工具是在TDengineGUI (https://gitee.com/skyebaobao/...) 根底上革新而来,局部源码来自此处。

作者介绍:

宁龙,码云昵称【村口的大爷】,目前就任于华自科技。后端程序猿一个,混迹Java界十余年,就爱写点代码。一杯茶一首歌,一个参数秀一天。


近期taosAdapter已正式公布,反对从OpenTSDB等时序数据库向TDengine无缝迁徙,欢送浏览TDengine此前公布的技术文章,理解体验taosAdapter!