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

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

0 引 言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 相關(guān)工作

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

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

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

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

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

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

1.2 分布式SQL查詢引擎

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

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

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

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

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

2.1 平臺上下文分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 平臺技術(shù)方案設(shè)計

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

3.1 技術(shù)選型約束

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

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

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

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

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

3.2 選型方案設(shè)計

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

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

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

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

（1）文件存儲方案

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

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

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

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

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

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

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

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

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

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

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

4 平臺實現(xiàn)與性能優(yōu)化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 總 結(jié)

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