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

汪保友，錢晶，袁時金

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

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

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

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

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

1 引言

移動互聯(lián)網(wǎng)時代，數(shù)據(jù)資源無疑是重要的戰(zhàn)略資源。電信運(yùn)營商擁有龐大的活躍用戶群體，處在大數(shù)據(jù)產(chǎn)業(yè)鏈的傳輸與交換中心地位，具有豐富的高價值數(shù)據(jù)資源。除了用戶辦理業(yè)務(wù)時產(chǎn)生的用戶實名制基礎(chǔ)信息外，每天還會持續(xù)產(chǎn)生大量的用戶消費數(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ù)據(jù)庫中發(fā)現(xiàn)價值信息，如何在預(yù)期時間內(nèi)實現(xiàn)價值發(fā)現(xiàn)過程，其基礎(chǔ)是要建立穩(wěn)定可靠的企業(yè)級數(shù)據(jù)倉庫。眾所周知，ETL（extract-transform-load，抽取—轉(zhuǎn)換—加載）是數(shù)據(jù)倉庫實施過程中非常重要的一個步驟。國內(nèi)外很多學(xué)者在研究中發(fā)現(xiàn)，ETL的實施時間通常要占到數(shù)據(jù)倉庫整個開發(fā)時間的60%～80%，是數(shù)據(jù)倉庫開發(fā)過程中最耗費時間的階段。ETL處理效率的高低、轉(zhuǎn)換質(zhì)量的好壞，直接影響著數(shù)據(jù)倉庫的建設(shè)和數(shù)據(jù)挖掘結(jié)果的有效性。設(shè)計一個能夠?qū)Υ髷?shù)據(jù)進(jìn)行有效處理的ETL流程，對提高運(yùn)營平臺的采集效率具有重要的實際意義。

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

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

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

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

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

3.1 問題提出

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

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

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

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

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

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

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

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

圖4主要包括4層結(jié)構(gòu)，即數(shù)據(jù)獲取層、數(shù)據(jù)存儲層、數(shù)據(jù)應(yīng)用層和數(shù)據(jù)服務(wù)層。采集的數(shù)據(jù)源涵蓋了電信運(yùn)營商擁有的過程數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)，數(shù)據(jù)資源的真實性、豐富性、完整性、連續(xù)性，集中體現(xiàn)運(yùn)營商大數(shù)據(jù)優(yōu)勢。數(shù)據(jù)獲取層通過基于Hadoop的ETL加工過程，包括數(shù)據(jù)校驗、數(shù)據(jù)清洗、數(shù)據(jù)關(guān)聯(lián)、數(shù)據(jù)匯總、數(shù)據(jù)聚合等系列加工流程，進(jìn)行深度分析和信息挖掘，在數(shù)據(jù)存儲層形成企業(yè)數(shù)據(jù)倉庫和數(shù)據(jù)集市。數(shù)據(jù)存儲層包括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分析、異動分析、運(yùn)營監(jiān)控、KPI、電子書、行業(yè)應(yīng)用等生產(chǎn)服務(wù)支撐體系。在數(shù)據(jù)服務(wù)層，可通過個性化定制、信息推送、用戶搜素、能力開放等方式，實現(xiàn)對內(nèi)對外服務(wù)。在整個數(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ù)平臺邏輯架構(gòu)

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

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

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

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

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

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

4 雙平臺效率比較

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

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

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

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

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

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

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

5 結(jié)束語

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

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

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

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

2016-12-11；

2017-01-03