堯 煒（中訊郵電咨詢?cè)O(shè)計(jì)院有限公司，北京100048）

0 前言

隨著大數(shù)據(jù)時(shí)代的來臨，企業(yè)數(shù)據(jù)所蘊(yùn)藏的潛在價(jià)值越來越被重視。對(duì)電信運(yùn)營(yíng)商來說，海量的網(wǎng)絡(luò)數(shù)據(jù)有著廣泛的應(yīng)用場(chǎng)景。針對(duì)用戶，可用于用戶體驗(yàn)分析、用戶行為分析、精細(xì)化營(yíng)銷、輔助處理客戶投訴等；針對(duì)網(wǎng)絡(luò)，可精準(zhǔn)地指導(dǎo)網(wǎng)絡(luò)規(guī)劃、網(wǎng)絡(luò)建設(shè)及網(wǎng)絡(luò)優(yōu)化。要挖掘網(wǎng)絡(luò)數(shù)據(jù)的價(jià)值，必須采集分布在各個(gè)設(shè)備上的數(shù)據(jù)并進(jìn)行匯集，因此各大運(yùn)營(yíng)商均在著手建設(shè)集中的網(wǎng)絡(luò)數(shù)據(jù)采集系統(tǒng)。

電信運(yùn)營(yíng)商內(nèi)部IT 系統(tǒng)對(duì)于技術(shù)穩(wěn)定性要求非常高，往往會(huì)優(yōu)先考慮使用成熟的商業(yè)軟件外加二次開發(fā)，并且由于建設(shè)起步較早，經(jīng)過多年的發(fā)展各個(gè)系統(tǒng)已經(jīng)比較成熟和穩(wěn)定。因此，電信運(yùn)營(yíng)商對(duì)于全部采用開源技術(shù)的態(tài)度比較保守。

然而以Hadoop、Spark 為核心已經(jīng)形成了廣泛的開源技術(shù)生態(tài)圈，覆蓋了數(shù)據(jù)采集、數(shù)據(jù)處理、數(shù)據(jù)挖掘、數(shù)據(jù)共享等各個(gè)環(huán)節(jié)。Hadoop、Spark 技術(shù)已成為大數(shù)據(jù)領(lǐng)域的標(biāo)配。

鑒于開源技術(shù)在大數(shù)據(jù)技術(shù)領(lǐng)域已經(jīng)占據(jù)了主導(dǎo)地位，同時(shí)使用開源技術(shù)也是去IOE的必然要求，本文將分析電信運(yùn)營(yíng)商網(wǎng)絡(luò)數(shù)據(jù)采集的特點(diǎn)，并以積極擁抱開源技術(shù)的態(tài)度，借鑒互聯(lián)網(wǎng)行業(yè)類似系統(tǒng)的設(shè)計(jì)經(jīng)驗(yàn)，探討網(wǎng)絡(luò)數(shù)據(jù)采集系統(tǒng)的架構(gòu)設(shè)計(jì)。

1 系統(tǒng)架構(gòu)設(shè)計(jì)

1.1 網(wǎng)絡(luò)數(shù)據(jù)采集特點(diǎn)分析

網(wǎng)絡(luò)數(shù)據(jù)采集具有以下4個(gè)特點(diǎn)。

第一個(gè)特點(diǎn)是數(shù)據(jù)源種類多。從數(shù)據(jù)來源看，可分為網(wǎng)元、網(wǎng)管、OMC、網(wǎng)優(yōu)以及分光后DPI解析等；從專業(yè)看，可分為移動(dòng)網(wǎng)、固網(wǎng)交換、傳輸網(wǎng)、互聯(lián)網(wǎng)、IP承載網(wǎng)、寬帶接入、業(yè)務(wù)平臺(tái)、動(dòng)力環(huán)境等；從數(shù)據(jù)用途看，可分為性能數(shù)據(jù)、配置數(shù)據(jù)、告警數(shù)據(jù)、信令數(shù)據(jù)、用戶面數(shù)據(jù)、投訴數(shù)據(jù)等。

