【摘? 要】提出了基于Spark、HBase和JavaWeb的移動網(wǎng)絡測評系統(tǒng)設計，把柵格數(shù)據(jù)進行地域分組聚合和比鄰分區(qū)存儲，提供適合分布式并行處理的數(shù)據(jù)架構(gòu)，設計自主研發(fā)的集群，采用完全分布式架構(gòu)完成從數(shù)據(jù)檢索到測評切片子圖生成的全過程，實現(xiàn)了全高清分辨率下像素級柵格化測評結(jié)果的高效可視化。

【關(guān)鍵詞】大數(shù)據(jù);移動網(wǎng)絡;測評系統(tǒng);系統(tǒng)優(yōu)化

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

文獻標志碼：A? ? ? ? 文章編號：1006-1010（2020）01-0092-05

引用格式：高智衡. 基于大數(shù)據(jù)的移動網(wǎng)絡測評系統(tǒng)設計和優(yōu)化[J]. 移動通信， 2020，44（1）： 92-96.

0? ?引言

移動通信網(wǎng)的業(yè)務分布具有較強的地理空間特征，網(wǎng)絡規(guī)劃、優(yōu)化等大部分工作要求結(jié)合地理環(huán)境對網(wǎng)絡覆蓋進行測評[1]，而把網(wǎng)絡數(shù)據(jù)映射到電子地圖上進行地理化呈現(xiàn)是一種重要的測評方式。

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

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

1? ?系統(tǒng)方案設計

系統(tǒng)業(yè)務邏輯方案如圖1所示，分為數(shù)據(jù)預處理和測評結(jié)果生成兩個階段。

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

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

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

2? ?系統(tǒng)優(yōu)化

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

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

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

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

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

針對以上問題，圍繞著實現(xiàn)像素級高精度大范圍即時測評的目標，對系統(tǒng)進行了以下優(yōu)化。

（1）重構(gòu)柵格，提供像素級別的精細度

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

（2）重組柵格數(shù)據(jù)的存儲結(jié)構(gòu)，實現(xiàn)批量檢索

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

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

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

（3）使用分布式架構(gòu)處理柵格組查詢和測評結(jié)果子圖生成

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

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

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

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

3? ? 結(jié)束語

本文所提出的基于大數(shù)據(jù)的移動網(wǎng)絡測評系統(tǒng)，把柵格數(shù)據(jù)進行地域分組聚合和比鄰分區(qū)存儲，提供了適合分布式并行處理的數(shù)據(jù)架構(gòu)，通過自主研發(fā)分布式集群，采用完全分布式的架構(gòu)完成從數(shù)據(jù)檢索到測評切片子圖生成的全過程，實現(xiàn)了全高清分辨率下像素級柵格化測評結(jié)果的高效可視化，可為類似系統(tǒng)的建設提供參考。

參考文獻：

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

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

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

[4]? ? ?陳飛翔. 移動空間信息服務關(guān)鍵技術(shù)研究[D]. 北京： 中國科學院， 2006.

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

[6]? ? 向俊，王靜，夏幼明. 判斷點與多邊形拓撲關(guān)系的改進算法[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 繪圖技術(shù)應用[J]. 電子測試， 2018（4）： 116-118.

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

[10]? ?李興菊，趙建軍. HBase數(shù)據(jù)庫行鍵設計及驗證[J]. 軟件導刊， 2019（6）： 26-30.

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

作者簡介

高智衡（orcid.org/0000-0002-2357-6921）：高級工程師，碩士畢業(yè)于華南理工大學，MBA畢業(yè)于中山大學，現(xiàn)任職于中國電信股份有限公司研究院，主要從事大數(shù)據(jù)平臺開發(fā)和應用研究等工作。