基於Spark的移動使用者主要活動地點的挖掘演算法實現以及JavaEE技術整合
本演算法基於Spark計算引擎,能夠從海量的手機基站資料中挖據出使用者的主要活動地點,比如工作地點和居住地點。實現好挖掘演算法之後,通過JavaEE來整合上面的演算法,讓使用者能夠通過簡單的Web UI就能夠操作使用該演算法,同時為使用者提供了視覺化資料的功能。
1、移動使用者主要活動地點挖掘演算法
1.1 演算法輸入資料欄位:
欄位名稱 | 說明 | 例子 |
---|---|---|
phoneNo | 手機號碼,唯一標誌一個使用者 | DEF2B5CA38FF9699732B65BA3941DBA2 |
time | 使用者連線基站的時間 | 20160923032356 |
longitude | 經度 | 113.4138 |
latitude | 緯度 | 23.1205 |
演算法資料是以CSV格式儲存,只要csv資料中包含上面的四個欄位就可以作為本演算法的輸入資料集。
1.2 手機基站資料的特點:
優點:
1)、獲取成本低
2)、資料量多
3)、覆蓋人群廣
4)、軌跡資料聯絡
缺點:
1)、資料不準確:手機基站的日誌資訊裡面包含移動使用者的經緯度資料,但是這個位置資料是不準確的,誤差範圍不超過該基站的訊號覆蓋半徑。當前通訊運營商的基站型號不統一,它們的覆蓋範圍也不同,覆蓋範圍從幾百米到上千米不等,這就使得手機基站記錄使用者的地理位置具有不準確性。
2)、資料分佈密度不均:居住人口密集的地方手機基站分佈也會密集,所以,城市的基站分佈比農村密集,城市市中心的基站分佈比城市外圍區域密集。在基站分佈密集的地方在幾百平方米內可能會存在多個手機基站,而在基站分佈稀疏的地方几公里範圍內可能只有一個手機基站。
3)、資料集中包含噪聲:一般情況下,移動使用者短暫停留在某手機基站的覆蓋範圍內的時候就會和該基站連線,該基站就會產生連線日誌資訊。因這些短暫的停留而產生的日誌資訊會影響到演算法對使用者重要活動地點的挖掘和分析。這便是噪聲資料。
4)、存在基站跳變的現象:當多個基站的訊號覆蓋區域存在重疊的時候,移動使用者恰好處於訊號的重疊區域,就會出現基站跳變的現象。具體表現為:使用者的手機訊號在這些基站間不斷切換。
本演算法能夠在很大程度上面克服手機基站資料的缺點,挖掘出使用者的主要活動地點。
1.3 演算法總體思路:
1.4 開發環境
開發環境統計表
名字 | 版本 | 描述 |
---|---|---|
Java | 1.8 | 後臺邏輯(語言) |
Scala | 2.11.8 | 演算法部分的程式語言 |
Javascript | 前臺邏輯(語言) | |
CSS | 前臺佈局和樣式(語言) | |
Jquery | 3.2.1 | 前臺邏輯(框架) |
Boostrap | 3.3.7 | 前臺佈局和樣式(框架) |
Spring | 4.1.7 | 後臺java物件容器(框架) |
SpringMVC | 4.1.7 | 和前臺互動(框架) |
LocalFS | 本地檔案系統 | |
HDFS | 2.7 | Hadoop分散式檔案系統 |
Apache Spark | 2.0.2 | 分散式計算框架 |
Intellij IDEA | 2016.2.5 | 整合開發環境 |
Tomcat | 1.7 | 應用伺服器 |
Maven | 3.0.5 | 版本管理工具 |
Open SUSE | leap 42.1 | Linux系統 |
1.5 演算法詳細思路:
來自論文:http://www.jos.org.cn/html/2016/7/5035.htm
2、JavaEE整合演算法
2.1 需求分析
前面的內容已經講了本應用系統的演算法,包括該演算法所解決的實際問題。實現好該演算法之後,我們需要考慮的問題是,如何讓使用者“方便”地使用該演算法?這裡所謂的“方便”指的是底層的演算法程式碼對使用者透明,使用者只需要關心演算法的輸入資料集、演算法閾值、結果儲存路徑等,使用者設定好這些引數之後,點選執行按鈕就可以執行。演算法執行結束之後,使用者能夠以視覺化的方式(比如地圖展示)檢視演算法執行結果。使用者在整個操作過程中,面對的只有人性化的Web UI互動頁面。
那麼,具體的需求是什麼呢?
1)原始資料集和演算法結果集既能夠儲存在本地檔案系統也能儲存在HDFS中。
2)使用者能夠通過Web UI設定以下引數:
(1)演算法資料集所在路徑。
(2)演算法結果儲存路徑。
(3)演算法閾值。
(4)Spark的執行模式:Local模式或者Standalone模式。
(5)資料集和結果集將儲存的檔案系統:本地系統檔案系統或者HDFS。
3)使用者能夠通過Web UI執行演算法。
4)使用者能夠通過Web UI檢視演算法在Spark叢集中的當前執行日誌。
5)使用者能夠通過地圖展示演算法結果座標點以及相應的原始資料座標點。
2.2 系統架構設計
從總體上看,本應用系統分為兩部分,分別是web前端和後臺。前端和後臺之間通過Ajax互動資料,資料的格式被封裝成JSON格式。
對於前臺,使用CSS和Boostrap進行頁面佈局和樣式設定。使用JQuery和Javascript編寫前臺的邏輯,包括前端和後臺之間的資料互動邏輯。使用Baidu Map API進行資料視覺化展示。
對於後臺,可把它分為兩部分,分別是Web Server和Core。Web Server處理網站邏輯,向上它能夠和web前臺互動,向下能夠操作演算法模型,所以,Web Server起到了橋樑的連線作用。Core部分主要執行演算法。Core中演算法主要有兩個,一個上文所講到的使用者職住地挖掘演算法,另一個是由Apache Common math提供DBSCAN演算法,該DBSCAN演算法是單機版的,選擇單機版而不是叢集版的原因有:(1)一個使用者的資料量往往不超過100兆,也就是在一臺機器上面也能正常執行。(2)在都能正常執行的情況下,單機版的DBSCAN演算法的運算效能是優於叢集版的,因為它減少了一些沒必要的排程。HDFS是Hadoop Distibuted File System的簡稱,是Hadoop生態圈中的一個分散式檔案系統,LocalFS指的是本地作業系統的檔案系統。當原始資料集或者演算法結果集比較大的時候,應該將它們儲存在HDFS檔案系統中。
2.3 應用操作時序圖
2.4 應用系統介面
2.4.1 引數設定模組
演算法的引數可以通過引數設定模組設定,演算法的引數有:DBSCAN演算法的eps引數,DBSCAN演算法的Min Points引數,Box Length引數,一個簇的最小點個數,狀態的持續時間和兩個相鄰狀態的時間間隔。這些引數不會因為介面切換到另一個模組而丟失。
2.4.2 資料集模組
演算法的輸入資料集既可以儲存在本地作業系統的檔案系統中,也可以儲存在HDFS檔案系統中。需要指定資料集的具體路徑。所以,需要提供輸入框讓使用者輸入資料集的URL。輸入的資料集是CSV(Comma-Separated Values)檔案,所以,使用者可以指定欄位之間的分隔符以及欄位所對應的下標。這樣可以大大較少資料集的格式要求:只需要資料集是CSV檔案,並且存在演算法所需的欄位,那麼它就可以作為本演算法的輸入資料集。
2.4.3 執行模組
經過前面的步驟,使用者已經設定好演算法的引數、演算法輸入的資料集、演算法結果儲存的位置。進入執行模組,使用者可以選擇演算法在Spark中的執行模式:Local模式或者Standalone模式。點選“執行演算法”按鈕之後,演算法就可以執行,在執行的過程中,使用者可以通過點選“重新整理日誌”按鈕檢視演算法的執行日誌,從而定位演算法執行進度。每一次點選“重新整理日誌”按鈕,給使用者展現的是最新的日誌,即使日誌的行數超過文字框的行數,這能體現系統的人性化設計。使用者也可以點選“清空日誌”按鈕清空日誌。
2.4.4執行模組
經過前面的步驟,使用者已經設定好演算法的引數、演算法輸入的資料集、演算法結果儲存的位置。進入執行模組,使用者可以選擇演算法在Spark中的執行模式:Local模式或者Standalone模式。點選“執行演算法”按鈕之後,演算法就可以執行,在執行的過程中,使用者可以通過點選“重新整理日誌”按鈕檢視演算法的執行日誌,從而定位演算法執行進度。每一次點選“重新整理日誌”按鈕,給使用者展現的是最新的日誌,即使日誌的行數超過文字框的行數,這能體現系統的人性化設計。使用者也可以點選“清空日誌”按鈕清空日誌。
2.4.5 視覺化展示模組
在視覺化展示模組中,使用者能夠把演算法的原始資料集和結果集展示在地圖上面。資料集和結果集分別使用兩種不同的地圖標註表示。當在同一個地方出現多個重合點的時候,只需顯示一個標註,並在該標註增加累加的計數,以表示該點有多少個重合的點。資料集和結果集的路徑是使用者在前面的模組中設定的,也就是說,在視覺化展示模組中,被展示的資料既可以來自本地檔案系統,也可以來自HDFS。紅色的地圖標註表示結果集的點,紫色且帶有數字的地圖標註表示原始資料集的點。
PPT下載地址為:
http://download.csdn.net/detail/liangyihuai/9863108