汪保友，錢晶，袁時(shí)金

（1.中國聯(lián)合網(wǎng)絡(luò)通信有限公司上海市分公司，上海 200050；2.同濟(jì)大學(xué)軟件學(xué)院，上海 201804）

基于Hadoop的電信大數(shù)據(jù)采集方案研究與實(shí)現(xiàn)

汪保友1，錢晶1，袁時(shí)金2

（1.中國聯(lián)合網(wǎng)絡(luò)通信有限公司上海市分公司，上海 200050；2.同濟(jì)大學(xué)軟件學(xué)院，上海 201804）

ETL是數(shù)據(jù)倉庫實(shí)施過程中一個(gè)非常重要的步驟，設(shè)計(jì)一個(gè)能夠?qū)Υ髷?shù)據(jù)進(jìn)行有效處理的ETL流程以提高運(yùn)營平臺(tái)的采集效率，具有重要的實(shí)際意義。首先簡單介紹某運(yùn)營商大數(shù)據(jù)平臺(tái)采集的主要數(shù)據(jù)內(nèi)容。隨后，為提升海量數(shù)據(jù)采集效率，提出了Hadoop與Oracle混搭架構(gòu)解決方案。繼而，提出一種動(dòng)態(tài)觸發(fā)式ETL調(diào)度流程與算法，與定時(shí)啟動(dòng)的ETL流程調(diào)度方式相比，可有效縮短部分流程的超長等待時(shí)間；有效避免資源搶占擁堵現(xiàn)象。最后，根據(jù)Hadoop和Oracle的系統(tǒng)運(yùn)行日志，比較分析了兩個(gè)平臺(tái)的采集效率與數(shù)據(jù)量之間的關(guān)系。實(shí)踐表明，混搭架構(gòu)的大數(shù)據(jù)平臺(tái)優(yōu)勢(shì)互補(bǔ)，可有效提升數(shù)據(jù)采集時(shí)效性，獲得比較好的應(yīng)用效果。關(guān)鍵詞：大數(shù)據(jù)；ETL；Hadoop；調(diào)度流程；混搭架構(gòu)

1 引言

移動(dòng)互聯(lián)網(wǎng)時(shí)代，數(shù)據(jù)資源無疑是重要的戰(zhàn)略資源。電信運(yùn)營商擁有龐大的活躍用戶群體，處在大數(shù)據(jù)產(chǎn)業(yè)鏈的傳輸與交換中心地位，具有豐富的高價(jià)值數(shù)據(jù)資源。除了用戶辦理業(yè)務(wù)時(shí)產(chǎn)生的用戶實(shí)名制基礎(chǔ)信息外，每天還會(huì)持續(xù)產(chǎn)生大量的用戶消費(fèi)數(shù)據(jù)、用戶行為數(shù)據(jù)、用戶地理位置數(shù)據(jù)、用戶社交UGC數(shù)據(jù)等。智能終端的普遍使用，4G網(wǎng)絡(luò)的興起、網(wǎng)絡(luò)帶寬的大提速等業(yè)務(wù)和技術(shù)的發(fā)展，使得運(yùn)營商的數(shù)據(jù)容量變得更大，數(shù)據(jù)增長速度變得更快，數(shù)據(jù)格式變得更復(fù)雜，大數(shù)據(jù)處理的及時(shí)性變得更為迫切。如何從海量低價(jià)值的數(shù)據(jù)庫中發(fā)現(xiàn)價(jià)值信息，如何在預(yù)期時(shí)間內(nèi)實(shí)現(xiàn)價(jià)值發(fā)現(xiàn)過程，其基礎(chǔ)是要建立穩(wěn)定可靠的企業(yè)級(jí)數(shù)據(jù)倉庫。眾所周知，ETL（extract-transform-load，抽取—轉(zhuǎn)換—加載）是數(shù)據(jù)倉庫實(shí)施過程中非常重要的一個(gè)步驟。國內(nèi)外很多學(xué)者在研究中發(fā)現(xiàn)，ETL的實(shí)施時(shí)間通常要占到數(shù)據(jù)倉庫整個(gè)開發(fā)時(shí)間的60%～80%，是數(shù)據(jù)倉庫開發(fā)過程中最耗費(fèi)時(shí)間的階段。ETL處理效率的高低、轉(zhuǎn)換質(zhì)量的好壞，直接影響著數(shù)據(jù)倉庫的建設(shè)和數(shù)據(jù)挖掘結(jié)果的有效性。設(shè)計(jì)一個(gè)能夠?qū)Υ髷?shù)據(jù)進(jìn)行有效處理的ETL流程，對(duì)提高運(yùn)營平臺(tái)的采集效率具有重要的實(shí)際意義。

