晁平復(fù)， 鄭芷凌， 房俊華， 張 蓉，2，

（1.華東師范大學(xué) 軟件學(xué)院，上海 200062；2.華東師范大學(xué) 數(shù)據(jù)科學(xué)與工程學(xué)院，上海 200062）

0 引 言

在信息時(shí)代，信息通信與人們的生活密不可分.隨著移動(dòng)通信終端的普及和移動(dòng)智能設(shè)備的發(fā)展，移動(dòng)通信領(lǐng)域不再僅限于遠(yuǎn)距離通話以及信息通訊等基礎(chǔ)業(yè)務(wù)，還包括互聯(lián)網(wǎng)訪問(wèn)、智能導(dǎo)航、在線視頻會(huì)議等一批新興應(yīng)用，響應(yīng)這些應(yīng)用需要高效的實(shí)時(shí)數(shù)據(jù)處理的數(shù)據(jù)管理平臺(tái)的支持.

傳統(tǒng)的移動(dòng)通信過(guò)程其本質(zhì)是為基于遠(yuǎn)程無(wú)線通信網(wǎng)絡(luò)或有線網(wǎng)絡(luò)的信號(hào)建立數(shù)據(jù)傳輸?shù)倪^(guò)程.在通信請(qǐng)求發(fā)起以及數(shù)據(jù)傳輸?shù)倪^(guò)程中，通信數(shù)據(jù)需要經(jīng)過(guò)多個(gè)無(wú)線基站或有線中轉(zhuǎn)站的接收與轉(zhuǎn)發(fā).為了防止數(shù)據(jù)丟包以及通信掉話等異常情況發(fā)生，每個(gè)基站會(huì)在數(shù)據(jù)傳輸?shù)倪^(guò)程中輸出大量的監(jiān)測(cè)日志數(shù)據(jù).移動(dòng)運(yùn)營(yíng)商通過(guò)對(duì)日志記錄的實(shí)時(shí)分析可以及時(shí)捕獲通話異常并分析異常原因，實(shí)現(xiàn)對(duì)移動(dòng)網(wǎng)絡(luò)的故障監(jiān)控.同時(shí)，深入分析與挖掘日志數(shù)據(jù)，能夠獲取通信網(wǎng)絡(luò)中的熱點(diǎn)區(qū)域、熱點(diǎn)用戶以及故障集中區(qū)域，可以協(xié)助優(yōu)化通信服務(wù)質(zhì)量.目前通信數(shù)據(jù)管理平臺(tái)通常需要支持以下幾個(gè)功能.

（1）基于計(jì)算的存儲(chǔ)：支持多源海量數(shù)據(jù)依據(jù)數(shù)據(jù)集成、計(jì)算等數(shù)據(jù)處理操作，支持海量數(shù)據(jù)的實(shí)時(shí)存儲(chǔ).

（2）高效離線分析、挖掘：提供針對(duì)已存儲(chǔ)歷史數(shù)據(jù)的離線分析、數(shù)據(jù)挖掘的能力.

（3）實(shí)時(shí)查詢：支持用戶在線故障查詢等實(shí)時(shí)查詢業(yè)務(wù).

（4）基于業(yè)務(wù)的數(shù)據(jù)存儲(chǔ)自適應(yīng)：支持容量的橫向擴(kuò)展以及業(yè)務(wù)功能的快速定制以適應(yīng)業(yè)務(wù)擴(kuò)展需要.

為了達(dá)到以上要求，通信數(shù)據(jù)管理平臺(tái)必須在分布并行的環(huán)境下設(shè)計(jì)和實(shí)現(xiàn)高效的處理方案，設(shè)計(jì)和實(shí)現(xiàn)主要遇到以下幾個(gè)方面的挑戰(zhàn).

（1）數(shù)據(jù)量龐大.隨著移動(dòng)通信用戶數(shù)量的激增以及業(yè)務(wù)的豐富，系統(tǒng)在單位時(shí)間內(nèi)會(huì)生成大量的通信日志數(shù)據(jù)（以一個(gè)中等城市為例，單日的通信日志數(shù)據(jù)量達(dá)到10TB量級(jí)）.因此，高效的數(shù)據(jù)處理以及存儲(chǔ)為平臺(tái)的構(gòu)建提出第1個(gè)挑戰(zhàn).

（2）數(shù)據(jù)結(jié)構(gòu)復(fù)雜.為了更準(zhǔn)確地監(jiān)控并分析通信故障或用戶行為，系統(tǒng)在用戶通話過(guò)程中捕捉多種監(jiān)控日志數(shù)據(jù)，監(jiān)控?cái)?shù)據(jù)指標(biāo)繁多且結(jié)構(gòu)復(fù)雜（每種監(jiān)控?cái)?shù)據(jù)含有幾百到上千種不同屬性字段，且數(shù)據(jù)結(jié)構(gòu)非平面化）.數(shù)據(jù)的結(jié)構(gòu)化存儲(chǔ)以及快速訪問(wèn)為平臺(tái)構(gòu)建提出第2個(gè)挑戰(zhàn).

（3）數(shù)據(jù)時(shí)序混亂.由于網(wǎng)絡(luò)存在不穩(wěn)定性，通信數(shù)據(jù)在傳輸過(guò)程中會(huì)出現(xiàn)大量的數(shù)據(jù)遲到、數(shù)據(jù)丟包等時(shí)序混亂現(xiàn)象.為了保證數(shù)據(jù)的正確性，對(duì)日志數(shù)據(jù)的分析需要實(shí)現(xiàn)對(duì)亂序數(shù)據(jù)的基于時(shí)序的集成，有限內(nèi)存與長(zhǎng)時(shí)間的通信信號(hào)緩存為數(shù)據(jù)處理提出又一挑戰(zhàn).

龐大的數(shù)據(jù)吞吐量、復(fù)雜的數(shù)據(jù)結(jié)構(gòu)以及實(shí)時(shí)性任務(wù)需求使得數(shù)據(jù)的處理變得非常困難，但實(shí)時(shí)的通信日志存儲(chǔ)、分析對(duì)提高通信服務(wù)質(zhì)量以及創(chuàng)造商業(yè)價(jià)值提供了機(jī)會(huì).因此，針對(duì)通信數(shù)據(jù)大數(shù)據(jù)管理平臺(tái)的設(shè)計(jì)和實(shí)現(xiàn)是一項(xiàng)潛力巨大又充滿挑戰(zhàn)的工作.

傳統(tǒng)的通信數(shù)據(jù)管理系統(tǒng)主要架構(gòu)于基于硬盤的單機(jī)系統(tǒng)或分布式環(huán)境之上.由于數(shù)據(jù)存儲(chǔ)與處理的能力有限，目前的數(shù)據(jù)處理方式主要是通過(guò)數(shù)據(jù)采樣與統(tǒng)計(jì)，只將統(tǒng)計(jì)信息保存在數(shù)據(jù)庫(kù)系統(tǒng)中，丟棄原始數(shù)據(jù)，通過(guò)對(duì)業(yè)務(wù)上的妥協(xié)來(lái)滿足性能的要求.然而，隨著近年來(lái)分布式系統(tǒng)的迅速發(fā)展以及內(nèi)存技術(shù)的不斷完善，通過(guò)分布式內(nèi)存技術(shù)實(shí)現(xiàn)海量數(shù)據(jù)的高速處理與實(shí)時(shí)響應(yīng)成為可能.

為了解決通信管理的問(wèn)題，數(shù)據(jù)管理平臺(tái)需要解決如何提升系統(tǒng)容量、處理能力、響應(yīng)速度3個(gè)大問(wèn)題.系統(tǒng)容量的要求需要實(shí)現(xiàn)平臺(tái)的可擴(kuò)展性.分布式架構(gòu)為系統(tǒng)提供足夠多的存儲(chǔ)空間.并行處理架構(gòu)為高效、快速計(jì)算、存儲(chǔ)數(shù)據(jù)提供了解決手段.

