一、行业背景

智能综采管控平台，是将煤矿综采工作面传感器数据采集，通过可视化界面展示。实现综采工作面的透明化展示，并基于历史的传感器数据进行机器学习的训练，了解工作面周期来压，设备故障检测等数据应用。因此针对于综采工作面的数据采集具有很深刻的应用。

二、现状

综采工作面是井工煤矿采煤的最重要的系统，是煤矿主要关注的系统之一，同时也是井工煤矿最危险的区域。因此针对于综采工作面的可视化，已经相关的研究是十分重要的。下面我将介绍煤矿综采工作面的相关数据情况。

数据种类

煤矿综采工作面一般由以下几个部分组成：液压支架系统，采煤机，刮板机系统，运输机，转载机、破碎机、乳化泵、清水泵等一系列设备及其系统组成。其中：

1. 液压支架系统主要用于支护整个工作面，我们需要采集其中的压力等一系列的传感器，其中压力数据可以用于研究周期来压等一系列研究
2. 采煤机系统主要是用于割煤，我们同时要采集其中数据，针对于采煤机工况数据进行设备故障检测等功能。
3. 其他系统类似，我就不一一赘述了。

数据量

1. 根据实际矿山应用，综采工作面的传感器大概在12000~20000个，如果是大型煤矿其中传感器数量会更多。
2. 按照我们现在的采集频率，我们一秒钟采集一次所有的数据，采集的内容包括:哥哥传感器的感知数据、设备的开关故障的信号、电流、电压等一系列数据。
3. 按照上述的采集数据，我们平均一天会产生十亿条以上的原始数据。平均一天会产生原始数据50G以上。

上图为一天采集原始数据量截图。

数据应用

针对于数据应用有两个方面，一方面是用于管控平台的可视化展示，另一个是针对于数据进行挖掘，将数据应用于算法模型训练。

三、技术选型

针对于这个规模大数据的存储，我们针对于技术进行了选型

MySQL

MySQL作为一个十分常用的关系型数据库，其核心采用平衡树进行数据的存储，当数据量大于2000万条时，二叉树会分裂，索引会增加一层。因此当MySQL数据量大于2000万条后，其查询效率是急剧下滑的。为了应对这个情况，我们也做了一些优化措施，类似于分库分表、以及保留变化值等方式。其效果永远都不理想，因此我们放弃了MySQL的方案。

Hadoop方案

Hadoop作为一个大规模数据存储方案，常应用于大数据等解决方案，其中对于大规模数据的存储的优势十分明显。虽然Hadoop可以存储这个数据，但是其中MapReduce的查询速度还是太慢。虽然我们通过替换MapReduce的处理引擎为Spark显著提高了数据查询的效率，但是Hadoop集群的部署成本以及维护成本十分的高。我们因此放弃了Hadoop的方案

TDengine

最后我们调研了时序数据库TDengine，其中的技术优势十分适合我们

1. TDengine的维护成本远远小于hadoop，并且还可以存储大量的数据
2. TDengine的文档齐全，技术学习成本比较小
3. TDengine的超级表可以实现我们不同类型的设备进行建模，通过设备子表来分别存储设备的数据
4. TDengine采用了高性能的数据压缩格式，在不影响查询效率的情况实现了数据压缩的功能，从而减少了数据存储的成本。
5. TDengine具有高性能的查询能力，其中毫秒级的查询速度满足管控平台的应用。

四、技术方案

数据架构

下面我将介绍系统的整体架构设计，我将分为四个部分介绍整体数据架构设计：1.设备层；2.协议层；3.数据库；4.数据应用

上图为整体的数据架构图，其中：

1. 设备端：综采系统各个应用子系统，该层为数据的产生端
2. 协议层：协议层为工业协议层，该协议层将设备端的数据进行转化和收集
3. 数据库：该层主要存储设备端产生的数据，其中消息中间件为数据暂存
4. 数据应用层：该层为设备端的数据应用，例如提供给管控平台使用等。

数据采集、清洗治理流程图

说完了数据的整体架构，下面我将介绍数据采集、数据清洗治理的整体的流程，我们使用的数据平台采用的lambda架构，通过历史库的数据来校准实时库数据。

上图为数据整体流程图，我将详细介绍各个流程中的作用

1. 设备端产生数据，我们撰写数据采集软件，通过工业协议进行相关数据的采集
2. 采集软件将采集的数据的数据进行处理后，发送到消息中间的同时，并将数据输出到文件中
3. 通过Spark Streaming程序处理消息中间件的数据，一部分存储到TDEngine中，另一部分发送到Redis中。其中发送到TDEngine中的数据为实时库，该实时库主要为管控平台使用。Redis数据库通过唯一key，只保留最新的一条传感器数据，应用于大屏监控。
4. 采集软件采集的数据文件，经过加工处理后存储到TDEngine中，该TDEngine为历史库，其主要作用是校准实时库和为算法模型训练使用。

消息中间件数据和主题设计以及数据处理方式

为了更好的进行数据数据拆分，因此我们针对于消息中间的主题进行划分，进而实现综采工作面的子系统数据的划分，具体划分规则如下：

1. 按照设备类别创建数据主题，同一类型的数据发送到同一的消息中间件主题中
2. 发送到消息中间件的数据字段中包含有设备编号，通过区别设备编号与消息中间件topic名称拼接，通过查询设备编号和设备子表的映射关系，实现数据的分发。该流程为Spark Streaming程序，经过该流程可以实现无效数据的过滤。
3. 针对于Redis中的设备数据的key设计规则为：设备类别+编号+传感器标签，中间使用分隔符”|“进行拼接的方式建立唯一索引。
4. 针对于采集软件备份的数据，我们通过定时任务（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用于表示设备编号。由于矿井下会存在多个液压支架，其中部署的传感器数量和数据类型一致，因此通过超级表设置液压支架数据的模型。

为了更加容易索引指定的设备，为此设计了一下的子表的名称的规则：

1. 子表的名称采用设备类型+编号构成
2. 其中前面四个字母设计为表示设备类型
3. 后面的四位数据表示设备的编号

索引加速

为了更加容易的索引到指定的数据，因此我们基于MySQL建立了二级索引，其中具体的实施方式为：

1. 通过抽离各个超级表的原始字段，建立超级表名称和字段类型的映射关系，这样可以根据超级表知道设备传感器类型信息。
2. 通过抽离子表以及子表的编号与超级表的映射关系，这样可以通过超级表知道设备表的映射关系。
3. 抽离设备子表与设备id的映射关系，可以通过设备id查询到设备子表。

五、展望

TDEngine 是一个十分优秀的时序数据库，我们暂时使用在综采系统的管控。希望后续随着业务的扩大，我们能更好的应用于智慧矿山的感知层数据存储。