圖1 省分大數(shù)據(jù)平臺(tái)主要采集內(nèi)容

2 主要采集內(nèi)容

大數(shù)據(jù)產(chǎn)業(yè)的迅猛發(fā)展，給電信運(yùn)營商開辟新的業(yè)務(wù)增長點(diǎn)，打開了機(jī)遇窗口。電信運(yùn)營商在業(yè)務(wù)運(yùn)營中產(chǎn)生大量用戶信息數(shù)據(jù)和行為數(shù)據(jù)，這些數(shù)據(jù)中包括 BSS（business support system，業(yè)務(wù)支持系統(tǒng)）域業(yè)務(wù)數(shù)據(jù)、OSS（operation support system，運(yùn)營與支撐系統(tǒng)）域過程數(shù)據(jù)以及VAC平臺(tái)互聯(lián)網(wǎng)數(shù)據(jù)等，以700萬活躍用戶為例，每天產(chǎn)生大約16 TB的數(shù)據(jù)。BSS包括客戶關(guān)系管理（customer relationship management，CRM）、計(jì)費(fèi)、賬務(wù)管理、在線計(jì)費(fèi)系統(tǒng) （online charging system，OCS）、客服、cBSS（central business support system，集中業(yè)務(wù)支撐系統(tǒng)）等系統(tǒng)，記錄用戶三戶資料、產(chǎn)品、訂購、合約活動(dòng)等基礎(chǔ)信息，用戶流量、語音、短信等使用詳單信息，應(yīng)收、預(yù)存款、繳費(fèi)、欠費(fèi)、賬戶余額等賬務(wù)數(shù)據(jù)；OSS包括基站、傳輸、固網(wǎng)和核心網(wǎng)等網(wǎng)絡(luò)單元，記錄大量信令類詳單、上網(wǎng)類詳單、MR測(cè)量報(bào)告位置數(shù)據(jù)等。

圖1列出了某省級(jí)運(yùn)營商大數(shù)據(jù)平臺(tái)主要采集內(nèi)容。

在圖1中，左邊和右上側(cè)代表來源于省分BSS、總部cBSS及總部大數(shù)據(jù)平臺(tái)，內(nèi)容是賬單、詳單、用戶資料、產(chǎn)品服務(wù)訂購、業(yè)務(wù)受理記錄等結(jié)構(gòu)化明細(xì)數(shù)據(jù)以及總部下發(fā)的各類明細(xì)及標(biāo)簽數(shù)據(jù)等。這部分?jǐn)?shù)據(jù)量相對(duì)占比較?。s占運(yùn)營商數(shù)據(jù)總量的5%左右）；右側(cè)陰影部分，來源于OSS和VAC平臺(tái)，主要是信令類數(shù)據(jù)、位置數(shù)據(jù)和互聯(lián)網(wǎng)內(nèi)容數(shù)據(jù)，有半結(jié)構(gòu)化、非結(jié)構(gòu)化的數(shù)據(jù)，數(shù)據(jù)量特別龐大（約占運(yùn)營商數(shù)據(jù)總量的95%）。

3 方案設(shè)計(jì)

3.1 問題提出

在長時(shí)間的系統(tǒng)運(yùn)維實(shí)踐中，從“5M1E（人機(jī)料法環(huán)測(cè)）”6個(gè)方面，采用魚骨圖法對(duì)“采集響應(yīng)耗時(shí)長”的原因進(jìn)行歸納總結(jié)，列出了12個(gè)末端原因，如圖2所示。

