［宮云平 鄭博 許群路］

4G移動用戶端到端業(yè)務清單關聯(lián)算法研究及實現(xiàn)

［宮云平 鄭博 許群路］

隨著4G網(wǎng)絡的全面部署和4G用戶的爆發(fā)增長，4G用戶感知提升成為電信運營商最主要的網(wǎng)絡優(yōu)化工作，尤其是室內(nèi)4G用戶感知評估和提升，由于室內(nèi)無線環(huán)境復雜、干擾因素多等，更是一直困擾運營商網(wǎng)優(yōu)部門的難題。傳統(tǒng)的室內(nèi)用戶質量提升主要從無線側入手，側重于提高無線側的網(wǎng)絡質量，而對于用戶的業(yè)務行為特點關注較少，往往會造成網(wǎng)絡的KPI指標和用戶的業(yè)務感知脫節(jié)的情況。本文則從用戶端到端的業(yè)務感知出發(fā)，運用大數(shù)據(jù)處理技術，形成從終端到云端，貫穿無線、承載、核心網(wǎng)、SP的，端到端的，用戶級的業(yè)務清單，為全網(wǎng)用戶端到端網(wǎng)絡質量評估分析和室內(nèi)深層覆蓋質差優(yōu)化提供基礎和前提。

4G 端到端 關聯(lián)算法

宮云平

中國電信股份有限公司廣州研究院，畢業(yè)于重慶郵電學院，本科，就職于中國電信股份有限公司廣州研究院，高級工程師，從事運營商大數(shù)據(jù)技術研究及數(shù)據(jù)應用產(chǎn)品開發(fā)工作。

鄭博

中國電信股份有限公司廣東分公司，畢業(yè)于華南理工大學，碩士研究生，就職于中國電信股份有限公司廣東分公司網(wǎng)絡運營部，主要研究方向為網(wǎng)絡運營支撐系統(tǒng)建設。

許群路

中國電信股份有限公司廣東分公司，就職于中國電信股份有限公司廣東分公司網(wǎng)絡運營部，主要研究方向為網(wǎng)絡運營支撐系統(tǒng)建設。

1 背景及目的

在當前4G網(wǎng)絡大規(guī)模部署中，4G移動網(wǎng)絡質量提升越來越強調(diào)面向用戶感知，基于端到端的業(yè)務流程來分析網(wǎng)絡質量對用戶感知的影響，并根據(jù)不同的業(yè)務特征來優(yōu)化網(wǎng)絡、配置相應的網(wǎng)絡資源，因此，需要在傳統(tǒng)的網(wǎng)絡運行KPI指標分析的基礎上，轉向基于端到端的用戶業(yè)務清單來分析4G移動用戶的感知和網(wǎng)絡質量。而4G網(wǎng)絡下全量用戶端到端清單數(shù)據(jù)的關聯(lián)分析存在以下難點：

（1）種類多、體量大：涉及從終端、無線、承載網(wǎng)、核心網(wǎng)、SP等維度的多種數(shù)據(jù)，百億條記錄的大表關聯(lián)

（2）不等值關聯(lián)：MR、CDR與CHR的關聯(lián)、DPI與MR的關聯(lián)都不是簡單的等值關聯(lián)，需要提供一些特殊算法來提升關聯(lián)程序的的性能和效率

（3）實時性要求高：準實時數(shù)據(jù)流處理，時延要求高

因此，4G移動用戶端到端業(yè)務清單關聯(lián)算法研究及實現(xiàn)作為一項前提性的基礎工作需要首先解決。

2 算法實現(xiàn)的關鍵技術點

2.1 根據(jù)數(shù)據(jù)業(yè)務特點劃小數(shù)據(jù)塊

4G用戶端到端清單關聯(lián)最大的難點在于數(shù)據(jù)量大，而且是不等值關聯(lián)，其中最主要的一個數(shù)據(jù)是DPI、CHR、MR三者的不等值關聯(lián)。MR數(shù)據(jù)作為無線側用戶級的主要數(shù)據(jù)，需要與核心網(wǎng)側用戶級的清單數(shù)據(jù)DPI關聯(lián)，這兩個數(shù)據(jù)是我們端到端的清單數(shù)據(jù)的核心。但是有MR數(shù)據(jù)中沒有用戶的MDN/IMSI信息，而DPI數(shù)據(jù)則是以用戶的MDN/IMSI作為主要索引的，所有如果想把無線側的MR數(shù)據(jù)與核心網(wǎng)的DPI數(shù)據(jù)關聯(lián)起來，得到用戶級的清單數(shù)據(jù)，必須借助CHR數(shù)據(jù)為橋梁。目前廣東電信DPI數(shù)據(jù)一天約200億條記錄，MR數(shù)據(jù)約60億條記錄，CHR數(shù)據(jù)約50億條記錄。如此大量的三個數(shù)據(jù)做不等值關聯(lián)，即使使用hadoop集群處理技術，仍然是一個非常大的難題。

