[宮云平 鄭博 許群路]
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è)。
在當(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.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),效率顯著提升。
端到端用戶清單關(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í)的查詢返回速度。
端到端的業(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)用。
用戶端到端的業(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)