第二個(gè)特點(diǎn)是數(shù)據(jù)消費(fèi)者多。電信運(yùn)營(yíng)商內(nèi)部的IT 系統(tǒng)經(jīng)過多年的發(fā)展，形成了相對(duì)穩(wěn)定的應(yīng)用架構(gòu)，各個(gè)系統(tǒng)之間分工比較明確，各個(gè)系統(tǒng)都有可能是網(wǎng)絡(luò)數(shù)據(jù)的消費(fèi)者，例如網(wǎng)管/監(jiān)控類應(yīng)用、運(yùn)維工單類應(yīng)用、資源管理類應(yīng)用、客戶支撐類應(yīng)用、網(wǎng)絡(luò)規(guī)劃類應(yīng)用、網(wǎng)絡(luò)建設(shè)類應(yīng)用、網(wǎng)絡(luò)優(yōu)化類應(yīng)用，用戶行為分析類應(yīng)用。此外，由于運(yùn)營(yíng)商目前普遍沒有完全實(shí)現(xiàn)IT系統(tǒng)的集中化，在IT系統(tǒng)由二級(jí)架構(gòu)向一級(jí)架構(gòu)轉(zhuǎn)變的過程中，網(wǎng)絡(luò)數(shù)據(jù)消費(fèi)者既包括總部系統(tǒng)，也包括省分系統(tǒng)。

第三個(gè)特點(diǎn)是數(shù)據(jù)總量大。通常每天采集的網(wǎng)絡(luò)數(shù)據(jù)總量將達(dá)到幾百TB，隨著4G終端的普及、用戶流量使用習(xí)慣的改變，未來數(shù)據(jù)量仍將持續(xù)高速增長(zhǎng)。

第四個(gè)特點(diǎn)是既有實(shí)時(shí)數(shù)據(jù)又有批量數(shù)據(jù)。嚴(yán)格來說，網(wǎng)絡(luò)數(shù)據(jù)都是實(shí)時(shí)產(chǎn)生的，但是由于網(wǎng)絡(luò)設(shè)備不同于IT系統(tǒng)，有很大一部分網(wǎng)絡(luò)設(shè)備產(chǎn)生數(shù)據(jù)的方式是周期性地生成數(shù)據(jù)文件，因此只能通過批量發(fā)送文件的方式采集數(shù)據(jù)。典型的實(shí)時(shí)數(shù)據(jù)是告警類數(shù)據(jù)，典型的批量數(shù)據(jù)是經(jīng)DPI解析后的信令數(shù)據(jù)。

1.2 設(shè)計(jì)目標(biāo)

根據(jù)對(duì)網(wǎng)絡(luò)數(shù)據(jù)采集特點(diǎn)的分析，結(jié)合應(yīng)用系統(tǒng)對(duì)網(wǎng)絡(luò)數(shù)據(jù)采集系統(tǒng)能力要求的預(yù)期，針對(duì)網(wǎng)絡(luò)數(shù)據(jù)采集系統(tǒng)提出了以下設(shè)計(jì)目標(biāo)。

a）支持關(guān)鍵網(wǎng)絡(luò)指標(biāo)實(shí)時(shí)計(jì)算、查詢。

b）支持在一套框架下適配多種數(shù)據(jù)源。

c）支持多個(gè)數(shù)據(jù)消費(fèi)者，且同時(shí)支持在線和離線處理。

d）支持實(shí)時(shí)采集和批量采集數(shù)據(jù)。

e）系統(tǒng)具備線性擴(kuò)展能力。

1.3 系統(tǒng)架構(gòu)

根據(jù)上述設(shè)計(jì)目標(biāo)，本文提出的網(wǎng)絡(luò)數(shù)據(jù)采集系統(tǒng)架構(gòu)如圖1所示，架構(gòu)中采用了Flume、Kafka、Storm、Hadoop、Hive/Impala、Spark、MySQL 等一系列開源技術(shù)，架構(gòu)說明如下。

a）Flume Agent運(yùn)行在產(chǎn)生數(shù)據(jù)的服務(wù)器（即數(shù)據(jù)源）上，負(fù)責(zé)實(shí)時(shí)采集數(shù)據(jù)并發(fā)送給Kafka集群。通過配置不同的source，可以靈活地適配多種數(shù)據(jù)源采集數(shù)據(jù)，經(jīng)過Channel 輸出至sink，如果sink 配置為kafka則該sink 就是Kafka 中的Producer。如果本省系統(tǒng)有同樣的數(shù)據(jù)需求，可通過設(shè)置多個(gè)sink來實(shí)現(xiàn)。