解決這個問題的基本思路是化小，并且根據(jù)數(shù)據(jù)關聯(lián)的化小。首先是MR和CHR的關聯(lián)，其關聯(lián)規(guī)則是：兩個數(shù)據(jù)的eNodeB_ID相等、MmeUeS1apId相等、且記錄中的時間戳前后相差不超過60秒，選擇符合上述要求的時間戳最接近的兩條做關聯(lián)。根據(jù)關聯(lián)規(guī)則，首先按照小時化小數(shù)據(jù)塊，這樣CHR和MR的數(shù)據(jù)忙時一小時大概是5億條數(shù)據(jù)的級別，再按照eNodeB_ID分成50個數(shù)據(jù)塊（用eNodeB_ID模50的方法），這樣切分下來，每個數(shù)據(jù)塊就百萬—千萬級別，然后再按照時間戳取前后60秒的數(shù)據(jù)去關聯(lián)MR和CHR，最后得到時間最接近的兩條數(shù)據(jù)，將CHR中的IMSI/MDN賦值給MR，這樣就讓MR數(shù)據(jù)有了用戶的MDN/IMSI信息。

對于MR和DPI數(shù)據(jù)的關聯(lián)，思路也是同樣的化小。MR和DPI的關聯(lián)規(guī)則是：兩個數(shù)據(jù)的MDN相等，且記錄中的時間戳相差不超過5秒，選擇符合上述要求的時間戳最接近的兩條做關聯(lián)。按照同樣的思路，我們把MR和DPI數(shù)據(jù)首先按照小時化小數(shù)據(jù)塊，然后再按照MDN劃分成50個數(shù)據(jù)塊（用MDN模50的方法），經(jīng)過這樣切分，每個數(shù)據(jù)塊化小到千萬級別，再進行兩者的關聯(lián)后，就可以將MR和DPI數(shù)據(jù)串接起來，形成用戶端到端業(yè)務清單數(shù)據(jù)的核心。

2.2 預判下一個環(huán)節(jié)數(shù)據(jù)處理要求

數(shù)據(jù)處理是采集-入庫-分析-處理-輸出這樣一個一環(huán)扣一環(huán)的流水線似的作業(yè)，每一個環(huán)節(jié)都應該考慮下一個環(huán)節(jié)怎么使用這個數(shù)據(jù)，因此在輸出給下一個環(huán)節(jié)是，不但要考慮本環(huán)節(jié)生成的性能要求，還要提前考慮下一個環(huán)節(jié)的數(shù)據(jù)要求。

例如上面的DPI、CHR、MR關聯(lián)時，首先做的是MR和CHR的關聯(lián)，這兩個數(shù)據(jù)的關聯(lián)規(guī)則是按照“小時+eNodeB_ID（模50分區(qū)）”的，所以在MR和CHR數(shù)據(jù)入庫后就直接采用這種分塊方式存儲。而MR和CHR關聯(lián)后，接下來跟DPI關聯(lián)時，需要采用“小時+MDN（模50分區(qū)）”，所以MR和CHR的關聯(lián)結果文件以及DPI入庫后的文件都應該按照“小時+MDN（模50分區(qū)）”的數(shù)據(jù)塊存儲。這樣對下一個環(huán)節(jié)數(shù)據(jù)處理要求的預判以及提前做的準備工作，可以大大提升數(shù)據(jù)的處理效率，減少I/O讀取次數(shù)。

2.3 數(shù)據(jù)處理由MapReduce改成Spark處理。

MR、CHR、DPI大表不等值關聯(lián)數(shù)據(jù)的處理，由傳統(tǒng)的調(diào)用hadoop的MapReduc程序處理，改用Spark內(nèi)存式分布處理架構，一小時的MR/CHR/DPI數(shù)據(jù)（約15億*5億條）進行關聯(lián)時間由原來的8小時提升到10分鐘以內(nèi)，效率顯著提升。

3 算法關鍵實現(xiàn)過程概述

