基于大數據的移動網絡測評系統設計和優化

2020-02-22 12:25:59 移動通信 2020年1期

【摘? 要】提出了基于Spark、HBase和JavaWeb的移動網絡測評系統設計,把柵格數據進行地域分組聚合和比鄰分區存儲,提供適合分布式并行處理的數據架構,設計自主研發的集群,采用完全分布式架構完成從數據檢索到測評切片子圖生成的全過程,實現了全高清分辨率下像素級柵格化測評結果的高效可視化。

【關鍵詞】大數據;移動網絡;測評系統;系統優化

doi:10.3969/j.issn.1006-1010.2020.01.0017? ? ? ? 中圖分類號:TN929.5

文獻標志碼:A? ? ? ? 文章編號:1006-1010(2020)01-0092-05

引用格式:高智衡. 基于大數據的移動網絡測評系統設計和優化[J]. 移動通信, 2020,44(1): 92-96.

0? ?引言

移動通信網的業務分布具有較強的地理空間特征,網絡規劃、優化等大部分工作要求結合地理環境對網絡覆蓋進行測評[1],而把網絡數據映射到電子地圖上進行地理化呈現是一種重要的測評方式。

當數據量較少(如傳統路測)時,采用打點式測評,即直接在地圖上打點,使用不同色系渲染不同區間內的數據。隨著網絡演進和大數據技術普及,可取得的測評數據越來越多,如南方某省運營商從基站采集MR(Measure Report)測量報告數據每天多達300多億條,因而演化出柵格化測評。柵格是指地圖平面上選定某個點為原點,按橫向和縱向進行等距離切分而形成的網格。為配合各個地圖縮放級別,柵格的切分也相應有多個級別。基于MR數據的位置計算各個柵格內錄得的通信指標統計均值,然后在地圖上以不同顏色代表各柵格的指標質量好壞[2]。

業界的柵格化測評方案主要有兩種。一種方案是預切圖,即針對所研究的地理范圍內各種地圖比例尺預生成小圖塊,用戶訪問時直接加載小圖塊[3]。因評估結果已預生成,故此方案測評響應非常快,然而當指標種類較多時,每個指標均需預切一套圖,占用非常龐大的存儲空間。而且,無法滿足面向用戶的自定義指標分段區間和個性化色系需求。另一種方案是即時動態渲染,即根據所需顯示的柵格計算出需要可視化的像素位置,根據相關柵格指標所屬區間計算出各柵格對應的著色,然后進行可視化。此方案可靈活調整色系、區間劃分等可視化效果。然而當柵格數據量龐大時,對系統的性能開銷巨大,為提供較快的測評響應,往往把柵格設計得較粗,以減少所需檢索的數據,因而測評精度不高。本文研究如何基于大數據技術構建高效率高精度的移動網絡柵格化即時測評系統。

1? ?系統方案設計

系統業務邏輯方案如圖1所示,分為數據預處理和測評結果生成兩個階段。

在數據預處理階段,先對采集到的MR數據進行定位,確定其經緯度坐標,并按各級別的柵格進行匯總。為了使更多MR數據可用,除使用基于終端的AGPS(Assisted Global Positioning System)定位外,還需要結合三角定位、指紋定位等多種基于網絡的定位技術[4]。然后,把各級別柵格的匯總數據以統計日期和柵格編號為行鍵(KEY)存入HBase。HBase是具有支持海量數據、列式存儲、分布式可擴展、高可靠、高性能等特點的開源數據庫,能為數據檢索提供毫秒級快速響應[5]。

在測評結果生成階段,先計算出關注區域的外接矩形所涉及的所有柵格,然后對這些柵格逐一處理:采用射線法快速判斷柵格中心點與關注區的關系[6],對于中心點落入關注區的柵格,則根據其柵格號檢索出相應業務數據,最后,根據取得的所有數據運用Canvas高效渲染技術[7]展現測評結果。

本方案的技術架構如圖2所示,數據存儲層為HDFS(Hadoop Distributed File System),負責MR數據源和HBase結果表數據的存儲,使用Spark對MR源數據進行定位和匯總預處理,并加載數據到HBase集群。基于內存計算的Spark可提供高性能的大規模數據處理能力[8],實現海量MR數據的處理。需要注意的是,為提升數據加載到HBase時的寫入性能,加載前Spark已對數據按KEY進行排序,HBase集群提供對任意柵格的快速數據檢索服務。基于JavaWeb構建數據查詢服務,負責接收用戶提交的測評請求,檢索出所有相關柵格測評數據,瀏覽器則負責結果展現。本方案一方面提供了面向海量數據源的高性能預處理能力,另一方面對任意形狀的關注區域,在檢索柵格量不超10萬的情況下,均可快速返回數據并展示測評結果。

