基于SpringBoot+Spark+Vue的旅游大數據分析平臺的設計與實現

寧 毅,陳金龍,羅德明,趙仲達

(桂林電子科技大學 計算機與信息安全學院,廣西 桂林 541004)

0 引言

據統計,桂林市的GDP中,旅游業占比超過30%,并且每年接待數百萬國內外游客,為當地帶來可觀的經濟效益。可見,旅游業已成為桂林經濟的重要成分。旅游業不但繁榮桂林的經濟,而且還緩解了城市就業的壓力,擴大了對外開放,搞活市場流通,帶動了第三產業乃至整個國民經濟的發展[1]。

如今,互聯網發展已經相當成熟,旅游業也逐漸向數字化、智能化方向轉型,景區的服務創新水平隨著時間而動態變化[2]。旅游數據的規模不斷擴大,包括酒店入住數據、景點游客流量數據、航班購票數據等。這些數據蘊含著豐富的信息,可以幫助旅游從業者更好地了解市場需求、優化產品設計、提高客戶滿意度等。然而,由于數據來源分散、格式多樣、數量龐大,單靠人工分析已經很難滿足實際需求,加之市面上也沒有針對桂林A級景區做數據分析的應用平臺,因此,本文針對桂林市的景區構建一個初步、相對簡易的游客數據、景區數據分析平臺。

1 平臺設計

1.1 總體架構設計

前端技術涉及Vue、Vuex、Echarts、Axios。將平臺各個數據指標通過地圖、折線圖、條形圖、雷達圖、表格等形式可視化,便于用戶了解景區大體情況[3]。

后端使用Maven倉庫,整合SpringBoot、MyBatis-Plus用以快速搭建開發腳手架,數據庫則使用HBase和MySQL。HBase用來存儲使用Python爬蟲技術采集的大數據集,包括游客Vlog數據、遷入桂林指數、景區攻略數等信息;MySQL則用以存儲無需分析的和分析后的數據;數據處理分析使用Scala語言讀取HBase數據,經過Spark處理分析,將結果保存于MySQL。采用上述作為平臺整體的技術架構是因為Spark 適用于各種各樣原先需要多種不同的分布式平臺的場景,包括批處理、迭代算法、交互式查詢、流處理[4]。另外,HBase集群具有線性伸縮、自動容災和負載均衡的優勢,可以很容易地增加或者替換集群節點以擴展集群的存儲和計算能力[5]。具體如圖1所示。

圖1 系統架構

1.2 功能結構設計

面向桂林市A級景區客流大數據分析平臺的功能模塊劃分為景區信息管理、輿情分析、客流統計、客源分析4個模塊,如圖2所示。

圖2 系統功能結構

1.3 數據庫設計

在細化平臺功能之后再將數據庫設計精化到具體的實體表、字段及實體之間的關聯關系表[6]。通過ER圖描繪各個表或表之間的聯系,如圖3所示。

圖3 景區、客流、微博簽到、指數、詞條關系

參考各數據集來源于不同的網絡平臺,實際設計表時無法做到完全符合三范式的要求,具體的數據庫如表1所示。

表1 數據庫關系模型

1.4 用戶界面設計

平臺在UI設計方面,使用Vue、Vuex、Axios技術可以基于組件化開發美觀的界面,配合ECharts技術可以快速引入各種圖表以滿足自身平臺的功能需求。由于不同的用戶設備的屏幕尺寸、分辨率不一,本平臺雖然沒有對移動端瀏覽器做出適配,一套代碼想同時適應PC和手機幾乎不可能,但是在前端頁面開發時考慮瀏覽器、設備屏幕適配問題,因此采用Flex布局、百分比布局的響應式界面設計,便于適配不同的設備屏幕[7]。

2 系統實現

面向桂林A級景區客流大數據分析平臺具體實現由數據采集、數據存儲、Spark數據分析、后端業務處理和UI設計5個功能模塊組成,各模塊關系如圖4所示。下面將介紹各模塊的實現。

圖4 平臺模塊關系

2.1 數據采集模塊

使用Python爬蟲技術作為第三方庫收集與初步過濾分析桂林A級景區游客數量、行為和趨勢等方面數據的工具[8]。將采集到的數據保存到HBase、MySQL數據庫中,以便進行進一步的分析處理。

2.2 數據存儲模塊

數據存儲模塊使用關系型MySQL和非關系型HBase數據庫,其中MySQL存儲與平臺直接相關的數據,數據采集爬取的大多數據可直接保存到MySQL里面供業務處理模塊操作,數據庫設計方面也會根據平臺的需求,對經常使用到的字段建立索引,提高查詢效率。HBase則存儲冗余性大、數據量大、待處理分析的數據,如線路評論及其指標、全國來桂客流信息、游客信息等[9]。

2.3 Spark數據分析模塊

2.3.1 客源分析實現過程

首先,建立遠程HBase數據庫連接,過濾空值、無用數據值(例如來源地為未知、游客數量為0等數據集),將初步處理的數據保存到HBase數據庫表,此步處理具體實現如圖5所示。

圖5 數據初步處理流程

其次,基于Scala的Spark數據處理分析,讀取并處理passenger_flow的數據得到初始RDD。flatmap將原始RDD數據進行扁平化處理得到的元組格式如((“2018-08-30”,“世外桃源”),4)的RDD算子,進一步對“世外桃源”和業務相關的MySQL數據庫景區表進行ID映射,最終的RDD的元組形式為((“2018-08-30”,景區的ID),4),將數據保存到MySQL里面。

2.3.2 來源地分析實現