端到端用戶清單關聯(lián)的關鍵實現(xiàn)過程包括數(shù)據(jù)采集、數(shù)據(jù)入庫、數(shù)據(jù)分析三個層面，如圖1所示。

3.1 數(shù)據(jù)采集

端到端業(yè)務清單數(shù)據(jù)關聯(lián)涉及到不同專業(yè)、不同網(wǎng)元、不同系統(tǒng)產(chǎn)生的數(shù)據(jù)，關聯(lián)的第一步首先通過FTP方式把各類數(shù)據(jù)采集到集中的網(wǎng)絡數(shù)據(jù)運營平臺的采集機上，然后再送上hadoop集群，如圖2所示。

圖1 端到端用戶清單關聯(lián)數(shù)據(jù)處理整體架構示意圖

圖2 數(shù)據(jù)采集處理架構示意圖

在采集過程中，有幾個關鍵點需要注意：

（1）從網(wǎng)管服務器傳到采集機上的文件，如何判斷文件已經(jīng)傳完？

方案1 ：執(zhí)行l(wèi)sof命令判斷是否有進程在寫文件。特點：

① Windows平臺不支持

② 調(diào)用一次要10毫秒以上

③ 多個進程在很短的間隔內(nèi)依次寫同一個文件時，lsof在這個間隔中間執(zhí)行會誤判文件已經(jīng)寫完

方案2.依據(jù)時間間隔判斷

① 給一個時間間隔，比如兩分鐘： 如果文件的修改時間跟當前時間相比超過兩分鐘了； 說明在這段時間內(nèi)都沒有修改，就認為它寫完了。

② 缺點: 文件傳到hadoop集群會有延遲，如果在那段時間間隔后再寫怎么辦？

方案3.制定規(guī)范

① 傳到采集機上的文件，如果正在傳，還沒有寫完，先以”.tmp”（或其他）后綴命名，寫完后再去掉”.tmp”后綴。

② 只有非”.tmp”結尾的文件才能從采集機上傳到hadoop集群。

通過對比，最終選擇相對較優(yōu)的方案3實現(xiàn)。

（2）如何判斷采集機上的文件已經(jīng)傳到hadoop集群，避免重傳，同時支持發(fā)生錯誤時補傳？

① 方案1: 加”.copied”后綴，缺點: 需要rename權限、只支持一個應用對文件進行rename，不支持多個應用

② 方案2: 把讀過的文件名記錄到一個HDFS文件或本地文件中，傳失敗的文件不記錄。同時，這種方案還可以方便核查比對，幫助尋找代碼中的bug。

通過對比，最終選擇方案2。

（3）當發(fā)生日期切換時，如何采到23點的文件？

采集機上的文件有些是按日期分目錄的，例如2016-08-28號23點的一小部分文件，可能會意外的放到2016-08-29號的目錄中，這時不能以2016-08-29號為日期，而是提取文件名中的日期時間，然后傳到Hadoop集群相應的HDFS目錄下。

（4）如何優(yōu)雅地關閉采集程序？

使用shutdown hook，kill pid （不加-9）。 直到正在傳送的文件傳完到hadoop集群時才退出

（5）如何用簡單的辦法及時通知入庫程序有新文件了？

① 在HDFS中為CHR、CDR、MR、DPI創(chuàng)建特殊的NEW_FILES_子目錄，例如CHR是: /DATA/ PUBLIC/NOCE/SRC/SRC_CHR_L_MM/_NEW_FILES_

② 采集程序每次傳了一批文件到Hadoop集群后，在NEW_FILES_目錄中生成一個文件名包含日期時間的臨時文件

③ 入庫程序檢查_NEW_FILES_目錄的修改時間，如果比上一次要新，把該目錄中的文件名列出來，抽取出日期時間，然后去對應的SRC目錄中找新文件，入庫后刪除臨時文件

3.2 數(shù)據(jù)入庫

數(shù)據(jù)入庫就是把送上HDFS的文件進行清洗、加密、分區(qū)，生成ETL表。入庫程序自動識別采集程序傳到Hadoop集群的各種文件類型，然后將文件分批處理，集群每個節(jié)點一次處理一批文件，各類數(shù)據(jù)文件并行處理，提高入庫效率。同時對于壓縮文件不解壓到硬盤，邊讀邊解析邊分區(qū)入庫。對于大文件，在單個節(jié)點上，用一個讀線程加多個解析線程的方式，充分利用CPU，減少大文件的入庫時間，如圖3所示。