其中，“海量數(shù)據(jù)采集耗時(shí)長”“流程等待時(shí)間長”兩個(gè)原因，是影響 “采集響應(yīng)及時(shí)率”的關(guān)鍵因素。考慮到Hadoop計(jì)算架構(gòu)具有的高性能集群計(jì)算和存儲(chǔ)能力，且易擴(kuò)展，選擇采用Hadoop與傳統(tǒng)關(guān)系型數(shù)據(jù)庫混搭模式，優(yōu)勢(shì)互補(bǔ)，既可提升數(shù)據(jù)采集時(shí)效性，又可確保核心數(shù)據(jù)服務(wù)能力的穩(wěn)定。

Hadoop由Apache Lucene創(chuàng)始人Cutting D創(chuàng)建，其核心組件是HDFS和MapReduce。Hadoop通過HDFS為用戶提供高容錯(cuò)性和高伸縮性的海量數(shù)據(jù)的分布式存儲(chǔ)，通過MapReduce為用戶提供邏輯簡單、底層透明的并行處理框架。Hadoop底層存儲(chǔ)和并行計(jì)算需要對(duì)用戶進(jìn)行透明化處理，可以按照實(shí)際需要搭建平臺(tái)，易擴(kuò)展，通過增加集群節(jié)點(diǎn)，可以線性地?cái)U(kuò)展計(jì)算能力。Hadoop2.0生態(tài)圈如圖3所示。

HDFS具有高容錯(cuò)性，適合批處理、大數(shù)據(jù)處理，可構(gòu)建在廉價(jià)機(jī)器上等優(yōu)點(diǎn)，缺點(diǎn)是不適宜小文件存取、并發(fā)寫入、文件隨機(jī)修改。MapReduce是一種線性可伸展的編程模型，它建立了清晰的抽象層，采用“分而治之”思想，為用戶提供邏輯簡單、底層透明的并行處理框架。

Hive支持HQL語言 （一種類似傳統(tǒng)SQL的語言），允許用戶運(yùn)行與SQL類似的操作，通過編譯器將SQL腳本轉(zhuǎn)換成對(duì)應(yīng)的MapReduce程序運(yùn)行，讓熟悉SQL編程的人員也能擁抱Hadoop。Hive是一種純邏輯意義上的表，Hive的表格邏輯上通過元數(shù)據(jù)進(jìn)行組織和描述 （表名、表列、分區(qū)及屬性），通過HDFS進(jìn)行數(shù)據(jù)的實(shí)際存儲(chǔ)。簡而言之，Hive是基于Hadoop體系結(jié)構(gòu)進(jìn)行大數(shù)據(jù)存儲(chǔ)及處理的數(shù)據(jù)倉庫工具，它使用HQL作為查詢接口，使用HDFS作為底層存儲(chǔ)，使用MapReduce作為執(zhí)行層，通過把類 SQL腳本編譯解析成 MapReduce程序，簡化MapReduce編程的復(fù)雜度。

3.2 基于Hadoop的采集預(yù)處理架構(gòu)

采用Hadoop、傳統(tǒng)關(guān)系型數(shù)據(jù)庫混搭架構(gòu)，揚(yáng)長避短，對(duì)大數(shù)據(jù)平臺(tái)數(shù)據(jù)進(jìn)行分層管理。利用Hadoop分布式并行計(jì)算框架，對(duì)海量數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)進(jìn)行采集預(yù)處理整合，存儲(chǔ)SRC層、ODS層數(shù)據(jù)以及DWD層加工過度數(shù)據(jù)。將傳統(tǒng)成熟關(guān)系型數(shù)據(jù)庫（Oracle、DB2等）作為主數(shù)據(jù)倉庫，對(duì)DWD層、DWA層、DM層數(shù)據(jù)進(jìn)行存儲(chǔ)管理，存儲(chǔ)用戶標(biāo)簽庫、客戶立體全息視圖、粗粒度匯總數(shù)據(jù)、報(bào)表數(shù)據(jù)、多維數(shù)據(jù)、指標(biāo)庫等結(jié)果數(shù)據(jù)，確保核心數(shù)據(jù)服務(wù)能力的穩(wěn)定。采用混搭架構(gòu)的大數(shù)據(jù)支撐平臺(tái)，其邏輯架構(gòu)如圖4所示。

