基于大数据的空气监测系统及方法与流程

1.本发明涉及空气监测系统技术领域，尤其涉及基于大数据的空气监测系统及方法。


背景技术：

2.空气监测指对存在于空气中的污染物质进行定点、连续或定时的采样和测量，为了对空气进行监测，一般在一个城市设立若干个空气监测点，安装自动监测的仪器作连续自动监测，将监测结果派人定期取回，加以分析并得到相关的数据，空气监测的项目主要包括二氧化硫、一氧化氮、碳氢化合物、浮尘等，空气监测是大气质量控制和对大气质量进行合理评价的基础。
3.现有技术存在以下不足：现有监测系统的过程回归模型协方差函数的超参数准确度底，使感知层不能有效对细颗粒物的空间和时间维度复杂变化台式准确跟踪，从而导致系统给的收敛效率低，不能够准确预测和吸力颗粒物多污染源的动态回溯。


技术实现要素：

4.本发明针对现有技术的不足，提供了基于大数据的空气监测系统及方法。
5.本发明通过以下技术手段实现解决上述技术问题的：基于大数据的空气监测系统，所述系统包括，
6.数据应用层：在spring环境下完成开发；
7.数据服务层：作为系统的数据过渡层，输出接口面向数据应用层服务器的api接口；
8.数据感知层；为系统的采样层，数据感知层采集多项数据用于数据应用层服务器的数据流中间件的构建中，数据服务层处理流式特征数据，并且面向未来实际部署中数据流大的特征。
9.优选的，所述数据应用层的框架设计为ssm，分别对应spring、springmvc和mybatis，数据库，应用redis与mysql实现对应用层的数据库支撑。
10.优选的，所述数据应用层包括细颗粒物的数据监测、数据溯源分析、数据预测分析、历史数据统计、节点数据比较以及环境因子影响。
11.优选的，所述数据预测分析包括高斯羽流扩散模型或社区多尺度空气质量模型。
12.优选的，上层应用从mongodb数据库读取数据，经过数据预处理模块(信号重构)的数据流用于对高斯过程回归模型的训练和预测，模型输出的空间和时间维度预测值，存入mysql数据库相应的数据表中，并通过redis缓存与mysql数据库合作完成对系统相应功能模块前端热力图的动态渲染。
13.优选的，mongodb数据库中历史统计数据样本完成对模型的训练，通过训练后模型预测未来系统设定短时间内某些时间节点的数值，通过把每个节点的训练数值输入到空间维度分布情况预测模型中，获取到未来时间细颗粒物空间分布情况，用于渲染百度地图上
层热力图。
14.优选的，mongodb数据库读取原始监测数据接入后端数据接口，获得http渲染前端界面，包括细颗粒物数据、pm1数据、pm10数据和温度湿度。
15.本发明还提供一种基于大数据的空气监测系统的监测方法，其特征在于：所述方法包括以下步骤：
16.(1)通过细颗粒物预测模块对其空间维度分布情况进行预测，获取到整个监测环境下细颗粒物在此时刻的分布情况；
17.(2)获取到此帧数据的局部、全局最优解，并标记为本帧数据的目标源；
18.(3)业务逻辑层设定细颗粒物的污染溯源阈值，当细颗粒物浓度大于这一阈值时，进行溯源分析与源点标记，并把模型的输入输出数据读入mysql数据库；
19.(4)当监测区域出现细颗粒物超标时系统会通过动态刷新的形式，同时设定相同目标源距离阈值找到同一个污染源迁移点，在前端动态刷新的过程中，把同一个迁移点用线连接起来显示。
20.本发明的有益效果：
21.本发明通过面向数据感知层、数据服务层、数据应用层三层架构系统开发，并通过百度地图aip实现了细颗粒物空间、时间维度变化态势的在线准确预测和细颗粒物多污染源的在线高效准确动态回溯。
附图说明
22.图1为本发明的系统整体构架示意图；
23.图2为本发明数据应用层的框架结构示意图；
24.图3为本发明htp请求cookie下发过程示意图；
25.图4为本发明消息队列的结构示意图；
26.图5为本发明细颗粒物预测方法的构架图。
27.图6为本发明的单台设备统计数据图。
28.图7为本发明细颗粒物溯源方法的构架图。
具体实施方式
29.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
30.需要说明的是，当元件被称为“固定于”另一个元件，它可以直接在另一个元件上或者也可以存在居中的元件。当一个元件被认为是“连接”另一个元件，它可以是直接连接到另一个元件或者可能同时存在居中元件。
31.实施例1
32.请参阅图1所示，本实施例所述基于大数据的空气监测系统，所述系统包括数据应用层、数据服务层以及数据感知层；
33.请参阅图2所示，数据应用层：数据应用层的开发在spring环境下完成，不需要依
赖于任何web服务器或者容器，框架设计为ssm，其中分别对应spring、springmvc和mybatis，数据库方面，应用redis与mysql实现对应用层的数据库支撑，此外还需要满足业务需求，包括细颗粒物的数据监测、数据溯源分析、数据预测分析、历史数据统计、节点数据比较以及环境因子影响等功能。
34.实施例2
35.请参阅图1所示，本实施例所述基于大数据的空气监测系统，所述系统包括数据应用层、数据服务层以及数据感知层；
36.请参阅图2所示，数据应用层：数据应用层的开发在spring环境下完成，不需要依赖于任何web服务器或者容器，框架设计为ssm，其中分别对应spring、springmvc和mybatis，数据库方面，应用redis与mysql实现对应用层的数据库支撑，此外还需要满足业务需求，包括细颗粒物的数据监测、数据溯源分析、数据预测分析、历史数据统计、节点数据比较以及环境因子影响等功能。
37.请参阅图3所示，数据服务层：数据服务层作为系统的数据过渡层设计，数据读入接口主要是数据库服务器作为消费者从kafka消息队列中对数据包的请求，而输出接口主要面向对应用服务器的数据支持统一的api接口，面对数据的读入，mongodb作为了kafka的数据消费者存在，mongodb作为一个(key＝》value)键值对数据库，它可以在网络或者本地创建数据镜像，使得数据库的可扩展性得到满足；
38.相较于关系型数据库的设计，mongodb在处理超大数据量的方面，击碎性能瓶颈，本实施例将mongodb作为kafka消费者使用，接收到的事件必须先转换为bson文档，然后再存储到数据库中；
39.在面向数据应用层的数据支撑作用时，系统需要统一的api接口，支持上层不同业务需求对数据的请求，需要通过一定的web访问机制来保证数据库数据安全，其中应用cookie下发，token有效期设置，添加验证码机制，防止数据爆破，此外还要对客户端上传的数据进行用户名合法性监测，长度(长度判断，存数据库)，敏感词(管理员等)，重复性判断、特殊字符(html脚本，“《”，“》”，script转意)，通过以上机制来保证系统的安全与稳定。
40.实施例3
41.请参阅图1所示，本实施例所述基于大数据的空气监测系统，所述系统包括数据应用层、数据服务层以及数据感知层；
42.请参阅图2所示，数据应用层：数据应用层的开发在spring环境下完成，不需要依赖于任何web服务器或者容器，框架设计为ssm，其中分别对应spring、springmvc和mybatis，数据库方面，应用redis与mysql实现对应用层的数据库支撑，此外还需要满足业务需求，包括细颗粒物的数据监测、数据溯源分析、数据预测分析、历史数据统计、节点数据比较以及环境因子影响等功能。
43.请参阅图3所示，数据服务层：数据服务层作为系统的数据过渡层设计，数据读入接口主要是数据库服务器作为消费者从kafka消息队列中对数据包的请求，而输出接口主要面向对应用服务器的数据支持统一的api接口，面对数据的读入，mongodb作为了kafka的数据消费者存在，mongodb作为一个(key＝》value)键值对数据库，它可以在网络或者本地创建数据镜像，使得数据库的可扩展性得到满足；
44.相较于关系型数据库的设计，mongodb在处理超大数据量的方面，击碎性能瓶颈，
本实施例将mongodb作为kafka消费者使用，接收到的事件必须先转换为bson文档，然后再存储到数据库中；
45.在面向数据应用层的数据支撑作用时，系统需要统一的api接口，支持上层不同业务需求对数据的请求，需要通过一定的web访问机制来保证数据库数据安全，其中应用cookie下发，token有效期设置，添加验证码机制，防止数据爆破，此外还要对客户端上传的数据进行用户名合法性监测，长度(长度判断，存数据库)，敏感词(管理员等)，重复性判断、特殊字符(html脚本，“《”，“》”，script转意)，通过以上机制来保证系统的安全与稳定。
46.请参阅图4所示，数据感知层：细颗粒物的监测传感器采用攀藤激光细颗粒物传感器，在温湿度的监测方面应用瑞士sensirionsht20温湿度传感器，国标/usa美标双重显示；
47.完成数据校验和硬件封装后，软件方面在硬件控制中心主函数写入一条中断，实现对指令端口的轮询，从而完成对广播机制的支持，在控制中心接收到对应的id指令后，通过串口发送一条符合之前设定协议进行编码的传感器数据；
48.硬件方面在现有的传感器监测硬件系统中添加srm1276的433m无线数传模块，无线模块可完成三层楼间的稳定通信，该接收模块性能优异，采用数字处理技术，具有抗干扰强，性能稳定，可靠性高，通过无线模块与传感器硬件系统板的串口连接，实现对指令的接收和数据的发送，终端pc的上位机每一分钟会向传感器节点发送一条带id的指令数据，与指令id匹配的节点会返回一条数据包，其中包含按要求协议的奇偶校验位；
49.pc终端方面应用usb转ttl的ft232模块，实现433m主模块与计算机的数据交付；
50.在终端pc与远程数据服务器的数据流中间件的构建中，由于用来处理活跃的流式特征数据，并且面向未来实际部署中数据流大的特征，我们选择了kafka消息发布订阅的异步数据架构，现有b/s(brower/server)系统的设计都应用消息中间件实现系统前后端的分离，kafka作为消息中间件，好比一个数据容器，把终端pc推送数据请求当作生产者，后端的数据入库当作消费者，终端pc中客户端每请求一次，后端的处理线程响应一次，但当数据库服务器宕机终端pc的请求依然还在请求时，这就会导致请求数据的丢失，造成严重的后果；
51.当传感器网络后续扩展后，终端pc每秒需求请求服务器100次，而数据库服务器每秒只能响应50次，这就会导致消息阻塞，最后出现系统超时，kafka作为中间数据容器，每次生产者客户端pc发送的数据存入kafka，消费者的消费请求就会从kafka中获取数据，完成了前后端生产者消费者的数据请求分离，为消息队列基本结构，kafka其中承担的角色就是其中单向/优先队列。
52.实施例4
53.请参阅图1所示，本实施例所述基于大数据的空气监测系统，所述系统包括数据应用层、数据服务层以及数据感知层；
54.请参阅图2所示，数据应用层：数据应用层的开发在spring环境下完成，不需要依赖于任何web服务器或者容器，框架设计为ssm，其中分别对应spring、springmvc和mybatis，数据库方面，应用redis与mysql实现对应用层的数据库支撑，此外还需要满足业务需求，包括细颗粒物的数据监测、数据溯源分析、数据预测分析、历史数据统计、节点数据比较以及环境因子影响等功能；
55.数据预测分析利用经典的扩散模型如高斯羽流扩散模型或者社区多尺度空气质量模型，可以得到比较准确的结果，共同的缺点是很难确定应用的条件，很多关键参数的设
置都很繁琐，需要的现实环境建模数据输入较多；
56.在环境科学领域，密度与空气相同或者相似的气体，其本身的重力与空气的浮力作用相抵消，这也使得气体物质在空气中的扩散分布主要受大气湍流的影响，而在大气湍流场均匀的环境下，气体或者细颗粒物的浓度按照高斯函数呈现分布规律；
57.对于空气中的气体或者细颗粒物等物质的预测应用较多的是人工神经网络模型(ann)，然而，面对室外复杂环境下的预测，人工神经网络模型输入等条件的限制可能导致模型产生复杂的网络结构进而导致预测估计时间过长，虽然我们的监测网络计划部署密度要比公共监测站大很多，但相对于真实的室外场景(整个市区，或者县区等)，整体监测数据依然呈现出小样本特征；
58.尽管人工神经网络在非线性建模方面有较强的能力，但面对这种小样本数据显得有些无力，另一方面，在细颗粒物空间维度分布预测数据需要支撑后续溯源算法的实现，要实现准确的溯源特征，就必须保证数据在突变状态下的敏感性，而人工神经网在处理非平稳数据方面跟踪性差误差较大，后续实验会给出说明。系统需要在线完成雾霾天气准确实时的细颗粒物空间维度分布预测和细颗粒物短时间内变化态势准确预测，因此对预测模型的计算时间和实现复杂度要求较高；
59.本实施中选择应用高斯过程回归模型来完成两种预测功能，其在处理小样本、非线性等复杂问题时具有很好的效果，相较于人工神经网络具有容易实现、超参数自适应获取、泛化能力强等特点，并且高斯过程回归模型在处理非平稳性问题时，跟踪性更好误差更小，更适合应用于在线预测，为了提高预测精度，引入粒子群优化算法用于协方差矩阵的超参数优化，减少超参数优化的计算冗余，提高估算精度；
60.在数据流方面，首先空气监测节点终端pc通过kafka分布式消息系统实现对数据流面向mongodb数据库的可靠交付，系统上层应用从mongodb数据库读取数据，经过数据预处理模块(信号重构)的数据流用于对高斯过程回归模型的训练和预测，模型输出的空间和时间维度预测值，存入mysql数据库相应的数据表中，并通过redis缓存与mysql数据库合作完成对系统相应功能模块前端热力图的动态渲染；
61.请参阅图5所示，在单节点时间维度预测中，线下利用mongodb数据库中历史统计数据样本完成对模型的训练，并通过训练后模型预测未来系统设定短时间内某些时间节点的数值，通过把每个节点的训练数值输入到空间维度分布情况预测模型中，获取到未来时间细颗粒物空间分布情况，用于渲染百度地图上层热力图，此外，在空间维度分布情况预测中，利用实时数据(16个节点值)来在线完成模型训练，并得到空间分布预测值，用于渲染热力图，其中在线训练模型需要利用每一帧数据训练一个新的模型。
62.请参阅图6所示，使用空气监测传感器进行监测部署，传感器节点输出的监测数据存在一定的小范围波动，加上硬件传输过程中信号噪声的污染，使得消费者mongodb从kafka数据接口读取到的传感器监测数据中会夹杂一定的噪声，从mongodb数据库读取原始监测数据接入后端数据接口，获得http渲染前端界面，单台传感器在实验环境下05小时监测历史数据统计，其中包括细颗粒物数据、pm1数据、pm10数据和温度湿度，从中可以看到数据在小范围的波动，横坐标单位缩小到2分钟，可以更清除看出数据的小范围波动，系统传感器节点的测试数据的上传频率为每20秒/次；
63.细颗粒物空间维度分布预测的模型训练和估算是在线完成的，而细颗粒物短时间
内变化态势预测的训练是离线的，估值是在线完成的，高斯过程回归模型的在线训练和预测估值本身就存在计算量大，效率低的特点，加上噪声的存在一方面会加大模型计算量影响模型效率，另一方面会增加模型预测估算误差，这就会增加服务器负担，降低前后端交互的效率，影响用户的服务体验，如果在并发量高的状态下，很可能导致后端吃不消，出现消息阻塞使得系统超时。
64.请参阅图3所示，数据服务层：数据服务层作为系统的数据过渡层设计，数据读入接口主要是数据库服务器作为消费者从kafka消息队列中对数据包的请求，而输出接口主要面向对应用服务器的数据支持统一的api接口，面对数据的读入，mongodb作为了kafka的数据消费者存在，mongodb作为一个(key＝》value)键值对数据库，它可以在网络或者本地创建数据镜像，使得数据库的可扩展性得到满足；
65.相较于关系型数据库的设计，mongodb在处理超大数据量的方面，击碎性能瓶颈，本实施例将mongodb作为kafka消费者使用，接收到的事件必须先转换为bson文档，然后再存储到数据库中；
66.在面向数据应用层的数据支撑作用时，系统需要统一的api接口，支持上层不同业务需求对数据的请求，需要通过一定的web访问机制来保证数据库数据安全，其中应用cookie下发，token有效期设置，添加验证码机制，防止数据爆破，此外还要对客户端上传的数据进行用户名合法性监测，长度(长度判断，存数据库)，敏感词(管理员等)，重复性判断、特殊字符(html脚本，“《”，“》”，script转意)，通过以上机制来保证系统的安全与稳定。
67.请参阅图4所示，数据感知层：细颗粒物的监测传感器采用攀藤激光细颗粒物传感器，在温湿度的监测方面应用瑞士sensirionsht20温湿度传感器，国标/usa美标双重显示；
68.完成数据校验和硬件封装后，软件方面在硬件控制中心主函数写入一条中断，实现对指令端口的轮询，从而完成对广播机制的支持，在控制中心接收到对应的id指令后，通过串口发送一条符合之前设定协议进行编码的传感器数据；
69.硬件方面在现有的传感器监测硬件系统中添加srm1276的433m无线数传模块，无线模块可完成三层楼间的稳定通信，该接收模块性能优异，采用数字处理技术，具有抗干扰强，性能稳定，可靠性高，通过无线模块与传感器硬件系统板的串口连接，实现对指令的接收和数据的发送，终端pc的上位机每一分钟会向传感器节点发送一条带id的指令数据，与指令id匹配的节点会返回一条数据包，其中包含按要求协议的奇偶校验位；
70.pc终端方面应用usb转ttl的ft232模块，实现433m主模块与计算机的数据交付；
71.在终端pc与远程数据服务器的数据流中间件的构建中，由于用来处理活跃的流式特征数据，并且面向未来实际部署中数据流大的特征，我们选择了kafka消息发布订阅的异步数据架构，现有b/s(brower/server)系统的设计都应用消息中间件实现系统前后端的分离，kafka作为消息中间件，好比一个数据容器，把终端pc推送数据请求当作生产者，后端的数据入库当作消费者，终端pc中客户端每请求一次，后端的处理线程响应一次，但当数据库服务器宕机终端pc的请求依然还在请求时，这就会导致请求数据的丢失，造成严重的后果；
72.当传感器网络后续扩展后，终端pc每秒需求请求服务器100次，而数据库服务器每秒只能响应50次，这就会导致消息阻塞，最后出现系统超时，kafka作为中间数据容器，每次生产者客户端pc发送的数据存入kafka，消费者的消费请求就会从kafka中获取数据，完成了前后端生产者消费者的数据请求分离，为消息队列基本结构，kafka其中承担的角色就是
其中单向/优先队列。
73.实施例5
74.请参阅图1所示，本实施例所述基于大数据的空气监测系统，所述系统包括数据应用层、数据服务层以及数据感知层；
75.请参阅图2所示，数据应用层：数据应用层的开发在spring环境下完成，不需要依赖于任何web服务器或者容器，框架设计为ssm，其中分别对应spring、springmvc和mybatis，数据库方面，应用redis与mysql实现对应用层的数据库支撑，此外还需要满足业务需求，包括细颗粒物的数据监测、数据溯源分析、数据预测分析、历史数据统计、节点数据比较以及环境因子影响等功能；
76.由于扩散过程由于受到室外环境的多种因素影响，细颗粒物在空间中的分布是动态变化的，使得在函数模型创建过程中并不能应用静态的多模态函数建模,而在创建动态气体模型过程中，模型需要设定的环境假设过多，并且对现实环境的空气变化状态有各种要求；
77.数据溯源分析面向于线上应用，系统获取到的模型支撑数据类别有限，因此在现实环境中的应用受到极大限制，解决上述问题设计了面向本系统特征的细颗粒物溯源算法：
78.(1)实际部署后整个网络监测数据更新周期为1分钟(16台监测设备)，系统每1个周期得到的监测数据作为细颗粒物溯源模块的1帧数据，对于每1帧数据会通过细颗粒物预测模块对其空间维度分布情况进行预测，获取到整个监测环境下细颗粒物在此时刻的分布情况；
79.(2)每1帧静态的预测数据就是一个多模态函数，应用改进的萤火虫算法进行多模态函数的求解，获取到此帧数据的局部、全局最优解，并标记为本帧数据的目标源，由于本系统是在百度地图api数据接口上实现的节点假设部署(系统设计部分会详细描述)，所以在得到每1帧数据的目标源后，会记录本帧数据目标源在百度地图上的经纬度坐标信息；
80.(3)业务逻辑层会设定细颗粒物的污染溯源阈值，当细颗粒物浓度大于这一阈值时，开始对每1帧数据进行溯源分析与源点标记，得到每1帧数据的目标源快照，并把模型的输入输出数据读入mysql数据库，其中包括每1帧空间维度预测数据和百度地图标记点坐标；
81.(4)在业务逻辑设计中，当监测区域出现细颗粒物超标时系统会通过动态刷新的形式，用每1帧目标源快照数据渲染百度地图上层热力图，并动态刷新出来，同时设定相同目标源距离阈值，通过阈值找到了每1帧快照的同一个污染源迁移点，在前端动态刷新的过程中，把同一个迁移点用线连接起来，这样就可以很直观地展示给用户，确切的污染源点位置。
82.请参阅图7所示，涉及前端与后端的数据交互，前端数据可视化和后端溯源功能的业务逻辑，箭头表示为整个细颗粒物溯源模块中的输入输出的数据流。
83.请参阅图3所示，数据服务层：数据服务层作为系统的数据过渡层设计，数据读入接口主要是数据库服务器作为消费者从kafka消息队列中对数据包的请求，而输出接口主要面向对应用服务器的数据支持统一的api接口，面对数据的读入，mongodb作为了kafka的数据消费者存在，mongodb作为一个(key＝》value)键值对数据库，它可以在网络或者本地
创建数据镜像，使得数据库的可扩展性得到满足；
84.相较于关系型数据库的设计，mongodb在处理超大数据量的方面，击碎性能瓶颈，本实施例将mongodb作为kafka消费者使用，接收到的事件必须先转换为bson文档，然后再存储到数据库中；
85.在面向数据应用层的数据支撑作用时，系统需要统一的api接口，支持上层不同业务需求对数据的请求，需要通过一定的web访问机制来保证数据库数据安全，其中应用cookie下发，token有效期设置，添加验证码机制，防止数据爆破，此外还要对客户端上传的数据进行用户名合法性监测，长度(长度判断，存数据库)，敏感词(管理员等)，重复性判断、特殊字符(html脚本，“《”，“》”，script转意)，通过以上机制来保证系统的安全与稳定。
86.请参阅图4所示，数据感知层：细颗粒物的监测传感器采用攀藤激光细颗粒物传感器，在温湿度的监测方面应用瑞士sensirionsht20温湿度传感器，国标/usa美标双重显示；
87.完成数据校验和硬件封装后，软件方面在硬件控制中心主函数写入一条中断，实现对指令端口的轮询，从而完成对广播机制的支持，在控制中心接收到对应的id指令后，通过串口发送一条符合之前设定协议进行编码的传感器数据；
88.硬件方面在现有的传感器监测硬件系统中添加srm1276的433m无线数传模块，无线模块可完成三层楼间的稳定通信，该接收模块性能优异，采用数字处理技术，具有抗干扰强，性能稳定，可靠性高，通过无线模块与传感器硬件系统板的串口连接，实现对指令的接收和数据的发送，终端pc的上位机每一分钟会向传感器节点发送一条带id的指令数据，与指令id匹配的节点会返回一条数据包，其中包含按要求协议的奇偶校验位；
89.pc终端方面应用usb转ttl的ft232模块，实现433m主模块与计算机的数据交付；
90.在终端pc与远程数据服务器的数据流中间件的构建中，由于用来处理活跃的流式特征数据，并且面向未来实际部署中数据流大的特征，我们选择了kafka消息发布订阅的异步数据架构，现有b/s(brower/server)系统的设计都应用消息中间件实现系统前后端的分离，kafka作为消息中间件，好比一个数据容器，把终端pc推送数据请求当作生产者，后端的数据入库当作消费者，终端pc中客户端每请求一次，后端的处理线程响应一次，但当数据库服务器宕机终端pc的请求依然还在请求时，这就会导致请求数据的丢失，造成严重的后果；
91.当传感器网络后续扩展后，终端pc每秒需求请求服务器100次，而数据库服务器每秒只能响应50次，这就会导致消息阻塞，最后出现系统超时，kafka作为中间数据容器，每次生产者客户端pc发送的数据存入kafka，消费者的消费请求就会从kafka中获取数据，完成了前后端生产者消费者的数据请求分离，为消息队列基本结构，kafka其中承担的角色就是其中单向/优先队列。
92.实施例6
93.本实施例提供所述基于大数据的空气监测方法，所述方法包括以下步骤：
94.(1)通过细颗粒物预测模块对其空间维度分布情况进行预测，获取到整个监测环境下细颗粒物在此时刻的分布情况；
95.(2)获取到此帧数据的局部、全局最优解，并标记为本帧数据的目标源；
96.(3)业务逻辑层设定细颗粒物的污染溯源阈值，当细颗粒物浓度大于这一阈值时，进行溯源分析与源点标记，并把模型的输入输出数据读入mysql数据库；
97.(4)当监测区域出现细颗粒物超标时系统会通过动态刷新的形式，同时设定相同
目标源距离阈值找到同一个污染源迁移点，在前端动态刷新的过程中，把同一个迁移点用线连接起来显示。
98.需要说明的是，在本文中，如若存在第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
99.以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。