［宮云平 鄭博 許群路］

4G移動(dòng)用戶端到端業(yè)務(wù)清單關(guān)聯(lián)算法研究及實(shí)現(xiàn)

［宮云平 鄭博 許群路］

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

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

宮云平

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

鄭博

中國(guó)電信股份有限公司廣東分公司，畢業(yè)于華南理工大學(xué)，碩士研究生，就職于中國(guó)電信股份有限公司廣東分公司網(wǎng)絡(luò)運(yùn)營(yíng)部，主要研究方向?yàn)榫W(wǎng)絡(luò)運(yùn)營(yíng)支撐系統(tǒng)建設(shè)。

許群路

中國(guó)電信股份有限公司廣東分公司，就職于中國(guó)電信股份有限公司廣東分公司網(wǎng)絡(luò)運(yùn)營(yíng)部，主要研究方向?yàn)榫W(wǎng)絡(luò)運(yùn)營(yíng)支撐系統(tǒng)建設(shè)。

1 背景及目的

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

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

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

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

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

2 算法實(shí)現(xiàn)的關(guān)鍵技術(shù)點(diǎn)

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

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

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

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

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

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

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

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

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

3 算法關(guān)鍵實(shí)現(xiàn)過(guò)程概述

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

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

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

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

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

在采集過(guò)程中，有幾個(gè)關(guān)鍵點(diǎn)需要注意：

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

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

① Windows平臺(tái)不支持

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

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

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

① 給一個(gè)時(shí)間間隔，比如兩分鐘： 如果文件的修改時(shí)間跟當(dāng)前時(shí)間相比超過(guò)兩分鐘了； 說(shuō)明在這段時(shí)間內(nèi)都沒(méi)有修改，就認(rèn)為它寫完了。

② 缺點(diǎn): 文件傳到hadoop集群會(huì)有延遲，如果在那段時(shí)間間隔后再寫怎么辦？

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

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

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

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

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

① 方案1: 加”.copied”后綴，缺點(diǎn): 需要rename權(quán)限、只支持一個(gè)應(yīng)用對(duì)文件進(jìn)行rename，不支持多個(gè)應(yīng)用

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

通過(guò)對(duì)比，最終選擇方案2。

（3）當(dāng)發(fā)生日期切換時(shí)，如何采到23點(diǎn)的文件？

采集機(jī)上的文件有些是按日期分目錄的，例如2016-08-28號(hào)23點(diǎn)的一小部分文件，可能會(huì)意外的放到2016-08-29號(hào)的目錄中，這時(shí)不能以2016-08-29號(hào)為日期，而是提取文件名中的日期時(shí)間，然后傳到Hadoop集群相應(yīng)的HDFS目錄下。

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

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

（5）如何用簡(jiǎn)單的辦法及時(shí)通知入庫(kù)程序有新文件了？

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

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

③ 入庫(kù)程序檢查_(kāi)NEW_FILES_目錄的修改時(shí)間，如果比上一次要新，把該目錄中的文件名列出來(lái)，抽取出日期時(shí)間，然后去對(duì)應(yīng)的SRC目錄中找新文件，入庫(kù)后刪除臨時(shí)文件

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

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

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

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

在數(shù)據(jù)入庫(kù)過(guò)程中，有幾個(gè)關(guān)鍵點(diǎn)需要注意：

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

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

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

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

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

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

圖4 數(shù)據(jù)關(guān)聯(lián)架構(gòu)示意圖

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

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

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

③ 使用折半查找算法，從CHR中找出該條MR對(duì)應(yīng)的MDN/IMSI

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

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

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

① 啟動(dòng)25個(gè)Spark executor，分別讀取CHR_MR關(guān)聯(lián)表對(duì)應(yīng)的編號(hào)從0～24的25個(gè)分區(qū)文件

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

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

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

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

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

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

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

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

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

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

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

5 結(jié)束語(yǔ)

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

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

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

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

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

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

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

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

7馮登國(guó)，張敏，李昊.大數(shù)據(jù)安全與隱私保護(hù)［J］.計(jì)算機(jī)學(xué)報(bào)，2014，01:246-258

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

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

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

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

10.3969/j.issn.1006-6403.2016.10.007

（2016-10-12）