近年來(lái)，MapReduce［1］分布式運(yùn)算框架的提出，使得傳統(tǒng)的數(shù)據(jù)處理業(yè)務(wù)可以便捷地移植到分布式運(yùn)算環(huán)境中，以應(yīng)對(duì)數(shù)據(jù)量迅速膨脹后單機(jī)系統(tǒng)的乏力.而開源Apache Hadoop［2］分布式系統(tǒng)的盛行，使得分布式系統(tǒng)作為大數(shù)據(jù)解決方案中最重要的一環(huán)［3］，得到了廣泛的認(rèn)可.系統(tǒng)響應(yīng)速度的要求需要實(shí)現(xiàn)高效計(jì)算.隨著硬件技術(shù)水平的提升以及內(nèi)存成本的下降，目前單臺(tái)服務(wù)器在擁有大容量硬盤存儲(chǔ)空間的同時(shí)，內(nèi)存容量也得到了顯著的提升.內(nèi)存由于其遠(yuǎn)高于硬盤的數(shù)據(jù)訪問(wèn)速度以及較低的響應(yīng)延遲，其特性非常適合應(yīng)用在實(shí)時(shí)性要求較高的業(yè)務(wù).然而，與相對(duì)發(fā)展較為成熟的硬盤分布式系統(tǒng)相比，分布式內(nèi)存計(jì)算系統(tǒng)目前仍處在起步階段，無(wú)論是基于RDD［4］（Resilient Distributed Dataset，分布式彈性數(shù)據(jù)集）技術(shù)的分布式內(nèi)存系統(tǒng)Spark［5，6］，還是基于內(nèi)存的查詢引擎Impala［7］等，其對(duì)于應(yīng)用場(chǎng)景以及內(nèi)存技術(shù)的利用上都存在一定的局限性.

本文針對(duì)通信數(shù)據(jù)處理中存在的數(shù)據(jù)高吞吐量、結(jié)構(gòu)復(fù)雜、時(shí)序混亂以及查詢業(yè)務(wù)的高實(shí)時(shí)性、運(yùn)算密集等特點(diǎn)，提出基于當(dāng)前的分布式技術(shù)，設(shè)計(jì)和實(shí)現(xiàn)高效通信數(shù)據(jù)管理平臺(tái)，支持?jǐn)?shù)據(jù)的高效存儲(chǔ)、近實(shí)時(shí)查詢處理以及動(dòng)態(tài)業(yè)務(wù)模型生成.從分布式文件存儲(chǔ)數(shù)據(jù)處理技術(shù)的角度對(duì)當(dāng)前分布式技術(shù)進(jìn)行比較，包括基于硬盤的分布式系統(tǒng)Hadoop，分布式數(shù)據(jù)庫(kù)HBase［8］、Cassandra，基于內(nèi)存的分布式系統(tǒng)Spark，分布式查詢引擎Impala.本文通過(guò)大量測(cè)試數(shù)據(jù)證明基于分布式平臺(tái)與分布式計(jì)算模式結(jié)合內(nèi)存技術(shù)支持大數(shù)據(jù)處理，而且能夠提升實(shí)時(shí)查詢的性能.

1 相關(guān)工作

隨著大數(shù)據(jù)環(huán)境下數(shù)據(jù)量的迅速膨脹，近年來(lái)分布式技術(shù)發(fā)展速度較快，涌現(xiàn)了大量?jī)?yōu)秀的基于分布式環(huán)境的運(yùn)算工具.然而，不同的分布式技術(shù)所具有的特點(diǎn)各不相同，在應(yīng)用領(lǐng)域上也同樣存在著差異.目前分布式工具主要分為3類：分布式計(jì)算系統(tǒng)、分布式SQL查詢引擎以及分布式NoSQL數(shù)據(jù)庫(kù).

1.1 分布式計(jì)算系統(tǒng)

分布式計(jì)算系統(tǒng)通常基于不同的分布式運(yùn)算框架進(jìn)行構(gòu)建，并圍繞該框架提供一套完整的解決方案，包括分布式數(shù)據(jù)存儲(chǔ)、資源分配以及任務(wù)調(diào)度.分布式計(jì)算系統(tǒng)具有優(yōu)秀的數(shù)據(jù)批處理能力，在擁有大數(shù)據(jù)吞吐量的同時(shí)，對(duì)復(fù)雜邏輯的任務(wù)也提供了較好的支持.

目前較為流行的分布式計(jì)算系統(tǒng)主要由兩部分組成：分布式文件系統(tǒng)以及分布式運(yùn)算框架.其中分布式文件系統(tǒng)在確保數(shù)據(jù)容錯(cuò)的基礎(chǔ)上，保證數(shù)據(jù)存儲(chǔ)在分布式環(huán)境下讀寫的高效性以及存儲(chǔ)的可擴(kuò)展性.此外，分布式文件系統(tǒng)對(duì)于多種數(shù)據(jù)結(jié)構(gòu)的兼容也保證了上層業(yè)務(wù)的靈活性.分布式運(yùn)算框架作為數(shù)據(jù)處理過(guò)程的核心架構(gòu)，其為使用者提供了一套運(yùn)算模型，用戶可以通過(guò)模塊化編程來(lái)實(shí)現(xiàn)豐富的數(shù)據(jù)處理功能.系統(tǒng)通過(guò)對(duì)任務(wù)進(jìn)行合理的資源調(diào)度與分配，實(shí)現(xiàn)分布式環(huán)境下高效的數(shù)據(jù)處理.目前主流的分布式系統(tǒng)包括Hadoop以及Spark.

基于MapReduce運(yùn)算框架下的Hadoop系統(tǒng)，由于其極高的編程靈活性，可以支持復(fù)雜的數(shù)據(jù)處理邏輯.系統(tǒng)在實(shí)現(xiàn)多任務(wù)并發(fā)的同時(shí)，通過(guò)數(shù)據(jù)分塊執(zhí)行，單塊故障重做的方法，以較小的代價(jià)實(shí)現(xiàn)了系統(tǒng)容錯(cuò)，從而保障集群中任意slave節(jié)點(diǎn)出現(xiàn)故障時(shí)不影響任務(wù)順利執(zhí)行.此 外，Hadoop 底 層 的 分 布 式 文 件 系 統(tǒng) HDFS［9，10，11］（Hadoop Distributed File System）通過(guò)多副本機(jī)制保證了數(shù)據(jù)的可靠性，集群的穩(wěn)定性.而HDFS對(duì)多種存儲(chǔ)格式的支持使其可以應(yīng)對(duì)不同應(yīng)用的需求，如列存儲(chǔ)可以用于分析業(yè)務(wù)，行存儲(chǔ)可以進(jìn)行事務(wù)處理.HDFS憑借其良好的穩(wěn)定性與兼容性成為目前使用最為廣泛的分布式文件系統(tǒng).

借鑒MapReduce思想，采用有向無(wú)環(huán)圖框架的Spark系統(tǒng)，在繼承了MapReduce框架編程靈活性的同時(shí)，將Map和Reduce操作拆分成了filter、groupby、join等多種數(shù)據(jù)集操作，優(yōu)化了操作執(zhí)行效率與內(nèi)存占用.此外，Spark基于內(nèi)存特性，針對(duì)任務(wù)的容錯(cuò)性、數(shù)據(jù)本地化、網(wǎng)絡(luò)開銷以及CPU資源利用率等方面進(jìn)行了大量?jī)?yōu)化，使得目前Spark系統(tǒng)在多任務(wù)并發(fā)以及迭代運(yùn)算等性能上相較于Hadoop有著較大的優(yōu)勢(shì).

1.2 分布式SQL查詢引擎

