汪保友，錢晶，袁時金

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

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

汪保友1，錢晶1，袁時金2

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

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

1 引言

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

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

2 主要采集內容

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

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

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

3 方案設計

3.1 問題提出

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

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

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

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

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

3.2 基于Hadoop的采集預處理架構

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

圖2 采集響應影響因素

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

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

圖4 大數(shù)據(jù)平臺邏輯架構

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

采用混搭架構的大數(shù)據(jù)支撐平臺，其網(wǎng)絡架構拓撲如圖5所示。

圖5 大數(shù)據(jù)平臺網(wǎng)絡架構拓撲

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

3.3 動態(tài)觸發(fā)式ETL調度流程

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

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

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

4 雙平臺效率比較

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

圖7是根據(jù)兩個平臺的實際運行日志結果，分段列出了Hadoop平臺與Oracle平臺的采集效率比較。

圖6 動態(tài)觸發(fā)式ETL調度流程

圖7 雙平臺日數(shù)據(jù)采集（時長）與記錄數(shù)量關系比較

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

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

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

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

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

圖9 兩個接口的雙平臺采集效率對比

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

5 結束語

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

[1]許佳捷,鄭凱,池明旻,等．軌跡大數(shù)據(jù):數(shù)據(jù)、應用與技術現(xiàn)狀[J]．通信學報,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ù)時代運營商分析支撐域轉型的實踐與思考[J]．電信科學,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)評測基準:從傳統(tǒng)數(shù)據(jù)庫到新興大數(shù)據(jù) [J].計算機學報,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ù)關鍵技術挑戰(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技術的網(wǎng)絡大數(shù)據(jù)分析平臺搭建與應用[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平臺的大數(shù)據(jù)遷移與查詢方法研究及應用[D].武漢:武漢理工大學,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)絡通信有限公司上海市分公司高級工程師，主要研究方向為數(shù)據(jù)科學、數(shù)據(jù)挖掘、數(shù)據(jù)簽名。

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

袁時金（1975-），女，博士，同濟大學軟件學院副教授，主要研究方向為大數(shù)據(jù)與高性能計算。

2016-12-11；

2017-01-03