技術領域

本發(fā)明涉及計算機技術領域，具體地說是一種基于物聯(lián)網(wǎng)大數(shù)據(jù)的設備信息采集系統(tǒng)及方法。

背景技術：

在實際項目開發(fā)中經(jīng)常會遇到類似問題，例如：需要給手機用戶推送一條服務信息，或者使用手機控制稅控機或者其他硬件設備。但是在現(xiàn)有技術層面（TCP、HTTP、Socket等）沒有符合相應技術要求的技術。因此MQTT協(xié)議就成為完成上述技術比較好的解決方案。因為MQTT協(xié)議相對于其他協(xié)議來說更輕量級，網(wǎng)絡流量消耗極少（以字節(jié)為單位），對于客戶機（手機、稅控機等）耗電量得到很好控制。

MQTT協(xié)議是指消息隊列遙測傳輸，協(xié)議支持所有平臺，幾乎可以把所有聯(lián)網(wǎng)物品和外部連接起來，該協(xié)議特點，使用發(fā)布/訂閱消息模式，提供一對多的消息發(fā)布，解除應用程序耦合；對負載內(nèi)容屏蔽的消息傳輸；使用 TCP/IP 提供網(wǎng)絡連接；小型傳輸，開銷很小。

但是如果沒有合適的框架系統(tǒng)，用戶使用EMQTT與數(shù)據(jù)結合分析時會遇到種種繁瑣的問題。第一客戶需要關心安全問題，因為EMQTT的服務器是部署在外網(wǎng)，需要很高的安全性為了防止數(shù)據(jù)的丟失與泄漏；而且對于重新開發(fā)一套大數(shù)據(jù)Hadoop模型與EMQTT模型的結合費事費力，有很多無用功浪費在研究與封裝上面。

基于此，現(xiàn)提供一種基于物聯(lián)網(wǎng)大數(shù)據(jù)的設備信息采集系統(tǒng)及方法，使用該平臺框架用戶直接接入即可，安全性與數(shù)據(jù)結合分析都由框架完成用戶不必操心，只需要專注于業(yè)務邏輯的實現(xiàn)即可。

同時隨著物聯(lián)網(wǎng)時代的到來，人工智能為當今社會生活提供的巨大的便利。本方案主要結合互聯(lián)網(wǎng)時代，為發(fā)票開具終端、離境退稅終端開具終端設計，同時可適用于具有該特點的所有系統(tǒng)。目前中國發(fā)票的多樣性，電子發(fā)票，網(wǎng)絡發(fā)票，電腦終端利用設備開具的增值稅發(fā)票等。傳統(tǒng)的設備終端開具系統(tǒng)都是利用傳統(tǒng)的http協(xié)議服務，傳輸為單項傳輸，數(shù)據(jù)協(xié)議復雜，大量帶寬被無意義的結構化數(shù)據(jù)信息占用。同時，http服務支撐的終端有限。該方案能夠將互聯(lián)網(wǎng)開票終端的數(shù)據(jù)實時采集，同時服務端控制終端上傳數(shù)據(jù)不再是單項數(shù)據(jù)傳遞。

技術實現(xiàn)要素：

本發(fā)明的技術任務是針對以上不足之處，提供一種基于物聯(lián)網(wǎng)大數(shù)據(jù)的設備信息采集系統(tǒng)及方法。

一種基于物聯(lián)網(wǎng)大數(shù)據(jù)的設備信息采集系統(tǒng)，包括客戶端和服務端，所述服務端采用開源的EMQTT服務集群，通過長連接的方式與客戶端連接通信，客戶端可以請求服務端也可以實時向服務端發(fā)送信息，相反服務端也可以請求客戶端實時向客戶端發(fā)送信息。

所述服務端的EMQTT服務集群中，部署有Redis緩存數(shù)據(jù)庫；安裝Kafka消息隊列；集成安裝hadoop組件，包括HDFS、hbase、zookeeper、Spark；且該EMQTT服務集群配置Nginx反向代理。

在服務端中，通過MQTT的長連接，實時獲取終端設備的行為數(shù)據(jù)，并控制終端設備的行為；Hadoop 組件用于數(shù)據(jù)實時收集存儲，通過MQTT的消息隊列，將終端產(chǎn)生的高并發(fā)數(shù)據(jù)，勻化處理使后端接入的數(shù)據(jù)監(jiān)聽任務工作更具有穩(wěn)定性；Redis緩存數(shù)據(jù)庫作為數(shù)據(jù)暫存的臨時位置，保證數(shù)據(jù)的重復傳遞，并通過Redis的haset存儲類型去重。