由于分布式計(jì)算系統(tǒng)較為自由的編程模式，在增加了系統(tǒng)靈活性的同時(shí)，也增加了其上手的難度，而分布式SQL查詢引擎的出現(xiàn)解決了這樣的問(wèn)題.分布式查詢引擎架構(gòu)于分布式計(jì)算系統(tǒng)之上，在系統(tǒng)的外層增加SQL查詢解析模塊，將用戶提交的SQL查詢轉(zhuǎn)換成計(jì)算系統(tǒng)的數(shù)據(jù)處理任務(wù)，為計(jì)算系統(tǒng)提供完善的SQL查詢接口.由于其以分布式計(jì)算系統(tǒng)為基礎(chǔ)，因此分布式查詢引擎保留了優(yōu)秀的可擴(kuò)展性、容錯(cuò)性以及對(duì)復(fù)雜數(shù)據(jù)結(jié)構(gòu)的支持.此外，分布式查詢引擎針對(duì)SQL查詢所具有的交互性特點(diǎn)提供了一系列的優(yōu)化策略，為提高查詢的實(shí)時(shí)性以及數(shù)據(jù)吞吐量起到了重要的作用.目前流行的分布式SQL查詢引擎包括基于Hadoop系統(tǒng)的Hive、Impala以及基于Spark的Shark［12］.

1.3 分布式NoSQL數(shù)據(jù)庫(kù)

分布式計(jì)算系統(tǒng)與查詢引擎雖然具有較高的數(shù)據(jù)處理能力，但由于其粗粒度且較為松散的數(shù)據(jù)組織方式以及缺乏高效索引結(jié)構(gòu)等特點(diǎn)，因此無(wú)法很好地支持海量數(shù)據(jù)下高實(shí)時(shí)性要求的數(shù)據(jù)查詢業(yè)務(wù).另一方面，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)由于其嚴(yán)謹(jǐn)?shù)臄?shù)據(jù)結(jié)構(gòu)以及高效的索引技術(shù)，面對(duì)實(shí)時(shí)數(shù)據(jù)查詢?nèi)蝿?wù)有著較強(qiáng)的性能優(yōu)勢(shì)，但其可擴(kuò)展性較差，無(wú)法滿足大數(shù)據(jù)量的存儲(chǔ)與查詢需求.分布式NoSQL數(shù)據(jù)庫(kù)的出現(xiàn)解決了上述的問(wèn)題.NoSQL數(shù)據(jù)庫(kù)削弱了關(guān)系型數(shù)據(jù)庫(kù)所具有的ACID性質(zhì)，通過(guò)使用鍵值對(duì)存儲(chǔ)等弱結(jié)構(gòu)化數(shù)據(jù)的形式，在保留了關(guān)系型數(shù)據(jù)庫(kù)索引技術(shù)等查詢優(yōu)化手段的同時(shí)，提升了其可擴(kuò)展性以及對(duì)大數(shù)據(jù)量的支持.目前主流的分布式NoSQL數(shù)據(jù)庫(kù)通常依據(jù)主鍵對(duì)數(shù)據(jù)進(jìn)行排序或索引等方式，使得在海量記錄中通過(guò)主鍵進(jìn)行點(diǎn)查詢時(shí)擁有非常優(yōu)秀的性能.當(dāng)前常用的分布式NoSQL數(shù)據(jù)庫(kù)包括HBase、Cassandra等.

2 通信數(shù)據(jù)管理平臺(tái)

針對(duì)通信日志的數(shù)據(jù)管理平臺(tái)旨在計(jì)算和存儲(chǔ)海量通信日志信息（每天數(shù)據(jù)量達(dá)到TB級(jí)，記錄條數(shù)達(dá)到百億）；通過(guò)分析與處理日志信息，為用戶提供實(shí)時(shí)的故障查詢以及多維度的數(shù)據(jù)挖掘支持，從而提升通信平臺(tái)的服務(wù)質(zhì)量.

2.1 平臺(tái)上下文分析

通信數(shù)據(jù)管理平臺(tái)的上下文如下圖1所示.

圖1 通信數(shù)據(jù)管理平臺(tái)上下文Fig.1 The context of communication data management platform

系統(tǒng)平臺(tái)將通信網(wǎng)絡(luò)捕獲的多種異構(gòu)數(shù)據(jù)收集起來(lái)，如通話日志數(shù)據(jù)、網(wǎng)絡(luò)訪問(wèn)日志數(shù)據(jù)、硬件終端匯報(bào)數(shù)據(jù)等，經(jīng)過(guò)管理平臺(tái)的數(shù)據(jù)處理與存儲(chǔ)，為上層數(shù)據(jù)分析與用戶查詢提供數(shù)據(jù)支持.

通信數(shù)據(jù)管理平臺(tái)處理的3種主要數(shù)據(jù)源是：

（1）用戶通話日志記錄了移動(dòng)終端用戶在呼叫過(guò)程中的相關(guān)信息.數(shù)據(jù)由呼叫所經(jīng)過(guò)的通訊中轉(zhuǎn)站與通訊基站記錄并輸出，其中用戶通話行為包括語(yǔ)音呼叫、簡(jiǎn)訊收發(fā)以及網(wǎng)絡(luò)訪問(wèn)，日志內(nèi)容包括呼叫建立、釋放等信息.

（2）用戶網(wǎng)絡(luò)訪問(wèn)日志是用戶使用無(wú)線網(wǎng)絡(luò)數(shù)據(jù)業(yè)務(wù)時(shí)通過(guò)無(wú)線網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)，包括網(wǎng)頁(yè)內(nèi)容、視頻內(nèi)容等信息.

（3）移動(dòng)終端測(cè)量報(bào)告是由移動(dòng)終端測(cè)量并通過(guò)通訊中轉(zhuǎn)站整理輸出的無(wú)線測(cè)量信息，包括信號(hào)電平、通話質(zhì)量、所在地區(qū)、信號(hào)干擾等信息.

這些數(shù)據(jù)存在數(shù)據(jù)schema龐大、結(jié)構(gòu)層次化以及數(shù)據(jù)關(guān)聯(lián)復(fù)雜等特征，給實(shí)時(shí)數(shù)據(jù)處理、存儲(chǔ)帶來(lái)非常大的挑戰(zhàn).原始數(shù)據(jù)記錄為樹形結(jié)構(gòu)，且分支較多（存在可選數(shù)據(jù)結(jié)構(gòu)、屬性），記錄屬性個(gè)數(shù)不確定；此外記錄內(nèi)可能存在結(jié)構(gòu)體數(shù)組，數(shù)據(jù)結(jié)構(gòu)表現(xiàn)為層次化、復(fù)雜化.如何有效存儲(chǔ)此類數(shù)據(jù)是一個(gè)大問(wèn)題.同類數(shù)據(jù)、異類數(shù)據(jù)間存在較多的關(guān)聯(lián)，例如有基于時(shí)序的關(guān)聯(lián)、基于用戶id的關(guān)聯(lián).網(wǎng)絡(luò)帶來(lái)的不穩(wěn)定性，數(shù)據(jù)基于規(guī)則的關(guān)聯(lián)與數(shù)據(jù)流的海量性以及處理要求的實(shí)時(shí)性產(chǎn)生了矛盾.

2.2 平臺(tái)架構(gòu)解析

根據(jù)當(dāng)前通信管理平臺(tái)的任務(wù)要求，平臺(tái)的功能主要包含3大模塊：數(shù)據(jù)處理模塊、數(shù)據(jù)查詢模塊以及數(shù)據(jù)存儲(chǔ)模塊，如圖2所示.

圖2 通信數(shù)據(jù)管理平臺(tái)功能模塊圖Fig.2 Function block diagram of communication data management platform