圖3 數(shù)據(jù)入庫處理架構示意圖

數(shù)據(jù)入庫階段要充分考慮該數(shù)據(jù)的業(yè)務特征，為下一個環(huán)節(jié)的數(shù)據(jù)處理做好準備，例如對于MR和CHR數(shù)據(jù)，這里就應按照小時、eNodeB_ID模50的方法，每小時分成50個數(shù)據(jù)塊。而對于DPI數(shù)據(jù)，則是按照小時和MDN模50的方法劃分數(shù)據(jù)塊。

在數(shù)據(jù)入庫過程中，有幾個關鍵點需要注意：

（1）異常記錄保留得處理

對于eNodeB_ID和MDN為0的記錄，單獨放到一個分區(qū)，例如第51個分區(qū)，用eNodeB_ID或MDN做關聯(lián)分析時忽略異常記錄

（2）避免多個節(jié)點同時寫同一個分區(qū)文件的方法：由于某一批文件只會在一個節(jié)點中處理，為每一批文件分配一個id（可循環(huán)使用），從而避免發(fā)生寫沖突

3.3 數(shù)據(jù)關聯(lián)

有前面數(shù)據(jù)入庫時做的數(shù)據(jù)塊化小的準備工作，數(shù)據(jù)關聯(lián)主要實現(xiàn)對應的兩個化小數(shù)據(jù)塊之間的關聯(lián)，同時為了避免內(nèi)存溢出，邊讀邊計算邊輸出，及時將關聯(lián)后的結果輸出到結果表，如圖4所示。

數(shù)據(jù)關聯(lián)過程中的關鍵實現(xiàn)步驟：

圖4 數(shù)據(jù)關聯(lián)架構示意圖

（1）CHR與MR關聯(lián)

① 啟動25個Spark executor，分別讀取某個小時的CHR數(shù)據(jù)中的前25個數(shù)據(jù)塊，并將其加載到內(nèi)存，同時按照eNodeB_ID、MmeUeS1apId、Start_Time這3個字段排序

② 讀取MR對應的分區(qū)文件，不用一次全加載到內(nèi)存

③ 使用折半查找算法，從CHR中找出該條MR對應的MDN/IMSI

④ 重復上面步驟，把后25個數(shù)據(jù)塊關聯(lián)完，這樣就完成了CHR和MR一小時內(nèi)的數(shù)據(jù)關聯(lián)

⑤ 結果輸出到CHR_MR關聯(lián)表中，同時將該表按照MDN劃分成50個數(shù)據(jù)塊（用MDN模50的方法），為接下來的和DPI的再次關聯(lián)做準備。

（2）DPI與MR關聯(lián)

① 啟動25個Spark executor，分別讀取CHR_MR關聯(lián)表對應的編號從0～24的25個分區(qū)文件

② 加載到內(nèi)存后，將MDN 相同的分成一組，同組內(nèi)的記錄按timeStamp字段升序排序

③ 讀取DPI對應的分區(qū)文件，不用一次全加載到內(nèi)存

④ 使用DPI的MDN字段找到對應的那組CHR_MR關聯(lián)表記錄，然后再順序比較timeStamp是否在DPI的ts_start和ts_end之間

⑤ 重復1～5，把分區(qū)25到49關聯(lián)完

（3）處理DPI MDN為0的記錄

DPI數(shù)據(jù)中有大量MDN為0的記錄，這部分記錄在用戶端到端關聯(lián)上是垃圾數(shù)據(jù)，但是在進行其他模型分析時，該部分數(shù)據(jù)是有用的，所以這部分數(shù)據(jù)需要保留。但是該部分數(shù)據(jù)與正常記錄產(chǎn)生的分區(qū)大小相比會有一個數(shù)量級的差距，造成數(shù)據(jù)不均衡，不能跟正常分區(qū)一起跑數(shù)據(jù)分析。解決方案是啟動第51個分區(qū)來分散存儲MDN為0的記錄額外啟動多個Spark Task來并行分析這些文件。

3.4 數(shù)據(jù)輸出

