作者：宁龙 华自科技
小 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和磁盘空间少；
- 支持集群：能够集群部署，容量可水平扩展；
- 安装维护简单: 数据量较小的情况下，支持单机部署，并且占用资源较少；
我们了解了多款典型的时序数据库（Time-Series Database）产品，最终InfluxDB、庚顿、麦杰、TimescaleDB、TDengine这几款进入了我们的考察范围。下面我们来具体看一下：
1.InfluxDB
在开源时序数据库领域长期霸榜，社区活跃，生态也比较丰富，性能也算中规中距，唯一的缺陷就是集群模块不开源。
2.庚顿、麦杰
两者都是传统老牌工业领域的时序数据库王者，功能、性能都非常不错，唯一的缺点就是不开源，只有商业版，而且价格昂贵。
3.TimescaleDB
它是在PostgreSQL之上开发的一个插件，是基于关系数据库的时序数据库，对于我们现有的业务使用几乎无感知，上层可以继续用MyBatis、JPA等ORM框架，但它不是一个纯粹的时序数据库；另外，它对集群支持不好，不支持水平扩展。
4.TDengine
支持使用类SQL查询语言来插入或查询数据，内嵌消息队列和缓存机制、无历史数据与实时数据之分、分布式架构，支持线性扩展、支持多副本，无单点故障。看到官网的这些介绍，瞬间感觉TDengine就是为我们准备的，于是马上做了各种验证，结果表明，TDengine完全符号我们的选型要求。
为什么没有采用传统Hadoop生态
提到大数据，人们可能第一反应就会想到Hadoop生态。因此我们前期也考查过腾讯云的TBDS数据套件。说实话那一套东西真的是太笨重了，Hadoop、HBase、HDFS、ZooKeeper、Hive、Spark\Flink这系列的东西搞下来，还真不是一般团队能玩得转的，另外我司的业务场景不止云端服务，还有可能会私有化部署在站内，硬件条件可能也就是一两台状况一般的服务器。
三、TDengine存储模型设计
由于TDengine Database可以设置将最新一条数据存储在内存中，因此我们利用这个特性替换掉了用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特性
我们直接使用TDengine提供的缓存（Cache）功能，替换了原有系统中的Redis。创建数据库直接开启cachelast=1，将每张表的最后一条记录缓存，应用程序通过last_row函数快速获取实时数据。
在我们的业务场景中有一类数据叫SOE事件告警数据，这类数据要实时动态在前端页面上滚动。原有做法是通过页面轮训来实现的，现在直接使用taos的数据订阅功能，配合WebSocket，可以优雅地实现这一功能，大大提升了用户体验。
3.其它一些很用的功能
比如降采样查询、多表聚合查询、各种标准函数等。
五、改造迁移
由于TDengine采用了类SQL的语法，支持MyBatis等ORM框架，因此对于老的业务，我们在代码层面的改动非常少，改动最多的就是将原来的MySQL函数结合应用代码的一些计算逻辑直接用TDengine的函数替换掉。
在试运行阶段，因为我们都是通过自研数据网关将数据通过TCP发送上来的，所以我们利用tcp-copy，将数据复制一份存到TDengine集群，然后通过业务系统观察和验证各项功能是否正常。
验证正常之后，就是历史数据的迁移了。由于TDengine的表结构与原来的MySQL存储结构基本类似，因此我们采用DataX的TDengine插件，很方便就将历史数据迁移过来了。
至此，我们就用TDengine Database替换了原有的存储架构。
总结
初始接触一个新产品，难免会遇到一些困难。好在办法总比困难多，在同事们的支持下，在TDengine的工程师们的支持下，我们总算是基本完成了这次实时数据存储查询的升级改造。
当前项目数据测点大概在18万左右，改造后数据存储周期由原来的5分钟减少到1秒钟，存储的数据维度更精细了，能为平台的智能诊断、智能分析服务提供更准确的数据支持，同时各业务场景下的计算查询性能也提升了不少，数据库服务器由原来的6台减少到目前的3个节点集群。
最后来个小广告
TD-Workbench 是一个基于Electron构建的，针对时序数据库TDengine的图形化管理工具。具有跨平台、易于使用、版本适应性强等特点。(gitee地址：https://gitee.com/bhdweb/tdengine-workbench)
TD-Workbench是本人利用周末的时间，参考开源社区部分优秀代码设计并实现的，目前已经开源。 这个仅代表我本人的业余好爱，与公司或某个组织无关，欢迎大家去star/fork。由于TDengine官方并未提供客户端GUI工具，社区目前能找到的两款工具都不是很完善。本工具是在TDengineGUI基础上改造而来，部分源码来自此处。
作者介绍：
宁龙，码云昵称【村口的大爷】，目前就职于华自科技。后端程序猿一个，混迹Java界十余年，就爱写点代码。一杯茶一首歌，一个参数秀一天。
