【北物联 | AIOT产品推荐】懂TDengine的 也就懂智慧矿山操作系统了

  

导读：华夏天信RED-MOS露天煤矿智慧矿山操作系统，基于微服务架构，结合HTAP混合大数据平台，将产、运、销各环节的生产与成本数据进行深度的挖掘和分析。TDengine是当前RED-MOS系统底层采用的测点数据存储引擎，解决了我们最为头疼的历史数据回溯性能问题。

 

应用场景

华夏天信RED-MOS露天煤矿智慧矿山操作系统，本身基于微服务架构，结合HTAP混合大数据平台，平台中包含TSDB及关系数据库，数仓系统等组成运用工业数据协议转换和数据采集网关系统将产、运、销各环节的生产与成本数据进行深度的挖掘和分析，从生产运营ODS系统、成本管控BI系统和市场分析BI系统三个维度给煤炭企业决策层提供精准、实时的数据支撑，实现降低成本、提高决策效率的目标。主要包括矿山生产大数据、销售大数据、物流大数据、设备运行大数据、安全大数据、环保大数据等的大数据分析应用。

 

地面生产集控系统采用的PLC设备采集的信号统一接入智能预警平台，整合一、二期集控系统、机房状态监测系统、电气综保装置、破碎系统等数据接入RED-MOS露天煤矿智慧矿山操作系统。系统中接入的监控点数量将近15000点。其中接近2300点需要绑定组态显示，即时页面更新，整体数据采集到显示到前端要求秒级展示。

 

客户同时要求大数据量展示（历史数据回溯），可展示30天的全量数据，点数量超过50万条。读取时间要求在5~10s。这对底层的数据库提出了一个相当大的挑战。

 

数据库方案选型

对于矿山监控的数据都是大量带有时间戳的数值，本身结构简单，也没有太多关联性的查询需求；最主要的应用场景就是按设备、按时间段回溯和统计分析。这种场景中，最大难点是要处理的数据量太大，而不是关联关系复杂，因此MySQL这类关系库的关联查询优势其实无法发挥。而HBase这种大数据存储方案对于矿山系统而言太过庞大，且硬件资源要求很多，我们处于成本考虑也排除了。最终考量的是两个数据库MongoDB和TDengine。

 

MongoDB方案

MongoDB和MySQL考察时也都是集群部署，至少需要6台服务器。这个方案的缺陷如下。

 

1）比较耗费服务器资源，占用空间过大。MongoDB每次空间不足时都会申请生成一大块的硬盘空间，而且申请的量从64MB、128MB、256MB那样的指数递增，客户使用2年后数据已超过500GB历史数据备份及恢复非常痛苦。

 

2）写入速度波动大，当点位超过10,000且采集频率低于1s后，通过生产环境上线前模拟压测发现，入库数据存在10%以上比例在个别入库时间超过2s的情况存在，无法达到项目要求。

 

3）MongoDB单机稳定性比较差，通过Prometheus监控MongoDB健康度发现，当docker容器内存使用量超过80%后，MongoDB单机大比例出现无法访问的情况，导致时序数据集群发生节点切换，严重时甚至发生实时数据集群整体无法访问。

 

TDengine方案

TDengine是一个专为物联网监测场景设计的高性能的时序数据库。本身非常轻量，在解决我们对时序数据的高性能读写需求同时，大大降低了安装、部署、维护的成本，是当前RED-MOS系统底层采用的测点数据存储引擎。TDengine解决了我们最为头疼的历史数据回溯性能问题。

 

1）安装简单。安装包仅约5MB，与docker集成比较好，特别适合项目部署维护。

 

2）性能强劲。在实际生产场景中：15,000点计算及实时入库时间均为1s内（docker容器2C 8g）。大数据量展示，可展示30天的全量数据，点数量超过50万条。读取时间5~10s。整体使用期间 cpu在30%~40%之间，内存维持在6GB左右。

 

3）我们也对比数据压缩的效果，TDengine的存储空间可以节省约5~8倍，推测是因为其采用列式存储的设计，比较适合压缩时序流。这是个非常不错的提高。

 

综合考虑，使用TDengine硬件成本和开发维护成本大大降低，写入和查询速度还比MongoDB等高一个级别。

 

实际应用展示

· 厂区监测

宏观上的监控，例如对筒仓气象站的监控，需要实时刷新显示其温度、风速、风向等数据。TDengine自带最新数据的缓存，前端通过REST发送SQL直接访问TDengine就可以获取最新数据。因此相当于省掉了一部分Redis的开销。当然整个组态画面中，我们也动态展示了各个厂区间的生产作业流。

 

· 系统设备状态统计

生产极其关键的一点也是要对设备进行监测，比如对送煤过程中各条线上皮带、电机在线状态的统计展示，对电力状态、振动等进行状态量统计。

 

 

· 设备明细数据查询

二级页面也会展示设备温度、震动、电流等实时数据。由于TDengine的查询都是即席查询，本身不区分历史库和实时库，因此应用系统查询最近一小时的数据有可能是从内存中读取的，也有可能是从硬盘上读取的，这点是无法准确判断的。因此对于测点数多的场景，如果缓存数据量要求大，就尽可能在TDengine中配置较大的cache参数，让整体能够缓存更多数据，实时显示时足够快。

 

 

· 设备趋势数据回溯

对于每个电机，客户要求系统能够快速读取相关设备属性趋势图，这是我们发现TDengine最强大的地方：针对一天2万条数据展示速度在200ms内。这块我们也和官方团队有过交流，之所以TDengine对这类查询速度飞快，主要是设计时按照设备分表后，数据按块存储并按块查出来，相对Key-Value型数据库节省很多寻址时间。下图是按照历史数据查询的可视化窗口，要开放给客户去用，指定时间范围拉取所有历史数据。

 

最难的一个任务：大数据量展示，可展示30天的全量数据，点数量超过50万条。读取时间要求5秒级。目前看到只有TDengine可以做到这个性能。

 

小结

对于矿山生产系统而言，安全是第一位的。因此，各个生产环节和场地都要进行全面、有效的数字化监控。监控数据的特点就是时序、结构化、简单但量大。TDengine应该说是量身定做来处理这类数据的数据库。监控数据上报后的实时展示、历史回溯都非常快，加上本身轻量的特点，对于缩减项目开发运维成本也非常有帮助。