b）Kafka 集群是整個(gè)采集系統(tǒng)的中心，可以對(duì)采集到的數(shù)據(jù)進(jìn)行緩沖，供多個(gè)Consumer消費(fèi)。不同的Consumer 可以消費(fèi)相同的數(shù)據(jù)（通過設(shè)置相同的Top?ic，不同的Consumer Group 實(shí)現(xiàn)），也可以消費(fèi)不同的數(shù)據(jù)（通過設(shè)置不同的Topic 實(shí)現(xiàn)）。Consumer 可以在線處理，也可以離線處理。

圖1 網(wǎng)絡(luò)數(shù)據(jù)采集系統(tǒng)架構(gòu)

c）省分系統(tǒng)需要同時(shí)在線和離線處理網(wǎng)絡(luò)數(shù)據(jù)，或者考慮到數(shù)據(jù)源不宜接入總部網(wǎng)絡(luò)，可以考慮在省分搭建一個(gè)前置的Kafka集群，將總部Kafka集群和省分系統(tǒng)分別設(shè)置為前置Kafka 集群的消費(fèi)者，并且分屬不同的Consumer Group。

d）Storm 集群為Kafka 的Consumer，負(fù)責(zé)實(shí)時(shí)計(jì)算，例如計(jì)算關(guān)鍵網(wǎng)絡(luò)指標(biāo)，處理告警等。Storm 集群在實(shí)時(shí)處理數(shù)據(jù)時(shí)，還可以有其他的數(shù)據(jù)輸入，例如接收外部事件、查詢歷史數(shù)據(jù)等，數(shù)據(jù)處理的結(jié)果寫入關(guān)系型數(shù)據(jù)庫(kù)，供應(yīng)用查詢。

e）Hadoop/Spark 集群同樣是Kafka 的Consumer，負(fù)責(zé)批量數(shù)據(jù)處理，例如解碼合成、格式轉(zhuǎn)換，處理結(jié)果可以保存成Parquet格式，供數(shù)據(jù)分析使用。

f）Hive/Impala 面向分析人員提供ad-hoc 查詢能力。

g）FTP 傳輸通道適用于無法實(shí)時(shí)產(chǎn)生數(shù)據(jù)，只能周期性地生成數(shù)據(jù)文件并且文件較大（即對(duì)吞吐量要求高）的數(shù)據(jù)源。如果存在數(shù)據(jù)源是關(guān)系型數(shù)據(jù)庫(kù)的情況，也可以使用Sqoop 批量采集數(shù)據(jù)至HDFS。FTP傳輸通道帶來的劣勢(shì)是從數(shù)據(jù)產(chǎn)生到分析人員得出分析結(jié)果，通常需要花費(fèi)幾個(gè)小時(shí)或幾天時(shí)間。

h）其他系統(tǒng)可以通過訂閱Kafka 的Topic、從FTP下載或從HDFS讀取等多種方式獲得所需數(shù)據(jù)。

i）關(guān)于擴(kuò)展性，Kafka 集群、Storm 集群、Hadoop 集群均具備線性擴(kuò)展能力，F(xiàn)TP僅作為文件傳輸通道，通過為不同地域、不同數(shù)據(jù)合理分配FTP 服務(wù)器即可擴(kuò)展。

1.4 技術(shù)成熟度

架構(gòu)中所使用的均是目前開源社區(qū)中炙手可熱的技術(shù)，其中MySQL、Hadoop、Hive、Impala等已被大家熟知，而Flume、Kafka、Storm 均是Apache 的頂級(jí)開源項(xiàng)目，被全世界范圍內(nèi)許多知名公司所采用。Kafka已被Linkedin、Yahoo、Twitter、Netflix、Uber、PayPal 等多家公司使用，在Apache Kafka 官方wiki上登記使用了Kafka的公司超過70 家。根據(jù)最新披露的數(shù)據(jù)，在Linkedin每天利用Kafka處理的消息超過1萬億條，在峰值時(shí)每秒鐘會(huì)發(fā)布超過450 萬條消息，每周處理的信息是1.34 PB，每條消息平均會(huì)被4個(gè)應(yīng)用處理。Storm已被Yahoo、阿里巴巴、淘寶、支付寶、百度、愛奇藝等多家公司使用，在Apache Storm 官方網(wǎng)站上登記使用的公司超過80 家。Flume 最早由Cloudera 開源，目前已經(jīng)更新至1.6.0版，廣泛用于日志采集的場(chǎng)景。

