格创东智选择TDengine，实现海量数据实时全生命周期管理

作者：唐时涛

​小 T 导读​：格创东智科技有限公司成立于2018年，孵化于中国500强企业TCL，是我国知名的工业互联网平台服务商。公司依托TCL集团40年工业场景和制造基因沉淀，基于“面向工业现场”的研发方向和“连接、协同、共享”的发展理念，深度融合人工智能、大数据、云计算、物联网等前沿技术，打造了新一代具有自主知识产权的工业互联网平台——"东智工业应用智能平台"。

作为东智工业应用智能平台产品家族的物联网平台，G-Things为工业设备提供了安全可靠的连接通信能力，其支持数据采集、规则引擎、数据转发、指令下发、数据可视化，同时提供开放的API与第三方系统快速对接，为工业企业提供高效率、低成本、高可靠的工业物联网解决方案。

从采集的数据类型上来看，平台采集的设备数据以及系统业务主要有以下时序数据特性:

• 设备所有采集的数据是时序性的、结构化的
• 设备采集点的数据源是唯一的
• 数据存在时效性
• 以写操作为主，读操作为辅
• 需要统计、聚合的实时计算操作
• 数据的查询一般指定时间区间
• 支持高频数据接入

为了让用户在最大程度上实现降本增效，G-Things在接入不同的租户时，会从用户类型(轻量级、重量级等)、设备规模、设备采集的数据量等角度帮助用户选择适配合理的时序数据持久化落地方案。

​一.​

​时序数据库选型调研​

自2019年我们便开始关注一些国内的数据库，通过调研发现TDengine很适合我们的业务场景，它拥有读写性能强大、部署简单、超强的数据压缩比等特性，同时超级表、子表的标签tag设计也很好地契合了平台物模型中的设备模型、设备概念。

为了验证TDengine在读写、存储等方面的性能，我们将其与Cassandra 、OpenTSDB在同等条件之下进行了相关的读写性能对比测试，测试结果如下：

在同等数据集和硬件环境下，对比发现：

TDengine的性能远超Cassandra和OpenTSDB，写入性能分别是两者的近20倍、25倍，读取性能约为17倍、32倍，聚合函数性能约为4000倍、1000倍，按标签分组查询性能约为2500倍、1000倍，按时间分组查询性能约为119倍、40倍，压缩比约为26倍、5倍。

基于此，TDengine在选型中脱颖而出。

​二.​

​技术架构与具体实践​

具体到实际业务中，我们使用TDengine主要存储以下三种类型的数据：

• 租户设备上抛的原始数据。经过实时计算处理后保存，租户彼此之间数据隔离，一个租户一个TDengine库
• 系统计算设备状态变更的日志数据
• 系统中跟设备关联的相关控制台的操作日志数据

TDengine在平台中的总体架构图如下所示：

相比于原架构，使用TDengine之后出现了以下变化：

• 平台接入的租户相关库、表通过监听Kafka中的binlog日志自动初始化，每个设备点设置独立一张表，数据分层清晰
• 将Cassandra、KairosDB、OpenTSDB均更换为TDengine
• 可以使用API或SDK对TDengine进行读写
• 减少了数据流流动、处理以及服务之间的消息通讯步骤
• TDengine提供的丰富函数减少了实时处理的数据计算
• TDengine提升了读写速度，减少了数据流处理时间

​1.​

​TDengine表结构设计​

具体到表结构设计上，​在我们的实际场景中，采用的是一个租户一个database的方式进行创建，这样的好处有三点：​

• 可以为不同的租户提供独立的数据库，用户数据隔离级别很高，安全性很好

• 有助于简化数据模型的扩展设计，满足不同租户的独特需求

• 如果出现故障，恢复数据相对简单

create database xxx keep 365 days 10 blocks 4 update 1；

​2.​

​设备运行数据​

设备运行数据以设备模型为超级表，该超级表命名规则为 pd_模型标志，例如：pd_devicemodel001，以设备参数为子表名。具体的建表语句如下：

create table pd_devicemodel001(ts timestamp， smallint_value smallint， int_value int，bigint_value bigint，double_value double，boolean_value bool，string_value nchar(200) ) tags( device_model_mark nchar(25) ，device_mark nchar(25)， param_mark nchar(25)) ;

如果需要创建的是单个参数的数据表，那子表命名规则是pd_模型标志_参数标志，例如：pd_devicemodel001_param01。具体的建表语句如下：

create table pd_devicemodel001_param01 using pd_devicemodel001 tags ("device01"，"did01"，"di0001");

​3.​

​设备状态变更日志​

在设备状态变更日志时超级表命名为device_state_change_log，代码如下所示：

create table if not exists device_state_change_log (ts timestamp， change_type nchar(10)， status_before nchar(10)，status_after nchar(10)) tags ( device_model_mark nchar(25) ，device_mark nchar(25));