數(shù)據(jù)處理模塊實(shí)時(shí)接收3種數(shù)據(jù)源的輸入數(shù)據(jù)，依據(jù)數(shù)據(jù)源間的關(guān)聯(lián)規(guī)則進(jìn)行數(shù)據(jù)的關(guān)聯(lián)拼接操作，并進(jìn)行大量指標(biāo)運(yùn)算，最終將處理完成的數(shù)據(jù)以統(tǒng)一的數(shù)據(jù)模型存儲(chǔ)至文件系統(tǒng)中，完成數(shù)據(jù)存儲(chǔ).當(dāng)前數(shù)據(jù)處理模塊主要包括以下兩部分業(yè)務(wù).

數(shù)據(jù)拼接：數(shù)據(jù)收集平臺(tái)接收到3種數(shù)據(jù)，依據(jù)數(shù)據(jù)間的關(guān)聯(lián)規(guī)則進(jìn)行連接.通信基站會(huì)監(jiān)控用戶通話、短信或者網(wǎng)絡(luò)訪問(wèn)行為，并輸出用戶通話日志；在通話日志輸出的過(guò)程中，若該通話為網(wǎng)絡(luò)訪問(wèn)，通信基站會(huì)隨著訪問(wèn)網(wǎng)址的變化生成不同的用戶網(wǎng)絡(luò)訪問(wèn)日志；無(wú)論通話與否，移動(dòng)終端會(huì)定時(shí)發(fā)送終端測(cè)量報(bào)告.3種數(shù)據(jù)源在處理過(guò)程中，每條用戶通話日志在時(shí)間軸上均可能與多條網(wǎng)絡(luò)訪問(wèn)日志與多條移動(dòng)終端測(cè)量報(bào)告相關(guān)，在數(shù)據(jù)收集階段，要求將3種數(shù)據(jù)源依據(jù)時(shí)間與用戶標(biāo)識(shí)進(jìn)行數(shù)據(jù)關(guān)聯(lián)，形成一條記錄所有測(cè)量信息的完整用戶通話記錄.但由于可能出現(xiàn)時(shí)序混亂、數(shù)據(jù)丟包以及數(shù)據(jù)延遲等情況，會(huì)導(dǎo)致大量數(shù)據(jù)因缺少部分信息而暫時(shí)無(wú)法完成拼接的情況，因此如何處理大量因未完成拼接而暫時(shí)堆積的數(shù)據(jù)也是該模塊面臨的主要困難之一.

指標(biāo)計(jì)算：提取已完成拼接的完整用戶通話記錄中部分指標(biāo)（attribute）字段，依據(jù)運(yùn)算規(guī)則生成新字段以及對(duì)應(yīng)值.該數(shù)據(jù)處理模塊在通信系統(tǒng)中較為常見(jiàn)，其意義在于將已有數(shù)據(jù)中大量無(wú)法被用戶解讀的參數(shù)信息進(jìn)行計(jì)算，轉(zhuǎn)換為可以被用戶理解的指標(biāo)信息.

數(shù)據(jù)查詢模塊接收上層用戶提交的查詢，并轉(zhuǎn)化為對(duì)當(dāng)前已存儲(chǔ)數(shù)據(jù)的邏輯查詢?nèi)蝿?wù).由于上層用戶查詢主要為離線分析類查詢與在線實(shí)時(shí)查詢.因此數(shù)據(jù)查詢模塊也分為兩部分：針對(duì)離線分析類查詢的數(shù)據(jù)分析查詢模塊以及針對(duì)在線查詢的實(shí)時(shí)定位查詢模塊.其中，數(shù)據(jù)分析查詢模塊主要針對(duì)某些列數(shù)據(jù)操作，即依據(jù)多個(gè)維度進(jìn)行數(shù)據(jù)分組、匯總、排序等復(fù)雜邏輯操作，最終返回?cái)?shù)據(jù)分析結(jié)果；實(shí)時(shí)定位查詢根據(jù)用戶提出的數(shù)據(jù)篩選條件，在海量數(shù)據(jù)中迅速定位到符合條件信息，并返回給用戶.由于其在線交互式的特點(diǎn)，對(duì)于數(shù)據(jù)處理的實(shí)時(shí)性要求非常高.

數(shù)據(jù)存儲(chǔ)模塊提供高壓縮率的數(shù)據(jù)序列化方案以及對(duì)復(fù)雜結(jié)構(gòu)數(shù)據(jù)的存儲(chǔ)支持，此外，由于數(shù)據(jù)業(yè)務(wù)特點(diǎn)的差異——數(shù)據(jù)分析業(yè)務(wù)需要提供自適應(yīng)的數(shù)據(jù)列重組以支持針對(duì)特定業(yè)務(wù)的分析和查詢工作.因此系統(tǒng)需要提供較高的列訪問(wèn)性能，而實(shí)時(shí)查詢業(yè)務(wù)要求以單條記錄的形式返回結(jié)果，需要較好的行訪問(wèn)效率，因此文件存儲(chǔ)模塊需要提供基于應(yīng)用的數(shù)據(jù)模型動(dòng)態(tài)生成支持.

3 平臺(tái)技術(shù)方案設(shè)計(jì)

從上文針對(duì)數(shù)據(jù)結(jié)構(gòu)以及業(yè)務(wù)模塊的介紹中可以看出，通信數(shù)據(jù)管理平臺(tái)無(wú)論是從數(shù)據(jù)復(fù)雜性、業(yè)務(wù)動(dòng)態(tài)性上都具有很大的挑戰(zhàn)，無(wú)法簡(jiǎn)單地通過(guò)套用其它領(lǐng)域的分布式解決方案來(lái)解決當(dāng)前問(wèn)題.因此本文根據(jù)應(yīng)用的需求，利用當(dāng)前流行的分布式數(shù)據(jù)處理技術(shù)來(lái)架構(gòu)一套針對(duì)通信業(yè)務(wù)的分布式解決方案.

3.1 技術(shù)選型約束

平臺(tái)技術(shù)方案的選型需要考慮硬件環(huán)境的約束以及數(shù)據(jù)業(yè)務(wù)的需求，當(dāng)前主要的設(shè)計(jì)約束如下.

（1）硬件環(huán)境：采用由高性能服務(wù)器組成的小型集群.在早期的分布式系統(tǒng)中，大規(guī)模廉價(jià)機(jī)集群由于其較低廉的成本以及便于擴(kuò)展的架構(gòu)而得到青睞.但隨著分布式技術(shù)與硬件技術(shù)的發(fā)展，廉價(jià)集群較低的性能水平、高設(shè)備維護(hù)成本以及高空間占用等問(wèn)題逐漸凸顯，小型高性能機(jī)集群憑借其靈巧、穩(wěn)定以及卓越的性能等特點(diǎn)，正逐漸取代傳統(tǒng)大型廉價(jià)機(jī)集群的地位.故本平臺(tái)采用少量小型高性能服務(wù)器搭建集群.在提供了高性能并行運(yùn)算能力的同時(shí)，通過(guò)配備大容量?jī)?nèi)存來(lái)提供足夠的數(shù)據(jù)緩存空間，減少系統(tǒng)對(duì)于硬盤I／O的依賴.具體測(cè)試系統(tǒng)的硬件環(huán)境如下表1所示.

表1 測(cè)試環(huán)境硬件配置明細(xì)Tab.1 Hardware configuration of test environment

（2）并發(fā)性能：3種元數(shù)據(jù)通過(guò)各個(gè)通訊基站匯總并發(fā)送至數(shù)據(jù)處理平臺(tái)，因此平臺(tái)將以基站為單位進(jìn)行數(shù)據(jù)處理.目前，單個(gè)數(shù)據(jù)平臺(tái)需要同時(shí)處理接近50個(gè)通訊基站的數(shù)據(jù)，必須具備較高的并發(fā)處理能力.