圖2 采集響應(yīng)影響因素

圖4主要包括4層結(jié)構(gòu)，即數(shù)據(jù)獲取層、數(shù)據(jù)存儲(chǔ)層、數(shù)據(jù)應(yīng)用層和數(shù)據(jù)服務(wù)層。采集的數(shù)據(jù)源涵蓋了電信運(yùn)營商擁有的過程數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)，數(shù)據(jù)資源的真實(shí)性、豐富性、完整性、連續(xù)性，集中體現(xiàn)運(yùn)營商大數(shù)據(jù)優(yōu)勢(shì)。數(shù)據(jù)獲取層通過基于Hadoop的ETL加工過程，包括數(shù)據(jù)校驗(yàn)、數(shù)據(jù)清洗、數(shù)據(jù)關(guān)聯(lián)、數(shù)據(jù)匯總、數(shù)據(jù)聚合等系列加工流程，進(jìn)行深度分析和信息挖掘，在數(shù)據(jù)存儲(chǔ)層形成企業(yè)數(shù)據(jù)倉庫和數(shù)據(jù)集市。數(shù)據(jù)存儲(chǔ)層包括Hadoop管理的SRC/ ODS粒度數(shù)據(jù)以及Oracle管理的DWD/DWA、DM粒度數(shù)據(jù)。數(shù)據(jù)應(yīng)用層表現(xiàn)形式包括：智能網(wǎng)優(yōu)、精準(zhǔn)營銷、征信產(chǎn)品、智慧足跡、用戶標(biāo)簽、用戶維系、OLAP分析、異動(dòng)分析、運(yùn)營監(jiān)控、KPI、電子書、行業(yè)應(yīng)用等生產(chǎn)服務(wù)支撐體系。在數(shù)據(jù)服務(wù)層，可通過個(gè)性化定制、信息推送、用戶搜素、能力開放等方式，實(shí)現(xiàn)對(duì)內(nèi)對(duì)外服務(wù)。在整個(gè)數(shù)據(jù)加工處理、流轉(zhuǎn)服務(wù)過程中，數(shù)據(jù)質(zhì)量、數(shù)據(jù)標(biāo)準(zhǔn)、元數(shù)據(jù)、生命周期等數(shù)據(jù)管理措施貫穿始終；通過安全制度、安全技術(shù)、

圖3 Hadoop2.0生態(tài)圈

圖4 大數(shù)據(jù)平臺(tái)邏輯架構(gòu)

安全運(yùn)營、安全教育等運(yùn)營機(jī)制確保數(shù)據(jù)安全。

采用混搭架構(gòu)的大數(shù)據(jù)支撐平臺(tái)，其網(wǎng)絡(luò)架構(gòu)拓?fù)淙鐖D5所示。

圖5 大數(shù)據(jù)平臺(tái)網(wǎng)絡(luò)架構(gòu)拓?fù)?/p>

圖5的上半部分，是基于IOE的Oracle數(shù)據(jù)庫以及基于x86的Hadoop集群，組成了混搭架構(gòu)的大數(shù)據(jù)平臺(tái)的硬件與系統(tǒng)軟件環(huán)境；圖5的下半部分，是采集數(shù)據(jù)源的拓?fù)洌∣SS域系統(tǒng)、BSS域系統(tǒng)、VAC平臺(tái)的各業(yè)務(wù)平臺(tái)和總部集中系統(tǒng)等。兩者之間通過查詢服務(wù)器、接口服務(wù)器、DCN、IP承載網(wǎng)等實(shí)現(xiàn)數(shù)據(jù)傳輸交互。

3.3 動(dòng)態(tài)觸發(fā)式ETL調(diào)度流程

數(shù)據(jù)采集應(yīng)用軟件部署在Hadoop集群接口機(jī)上，程序腳本規(guī)范為兩種類型，分別是：基礎(chǔ)邏輯腳本和業(yè)務(wù)邏輯腳本。其中，基礎(chǔ)邏輯腳本包含了日志記錄、注釋、配置文件讀取等工作，并調(diào)用業(yè)務(wù)邏輯腳本。業(yè)務(wù)邏輯腳本使用HQL語言編寫HQL語句，類同于SQL。