所述客戶端上配置有對應MQTT的發(fā)布和訂閱消息模塊，使得服務端實現(xiàn)訂閱監(jiān)聽各客戶端發(fā)布主題，并存入Redis中，這里的客戶端包括移動終端、配置有傳感器的終端設備。

一種基于物聯(lián)網(wǎng)大數(shù)據(jù)的設備信息采集方法，基于上述系統(tǒng)，其采集過程為：

首先將客戶端實時產(chǎn)生的數(shù)據(jù)信息，實時推送到EMQTT服務集群；

EMQTT服務集群接收到數(shù)據(jù)信息后，進行SparkStreaming流式計算；

然后將計算后的數(shù)據(jù)采集到分布式數(shù)據(jù)庫Hbase進行存儲，并通過Redis緩存數(shù)據(jù)庫處理接收訂閱重復數(shù)據(jù)的問題。

當客戶端進行訂閱或發(fā)布操作時，均通過Nginx反向代理有效隱藏后端服務的地址，然后通過地址映射連接到服務端后由EMQTT解析客戶端發(fā)來的信息，將信息存入Redis緩存數(shù)據(jù)庫處理接收訂閱重復數(shù)據(jù)的問題。

在數(shù)據(jù)存入Redis緩存數(shù)據(jù)庫后，將信息存入Hadoop大數(shù)據(jù)分析模型，進行下一步的分析操作：在Hadoop模型下通過SparkStreaming流式計算，將數(shù)據(jù)采集到分布式數(shù)據(jù)庫Hbase進行存儲，完成一次數(shù)據(jù)的邏輯交互于實時分析，當客戶端訂閱后收到服務端的指令信息，根據(jù)這些指令客戶端會做出相應邏輯動作。

所述指令信息是根據(jù)服務端SparkStreaming流失計算得到指令結果，將這些指令結果推回到服務端，再次根據(jù)EMQTT框架代理服務器將指令消息推送給NIGNX反向代理服務器，然后NIGNX反向代理服務器根據(jù)對應地址找到相應客戶端，當客戶端收到對應的指令信息后即可做出對應邏輯動作。

本發(fā)明的一種基于物聯(lián)網(wǎng)大數(shù)據(jù)的設備信息采集系統(tǒng)及方法和現(xiàn)有技術相比，具有以下有益效果：

本發(fā)明的一種基于物聯(lián)網(wǎng)大數(shù)據(jù)的設備信息采集系統(tǒng)及方法，解決傳感器、移動終端的數(shù)據(jù)在有限的帶寬同時節(jié)省電量的情況下完成實時采集，適用于大并發(fā)，支持百萬級傳輸終端，保證采集數(shù)據(jù)的實時，唯一和存儲，實用性強，適用范圍廣泛，具有很好的推廣應用價值。

附圖說明

附圖1是本發(fā)明實現(xiàn)示意圖。

附圖2為本發(fā)明的邏輯實現(xiàn)圖。

具體實施方式

下面結合附圖及具體實施例對本發(fā)明作進一步說明。

本發(fā)明基于物聯(lián)網(wǎng)、大數(shù)據(jù)技術，集成搭建一套設備數(shù)據(jù)實時（控制）采集。利用EMQTT開源服務體系和hbase、spark等hadoop生態(tài)圈組件，將設備實時產(chǎn)生的數(shù)據(jù)信息，實時推送到EMQTT服務，并通過SparkStreaming流式計算，準實時的將數(shù)據(jù)采集到分布式數(shù)據(jù)庫Hbase進行存儲，并通過Redis緩存數(shù)據(jù)庫處理接收訂閱重復數(shù)據(jù)的問題。（如果不進行重復處理，該架構為了保證數(shù)據(jù)的傳遞過程中不丟失，客戶端publish數(shù)據(jù)是采用至少發(fā)送一次的機制，而流式計算集群模式下很容易將數(shù)據(jù)采集重復造成冗余，故加入Redis緩存以采集的數(shù)據(jù)Rowkey，防止重復）。

如附圖1、圖2所示，一種基于物聯(lián)網(wǎng)大數(shù)據(jù)的設備信息采集系統(tǒng)，包括客戶端和服務端，所述服務端采用開源的EMQTT服務集群，通過長連接的方式與客戶端連接通信，客戶端可以請求服務端也可以實時向服務端發(fā)送信息，相反服務端也可以請求客戶端實時向客戶端發(fā)送信息。