（3）業(yè)務(wù)特點(diǎn)：當(dāng)前業(yè)務(wù)分為多種類型，技術(shù)特點(diǎn)各異，需要一套完整的解決方案以應(yīng)對(duì)不同特點(diǎn)的數(shù)據(jù)業(yè)務(wù).數(shù)據(jù)處理業(yè)務(wù)要求系統(tǒng)擁有高并發(fā)的數(shù)據(jù)批處理能力，并保證高性能的批量數(shù)據(jù)連接操作；數(shù)據(jù)分析類查詢對(duì)數(shù)據(jù)的列訪問(wèn)性能要求較高；實(shí)時(shí)查詢則要求系統(tǒng)實(shí)時(shí)性較強(qiáng)，能夠提供海量數(shù)據(jù)下的快速單點(diǎn)或范圍查詢性能.

3.2 選型方案設(shè)計(jì)

通信數(shù)據(jù)管理平臺(tái)在構(gòu)建過(guò)程中需要針對(duì)2個(gè)模塊進(jìn)行技術(shù)選型——分布式文件存儲(chǔ)方案以及分布式管理系統(tǒng).

當(dāng)前分布式環(huán)境下最為通用的文件系統(tǒng)為Hadoop Distributed File System（HDFS）.HDFS文件系統(tǒng)可以兼容各種存儲(chǔ)格式以及上層的分布式框架，因此HDFS是良好的文件系統(tǒng)方案之一.存儲(chǔ)格式方面，根據(jù)不同的應(yīng)用要求，可以在HDFS上使用Text文檔、以鍵值對(duì)的形式存儲(chǔ)的序列化文件、二進(jìn)制序列化存儲(chǔ)以及各種列存儲(chǔ)變體.常見(jiàn)的格式有Thrift、Parquet、RCFile［13］等.

分布式管理系統(tǒng)方面主要有3類方案——分布式運(yùn)算框架、分布式數(shù)據(jù)庫(kù)以及分布式查詢引擎.分布式運(yùn)算框架包括應(yīng)用最為廣泛的Hadoop以及基于內(nèi)存有著更多優(yōu)化策略的Spark；分布式數(shù)據(jù)庫(kù)選擇當(dāng)前較為流行的HBase，分布式類SQL查詢引擎包括基于硬盤的Hive以及基于內(nèi)存的Shark、Impala等.

依據(jù)平臺(tái)應(yīng)用目標(biāo)，后續(xù)內(nèi)容通過(guò)對(duì)上述技術(shù)進(jìn)行測(cè)試，最終選定平臺(tái)構(gòu)建的技術(shù)方案.

（1）文件存儲(chǔ)方案

分布式文件系統(tǒng)方面由于可選方案有限，因此本系統(tǒng)選擇HDFS作為分布式文件系統(tǒng).其在穩(wěn)定性與容錯(cuò)性上的優(yōu)勢(shì)可以保證業(yè)務(wù)的正常運(yùn)轉(zhuǎn)，而HDFS對(duì)于多數(shù)存儲(chǔ)格式的高度兼容也為存儲(chǔ)格式的選擇提供了更廣泛的空間.但由于平臺(tái)在數(shù)據(jù)處理的輸出以及查詢業(yè)務(wù)的輸入端需要對(duì)大量數(shù)據(jù)進(jìn)行I／O操作，因此基于HDFS實(shí)現(xiàn)高數(shù)據(jù)吞吐量是本系統(tǒng)需要達(dá)到的一個(gè)目標(biāo).數(shù)據(jù)的存儲(chǔ)格式方面，當(dāng)前方案主要集中為3類：通過(guò)HBase進(jìn)行管理的key－value對(duì)；由 Hadoop支持的鍵值對(duì)存儲(chǔ)方案有Sequence File；以及包括RCFile與Parquet在內(nèi)的二進(jìn)制列存儲(chǔ)方案.

表2 4種存儲(chǔ)格式的性能比較Tab.2 Performance comparison of four storage formats

表2對(duì)比了各種存儲(chǔ)格式在存儲(chǔ)性能與訪問(wèn)效率上的對(duì)比.首先從存儲(chǔ)空間的角度考慮，上述4種數(shù)據(jù)中，Sequence File作為非序列化方案，其空間占用相對(duì)較大.通過(guò)測(cè)試發(fā)現(xiàn)，由于原始數(shù)據(jù)量較大，若采用非壓縮Sequence File鍵值存儲(chǔ)格式，數(shù)據(jù)量將達(dá)到PB級(jí)，即使對(duì)數(shù)據(jù)進(jìn)行壓縮，其占用的空間也將接近集群的存儲(chǔ)空間上限，無(wú)法滿足系統(tǒng)的存儲(chǔ)容量要求，因此需要一種二進(jìn)制序列化的存儲(chǔ)格式.此外，由于當(dāng)前數(shù)據(jù)分析業(yè)務(wù)中存在大量列掃描操作，因此數(shù)據(jù)存儲(chǔ)方案傾向于使用列訪問(wèn)性能較好的RCFile和Parquet列存儲(chǔ)格式.當(dāng)前幾種二進(jìn)制序列化方案中，RCFile與Parquet是兩個(gè)性能相對(duì)較好的列存儲(chǔ)方案.RCFile根據(jù)HDFS數(shù)據(jù)塊的大小，首先將數(shù)據(jù)按照行切分，再將每個(gè)數(shù)據(jù)塊內(nèi)的完整記錄按照列切分存儲(chǔ).作為行列混合存儲(chǔ)方案，該方案能很好地支持行訪問(wèn)與列訪問(wèn)，而Parquet為單純的列切分方案，但由于其良好的數(shù)據(jù)組織形式與訪問(wèn)性能優(yōu)化，基于Parquet的列訪問(wèn)效率明顯高于RCFile，且行訪問(wèn)效率劣勢(shì)較小，考慮到當(dāng)前業(yè)務(wù)中大量的列訪問(wèn)需求，Parquet在性能上具有較大優(yōu)勢(shì).此外，Parquet對(duì)于通信數(shù)據(jù)中多結(jié)構(gòu)體嵌套等復(fù)雜數(shù)據(jù)結(jié)構(gòu)能夠提供較好的支持，而通過(guò)網(wǎng)絡(luò)傳輸數(shù)據(jù)時(shí)，網(wǎng)絡(luò)傳輸格式Thrift可以快速便捷的轉(zhuǎn)換為Parquet格式，因此將Parquet作為數(shù)據(jù)的存儲(chǔ)格式.

（2）分布式管理系統(tǒng)方案

根據(jù)當(dāng)前業(yè)務(wù)特點(diǎn)，通信數(shù)據(jù)管理平臺(tái)主要面臨兩類系統(tǒng)需求，數(shù)據(jù)處理業(yè)務(wù)以及實(shí)現(xiàn)查詢業(yè)務(wù).由于業(yè)務(wù)邏輯較為復(fù)雜，無(wú)法通過(guò)簡(jiǎn)單的SQL語(yǔ)句進(jìn)行表達(dá)，因此HBase等分布式數(shù)據(jù)庫(kù)以及SQL查詢引擎均無(wú)法支持，主要可選方案為Hadoop以及Spark.實(shí)時(shí)查詢的業(yè)務(wù)邏輯較為簡(jiǎn)單，但需要在海量原始數(shù)據(jù)中，根據(jù)條件篩選出極少量記錄，并實(shí)時(shí)返回查詢結(jié)果.這類業(yè)務(wù)更適合使用成熟的數(shù)據(jù)庫(kù)技術(shù)實(shí)現(xiàn).

根據(jù)數(shù)據(jù)處理與分析查詢業(yè)務(wù)的需求，將Hadoop與Spark作為主要的平臺(tái)構(gòu)建方案.與此同時(shí)，為了盡可能減少方案的技術(shù)復(fù)雜度，優(yōu)先考慮在Hadoop或Spark上實(shí)現(xiàn)實(shí)時(shí)查詢業(yè)務(wù).因此對(duì)分布式管理系統(tǒng)的性能要求包括：秒級(jí)響應(yīng)的實(shí)時(shí)性、較高的系統(tǒng)資源利用率、任務(wù)執(zhí)行效率以及較強(qiáng)的并發(fā)能力.