如果是单个设备一张子表的模式，子表命名规则为 dsl_模型标志_设备标志，例如：al_model01_device01。

create table if not exists %s using device_state_change_log tags ( "devicemodleMark001"，"device01");

​4.​

​设备信息变更日志​

在设备信息变更日志时超级表命名为 device_info_change_log，代码如下所示：

create table if not exists device_info_change_log (ts timestamp， opera_user nchar(50)， change_type nchar(10)，change_info nchar(50)， info_before nchar(200)，info_after nchar(200)) tags ( device_model_mark nchar(25) ，device_mark nchar(25));

单个设备一张子表情况下，子表命名规则为 dil_模型标志_设备标志，例如：al_model01_device01。

create table if not exists %s using device_info_change_log tags ( "devicemodleMark001"，"device01" )

​5.​

​问题及解决​

我们刚开始使用的是TDengine 2.0.13.0的版本，在建表以及使用过程中遇到了一些问题，主要包括以下3点：

• TDengine数据列需要提前创建
• TDengine数据列长度不可修改
• 在新建设备操作日志表时，提示DB error: invalid SQL: row length exceeds max length (0.000505s)

在我们跟涛思数据的技术专家进行相关沟通后，他们建议将TDengine升级到2.2.2.0的最新稳定版本，该版本支持数据列的动态新增、修改。在沟通中还发现，上面问题中“建表报错”一项是因为单条记录数据超长了，按理说总长度不能超过16KB，后面我们对字段长度进行了调整，问题随即迎刃而解。

​四.​

​具体的效果展示​

接下来为大家展示一下TDengine在压缩率（存储）、写入、查询等性能上的各种数据。

​1.​

​单机写入性能​

1）模拟10个厂区的数据、每个厂区10000个监测点，每个监测点从2020-01-01 00:00:00.000开始写入模拟数据，记录时间戳间隔5秒，每个测点写入100万条记录；

2）写入的数据应当保持一致，生成方式为：将10000条真实采集的数据复制100份，时间戳按照5秒间隔自动生成，分别作为不同测点的数据写入数据库；

3）记录以下内容，并观察写入过程中客户端线程数、CPU、内存资源使用率：

• 确认1000亿条记录全部正确写入数据库
• 平均每秒写入点数
• 所有写入请求完成的总时延

​最终显示的结果为——条数/秒：2348220  总时延（秒）：42585.4531  

​2.​

​时序数据库压缩比​

1）确认1000亿条记录原始数据文件大小，不计算标签为1117.59GB，算上标签为67.666TB；

2）落盘后数据文件大小（自带缓存的时序库需重启服务保证数据文件落盘）； 3）计算压缩比=落盘后数据文件大小/原始数据文件大小； ​落盘后所有文件大小为113GB，压缩比为 10.11%

​3.​

​时序数据库单测点原始历史数据投影查询性能​

1）随机选择任一个测点，查询该测点在某个时间段内的历史数据，比如从2020-01-10 00:00:00.000 到 2020-01-11 00:00:00.000一天内的共17280条数据记录（数据输出到文件）。

数据库中对应查询语句为：

select * from pt123 where ts >= '2020-01-10 00:00:00.000' and ts <= '2020-01-11 00:00:00.000' >> /dev/null

2）记录以下内容：

• 确认查询结果、记录条数正确
• 查询总耗时

3）重复执行上述查询3次，记录平均耗时 ​具体结果为——3次平均时延（秒）：0.13785

​4.​

​时序数据库单测点原始历史数据聚合查询性能​

1）随机选择任一个测点，查询该测点在某个时间段测点采集值的count、max、min、avg，比如从2020-01-01 00:00:00.000 到 2020-02-01 00:00:00.000 31天内的共535680条数据记录的count、max、min、avg。数据库中对应查询语句为：

select count(*), max(col1), min(col1), avg(col1) from pt1231 where ts >= '2020-01-10 00:00:00.000' and ts < '2020-01-11 00:00:00.000'

2）记录以下内容：

• 确认查询结果正确
• 查询总耗时

3）重复执行上述查询3次，记录平均耗时 ​具体结果为——3次平均时延（秒）：0.010504

目前我们已经将TDengine应用在数据采集、数据处理、数据边缘计算、数据存储等诸多方面，在实际业务中也展现出了如上所示的超强性能，特别是在处理超高频的数据采集、边缘智能计算框架、数据流引擎和数据模型等方面效果显著，面对海量数据轻松实现实时全生命周期管理。

​五.​

​写在最后​

在本次项目中，TDengine展现出了强大的读写性能和数据压缩能力，聚合类查询速度非常快，也帮助我们有效降低了机器使用成本。超级表、子表、标签等概念非常适配物联网大数据应用场景，潜力无限。

未来希望TDengine发展能够越来越好，期待周边生态工具更加完善。