2? ?系統優化

隨著測評工作的深入開展,用戶對測評的范圍和精度要求越來越高,當查詢大規模柵格量時,上述方案的不足之處就顯現出來了:

首先,由于柵格檢索量局限于10萬以內,所以測評效果精細度不高,存在著明顯的柵格方塊感。

其次,采用枚舉所有柵格的方式查詢HBase,總體效率低下。由于柵格數據進行了按柵格號排序存儲,雖然十萬以下柵格量的查詢時性能還是比較高的,但柵格量增長到數十萬甚至數百萬時,逐個柵格枚舉檢索方案的總體性能極其低下。

再次,柵格數據量龐大時,服務端處理壓力劇增,極易引起數據查詢服務端內存溢出故障。曾經嘗試精細測評某個營銷服務中心,其涉及柵格約80多萬個,程序執行后JavaWeb服務端因內存溢出而掛死。

最后,柵格數據量龐大時,客戶端處理壓力大。實測表明,即使運用了Canvas高效渲染技術,客戶端單機處理大量柵格的渲染也十分耗時,一般最多只可接受數萬柵格的測評。

針對以上問題,圍繞著實現像素級高精度大范圍即時測評的目標,對系統進行了以下優化。

(1)重構柵格,提供像素級別的精細度

如前所述,為配合各縮放級別地圖,柵格的切分也相應地有多種級別。柵格級別設計成從20 m開始,逐級倍增,形成[20, 40, 80, 160, 320……]這樣的柵格級別系列,因而每個級別均可從前一個級別直接匯總而成,有利于減少計算量。優化前后的柵格級別與地圖縮放級別對應關系如表1所示。優化前,為避免過多柵格量的檢索,設計原則為全高清分辨率下全屏柵格量控制在不超過10萬,雖有效保證了響應性能,但直接導致測評效果圖不精細,優化后方案以取得像素級別的測評精細度為目標,根據每個級別下的地圖像素距離,選取柵格級別系列中小于像素距離的最大值作為該級別的柵格距離。優化前、后各地圖縮放級別與柵格級別的對應關系如表1所示。

(2)重組柵格數據的存儲結構,實現批量檢索

從表1可見,優化后實現了像素級別的測評精細度,但帶來的問題是涉及的柵格查詢量劇增,最多可達360多萬個。圖3是根據不同的柵格檢索量,分別使用枚舉檢索和批量檢索得出的響應時間曲線。所謂枚舉檢索就是列出所有要求查詢柵格的KEY值來檢索;而批量檢索則是給出KEY的起止范圍。從圖可見,當柵格數量較少(少于3萬個)時,兩者的響應時間相差不大,但當柵格量增加到10萬、30萬時,枚舉檢索的時間急劇增長,而批量檢索則明顯高效得多。因此必須調整柵格按編號簡單排序的存儲方式,實現批量檢索,以提升查詢效率。

柵格數據的主要存儲結構有:直接編碼、鏈式編碼、游程編碼、塊式編碼和四叉樹編碼等[9]。前述的按KEY簡單排序就屬于直接編碼,我們對其進行改進,把k×j個柵格矩陣(稱為柵格組)合并為一個整體(對應一個KEY),從而實現了柵格組內的所有柵格數據的批量檢索。

優化后,測評結果生成階段業務流程如圖4所示。由于不再按柵格而是按柵格組來檢索,因此檢索工作量大幅度減少為原來的(k×j)分之一。對每一個柵格組,根據它與關注區的拓撲關系,分為三種情況來處理。左邊,柵格組整體位于關注區內,則渲染組內所有柵格而生成測評子圖;右邊,柵格組整體位于關注區外,則略過不處理;中間,柵格組部分處于關注區內而部分處于關注區外。所以需要再進一步遍歷組內的每一個柵格,只保留處于關注區內的柵格來生成測評子圖,最后把所有子圖拼接起來形成最終的測評結果。

(3)使用分布式架構處理柵格組查詢和測評結果子圖生成

在全屏展示的情況下,當柵格距離小于像素距離時,柵格組的數量多達數百個,為進一步提升測評結果生成的處理效率,引入分布式計算架構,采用多個計算節點并行處理柵格組數據查詢和測評結果子圖生成的任務。