圖3 Hadoop（a）與Spark（b）實(shí)時(shí)響應(yīng)能力對(duì)比Fig.3 Comparison of real－time response speed on Hadoop（a）and Spark（b）

基于通信業(yè)務(wù)中的一個(gè)經(jīng)典查詢，圖3與圖4比較了Hadoop與Spark在查詢響應(yīng)速度與系統(tǒng)資源利用率方面的優(yōu)劣.圖3從任務(wù)開始時(shí)，對(duì)系統(tǒng)資源利用率（CPU與I／O利用率）進(jìn)行了監(jiān)控，展示了Hadoop與Spark系統(tǒng)在實(shí)時(shí)響應(yīng)能力上的比較.從圖中可見(jiàn)，在任務(wù)提交后，圖（a）中Hadoop系統(tǒng)經(jīng)歷了接近25 s左右的低資源利用率階段，之后才開始任務(wù)執(zhí)行過(guò)程，而圖（b）中Spark的任務(wù)延遲時(shí)間極短.后續(xù)經(jīng)過(guò)大量測(cè)試發(fā)現(xiàn)，Hadoop在任務(wù)開始時(shí)通常需要消耗20 s左右任務(wù)調(diào)度的時(shí)間，在這期間，主節(jié)點(diǎn)在完成任務(wù)分發(fā)與資源調(diào)配后從每個(gè)節(jié)點(diǎn)上開啟任務(wù)，而Spark根據(jù)任務(wù)的復(fù)雜程度，需要消耗300 ms至幾秒鐘的任務(wù)調(diào)度時(shí)間，從實(shí)時(shí)性的角度來(lái)講，Hadoop無(wú)法滿足實(shí)時(shí)定位查詢的性能要求，而Spark在實(shí)時(shí)響應(yīng)上表現(xiàn)較好.

圖4 Hadoop（a，b）與Spark（c，d）在有無(wú)數(shù)據(jù)緩存下的性能對(duì)比Fig.4 Performance comparison of Hadoop（a，b）and Spark（c，d）with or without memory cache

圖4則展示了Hodoop和Spark在數(shù)據(jù)緩存在內(nèi)存中以及數(shù)據(jù)在硬盤中時(shí)，查詢?nèi)蝿?wù)執(zhí)行過(guò)程與資源利用情況.通過(guò)CPU曲線與硬盤I／O曲線可以看到，當(dāng)數(shù)據(jù)緩存在內(nèi)存時(shí)（圖4左a，c）兩者的CPU資源利用率均較高，但Hadoop存在間歇性的CPU低谷，這是由于Hadoop依據(jù)MapReduce架構(gòu)將數(shù)據(jù)拆分為多個(gè)Map塊，并且依據(jù)CPU并發(fā)能力進(jìn)行分批處理.當(dāng)?shù)?批Map接近同一時(shí)間處理完成時(shí)，由于系統(tǒng)需要調(diào)度第2批Map執(zhí)行，因此出現(xiàn)了CPU暫時(shí)處在無(wú)任務(wù)狀態(tài)，導(dǎo)致CPU低谷，影響了系統(tǒng)利用率.當(dāng)數(shù)據(jù)存儲(chǔ)在硬盤時(shí)（圖4右b，d），Hadoop受限于硬盤I／O效率而影響了CPU的利用率，Spark則受影響較小，其原因在于Spark對(duì)本地化的數(shù)據(jù)讀取的優(yōu)化較好，大多數(shù)數(shù)據(jù)從HDFS中讀取時(shí)，更多定向至本地磁盤數(shù)據(jù)，且在不同的RDD任務(wù)之間，數(shù)據(jù)交互也盡可能減少，從而降低了網(wǎng)絡(luò)延遲帶來(lái)的影響.從上述的實(shí)驗(yàn)可以發(fā)現(xiàn)，Spark無(wú)論是在系統(tǒng)執(zhí)行效率還是實(shí)時(shí)性上均優(yōu)于Hadoop，因此Spark能夠更好地支持通信數(shù)據(jù)的查詢和分析.

此外，在后續(xù)的實(shí)驗(yàn)中發(fā)現(xiàn)，雖然Spark在任務(wù)的實(shí)時(shí)性上性能較好，但作為優(yōu)秀的數(shù)據(jù)批處理架構(gòu)，面對(duì)實(shí)時(shí)定位查詢業(yè)務(wù)需要從海量數(shù)據(jù)中實(shí)現(xiàn)精確定位，其效率仍不能滿足需求.而HBase雖然可以提供高效的定位查詢能力，但面對(duì)通信數(shù)據(jù)復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，簡(jiǎn)單地采用表結(jié)構(gòu)存儲(chǔ)數(shù)據(jù)顯然不能滿足要求.因此在最終方案里將HBase引入，用于存儲(chǔ)數(shù)據(jù)的索引表，通過(guò)利用HBase高效的定位能力，在數(shù)十ms內(nèi)完成索引的檢索，并使用Spark掃描索引指向的剩余目標(biāo)文件，最終實(shí)現(xiàn)結(jié)果的快速返回.

最終，如圖5所示，通信數(shù)據(jù)管理平臺(tái)的技術(shù)選型劃分為兩層：分布式文件存儲(chǔ)層以HDFS為底層文件系統(tǒng)，Parquet作為文件存儲(chǔ)格式，并使用Thrift文件格式進(jìn)行網(wǎng)絡(luò)通信數(shù)據(jù)的傳輸，此外還包含部分HBase所生成的索引表；分布式管理系統(tǒng)層則以Spark作為核心的分布式計(jì)算系統(tǒng)，并引入HBase對(duì)數(shù)據(jù)建立查詢索引，提高查詢效率，最終形成了一套完整的分布式解決方案.

4 平臺(tái)實(shí)現(xiàn)與性能優(yōu)化

基于當(dāng)前技術(shù)選型方案，本文完整實(shí)現(xiàn)了通信數(shù)據(jù)管理平臺(tái)的全部功能.本節(jié)將針對(duì)實(shí)現(xiàn)過(guò)程中的幾個(gè)技術(shù)難點(diǎn)與解決方案進(jìn)行介紹.

圖5 通信數(shù)據(jù)管理平臺(tái)技術(shù)框架Fig.5 The technical framework for communication data management platform

4.1 文件系統(tǒng)性能優(yōu)化

當(dāng)前在平臺(tái)業(yè)務(wù)流程中涉及多次針對(duì)文件系統(tǒng)的讀寫操作，包括數(shù)據(jù)處理階段，具體的，從文件系統(tǒng)中讀取原始數(shù)據(jù)以及輸出處理后的數(shù)據(jù)記錄等；數(shù)據(jù)分析查詢階段針對(duì)大量數(shù)據(jù)的讀取與掃描；以及數(shù)據(jù)實(shí)時(shí)定位查詢中的數(shù)據(jù)過(guò)濾.而無(wú)論是數(shù)據(jù)處理還是數(shù)據(jù)查詢，對(duì)于任務(wù)時(shí)間的要求都較為嚴(yán)苛，這對(duì)文件系統(tǒng)的I／O性能提出了較高的要求，而任務(wù)在硬盤I／O時(shí)所消耗的時(shí)間也將直接影響平臺(tái)的性能.對(duì)此，針對(duì)HDFS的I／O性能進(jìn)行測(cè)試以檢測(cè)其是否可以滿足平臺(tái)的需要.

圖6 單機(jī)硬盤I／O與HDFS I／O性能對(duì)比Fig.6 Performance comparison of I／O speed between single disk and HDFS