ETL流程調(diào)度方式一般有兩種方式：定時(shí)啟動(dòng)式、事件觸發(fā)式。為方便采集流程調(diào)度與監(jiān)控，在Oracle數(shù)據(jù)庫上部署了幾張實(shí)體表，包括：業(yè)務(wù)邏輯前置條件配置表、應(yīng)采集接口配置表、FTP文件檢查日志、接口文件稽核日志、接口文件采集日志、SRC層已裝載觸發(fā)ODS流程日志表、ETL執(zhí)行日志表等。提出一種動(dòng)態(tài)觸發(fā)式ETL調(diào)度流程與算法，改變了以往定時(shí)啟動(dòng)的ETL流程調(diào)度方式，可有效縮短部分流程的超長等待時(shí)間；同時(shí)通過并發(fā)量的監(jiān)測(cè)和控制，可有效避免資源搶占擁堵現(xiàn)象，從而更有效地提升所有采集流程的整體完成時(shí)間。這種事件觸發(fā)式調(diào)度，每個(gè)ETL流程都預(yù)先配置了自動(dòng)觸發(fā)的條件，可能包括n個(gè)接口文件、m個(gè)依賴流程；如果n個(gè)接口采集和m個(gè)依賴流程處理完成，則觸發(fā)該流程。所有流程通過任務(wù)集中調(diào)度，在適當(dāng)?shù)臅r(shí)間自動(dòng)觸發(fā)運(yùn)行，經(jīng)過 ETL加工過程以及數(shù)據(jù)質(zhì)量稽核，實(shí)現(xiàn)數(shù)據(jù)自動(dòng)流動(dòng)，直至完成全部流程。

動(dòng)態(tài)觸發(fā)式ETL調(diào)度流程如圖6所示。

4 雙平臺(tái)效率比較

Hadoop與Oracle優(yōu)勢(shì)有互補(bǔ)性，在工程實(shí)施過程中，把原先Oracle平臺(tái)的數(shù)據(jù)采集存儲(chǔ)過程腳本，平行遷移為Hadoop平臺(tái)的業(yè)務(wù)邏輯腳本，同時(shí)保持雙平臺(tái)并行運(yùn)行一段時(shí)間，采集的數(shù)據(jù)源完全一樣，這為比較兩個(gè)平臺(tái)的優(yōu)勢(shì)和效率提供了一樣的基準(zhǔn)。通過對(duì)幾十萬條的運(yùn)行日志圖形化分析，總的來說，Hadoop在大數(shù)據(jù)量時(shí)執(zhí)行效率要好于Oracle。但在數(shù)據(jù)量小時(shí)，Oracle要好于Hadoop。為了避免超大數(shù)對(duì)微小數(shù)的淹沒，采用分段展現(xiàn)方式。

圖7是根據(jù)兩個(gè)平臺(tái)的實(shí)際運(yùn)行日志結(jié)果，分段列出了Hadoop平臺(tái)與Oracle平臺(tái)的采集效率比較。

圖6 動(dòng)態(tài)觸發(fā)式ETL調(diào)度流程

圖7 雙平臺(tái)日數(shù)據(jù)采集（時(shí)長）與記錄數(shù)量關(guān)系比較

記錄條數(shù)小于10萬條時(shí)，Oracle耗時(shí)很短，Oracle效率明顯好于Hive。記錄條數(shù)為10萬～100萬條時(shí)，Oracle效率好于Hive，隨記錄條數(shù)增大，耗時(shí)在增大，但Hive的耗時(shí)變化不明顯。在100萬條附近，Oracle與Hive的效率基本持平。記錄條數(shù)為100萬～500萬條時(shí)，Oracle耗時(shí)逐漸超過Hive；Hive的效率開始體現(xiàn)。記錄條數(shù)為500萬～3 500萬條時(shí)，Hive效率好于Oracle。隨記錄數(shù)增大，Oracle耗時(shí)增長快，與Hive效率差距增大。記錄條數(shù)在3 500萬條以上時(shí)，Oracle耗時(shí)長，Hive效率明顯好于Oracle。分析發(fā)現(xiàn)，Hadoop平臺(tái)對(duì)海量數(shù)據(jù)接口的采集效率優(yōu)化效果明顯，對(duì)千萬條記錄以上的日接口大表，Hadoop平臺(tái)的采集時(shí)長相比Oracle平臺(tái)縮短50%～80%。圖8列出雙平臺(tái)對(duì)海量數(shù)據(jù)（千萬條以上）采集效率氣泡圖。