所述服務端的EMQTT服務集群中，部署有Redis緩存數(shù)據(jù)庫；安裝Kafka消息隊列；集成安裝hadoop組件，包括HDFS、hbase、zookeeper、Spark；且該EMQTT服務集群配置Nginx反向代理。

在服務端中，通過MQTT的長連接，實時獲取終端設備的行為數(shù)據(jù)，并控制終端設備的行為；Hadoop 組件用于數(shù)據(jù)實時收集存儲，通過MQTT的消息隊列，將終端產(chǎn)生的高并發(fā)數(shù)據(jù)，勻化處理使后端接入的數(shù)據(jù)監(jiān)聽任務工作更具有穩(wěn)定性；Redis緩存數(shù)據(jù)庫作為數(shù)據(jù)暫存的臨時位置，保證數(shù)據(jù)的重復傳遞，并通過Redis的haset存儲類型去重。

所述客戶端上配置有對應MQTT的發(fā)布和訂閱消息模塊，使得服務端實現(xiàn)訂閱監(jiān)聽各客戶端發(fā)布主題，并存入Redis中，這里的客戶端包括移動終端、配置有傳感器的終端設備。

本系統(tǒng)利用了MQTT的長連接，可實時獲取終端網(wǎng)關設備的各項行為數(shù)據(jù)，并可以控制終端的各項行為。因為終端設備和服務端是長連接，實現(xiàn)服務端對設備終端的控制。

Hadoop hbase組件作為數(shù)據(jù)實時收集存儲的，能夠支撐pb級數(shù)據(jù)存儲和檢索，利用MQTT的消息隊列機制，將終端產(chǎn)生高并發(fā)數(shù)據(jù)，勻化處理使后端接入的數(shù)據(jù)監(jiān)聽任務工作更具有穩(wěn)定性。

Redis作為數(shù)據(jù)暫存的臨時位置，保證數(shù)據(jù)的重復傳遞，利用Redis的haset存儲類型去重，既保證了數(shù)據(jù)的唯一，有保證的數(shù)據(jù)的及時傳遞。

在本發(fā)明中，除平臺之外最重要的是對NINGX反向代理服務器、EMQTT與Hadoop大數(shù)據(jù)系統(tǒng)的整合封裝，對應的有2個模塊，一個為EMQTT與Redis分裝；一個為Hadoop大數(shù)據(jù)模塊封裝。

首先在客戶端有主動發(fā)布指令與被動指令，無論哪一種都以賦予EMQTT服務器，指令消息通過MQTT協(xié)議傳輸?shù)姆掌骱蟾鶕?jù)訂閱指令信息的不同會寫入到Redis中，為解決重復指令問題做數(shù)據(jù)存儲。

存入Redis后Hadoop中的SparkStreming流式計算既可以在其中獲取指令進行分析處理，因為在Redis中做了指令冗余處理所以在智力可以直接使用。

經(jīng)過計算分析之后得到最終結果可以將其存入Hbase中或者將數(shù)據(jù)指令再次返回給客戶端，這樣整個業(yè)務邏輯框架可以無縫連接，并且大大提高安全性與易用性，為客戶節(jié)省不必要的開發(fā)時間，將大部分精力都放在自己的業(yè)務邏輯開發(fā)上。

上述系統(tǒng)的實際搭建過程為：

1、EMQTT下載最新開源包編譯安裝，部署多個節(jié)點集群；配置EMQTT集群。

2、部署Redis緩存數(shù)據(jù)庫；

3、安裝Kafka消息隊列；

4、集成安裝hadoop組件，HDFS，hbase，zookeeper，Spark；

5、為EMQTT集群配置Nginx反向代理。

6、各客戶端開發(fā)針對MQTT的發(fā)布和訂閱消息（定義主題）。

7、服務平臺實現(xiàn)訂閱，監(jiān)聽各客戶端發(fā)布主題，并存入Redis中；

8、實現(xiàn)SparkStreming任務，讀取Redis任務寫入Hbase中。

一種基于物聯(lián)網(wǎng)大數(shù)據(jù)的設備信息采集方法，基于上述系統(tǒng)，其采集過程為：

首先將客戶端實時產(chǎn)生的數(shù)據(jù)信息，實時推送到EMQTT服務集群；