如圖6所示，通過(guò)對(duì)單臺(tái)高性能服務(wù)器（12塊2TB SATA硬盤并行I／O）的硬盤I／O性能以及HDFS下分布式硬盤I／O性能進(jìn)行比較發(fā)現(xiàn)，相較于單機(jī)硬盤平均700 MB／s以及2.5 GB／s的硬盤寫入與讀取速度，HDFS下250 MB／s的寫入與600 MB／s的讀取速度在性能上降低了很多，這是由于分布式文件系統(tǒng)中數(shù)據(jù)的備份與負(fù)載調(diào)整等額外代價(jià)所導(dǎo)致的，而通過(guò)對(duì)8臺(tái)機(jī)器組成的HDFS集群整體進(jìn)行I／O性能測(cè)試發(fā)現(xiàn)，系統(tǒng)I／O性能接近1.5 GB／s以及4 GB／s的寫入與讀取速度，整體性能損失明顯，相較于每半個(gè)小時(shí)100 GB左右的數(shù)據(jù)讀取與寫入量，其較差的I／O性能一定程度上會(huì)影響業(yè)務(wù)的執(zhí)行效率.為此，設(shè)計(jì)中采取以下兩方面的優(yōu)化.

針對(duì)大數(shù)據(jù)量的問(wèn)題，嘗試引入壓縮方法，并針對(duì)Spark下較為通用的壓縮策略進(jìn)行測(cè)試，表3展示了RCFile數(shù)據(jù)分別在不采用壓縮（RCFile默認(rèn)采用Run Length Encoding編碼算法）、采用默認(rèn)GZip壓縮以及采用BZip2壓縮方法下壓縮率以及訪問(wèn)時(shí)間的對(duì)比（使用基于業(yè)務(wù)的數(shù)據(jù)模型，多臺(tái)中端性能PC機(jī)組建的分布式測(cè)試環(huán)境）.通過(guò)實(shí)驗(yàn)可以得出，使用GZip壓縮可以在有效縮減數(shù)據(jù)存儲(chǔ)空間的同時(shí)提升數(shù)據(jù)的訪問(wèn)效率.

表3 200萬(wàn)條數(shù)據(jù)寫入（原始數(shù)據(jù)590.9MB）壓縮效率對(duì)比Tab.3 Comparison of compression efficiency on 2 million record inputs（original data size 590.9 MB）

表4 800萬(wàn)條數(shù)據(jù)寫入（原始數(shù)據(jù)2.2GB）壓縮效率對(duì)比Tab.4 Comparison of compression efficiency on 8 million record inputs（original data size 2.2 GB）

另一方面，鑒于集群系統(tǒng)內(nèi)存空間較為充足，且Spark系統(tǒng)對(duì)于數(shù)據(jù)的內(nèi)存緩存提供了較好的支持，設(shè)計(jì)中考慮將部分頻繁使用數(shù)據(jù)緩存至內(nèi)存中，以減少硬盤的訪問(wèn)頻率.對(duì)于數(shù)據(jù)處理模塊，每半個(gè)小時(shí)數(shù)據(jù)在處理過(guò)程中會(huì)出現(xiàn)大量因數(shù)據(jù)晚到現(xiàn)象而出現(xiàn)的無(wú)法完成拼接的殘缺數(shù)據(jù)，這部分?jǐn)?shù)據(jù)需要在下一個(gè)時(shí)間段時(shí)重新讀取和新到達(dá)數(shù)據(jù)一起再次進(jìn)行拼接，針對(duì)這部分未完成拼接的數(shù)據(jù)，可以通過(guò)將數(shù)據(jù)緩存在內(nèi)存中，從而減少每個(gè)任務(wù)加載的數(shù)據(jù)量.

通過(guò)在系統(tǒng)實(shí)現(xiàn)過(guò)程中添加上述兩類優(yōu)化，使得每半小時(shí)的系統(tǒng)輸入數(shù)據(jù)量從近100 GB縮減至40 GB，而數(shù)據(jù)處理模塊從原始每半小時(shí)數(shù)據(jù)處理時(shí)間超過(guò)45 min縮短至20 min左右（忙閑時(shí)不同時(shí)段數(shù)據(jù)處理耗時(shí)存在差異）.利用數(shù)據(jù)壓縮與內(nèi)存技術(shù)使得硬盤I／O方面的性能損失得到了一定程度的彌補(bǔ).

4.2 實(shí)時(shí)查詢性能優(yōu)化

由于數(shù)據(jù)分析查詢模塊對(duì)于處理時(shí)間的要求較低，在實(shí)現(xiàn)過(guò)程中不存在嚴(yán)重的性能瓶頸.而實(shí)時(shí)查詢模塊作為用戶交互式查詢，其高實(shí)時(shí)性要求成為平臺(tái)實(shí)現(xiàn)過(guò)程中的難點(diǎn).實(shí)時(shí)查詢的業(yè)務(wù)特點(diǎn)是在海量的數(shù)據(jù)記錄中（通常為百億條記錄，1TB左右的數(shù)據(jù)量），通過(guò)用戶ID精確定位某位用戶或多位用戶的通話信息（通常為幾十至上百條，KB級(jí)數(shù)據(jù)量），并且需要處理多用戶并發(fā)查詢?nèi)蝿?wù).對(duì)于這樣的業(yè)務(wù)特點(diǎn)，使用諸如HBase這樣的分布式NoSQL數(shù)據(jù)庫(kù)將具有更優(yōu)秀的性能，然而，使用數(shù)據(jù)庫(kù)進(jìn)行查詢則需要將查詢?cè)紨?shù)據(jù)存入數(shù)據(jù)庫(kù).考慮到查詢?cè)紨?shù)據(jù)需要兼顧數(shù)據(jù)分析業(yè)務(wù)，因此若使用HBase進(jìn)行數(shù)據(jù)存儲(chǔ)，則需要同時(shí)滿足對(duì)數(shù)據(jù)掃描的性能需求.基于上述需求，本文對(duì)分布式數(shù)據(jù)庫(kù)HBase進(jìn)行了性能的測(cè)試.

圖7為HBase多線程掃描性能的對(duì)比.在集群平臺(tái)下實(shí)驗(yàn)，對(duì)1.3億條數(shù)據(jù)進(jìn)行掃描，每條數(shù)據(jù)100 byte，分別返回百分之一，百分之五和百分之十的數(shù)據(jù).結(jié)果顯示HBase即使在多線程條件下，數(shù)據(jù)掃描的速度也僅限于25萬(wàn)條／s，對(duì)于數(shù)據(jù)分析類業(yè)務(wù)上百億條記錄的數(shù)據(jù)量，HBase的掃描性能顯然無(wú)法滿足需求.因此，使用HBase作為查詢?cè)紨?shù)據(jù)的存儲(chǔ)與查詢工具無(wú)法達(dá)到性能要求.

圖7 HBase多線程掃描性能Fig.7 Performance of HBase multi－thread scan

另一方面，采用Spark系統(tǒng)進(jìn)行實(shí)時(shí)查詢，通過(guò)對(duì)原始數(shù)據(jù)進(jìn)行并發(fā)掃描的方式獲取結(jié)果，在不考慮并發(fā)查詢的情況下，獲得了接近10 min的查詢性能.由此，本文提出了如下的優(yōu)化策略：

（1）建立基于用戶ID的索引.由于單一用戶的通話記錄在海量通話信息中分布較為稀疏，當(dāng)前進(jìn)行數(shù)據(jù)掃描過(guò)程，針對(duì)大部分文件的掃描均不會(huì)得到有效結(jié)果.故可以對(duì)所有記錄進(jìn)行離線數(shù)據(jù)掃描，并根據(jù)每一個(gè)用戶ID建立針對(duì)文件的倒排表索引.當(dāng)用戶發(fā)出針對(duì)某個(gè)用戶ID的查詢時(shí)，可以通過(guò)索引確定存在該用戶記錄的所有文件路徑，并掃描對(duì)應(yīng)文件即可快速獲取記錄.