area_distribution表的數據簡單但是數據量非常多,所以處理起來就非常簡易。只需簡單的一兩個RDD算子即可得到本文想要的數據格式,其格式轉變如圖6所示。

圖6 省份來桂人數處理RDD轉換

2.3.3 游客畫像實現

游客信息表則是生成簡單的游客畫像,如游客年齡、性別。具體RDD算子數據格式轉變如圖7所示。

圖7 游客信息RDD數據格式轉變

2.3.4 A級景區線路指標分析實現

此功能對數據采集模塊存儲到HBase數據庫的route_comment表數據進行處理分析。Scala編碼連接HBase數據庫后將RDD轉換生成DataFrame。SparkSQL編碼獲取指標Jason字符串,由Jason字符串生成Scala實例,多分支判斷游客給線路的線程安排、住宿體驗、交通體驗、商家服務等指標的評分,最后各指標得分取均值和評論總數保存于MySQL數據庫[10]。其代碼實現流程如圖8所示。

圖8 線路指標分析流程

2.4 業務處理模塊

該模塊遵循后端開發dao層、service層、controller層的編程規范,每一層有各自的職責,降低耦合度[11]。該模塊的各個包圖關系如圖9所示。

圖9 系統包圖

entity包對應數據庫表的實體類,如景區表對應scenic類,包含字段信息、日期格式化和主鍵自增等約束。pojo包衍生于該包下的類,返回符合前端要求的格式數據。

mapper包對數據庫進行常規的CRUD操作,結合數據庫表索引情況編寫適當的查詢字段和條件,對于沒必要的字段值就無需查詢,減少網絡傳輸開銷。

service包出于controller與mapper之間,主要負責系統的業務邏輯,將用戶傳遞的參數傳遞到service方法中,在mapper 包的基礎上進行邏輯查詢、封裝數據格式返回controller層。

controller層是MVC(Model-View-Controller)設計模式中的一部分,用于處理應用程序的用戶請求并根據請求選擇合適的操作進行處理。在Web應用程序中,controller通常充當路由和請求處理的角色。它接收來自用戶的HTTP請求,并將其路由到相應的業務邏輯處理代碼中[12]。通過HTTP請求將數據返回給用戶,生成響應格式的數據。

utils、config、advice包則是存放工具類、配置類和全局異常處理類,utils將系統用到的通用方法統一封裝,例如實例判空、字符轉日期、日期是否在2個時間之間等功能,降低耦合度。config用于解決SpringMVC跨域、配置MyBatis分頁攔截器、配置MySQL連接等。advice則用作對controller層的補充,避免返回給用戶異常信息,在controller異常處理不足的接口做統一的異常攔截返回前端提示信息。

2.5 平臺UI實現模塊

由于平臺多是數據看板,因此,UI將多以地圖、條形圖、折線圖和雷達圖等圖表形式進行設計與實現,下面給出具有代表性的頁面并展開描述。

(1)首頁展示桂林市景區的分布地圖、接待總客流量和詞云圖等。其中,來源地分析指出各省來桂林游玩的人數,景區發布圖標記出客流量數、搜索指數、評論數和攻略數。詞云圖則是對所有A級景區的評論做出的詞云分析,將游客情緒分為3個等級給出各個等級的數量,還畫出景區好評率Top10排名等,如圖10所示。

圖10 平臺首頁

(2)項目列表則是桂林A級景區的列表,通過表格信息展現,內容包含景區名、地址、好評率、中評率、差評率、簽到數、搜索指數等情況。景區指標信息如圖11所示。

圖11 景區指標信息

(3)針對每一個景區監控其每個月的客流情況,如圖12所示。

圖12 景區客流情況

3 測試與驗證

對平臺進行單元模塊測試更注重在數據處理分析這一模塊,對該模塊的方法、函數進行單元測試,隨機截取原數據集進行測試比對,通過黑盒測試的方法驗證方法的正確性[13]。在完成了數據處理分析之后,也對平臺接口進行了集成測試,驗證了數據及其接口的正確性。在平臺完成之際對已部署到云服務器的平臺接口使用JMeter進行了壓力測試,用以鑒別是否能完成預期的相應時間和在該相應時間內的異常率[14]。

(1)模擬對A級景區信息列表接口在2 s內完成100個請求。其中,吞吐量為9.1/sec,實現了0%異常。

(2)對某個具體景區的游客情緒接口進行測試,同樣是2 s內完成100個請求。此接口不像景區信息列表接口有那么多的聯表查詢,吞吐量達到了36.2/sec,異常為0%。

由于平臺面向的用戶并非大群體,系統吞吐量足以滿足用戶的性能需求,平均每次請求響應時間為200 ms,滿足了平臺單個請求響應時間為100 ms～300 ms的要求,且在此響應時間內沒有丟棄請求的情況出現。

4 結語

面向桂林A級景區客流大數據分析平臺提供了輿情分析、景區指標和客流情況等功能,可以給景區統籌管理者作為重要的參考依據,改善景區的設施環境,提高景區的服務質量,對景區的后續發展起到重要作用。然縱使該軟件平臺給決策者提供了景區服務游客反映情況,便于對景區服務做出改進,但是由于數據的有限性和自身技術的不足,不能對現有數據挖掘出更加有效的價值,平臺的數據處理分析也是簡單進行過濾、數據扁平化、映射本系統數據,基于自身能力并沒有對數據太多的深度挖掘分析。本平臺也是初版,待繼續改進實現更加豐富、更加深入研究的功能,為景區管理提供更有價值的參考依據。