本發(fā)明屬于通信技術(shù)領(lǐng)域，特別是移動互聯(lián)網(wǎng)及計算機通信領(lǐng)域，涉及一種基于游客移動信令數(shù)據(jù)的景區(qū)實時動態(tài)客流量統(tǒng)計方法。

背景技術(shù)：

近年來，以云計算、物聯(lián)網(wǎng)、移動通信等為代表的新一代信息技術(shù)取得了重大突破，開始廣泛應用于各行各業(yè)。物聯(lián)網(wǎng)技術(shù)突破了互聯(lián)網(wǎng)的“線上”局限，把虛擬世界與現(xiàn)實世界聯(lián)成一體；移動通信技術(shù)實現(xiàn)了實時數(shù)據(jù)在系統(tǒng)之間、遠程設備之間的無線連接，為無處不在的全程服務提供了條件；云計算解決了互聯(lián)網(wǎng)發(fā)展所帶來的巨量數(shù)據(jù)存儲與處理問題。這些技術(shù)的普及和應用，為旅游信息化的發(fā)展提供了有力支撐，將人類社會帶入了一個以“pb”(1024tb)為單位的新階段，大數(shù)據(jù)時代應運而生。大數(shù)據(jù)不僅更新了旅游信息化所需的技術(shù)，更從觀念和思維上革新了人類的認識，實現(xiàn)思維、商業(yè)、管理上的變革。

隨著中國經(jīng)濟的發(fā)展，人們收入的增長以及對生活品質(zhì)的追求，旅游業(yè)在國內(nèi)發(fā)展得很快，得到了國家的大力支持，旅游業(yè)進入爆發(fā)性的增長階段，成為新的支柱產(chǎn)業(yè)。旅游已經(jīng)成為人們生活方式的重要組成部分，但與此同時引發(fā)了一些景區(qū)管理的安全隱患，景區(qū)超流量接待游客已不是罕見現(xiàn)象。2015年跨年夜上海發(fā)生的踩踏事件，暴露出了我國在大量游客管理方面能力的匱乏。事后國家旅游局對景區(qū)安全管理更加嚴格，尤其是在景區(qū)客流量控制上。因此，無論是從國家還是旅游局層面來講，景區(qū)需要一套針對景區(qū)游客的安全監(jiān)控方案。

傳統(tǒng)的景區(qū)動態(tài)客流量統(tǒng)計方法在實時性方面體現(xiàn)的比較差，統(tǒng)計景區(qū)客流量是通過從傳統(tǒng)的數(shù)據(jù)庫中分析提取。而傳統(tǒng)數(shù)據(jù)庫具有效率不夠高、可讀性不高、數(shù)據(jù)時間性不足等缺點，導致分析傳統(tǒng)數(shù)據(jù)庫中的海量游客信令數(shù)據(jù)會造成查詢速度特別慢、統(tǒng)計速度特別慢等缺點。所以傳統(tǒng)數(shù)據(jù)庫不適合用于存儲分析海量數(shù)據(jù)，不利于應對短時間內(nèi)因游客劇增導致?lián)矶?、踩踏等引發(fā)的安全事故。

flume是一個分布式、可靠、和高可用的海量日志聚合的系統(tǒng)，支持在日志系統(tǒng)中定制各類數(shù)據(jù)發(fā)送方，用于收集數(shù)據(jù)；同時，flume提供對數(shù)據(jù)進行簡單處理，并寫到各種數(shù)據(jù)接受方(可定制)的能力。

kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，它可以處理消費者規(guī)模的網(wǎng)站中的所有動作流數(shù)據(jù)。kafka可實時記錄從數(shù)據(jù)采集工具flume中收集的數(shù)據(jù)，并作為消息緩沖組件為上游實時計算框架提供可靠數(shù)據(jù)支撐。