這些開源技術(shù)發(fā)展已相對(duì)成熟，案例豐富、社區(qū)活躍、文檔完備，電信運(yùn)營(yíng)商使用起來風(fēng)險(xiǎn)較小。

2 架構(gòu)實(shí)施面臨的挑戰(zhàn)及應(yīng)對(duì)策略

2.1 應(yīng)對(duì)不熟悉開源技術(shù)的挑戰(zhàn)

目前，電信運(yùn)營(yíng)商IT系統(tǒng)的建設(shè)從完全外包逐步轉(zhuǎn)向自主研發(fā)，自有開發(fā)人員規(guī)模普遍較小，對(duì)開源技術(shù)不熟悉。為了跟上技術(shù)發(fā)展的潮流，需加快自主研發(fā)隊(duì)伍的建設(shè)，通過引入對(duì)相關(guān)技術(shù)有豐富使用經(jīng)驗(yàn)的人員來彌補(bǔ)不足。在項(xiàng)目實(shí)施過程中應(yīng)堅(jiān)持先小范圍使用驗(yàn)證，再逐步推廣的原則以降低風(fēng)險(xiǎn)。

2.2 應(yīng)對(duì)數(shù)據(jù)源適配的挑戰(zhàn)

從技術(shù)上看，F(xiàn)lume 支持的source 類型非常豐富，如Avro、Thrift、Exec、JMS、Syslog 等，如果默認(rèn)不支持（例如Corba），可通過開發(fā)自定義的source來解決。對(duì)于一些不同于IT 系統(tǒng)的專業(yè)設(shè)備，無法直接運(yùn)行Flume Agent，短期的解決辦法是利用批量采集通道采集數(shù)據(jù)；長(zhǎng)遠(yuǎn)來看提高專業(yè)設(shè)備的IT化程度才是徹底的解決辦法。

2.3 應(yīng)對(duì)海量網(wǎng)絡(luò)數(shù)據(jù)對(duì)性能要求高的挑戰(zhàn)

電信運(yùn)營(yíng)商每天采集的網(wǎng)絡(luò)數(shù)據(jù)可能是幾百TB，對(duì)于采集系統(tǒng)的性能是極大的挑戰(zhàn)。上述架構(gòu)中各個(gè)集群在一定規(guī)模內(nèi)都具備線性擴(kuò)展能力（集群規(guī)模上限需要實(shí)際使用中逐步驗(yàn)證），如果單集群無法達(dá)到性能要求，可以根據(jù)采集系統(tǒng)上承載的業(yè)務(wù)量、集群處理能力以及處理能力隨集群大小變化曲線，合理地規(guī)劃1 個(gè)或多個(gè)集群，集群劃分的依據(jù)可以是地域、設(shè)備商、設(shè)備類型等。

2.4 應(yīng)對(duì)開源軟件安全功能支持不足的挑戰(zhàn)

開源軟件對(duì)于企業(yè)級(jí)安全功能的支持通常比較弱，比如Kafka 最新版本0.8.2.2 還沒有任何安全功能（預(yù)計(jì)下個(gè)版本將會(huì)支持Kerberos 認(rèn)證、ACL 鑒權(quán)、加密通信等），對(duì)此需做好以下幾點(diǎn)。

a）由于采集系統(tǒng)及相關(guān)外圍設(shè)備、系統(tǒng)均屬于企業(yè)內(nèi)部，通過管理手段增強(qiáng)安全性相對(duì)容易。

b）利用企業(yè)內(nèi)已有的安全機(jī)制，包括網(wǎng)絡(luò)、訪問控制、審計(jì)等。

c）對(duì)于不允許直接訪問的情形，可以通過代理提供REST API的方式來實(shí)現(xiàn)。

d）如果具備足夠的研發(fā)能力，可以對(duì)開源軟件的安全功能進(jìn)行增強(qiáng)。

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