（2）降低文件存儲(chǔ)粒度.當(dāng)前每30 min數(shù)據(jù)存儲(chǔ)為一個(gè)數(shù)據(jù)文件，存儲(chǔ)粒度過(guò)大，導(dǎo)致單一用戶ID在大多數(shù)文件中都存在數(shù)據(jù)分布.為增加基于用戶ID索引的數(shù)據(jù)篩選率，系統(tǒng)將每個(gè)時(shí)間周期的數(shù)據(jù)拆分為多個(gè)小粒度文件，通過(guò)實(shí)驗(yàn)表明，隨著文件粒度的降低，單一查詢所涉及的數(shù)據(jù)掃描量在一定區(qū)段內(nèi)呈近線性下降趨勢(shì).

（3）設(shè)計(jì)優(yōu)秀的索引訪問(wèn)方案.考慮到查詢數(shù)據(jù)以Parquet格式存儲(chǔ)，數(shù)據(jù)結(jié)構(gòu)復(fù)雜且數(shù)據(jù)量較大，無(wú)法通過(guò)分布式數(shù)據(jù)庫(kù)以數(shù)據(jù)表的形式直接進(jìn)行管理，因此使用“查詢索引＋數(shù)據(jù)掃描”的方案解決實(shí)時(shí)查詢問(wèn)題.數(shù)據(jù)掃描部分沿用Spark進(jìn)行數(shù)據(jù)的并發(fā)掃描，而查詢索引由于數(shù)據(jù)結(jié)構(gòu)較為簡(jiǎn)單，數(shù)據(jù)量較?。ó?dāng)前用戶ID數(shù)量約為6 000萬(wàn)左右），適合使用數(shù)據(jù)庫(kù)存儲(chǔ)，故采用分布式NoSQL數(shù)據(jù)庫(kù)HBase進(jìn)行索引存儲(chǔ).前期通過(guò)實(shí)驗(yàn)獲知，HBase針對(duì)單條記錄的查詢性能在50 ms左右，并且支持多達(dá)上千的查詢并發(fā)，而查詢性能與原始數(shù)據(jù)庫(kù)記錄的數(shù)量關(guān)聯(lián)不大.因此在實(shí)時(shí)查詢的索引環(huán)節(jié)，查詢性能非常優(yōu)異.此外，由于每半小時(shí)會(huì)新增一批數(shù)據(jù)，需要對(duì)新數(shù)據(jù)添加索引，這對(duì)HBase的數(shù)據(jù)插入性能也提出了要求.據(jù)此，本文對(duì)HBase的插入性能進(jìn)行測(cè)試.如表5所示，在單條記錄1 KB大小的條件下，HBase的隨機(jī)插入性能超過(guò)30萬(wàn)行／s，而實(shí)際業(yè)務(wù)中針對(duì)半小時(shí)數(shù)據(jù)的索引更新需要40 s左右的時(shí)間，性能可以滿足需求.

（4）查詢結(jié)果分段返回策略.當(dāng)前交互式查詢對(duì)性能的較高要求主要源于用戶在發(fā)送查詢請(qǐng)求后，需要長(zhǎng)時(shí)間等待結(jié)果，用戶對(duì)系統(tǒng)的不滿程度與界面空響應(yīng)時(shí)間呈指數(shù)關(guān)系.因此，嘗試將最先獲取的查詢結(jié)果立即返回，并隨著查詢過(guò)程分段反饋結(jié)果也是另一種減少界面空響應(yīng)時(shí)間的辦法.由于當(dāng)前使用的索引機(jī)制可以保證每個(gè)文件的掃描都可以確定返回查詢結(jié)果，因此可以采用分段掃描數(shù)據(jù)的方式來(lái)獲得第一條查詢結(jié)果的快速返回.

通過(guò)上述優(yōu)化措施，平臺(tái)最終實(shí)現(xiàn)了實(shí)時(shí)定位查詢性能從10 min提升至28 s的顯著性能變化（其中首條查詢結(jié)果返回時(shí)間為7 s），達(dá)到了30 s內(nèi)完成查詢的設(shè)計(jì)要求.

表5 HBase數(shù)據(jù)插入性能測(cè)試結(jié)果Tab.5 Performance of insertion on HBase

5 總 結(jié)

通信數(shù)據(jù)管理平臺(tái)由于具有復(fù)雜的數(shù)據(jù)特點(diǎn)以及較高的數(shù)據(jù)處理與在線查詢性能要求，使其無(wú)法通過(guò)單一的技術(shù)手段來(lái)滿足該平臺(tái)的性能需求.此外，傳統(tǒng)基于硬盤的技術(shù)受限于硬盤I／O速度，使得交互式系統(tǒng)應(yīng)用的實(shí)時(shí)性要求很難得到滿足.而隨著內(nèi)存技術(shù)的發(fā)展，基于內(nèi)存的分布式技術(shù)得到廣泛應(yīng)用，使得分布式在線查詢系統(tǒng)成為了可能.本文通過(guò)對(duì)當(dāng)今流行的內(nèi)存與硬盤分布式技術(shù)進(jìn)行分析與比較，采用多項(xiàng)開源技術(shù)融合的方式實(shí)現(xiàn)了通信數(shù)據(jù)管理平臺(tái)的設(shè)計(jì)；并在大容量?jī)?nèi)存環(huán)境下，通過(guò)優(yōu)化業(yè)務(wù)的內(nèi)存緩存方案，達(dá)到了分布式環(huán)境下高實(shí)時(shí)性與高吞吐量的性能要求，為復(fù)雜的通信業(yè)務(wù)提供了一套完善的分布式內(nèi)存系統(tǒng)解決方案.

［1］ DEAN J，GHEMAWAT S.MapReduce：simplified data processing on large clusters［J］.Communications of the ACM，2008，51（1）：107－113.

［2］ Apache Hadoop.http：／／hadoop.apache.org.

［3］ 陳勇.基于Hadoop平臺(tái)的通信數(shù)據(jù)分布式查詢算法的設(shè)計(jì)與實(shí)現(xiàn)［D］.北京：北京郵電大學(xué)，2009.

［4］ ZAHARIA M，CHOWDHURY M，DAS T，et al.Resilient distributed datasets：a fault－tolerant abstraction for in－memory cluster computing［R／OL］.2011［2014－08－30］.http：／／www.eecs.berkeley.edu／TecRpts／2011／EECS－2011－82.html.

［5］ Apache Spark.http：／／spark.apache.org.

［6］ ZAHARIA M，CHOWDHURY M，F(xiàn)RANKLIN M J，et al.Spark：cluster computing with working sets［R／OL］.2010［2014－08－31］.http：／／www.eecs.berkeley.edu／Pubs／TecRpts／2010／EECS－2010－53.pdf.

［7］ Cloudera Impala.http：／／impala.io.

［8］ Apache HBase.http：／／hbase.apache.org.

［9］ SHVACHKO K，KUANG H，RADIA S，et al.The hadoop distributed file system［C］／／Mass Storage Systems and Technologies（MSST），2010 IEEE26th Symposium on.IEEE，2010：1－10.

［10］ SHAFER J，RIXNER S，COX A L.The hadoop distributed filesystem：Balancing portability and performance［C］／／Performance Analysis of Systems ＆Software（ISPASS），2010 IEEE International Symposium on.IEEE，2010：122－133.

［11］ BORTHAKUR D.The hadoop distributed file system：Architecture and design［EB／OL］.Hadoop Project Website.2007－11－21［2014－08－30］.http：／／hadoop.apache.org／core.

［12］ ENGLE C，LUPHER A，XIN R，et al.Shark：fast data analysis using coarse－grained distributed memory［C］.SIGMOD，2012：689－692.

［13］ HE Y Q，LEE R B，HUAI Y，et al.RCFile：A fast and space－efficient data placement structure in MapReducebased warehouse systems［C］.ICDE，2011：1199－1208.