圖8 雙平臺(tái)對(duì)海量數(shù)據(jù)(千萬條以上)采集效率氣泡圖

其中“賬單流水表”接口（全量記錄條數(shù)平均72 000萬條），采集耗時(shí)最長；“流量詳單表”數(shù)據(jù)增幅很大（日增量記錄條數(shù)平均3 500萬條）；是原先Oracle平臺(tái)采集效率的瓶頸。圖9是這兩個(gè)接口的雙平臺(tái)采集效率對(duì)比。

其中，賬單流水接口，Oracle采集時(shí)長平均在110 min，Hadoop采集時(shí)長為53 min，效率提升52%；流量詳單日采集接口，Oracle采集時(shí)長平均在26 min，Hadoop采集時(shí)長為9 min，效率提升67%。

但從圖9也可看出，對(duì)數(shù)據(jù)量較小的表（尤其是一些代碼表）、需要頻繁增刪改的表、需要多表復(fù)雜關(guān)聯(lián)分析等，這些場景不適宜于在Hadoop上管理；相反，這些場景，Oracle可以實(shí)現(xiàn)很好的管理。同樣Hadoop對(duì)海量數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)的處理效率，明顯好于Oracle等傳統(tǒng)關(guān)系型數(shù)據(jù)庫。從成本上考慮，Hadoop比Oracle的優(yōu)勢(shì)明顯；從易于維護(hù)上考慮，Oracle反過來比Hadoop優(yōu)勢(shì)明顯；同時(shí)Oracle的可靠性比Hadoop高。

圖9 兩個(gè)接口的雙平臺(tái)采集效率對(duì)比

總的來說，通過Hadoop與Oracle混搭架構(gòu)以及動(dòng)態(tài)觸發(fā)式ETL調(diào)度流程兩大舉措，可有效提升數(shù)據(jù)采集時(shí)效性，在實(shí)踐中取得了比較好的應(yīng)用效果。

5 結(jié)束語

ETL是數(shù)據(jù)倉庫建設(shè)中非常重要的環(huán)節(jié)，本文提出Hadoop與 Oracle混搭解決方案，對(duì)電信大數(shù)據(jù)分層管理，利用Hadoop的并行計(jì)算和存儲(chǔ)優(yōu)勢(shì)，對(duì)海量數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)進(jìn)行采集預(yù)處理整合，可有效提升海量數(shù)據(jù)采集效率。同時(shí)提出一種動(dòng)態(tài)觸發(fā)式ETL調(diào)度流程與算法，與定時(shí)啟動(dòng)的ETL流程調(diào)度方式相比，可有效縮短部分流程的超長等待時(shí)間，有效避免資源搶占擁堵現(xiàn)象。在某運(yùn)營商大數(shù)據(jù)平臺(tái)建設(shè)的實(shí)踐過程中，取得了比較好的應(yīng)用效果，有效確保了公司每天經(jīng)營分析數(shù)據(jù)的及時(shí)展現(xiàn)，提升了數(shù)據(jù)服務(wù)支撐的時(shí)間窗口，提升了公司內(nèi)外部客戶的滿意度，對(duì)業(yè)界也有一定借鑒作用。

[1]許佳捷,鄭凱,池明旻,等．軌跡大數(shù)據(jù):數(shù)據(jù)、應(yīng)用與技術(shù)現(xiàn)狀[J]．通信學(xué)報(bào),2015,36(12):97-105．XU J J,ZHENG K,CHI M M,et al．Trajectory big data:data, applications and techniques[J]．Journal on Communications, 2015,36(12):97-105．

