TDEngine在煤矿综采管控平台中的应用
一、行业背景
智能综采管控平台,是将煤矿综采工作面传感器数据采集,通过可视化界面展示。实现综采工作面的透明化展示,并基于历史的传感器数据进行机器学习的训练,了解工作面周期来压,设备故障检测等数据应用。因此针对于综采工作面的数据采集具有很深刻的应用。
二、现状
综采工作面是井工煤矿采煤的最重要的系统,是煤矿主要关注的系统之一,同时也是井工煤矿最危险的区域。因此针对于综采工作面的可视化,已经相关的研究是十分重要的。下面我将介绍煤矿综采工作面的相关数据情况。
数据种类
煤矿综采工作面一般由以下几个部分组成:液压支架系统,采煤机,刮板机系统,运输机,转载机、破碎机、乳化泵、清水泵等一系列设备及其系统组成。其中:
- 液压支架系统主要用于支护整个工作面,我们需要采集其中的压力等一系列的传感器,其中压力数据可以用于研究周期来压等一系列研究
- 采煤机系统主要是用于割煤,我们同时要采集其中数据,针对于采煤机工况数据进行设备故障检测等功能。
- 其他系统类似,我就不一一赘述了。
数据量
- 根据实际矿山应用,综采工作面的传感器大概在12000~20000个,如果是大型煤矿其中传感器数量会更多。
- 按照我们现在的采集频率,我们一秒钟采集一次所有的数据,采集的内容包括:哥哥传感器的感知数据、设备的开关故障的信号、电流、电压等一系列数据。
- 按照上述的采集数据,我们平均一天会产生十亿条以上的原始数据。平均一天会产生原始数据50G以上。
上图为一天采集原始数据量截图。
数据应用
针对于数据应用有两个方面,一方面是用于管控平台的可视化展示,另一个是针对于数据进行挖掘,将数据应用于算法模型训练。
三、技术选型
针对于这个规模大数据的存储,我们针对于技术进行了选型
MySQL
MySQL作为一个十分常用的关系型数据库,其核心采用平衡树进行数据的存储,当数据量大于2000万条时,二叉树会分裂,索引会增加一层。因此当MySQL数据量大于2000万条后,其查询效率是急剧下滑的。为了应对这个情况,我们也做了一些优化措施,类似于分库分表、以及保留变化值等方式。其效果永远都不理想,因此我们放弃了MySQL的方案。
Hadoop方案
Hadoop作为一个大规模数据存储方案,常应用于大数据等解决方案,其中对于大规模数据的存储的优势十分明显。虽然Hadoop可以存储这个数据,但是其中MapReduce的查询速度还是太慢。虽然我们通过替换MapReduce的处理引擎为Spark显著提高了数据查询的效率,但是Hadoop集群的部署成本以及维护成本十分的高。我们因此放弃了Hadoop的方案
TDengine
最后我们调研了时序数据库TDengine,其中的技术优势十分适合我们
- TDengine的维护成本远远小于hadoop,并且还可以存储大量的数据
- TDengine的文档齐全,技术学习成本比较小
- TDengine的超级表可以实现我们不同类型的设备进行建模,通过设备子表来分别存储设备的数据
- TDengine采用了高性能的数据压缩格式,在不影响查询效率的情况实现了数据压缩的功能,从而减少了数据存储的成本。
- TDengine具有高性能的查询能力,其中毫秒级的查询速度满足管控平台的应用。
四、技术方案
数据架构
下面我将介绍系统的整体架构设计,我将分为四个部分介绍整体数据架构设计:1.设备层;2.协议层;3.数据库;4.数据应用
上图为整体的数据架构图,其中:
- 设备端:综采系统各个应用子系统,该层为数据的产生端
- 协议层:协议层为工业协议层,该协议层将设备端的数据进行转化和收集
- 数据库:该层主要存储设备端产生的数据,其中消息中间件为数据暂存
- 数据应用层:该层为设备端的数据应用,例如提供给管控平台使用等。
数据采集、清洗治理流程图
说完了数据的整体架构,下面我将介绍数据采集、数据清洗治理的整体的流程,我们使用的数据平台采用的lambda架构,通过历史库的数据来校准实时库数据。
上图为数据整体流程图,我将详细介绍各个流程中的作用
- 设备端产生数据,我们撰写数据采集软件,通过工业协议进行相关数据的采集
- 采集软件将采集的数据的数据进行处理后,发送到消息中间的同时,并将数据输出到文件中
- 通过Spark Streaming程序处理消息中间件的数据,一部分存储到TDEngine中,另一部分发送到Redis中。其中发送到TDEngine中的数据为实时库,该实时库主要为管控平台使用。Redis数据库通过唯一key,只保留最新的一条传感器数据,应用于大屏监控。
- 采集软件采集的数据文件,经过加工处理后存储到TDEngine中,该TDEngine为历史库,其主要作用是校准实时库和为算法模型训练使用。
消息中间件数据和主题设计以及数据处理方式
为了更好的进行数据数据拆分,因此我们针对于消息中间的主题进行划分,进而实现综采工作面的子系统数据的划分,具体划分规则如下:
- 按照设备类别创建数据主题,同一类型的数据发送到同一的消息中间件主题中
- 发送到消息中间件的数据字段中包含有设备编号,通过区别设备编号与消息中间件topic名称拼接,通过查询设备编号和设备子表的映射关系,实现数据的分发。该流程为Spark Streaming程序,经过该流程可以实现无效数据的过滤。
- 针对于Redis中的设备数据的key设计规则为:设备类别+编号+传感器标签,中间使用分隔符”|“进行拼接的方式建立唯一索引。
- 针对于采集软件备份的数据,我们通过定时任务(T+1)进行Spark数据处理任务的调度,通过批处理的方式来校准历史数据。
TDEngine中的数据库设计以及数据建模
为了更好的管理和查询数据,我们需要针对于传感器数据进行建模。由于TDEngine存在有超级表和子表的概念,因此我们针对于该基础下,建立了以下的数据模型。下面,我将用液压支架系统演示数据建模的。
-- 创建超级表
CREATE STABLE YYZJ (
ts timestamp,
QZ_Pressure float,
HZ_Pressure float,
Valve01_status int,
Valve01_Failed int,
...
) TAGS (
bracket_id int
);
-- 创建子表
CREATE TABLE YYZJ0001
USING YYZJ (
bracket_id
) TAGS (
1
);
其中,bracket_id用于表示设备编号。由于矿井下会存在多个液压支架,其中部署的传感器数量和数据类型一致,因此通过超级表设置液压支架数据的模型。
为了更加容易索引指定的设备,为此设计了一下的子表的名称的规则:
- 子表的名称采用设备类型+编号构成
- 其中前面四个字母设计为表示设备类型
- 后面的四位数据表示设备的编号
索引加速
为了更加容易的索引到指定的数据,因此我们基于MySQL建立了二级索引,其中具体的实施方式为:
- 通过抽离各个超级表的原始字段,建立超级表名称和字段类型的映射关系,这样可以根据超级表知道设备传感器类型信息。
- 通过抽离子表以及子表的编号与超级表的映射关系,这样可以通过超级表知道设备表的映射关系。
- 抽离设备子表与设备id的映射关系,可以通过设备id查询到设备子表。
五、展望
TDEngine 是一个十分优秀的时序数据库,我们暂时使用在综采系统的管控。希望后续随着业务的扩大,我们能更好的应用于智慧矿山的感知层数据存储。