本文針對(duì)網(wǎng)絡(luò)數(shù)據(jù)源種類多、數(shù)據(jù)消費(fèi)者多、數(shù)據(jù)量大、實(shí)時(shí)與批量數(shù)據(jù)并存的特點(diǎn)，明確了網(wǎng)絡(luò)數(shù)據(jù)采集系統(tǒng)的設(shè)計(jì)目標(biāo)，據(jù)此采用Flume、Kafka、Storm、Ha?doop、Spark、MySQL 等一系列開源技術(shù)設(shè)計(jì)了系統(tǒng)架構(gòu)，并針對(duì)架構(gòu)實(shí)施可能面臨的一些挑戰(zhàn)提出了應(yīng)對(duì)策略。

大數(shù)據(jù)推動(dòng)了跨行業(yè)的業(yè)務(wù)競(jìng)爭(zhēng)與合作，同樣也推動(dòng)了開源技術(shù)的發(fā)展。電信運(yùn)營(yíng)商在設(shè)計(jì)大數(shù)據(jù)系統(tǒng)架構(gòu)時(shí)，應(yīng)該以開放包容的心態(tài)勇敢地采用開源技術(shù)，多參與開源社區(qū)交流，借鑒全世界優(yōu)秀公司的先進(jìn)經(jīng)驗(yàn)，充分利用自身豐富的數(shù)據(jù)資源創(chuàng)造更多價(jià)值。

［1］ 施巍巍.電信運(yùn)營(yíng)商對(duì)大數(shù)據(jù)的應(yīng)用［J］.中國(guó)新通信，2015（3）：27-28.

［2］ 周龍，陳喜珠，彭江強(qiáng).運(yùn)營(yíng)商IT支撐系統(tǒng)“去IOE”思路探討［J］.電信工程技術(shù)與標(biāo)準(zhǔn)化，2015（6）：55-60.

［3］ 雷蕾，李景文，宮大鵬，等.基于Hadoop的OSS域數(shù)據(jù)建模與采集方法研究［J］.電信科學(xué)，2015，31（1）：128-138.

［4］ 人工智能.電信行業(yè)大數(shù)據(jù)應(yīng)用實(shí)踐和思考［EB/OL］.［2015-09-28］.http://labs.chinamobile.com.

［5］ 王長(zhǎng)武.移動(dòng)互聯(lián)網(wǎng)下的運(yùn)營(yíng)商大數(shù)據(jù)應(yīng)用淺析［J］.電子技術(shù)與軟件工程，2014（13）：45-45.

［6］ 郭俊.Kafka背景及架構(gòu)介紹［EB/OL］.［2015-09-28］.http://www.infoq.com/cn.

［7］ 美團(tuán).基于Flume 的美團(tuán)日志收集系統(tǒng)［EB/OL］.［2015-09-28］.http://tech.meituan.com.

［8］ yanbohappy. Impala/Hive 現(xiàn)狀分析與前景展望［EB/OL］.［2015-09-28］.http://yanbohappy.sinaapp.com.

［9］ Apache Software Foundation. Sqoop User Guide［EB/OL］.［2015-11-5］.http://sqoop.apache.org/docs/1.4.6/SqoopUserGuide.htm l.

［10］Jun Rao.Apache Kafka Powered By［EB/OL］.［2015-11-5］.https://cwiki.apache.org/.

［11］ Kartik Paramasivam. Linked In 是 如 何 優(yōu) 化Kafka 的［EB/OL］.［2015-11-5］.http://www.infoq.com/cn/articles/linkedIn-improvingkafka.

［12］ Apache Software Foundation. Companies Using Apache Storm［EB/OL］. ［2015- 11- 5］. https://storm.apache.org/documentation/Pow?ered-By.htm l.

［13］ Apache Software Foundation. Flume User Guide［EB/OL］.［2015-11-5］.http://flume.apache.org/FlumeUserGuide.htm l.

［14］朱擁華.CORBA 技術(shù)在構(gòu)建電信綜合網(wǎng)管系統(tǒng)中的應(yīng)用［J］.電信工程技術(shù)與標(biāo)準(zhǔn)化，2004（7）：67-71.

［15］ Apache Software Foundation，Apache Kafka Security［EB/OL］.［2015-11-22］. https://cwiki.apache.org/confluence/display/KAFKA/Security