經(jīng)過上述關聯(lián)后，形成了4G用戶端到端的業(yè)務清單數(shù)據(jù)，該清單數(shù)據(jù)反映了全網(wǎng)任何一個用戶，在任何時間，用什么類型的終端，在什么位置，訪問了什么業(yè)務，當時端到端的網(wǎng)絡質量/指標（包括無線網(wǎng)、承載網(wǎng)、核心網(wǎng)等）是怎樣的，用戶的業(yè)務體驗（網(wǎng)頁打開時延、視頻下載速率等）如何等。為了更好地支持這些端到端的清單數(shù)據(jù)的快速查詢和輸出，將清單數(shù)據(jù)存儲在HBASE數(shù)據(jù)庫中，并且以“MDN+時間”作為查詢主鍵，實現(xiàn)了百億條清單數(shù)據(jù)秒級的查詢返回速度。

4 系統(tǒng)現(xiàn)網(wǎng)部署驗證

端到端的業(yè)務清單關聯(lián)數(shù)據(jù)采用新算法后，與原來直接按照時間粒度劃分后采用MR程序進行大表關聯(lián)相比，性能提升為原來的48倍，極大地算短了數(shù)據(jù)結果輸出時延。端到端業(yè)務清單關聯(lián)數(shù)據(jù)完全采用自主研發(fā)團隊，基于hadoop開源軟件架構，自主設計開發(fā)實現(xiàn)，與購買外部商用軟件比，響應快、工期短、部署快。整個工作從設計到開發(fā)一個月內(nèi)完成。

4G用戶端到端的業(yè)務清單關聯(lián)在2015年10月已經(jīng)在廣東電信網(wǎng)絡數(shù)據(jù)運營平臺上線應用，運行一年以來，該套關聯(lián)算法運行穩(wěn)定，實時性好，處理效率高，其采用的設計理念計算法已經(jīng)成為該平臺核心數(shù)據(jù)處理程序，在多個海量數(shù)據(jù)關聯(lián)場景中得到應用。

5 結束語

用戶端到端的業(yè)務清單數(shù)據(jù)真正實現(xiàn)了全網(wǎng)任何用戶（Anyone）任何時間（Anytime）、任何位置（Anywhere）、任何業(yè)務行為（Anything），以及用戶當時的業(yè)務質量感知（時延、速率）等情況、無線網(wǎng)質量（覆蓋、干擾）與核心網(wǎng)的運行情況等。目前該清單數(shù)據(jù)被廣泛應用用客服投訴查詢、樓群感知評估、人群流動分析等應用中。

4G用戶端到端業(yè)務清單數(shù)據(jù)關聯(lián)的思路及實現(xiàn)方法可以廣泛應用于海量數(shù)據(jù)的大表關聯(lián)的數(shù)據(jù)處理實踐中，為海量網(wǎng)絡運營數(shù)據(jù)的處理和價值挖掘提供基礎。

1孟小峰，慈祥.大數(shù)據(jù)管理:概念、技術與挑戰(zhàn)［J］.計算機研究與發(fā)展，2013，01:146-169

2李建中，劉顯敏.大數(shù)據(jù)的一個重要方面:數(shù)據(jù)可用性［J］.計算機研究與發(fā)展，2013，06:1147-1162

3王元卓，靳小龍，程學旗.網(wǎng)絡大數(shù)據(jù):現(xiàn)狀與展望［J］.計算機學報，2013，06:1125-1138

4韓晶.大數(shù)據(jù)服務若干關鍵技術研究［D］.北京郵電大學，2013

5李學龍，龔海剛.大數(shù)據(jù)系統(tǒng)綜述［J］.中國科學:信息科學，2015，01:1-44

6李文蓮，夏健明.基于“大數(shù)據(jù)”的商業(yè)模式創(chuàng)新［J］.中國工業(yè)經(jīng)濟，2013，05:83-95

7馮登國，張敏，李昊.大數(shù)據(jù)安全與隱私保護［J］.計算機學報，2014，01:246-258

8孫大為，張廣艷，鄭緯民.大數(shù)據(jù)流式計算:關鍵技術及系統(tǒng)實例［J］.軟件學報，2014，04:839-862

9張引，陳敏，廖小飛.大數(shù)據(jù)應用的現(xiàn)狀與展望［J］.計算機研究與發(fā)展，2013，S2:216-233

10盧輝，數(shù)據(jù)挖掘與數(shù)據(jù)化運營實戰(zhàn)：思路、方法、技巧、應用，大數(shù)據(jù)技術叢書，機械工業(yè)出版社，2012.6

11中國電信客戶感知項目組，中國電信移動網(wǎng)業(yè)務感知分析系統(tǒng)功能規(guī)范，技術規(guī)范，中國電信集團 2015.1

10.3969/j.issn.1006-6403.2016.10.007

（2016-10-12）