HBase的KEY設計要考慮在同一時間段讀寫操作都集中在某一個Region上而出現負載不均衡問題[10]。柵格組簡單地按日期和編號為KEY排序時,某關注區所需檢索的HBase數據基本集中在一兩個Regionserver,容易引起HBase集群服務局部過熱。為此,增加柵格組的預分區設計,可強制使地域上鄰近的柵格組分布到不同的Region,避免HBase集群計算量分布不均衡[11]。預分區碼設計為P=(N×j+M)%=(j×k),其中j、k為正整數,M為柵格組經度方向編號,N為柵格組緯度方向編號。本設計可保證任意一個小于或等于j×k的柵格組矩陣內,P值不會重復,從而實現良好的分布性。

完成上述優化后,系統技術架構調整為如圖5所示。關鍵改進在于數據查詢服務和HBase之間加入了一個自主研發的分布式柵格檢索集群。集群中的Master負責:識別出相關的所有柵格組的KEY值;按KEY平均分配任務給Worker;接收Worker返回的測評子圖并返回給數據查詢服務。各Worker負責:向HBase集群提交查詢(枚舉所分配到的所有KEY);基于柵格組與關注區域的相互位置生成測評子圖;返回所負責的所有子圖給Master。Master采用多節點部署以提供高可用,整個集群集成到Zookeeper進行統一管理。另外,JavaWeb和Browser拿到的是測評結果子圖,不再處理柵格級別的數據,其處理壓力大大降低。

基于上述優化方案,在實際生產系統上采用64×64個柵格合并為一個柵格組,分區公式中的j、k取值均為8,使用64個節點的分布式集群,可在3 s內完成涉及3百多萬柵格的關注區域的即時測評。圖6和圖7是在5 km地圖比例尺下同一關注區域優化前、后測評效果的局部截屏,可看出優化后基于像素級精細度柵格的測評已不存在明顯的方塊感,黃色(質差)區域的形狀非常精確,甚至可以看到優化前無法呈現的少量紅色(質量極差)區域的存在,測評效果大幅度提升。

3? ? 結束語

本文所提出的基于大數據的移動網絡測評系統,把柵格數據進行地域分組聚合和比鄰分區存儲,提供了適合分布式并行處理的數據架構,通過自主研發分布式集群,采用完全分布式的架構完成從數據檢索到測評切片子圖生成的全過程,實現了全高清分辨率下像素級柵格化測評結果的高效可視化,可為類似系統的建設提供參考。

參考文獻:

[1]? ? ? ESRI中國(北京)有限公司. 通信行業GIS應用解決方案及海外案例集錦[R]. 2012.

[2]? ? ?章孝燦,潘云鶴. GIS中基于“柵格技術”的柵格數據矢量化技術[J]. 計算機輔助設計與圖形學學報, 2001,13(10): 895-900.

[3]? ? ? 鄭姍,劉國柱. 一種柵格覆蓋信息的展示方法與裝置: 中國, 201710096981.8[P/OL]. (2017-07-14)[2019-06-10]. http://www.soopat.com/Patent/201710096981.

[4]? ? ?陳飛翔. 移動空間信息服務關鍵技術研究[D]. 北京: 中國科學院, 2006.

[5]? ? RUCHIR C. HBase High Performance Cookbook[M]. Birmingham: Packt Publishing, 2017.

[6]? ? 向俊,王靜,夏幼明. 判斷點與多邊形拓撲關系的改進算法[J]. 計算機工程與設計, 2014,35(5): 1732-1737.

[7]? ? Apache Software Foundation. Spark Overview[EB/OL]. (2019-05-08)[2019-06-10]. https://spark.apache.org/docs/latest/.

[8]? ? ?吳飛燕. 基于 HTML5 Canvas 繪圖技術應用[J]. 電子測試, 2018(4): 116-118.

[9]? ? ?百度百科. 柵格數據[EB/OL]. (2019-03-27)[2019-06-20]. https://baike.baidu.com/item/柵格數據/5261386.

[10]? ?李興菊,趙建軍. HBase數據庫行鍵設計及驗證[J]. 軟件導刊, 2019(6): 26-30.

[11]? ?CSDN(Chinese Software Developer Network). HBase學習之六: HBase的預分區設計[EB/OL]. (2018-05-22)[2019-06-20]. https://blog.csdn.net/javajxz008/article/details/51913471.

作者簡介

高智衡(orcid.org/0000-0002-2357-6921):高級工程師,碩士畢業于華南理工大學,MBA畢業于中山大學,現任職于中國電信股份有限公司研究院,主要從事大數據平臺開發和應用研究等工作。

江南高纤股票分析