spark是一個分布式的內(nèi)存計算框架，其特點是能處理大規(guī)模數(shù)據(jù)，計算速度快。spark需要集成hadoop的分布式文件系統(tǒng)才能運作，它延續(xù)了hadoop的mapreduce計算模型，相比之下spark的計算過程保持在內(nèi)存中，減少了硬盤讀寫，能夠?qū)⒍鄠€操作進行合并后計算，因此提升了計算速度。spark必須搭在hadoop集群上，它的數(shù)據(jù)來源是hdfs，本質(zhì)上是yarn上的一個計算框架，像mapreduce一樣。spark核心部分分為rdd。sparksql、sparkstreaming、mllib、graphx、sparkr等核心組件解決了很多的大數(shù)據(jù)問題，其完美的框架日受歡迎。其相應的生態(tài)環(huán)境包括zepplin等可視化方面，正日益壯大。spark讀寫過程不像hadoop溢出寫入磁盤，都是基于內(nèi)存，因此速度很快。另外dag作業(yè)調(diào)度系統(tǒng)的寬窄依賴讓spark速度提高。

本方法采用快速的海量數(shù)據(jù)處理框架和相應的分析算法實時監(jiān)控景區(qū)內(nèi)的客流情況，以便景區(qū)和當?shù)厝嗣裾芗皶r采取疏導、分流等措施，從而達到景區(qū)安全管理的目的。

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

有鑒于此，本發(fā)明的目的在于提供一種基于游客移動信令數(shù)據(jù)的景區(qū)實時動態(tài)客流量統(tǒng)計方法，該方法針對傳統(tǒng)的景區(qū)動態(tài)客流量統(tǒng)計方法在實時性方面體現(xiàn)的比較差、海量數(shù)據(jù)不適合存儲在傳統(tǒng)數(shù)據(jù)庫中進行分析等問題，通過實時監(jiān)控景區(qū)內(nèi)的客流量，有助于應對短時間內(nèi)景區(qū)游客劇增情況，便于景區(qū)和當?shù)卣皶r采取疏導、分流等措施，從而達到景區(qū)安全管理的目的，同時更大程度地提升游客對景區(qū)的體驗度。

為達到上述目的，本發(fā)明提供如下技術(shù)方案：

一種基于游客移動信令數(shù)據(jù)的景區(qū)實時動態(tài)客流量統(tǒng)計方法，該方法包括以下步驟：

s1：lte-a空口監(jiān)測儀實時采集景區(qū)內(nèi)游客的信令數(shù)據(jù)，并將數(shù)據(jù)保存至遠程文件中，以一分鐘的時間粒度保存一個信令數(shù)據(jù)文件；

s2：通過flume組件監(jiān)測遠程文件是否有文件更新，若有更新，將文件逐條記錄收集；

s3：flume組件將更新的最新文件中的數(shù)據(jù)逐條發(fā)送至kafka數(shù)據(jù)緩沖組件中進行數(shù)據(jù)緩沖，直至更新后的最新文件中的數(shù)據(jù)全部發(fā)送完畢，將該數(shù)據(jù)流打包成批數(shù)據(jù)作為spark的數(shù)據(jù)輸入流；

s4：在spark分布式的內(nèi)存計算框架中，通過比較前一分鐘和后一分鐘游客所在基站的位置來實時統(tǒng)計景區(qū)內(nèi)游客總量；

s5：將每分鐘實時統(tǒng)計的客流量結(jié)果進行輸出并存儲，如存儲到mysql/oracle數(shù)據(jù)庫中。

進一步，在步驟s1中，所述lte-a空口監(jiān)測儀采集景區(qū)內(nèi)游客的移動信令數(shù)據(jù)，包括imsi庫、信令發(fā)生的時間、所在的基站位置信息，并將移動信令數(shù)據(jù)以一分鐘的時間粒度保存一個信令數(shù)據(jù)文件。

進一步，該方法還包括以下步驟：s6：將存入到數(shù)據(jù)庫的實時結(jié)果輸出至應用展示層中，以可視化界面的形式方便用戶查看。

本發(fā)明的有益效果在于：

1)本發(fā)明將景區(qū)內(nèi)游客的海量實時移動信令數(shù)據(jù)存儲在遠程文件系統(tǒng)中，為數(shù)據(jù)預處理和數(shù)據(jù)分析處理模塊提供數(shù)據(jù)準備，把數(shù)據(jù)分析后的結(jié)果存儲到傳統(tǒng)的數(shù)據(jù)庫中，從而大大減輕了傳統(tǒng)數(shù)據(jù)庫直接存儲海量實時數(shù)據(jù)的壓力。