[2]劉南海,雷蕾,王睿．大數(shù)據(jù)時(shí)代運(yùn)營商分析支撐域轉(zhuǎn)型的實(shí)踐與思考[J]．電信科學(xué),2016,32(8):146-158．LIU N H,LEI L,WANG R.Practice and thinking on the transition of telecom operator analysis support system in big data era [J].Telecommunications Science,2016,32(8): 146-158.

[3]金澈清,錢衛(wèi)寧,周敏奇,等.數(shù)據(jù)管理系統(tǒng)評(píng)測(cè)基準(zhǔn):從傳統(tǒng)數(shù)據(jù)庫到新興大數(shù)據(jù) [J].計(jì)算機(jī)學(xué)報(bào),2015,38(1): 18-34. JIN C Q,QIAN W N,ZHOU M Q,et al.Benchmarking data management systems:from traditional database to emergent big data[J].Chinese Journal of Computers,2015,38(1):18-34.

[4]曾嘉,劉詩凱,袁明軒.電信大數(shù)據(jù)關(guān)鍵技術(shù)挑戰(zhàn)[J].大數(shù)據(jù), 2016,2(3):96-105. ZENG J,LIU S K,YUAN M X.Key technical challenges in telecom big data[J].Big Data Research,2016,2(3):96-105.

[5]詹義,方媛.基于Spark技術(shù)的網(wǎng)絡(luò)大數(shù)據(jù)分析平臺(tái)搭建與應(yīng)用[J].互聯(lián)網(wǎng)天地,2016(2):75-78. ZHAN Y,FANG Y.Building and application of network big data analysis platform based on Spark technology[J].China Internet,2016(2):75-78.

[6]劉珂.基于Hadoop平臺(tái)的大數(shù)據(jù)遷移與查詢方法研究及應(yīng)用[D].武漢:武漢理工大學(xué),2014. LIU K.Research and application of big data migration and query based on Hadoop platform[D].Wuhan:Wuhan University of Technology,2014.

Research and implementation on acquisition scheme of telecom big data based on Hadoop

WANG Baoyou1,QIAN Jing1,YUAN Shijin2
1.Shanghai Branch of China United Network Communication Co.,Ltd.,Shanghai 200050,China 2.School of Software Engineering,Tongji University,Shanghai 201804,China

ETL is a very important step in the implementation process of data warehouse.A good ETL flow is important,which can effectively process the telecom big data and improve the acquisition efficiency of the operation platform.Firstly,the main data content of the big data platform was expounded.Secondly,in order to improve the efficiency of massive data collection,Hadoop and Oracle mashup solution was suggested.Subsequently,a dynamic triggered ETL scheduling flow and algorithm was proposed.Compared with timer start ETL scheduling method,it could effectively shorten waiting time and avoid the phenomenon of resources to seize and congestion.Finally, according to the running log of Hadoop platform and Oracle database,the relationship between acquisition efficiency and data quantity was analyzed comparatively.Furthermore,practice result shows that the hybrid data structure of the big data platform complement each other and can effectively enhance the timeliness of data collection and access better application effect.

big data,ETL,Hadoop,scheduling process,mashup architecture

TP311

A

10.11959/j.issn.1000-0801.2017010

汪保友（1968-），男，博士，中國聯(lián)合網(wǎng)絡(luò)通信有限公司上海市分公司高級(jí)工程師，主要研究方向?yàn)閿?shù)據(jù)科學(xué)、數(shù)據(jù)挖掘、數(shù)據(jù)簽名。

錢晶（1970-），女，中國聯(lián)合網(wǎng)絡(luò)通信有限公司上海市分公司工程師，主要研究方向?yàn)閿?shù)據(jù)科學(xué)、移動(dòng)互聯(lián)網(wǎng)、通信網(wǎng)絡(luò)規(guī)劃。

袁時(shí)金（1975-），女，博士，同濟(jì)大學(xué)軟件學(xué)院副教授，主要研究方向?yàn)榇髷?shù)據(jù)與高性能計(jì)算。

2016-12-11；

2017-01-03