EMQTT服務集群接收到數(shù)據(jù)信息后，進行SparkStreaming流式計算；

然后將計算后的數(shù)據(jù)采集到分布式數(shù)據(jù)庫Hbase進行存儲，并通過Redis緩存數(shù)據(jù)庫處理接收訂閱重復數(shù)據(jù)的問題。

當客戶端進行訂閱或發(fā)布操作時，均通過Nginx反向代理有效隱藏后端服務的地址，然后通過地址映射連接到服務端后由EMQTT解析客戶端發(fā)來的信息，將信息存入Redis緩存數(shù)據(jù)庫處理接收訂閱重復數(shù)據(jù)的問題。

在數(shù)據(jù)存入Redis緩存數(shù)據(jù)庫后，將信息存入Hadoop大數(shù)據(jù)分析模型，進行下一步的分析操作：在Hadoop模型下通過SparkStreaming流式計算，將數(shù)據(jù)采集到分布式數(shù)據(jù)庫Hbase進行存儲，完成一次數(shù)據(jù)的邏輯交互于實時分析，當客戶端訂閱后收到服務端的指令信息，根據(jù)這些指令客戶端會做出相應邏輯動作。

所述指令信息是根據(jù)服務端SparkStreaming流失計算得到指令結果，將這些指令結果推回到服務端，再次根據(jù)EMQTT框架代理服務器將指令消息推送給NIGNX反向代理服務器，然后NIGNX反向代理服務器根據(jù)對應地址找到相應客戶端，當客戶端收到對應的指令信息后即可做出對應邏輯動作。

首先客戶端上可以進行訂閱/發(fā)布操作，無論是訂閱還是發(fā)布都需要通過NIGNX，利用Nginx反向代理有效的隱藏了后端服務的地址，這樣可以大大提高系統(tǒng)以及框架的安全性，避免了很多不必要的黑客與網(wǎng)絡攻擊。

然后通過地址映射連接到服務器后EMQTT解析客戶端發(fā)來的信息，將信息存入Redis緩存數(shù)據(jù)庫處理接收訂閱重復數(shù)據(jù)的問題。處理完數(shù)據(jù)之后將信息存入Hadoop大數(shù)據(jù)分析模型，進行下一步的分析操作。

在Hadoop模型下通過SparkStreaming流式計算，準實時的將數(shù)據(jù)采集到分布式數(shù)據(jù)庫Hbase進行存儲，完成一次數(shù)據(jù)的邏輯交互于實時分析。

當客戶端訂閱后會收到服務端的指令信息，根據(jù)這些指令客戶端會做出相應邏輯動作。而這些指令信息也是根據(jù)服務端SparkStreaming流失計算得到指令結果，將這些指令結果推回到服務端，再次根據(jù)EMQTT框架代理服務器將指令消息推送給NIGNX反向代理服務器，然后服務器根據(jù)對應地址找到相應客戶端，當客戶端收到對應的指令信息后即可做出對應邏輯動作。

該技術方案中采用了開源的EMQTT服務，該服務集群可以支撐百萬級網(wǎng)絡終端設備實時在線連接，該連接為長連接。這樣相當于服務端和客戶端建立了一個通道，客戶端可以請求服務端也可以實時向服務端發(fā)送信息，相反服務端也可以請求客戶端實時向客戶端發(fā)送信息。傳統(tǒng)的http服務只能實現(xiàn)客戶端向服務端發(fā)送請求和傳遞數(shù)據(jù)。服務端只能被迫應答客戶端。

利用Nginx反向代理有效的隱藏了后端服務的地址，同時將客戶端的請求和監(jiān)聽進行了軟負載（EMQTT集群同樣具有負載能力），進一步加大了系統(tǒng)的穩(wěn)定性，服務端的監(jiān)聽客戶端上傳的數(shù)據(jù)信息，接收到后進入Redis臨時存儲，HSet保證數(shù)據(jù)唯一。Spark將存入Redis數(shù)據(jù)進行抽取進入HBase列式數(shù)據(jù)庫。

通過上面具體實施方式，所述技術領域的技術人員可容易的實現(xiàn)本發(fā)明。但是應當理解，本發(fā)明并不限于上述的具體實施方式。在公開的實施方式的基礎上，所述技術領域的技術人員可任意組合不同的技術特征，從而實現(xiàn)不同的技術方案。

除說明書所述的技術特征外，均為本專業(yè)技術人員的已知技術。