2)本發(fā)明基于hadoop平臺，在spark分布式內(nèi)存計算框架中進行海量的數(shù)據(jù)運算分析，把在傳統(tǒng)數(shù)據(jù)庫中進行數(shù)據(jù)運算的壓力轉(zhuǎn)移到高效快速的spark分布式內(nèi)存計算框架中，從而保證了景區(qū)內(nèi)對游客的實時監(jiān)控。

3)本發(fā)明可用于分析景區(qū)內(nèi)精細化的客流特征，通過重復利用kafka緩沖的批數(shù)據(jù)處理流，在spark中生成多個rdd變換，每個rdd變換用于一種客流特征的分析，形成各自的業(yè)務邏輯。

附圖說明

為了使本發(fā)明的目的、技術(shù)方案和有益效果更加清楚，本發(fā)明提供如下附圖進行說明：

圖1為本發(fā)明中的數(shù)據(jù)預處理流程圖；

圖2為本發(fā)明中數(shù)據(jù)實時計算處理流程圖；

圖3為本發(fā)明中精細化的客流特征分析流程框圖；

圖4為本發(fā)明中數(shù)據(jù)實時計算處理后數(shù)據(jù)表的設計。

具體實施方式

下面將結(jié)合附圖，對本發(fā)明的優(yōu)選實施例進行詳細的描述。

圖1為本發(fā)明中的數(shù)據(jù)預處理流程圖，圖2為本發(fā)明中數(shù)據(jù)實時計算處理流程圖，如圖所示，本發(fā)明提供了一種基于游客移動信令數(shù)據(jù)的景區(qū)實時動態(tài)客流量統(tǒng)計方法，該方法包括如下步驟：

步驟1：lte-a空口監(jiān)測儀實時采集景區(qū)內(nèi)游客的信令數(shù)據(jù)imsi號和(lac，ci)(移動終端imsi表示游客在景區(qū)的唯一標識，移動終端所在的基站位置(lac，ci)表示游客所在的位置)，并將數(shù)據(jù)保存至遠程的文件中，以一分鐘的時間粒度保存一個信令數(shù)據(jù)文件。

步驟2：通過flume組件監(jiān)測遠程文件是否有文件更新，若有更新，將文件逐條記錄收集。

步驟3：flume組件將更新的最新文件中的數(shù)據(jù)逐條發(fā)送至kafka數(shù)據(jù)緩沖組件中進行數(shù)據(jù)緩沖，直至更新后的最新文件中的數(shù)據(jù)全部發(fā)送完畢，將該數(shù)據(jù)流打包成批數(shù)據(jù)作為spark的數(shù)據(jù)輸入流。

步驟4：在spark分布式的內(nèi)存計算框架中，通過比較前一分鐘和后一分鐘游客所在基站的位置來實時統(tǒng)計景區(qū)內(nèi)游客總量。當前景區(qū)游客總量為各個基站下游客總量之和。當游客從景區(qū)內(nèi)一個基站到另一個基站，景區(qū)總量不變；當游客前后一分鐘都在該景區(qū)內(nèi)的同一個基站范圍內(nèi)，景區(qū)總量不變；當游客從景區(qū)外的一個基站到景區(qū)內(nèi)的一個基站，景區(qū)總量+1；當游客從景區(qū)內(nèi)的一個基站到景區(qū)外的一個基站，景區(qū)總量-1。

步驟5：將每分鐘實時統(tǒng)計的客流量結(jié)果進行輸出并存儲，如存儲到mysql/oracle數(shù)據(jù)庫中。數(shù)據(jù)庫中表的設計結(jié)構(gòu)如圖4所示。

步驟6：將存入到數(shù)據(jù)庫的實時結(jié)果輸出至應用展示層中。

本發(fā)明可用于分析景區(qū)內(nèi)精細化的客流特征，通過重復利用kafka緩沖的批數(shù)據(jù)處理流，在spark中生成多個rdd變換，每個rdd變換用于一種客流特征的分析，形成各自的業(yè)務邏輯。如圖3所示。

最后說明的是，以上優(yōu)選實施例僅用以說明本發(fā)明的技術(shù)方案而非限制，盡管通過上述優(yōu)選實施例已經(jīng)對本發(fā)明進行了詳細的描述，但本領(lǐng)域技術(shù)人員應當理解，可以在形式上和細節(jié)上對其作出各種各樣的改變，而不偏離本發(fā)明權(quán)利要求書所限定的范圍。