面向大數據處理的Hadoop與MongoDB整合技術研究

曾　強　繆　力　秦　拯

(湖南大學信息科學與工程學院　湖南 長沙 410086)

?

面向大數據處理的Hadoop與MongoDB整合技術研究

曾強繆力秦拯

(湖南大學信息科學與工程學院湖南 長沙 410086)

摘要隨著數據種類的增多和數據規(guī)模的增大，NoSQL技術與MapReduce并行處理思想越來越受到重視。MongoDB作為NoSQL數據庫的典型代表，支持對海量數據進行索引和查詢，但MongoDB提供的MapReduce還不能滿足復雜的數據分析和計算。而Hadoop雖然提供了強大的MapReduce并行計算框架,卻在實時服務方面存在較高延時。針對這種情況，綜合考慮擴展性,數據本地化，I/O性能等因素，提出并實現Hadoop與MongoDB四種不同的整合方案。通過設計三種具有代表性的應用作為性能的測量基準，對不同的整合方案進行性能對比實驗，得出不同應用場景下的最優(yōu)整合方案。實驗表明，在MongoDB與Hadoop的折衷使用過程中，若對不同的應用采用合理的方案，性能最多可以提高3倍。

關鍵詞整合MongoDBHadoop大數據

ON MONGODB AND HADOOP INTEGRATION TECHNOLOGY FOR BIG DATA PROCESSING

Zeng QiangMiao LiQin Zheng

(College of Computer Science and Electronic Engineering,Hunan University,Changsha 410086,Hunan,China)

AbstractWith the exponential growth in data variety and data volumes, NoSQL technology and MapReduce for scalable parallel analysis have garnered a lot of attentions. MongoDB, as a typical representative of NoSQL database, supports both scalable index and flexible query for massive data, but the MapReduce provided by MongoDB cannot meet the need of complex data analysis and computation. While Hadoop offers a powerful MapReduce framework for parallel computing, it performs high latency in real-time services. In view of this, we propose and implement four different integration schemes of Hadoop and MongoDB by considering comprehensively the factors of scalability, data locality and I/O performance. The optimal integration schemes under different scenarios are derived by designing three kinds of representative applications as the measuring benchmarks of performances and by performance contrastive experiments on different integration schemes. Experiments show that in the process of trade-off use of MongoDB and Hadoop, if reasonable integration schemes are applied to different applications, the performance can be improved up to 3 times.

KeywordsIntegrationMongoDBHadoopBig data

0引言

隨著互聯網的發(fā)展和科技的進步，不論企業(yè)，政府，科研機構還是個人，所產生的數據量越來越大。面對種類繁多的半結構化和非結構化海量數據，顯然，傳統(tǒng)的數據分析和存儲技術已力不從心。在大數據時代的背景下，海量數據的存儲和分析計算技術應運而生。對于海量數據的處理，應包括三個部分：存儲、計算和查詢。而要同時實現存儲和計算的可擴展性以及查詢的高效性成為大數據處理面臨的一個挑戰(zhàn)。

現今涌現出的很多云計算和云存儲技術在不同程度上滿足了大數據的處理要求。MapReduce[1]框架的提出，將龐大的計算任務分布在成千上萬的廉價的無共享低端服務器上并行運行，從而大大提高了運行效率，Hadoop[2,3]作為MapReduce的一個開源實現，具有良好的擴展性和容錯性，并在Facebook、Yahoo等公司得到了廣泛的應用。Hadoop的設計初衷是針對大規(guī)模數據的批量處理，需要對整個數據集進行掃描，也因此Hadoop對于小范圍內查詢、實時插入等服務存在較高延時。而NoSQL[4]數據庫的誕生，打破了傳統(tǒng)數據庫的關系型數據模式，能夠以鍵值對的形式輕松處理和存儲半結構化海量數據，在滿足分布式存儲和高可擴展性的前提下，還支持索引的建立，因而能夠實現對數據的快速定位和高性能查詢。在眾多的NoSQL數據庫中，像DynamoDB[5]、MongoDB[6,7]、BigTable[8]和Cassandra[9]專門針對大數據存儲而設計，通過橫向擴展的方式將服務部署在廉價的服務器上，相比傳統(tǒng)數據庫通過硬件升級的方式提高數據庫性能和存儲能力，大大節(jié)約了成本。由于MapReduce的流行，NoSQL數據庫也紛紛引入MapReduce模型作為其聚合計算強有力的一個工具，其中的典型代表是MongoDB，MongoDB通過內置的MapReduce處理一些簡單的聚合計算，但還不能滿足較為復雜的數據分析。因此，結合MongoDB強大的存儲能力和Hadoop MapReduce分析計算能力，搭建一個高可用、高性能的云計算和云存儲平臺成為本文的一個研究重點。

關于單方面評估和提高MapReduce和MongoDB性能的研究有很多[10-14]，而關于MongoDB與MapReduce的整合應用的研究相對較少。文獻[15]通過搭建MongoDB集群對網絡日志進行分析，對于網絡日志的聚合計算采用的是MongoDB內置的MapReduce，由于MongoDB內置MapReduce采用JavaScript編寫且采用SpiderMonkey[16]引擎，與Hadoop MapReduce相比存在性能低下的問題[17]。文獻[18]描述了MongoDB中MapReduce算法如何提高大數據的處理效率，但并沒有提供量化的結果。本文通過MongoDB服務器和Hadoop計算節(jié)點重疊部署的方式實現數據本地化，在實現Hadoop與MongoDB的整合應用的基礎上，通過配置不同的整合方案來應對不同應用的數據處理，并通過實驗對比的方式對二者在不同方案下的性能進行評估和分析，得出Hadoop與MongoDB在不同應用下的折衷使用策略和最優(yōu)整合方案。

1基于MongoDB和Hadoop的整合方案

1.1Hadoop

Hadoop MapReduce直接誕生于搜索領域，能夠將龐大的計算量分布到集群的各個節(jié)點進行并行處理。它主要由兩部分組成:編程模型和運行時環(huán)境。其中編程模型為用戶提供了可編程組件，分別是InputFormat、Mapper、Partitioner、Reducer和OutputFormat，運行時環(huán)境則將用戶MapReduce程序部署到集群的各個節(jié)點上，并通過各種機制保證其成功運行。Hadoop MapReduce處理的數據位于底層分布式文件系統(tǒng)HDFS，HDFS將用戶的文件切分成若干個固定大小的Block存儲到不同節(jié)點上，并且不同節(jié)點上保存同一Block的多個副本以實現容錯。Mapreduce的執(zhí)行過程分為分為兩個階段:Map和Reduce，每個Map任務以key-value鍵值對的形式，從分布式文件系統(tǒng)HDFS中讀取相關的數據，再經過用戶定義的Map程序，并將產生的結果合并排序，生成新的key-value鍵值對，將其保存到本地磁盤等待Reduce的讀取。Reduce任務主要根據鍵值從Map讀取其產生的中間結果，合并排序后交由用戶定義的Reduce程序，最后將產生的結果保存至HDFS文件系統(tǒng)中。

1.2MongoDB

MongoDB是10gen公司開發(fā)的一個高性能，開源，無模式的文檔型數據庫，他是最像傳統(tǒng)關系型數據庫的NoSQL數據庫，實現了關系數據庫的很多特點，比如排序、二級索引、范圍查詢、MongoDB是面向文檔型的數據庫，其中每個文檔(Document)相當于關系型數據庫中的一條記錄，每個集合(Collection)對應于關系型數據庫中的一張表，每個文檔中的數據是以key-value對的形式自由組織，他支持的數據結構非常松散，是類似Json的Bson格式，因此可以存儲比較復雜的數據類型。圖1展示了MongoDB的數據組織結構。

圖1　MongoDB數據組織結構

同時Mongodb也是一個基于分布式存儲的數據庫。MongoDB本身實現的自動分片機制能夠將大數據集平均分配到多個節(jié)點存儲。在實際的開發(fā)當中，一個簡單的分片集群由三部分組成:分片、配置服務器、路由服務器。其中分片存儲了實際的數據，這些數據以固定大小的數據塊(Chunck)組織，每個分片都是一個副本集，副本集是自帶故障轉移功能的主從復制。客戶端訪問路由節(jié)點來進行數據讀寫，配置服務器保存了兩個映射關系，一個是鍵值的區(qū)間對應哪一個Chunk的映射關系，另一個是Chunk存在哪一個分片節(jié)點的映射關系。路由節(jié)點通過配置服務器獲取數據信息，通過這些信息，找到真正存放數據的分片節(jié)點進行對應操作，路由節(jié)點還會在寫操作時判斷當前Chunk是否超出限定大小。如果超出，就分列成兩個Chunk、Mongodb分片集群結構如圖2所示。

圖2　MongoDB簡單分片集群

1.3整合框架

Hadoop擅長對海量數據進行分析計算，MongoDB主要用于大數據的分布式存儲和查詢。通過二者的整合可以同時滿足海量數據的查詢，存儲和計算要求。具體整合框架如圖3所示。

圖3　整合框架Mongo-Hadoop

對于MongoDB和Hadoop的整合用到了中間件:MongoDB Hadoop Connector、MongoDB Hadoop Connector是10gen公司提供的一個免費的開源插件，該插件的作用是將MongoDB代替Hadoop HDFS作為Hadoop MapReduce的數據源，在分布式集群中，集合被分割成固定大小的塊(64 MB)存儲在MongoDB分片上，Hadoop Mappers通過路由節(jié)點并行讀取塊并解析數據，再通過Reducer合并將結果回寫到MongoDB。在整個數據處理過程中，Hadoop HDFS并沒有參與進來，為提高Hadoop與MongoDB二者整合的靈活性以及對數據處理的高效性。本文針對Mogodb Hadoop Connector做了一些改進和擴展:在該Connector中添加InputFormat和OutputFormat兩個類。允許HDFS、MongoDB作為Hadoop MapReduce的可選輸入源或輸出目標。

從圖3可以看出，基于Hadoop和MongoDB的整合框架Mongo-Hadoop由三部分組成:

Storage System:該部分包括HDFS和MongoDB，用于海量數據存儲，其中MonogDB可對數據進行索引和查詢。

Mongo-hadoop-connector:該Connector主要包括四個類，其中InputFormat、OutputFormat負責HDFS中數據的讀取與寫入，MongoInput Format、Mongo Output Format負責MongoDB中數據的讀取與寫入。對MongoDB與Hadoop的整合可通過配置的方式提供四種方案:

方案一從HDFS讀數據，將計算結果寫入HDFS。

方案二從HDFS讀數據，將計算結果寫入MongoDB。

方案三從MongoDB讀數據，將計算結果寫入HDFS。

方案四從MongoDB讀數據，將計算結果寫入MongoDB。

Hadoop MapReduce Framework:該部分用于對MongoDB或HDFS中數據的并行分析計算。

Hadoop MapReduce與底層存儲系統(tǒng)的交互只包含讀取數據和寫入數據。因此本文從以下三種應用場合對不同的方案進行了性能評估和測試:

Read = Write,讀寫大致相等。

Read>>Write,讀遠遠大于寫。

Read<

1.4集群部署策略

整合MongoDB與Hadoop應對大規(guī)模數據的查詢和分析計算，集群部署顯得尤為重要。本文主要從兩個角度出發(fā)實現對Mongo-Hadoop集群的部署:

(1) MongoDB分片讀寫分離。MongoDB分片讀寫分離通過副本集來實現，在MongoDB集群中一個副本集一般包括3臺機器，其中一臺作主服務器，默認承擔數據的全部讀寫操作。另外兩臺作為從服務器，從服務器在后臺實現對主服務器數據的同步，作為主服務器的備份。在本文中，為簡單起見，在一個副本集中只設計了兩臺機器，一臺主服務器，一臺從服務器。通過參數設置，主服務器只承擔寫操作，而讀則優(yōu)先選擇從服務器，用以分擔主服務器高強度的寫壓力。

(2) 數據本地化。實現數據本地化是MapReduce框架設計的一個核心部分。數據本地化的思想是將數據塊放置在計算節(jié)點的本地磁盤上，因而在需要對數據進行計算時實現對數據的本地獲取，避免由于網絡傳輸造成的性能下降。在本文實現的Mongo-Hadoop集群中，數據本地化的實現是通過Hadoop TaskTrackers和DataNodes與MongoDB分片服務器的重疊部署來實現。但需要注意的是要同時實現數據本地化和MongoDB分片讀寫分離，必須將Hadoop TaskTrackers和DataNodes部署在MongoDB分片的從節(jié)點上。這樣MapReduce可以從本地MongoDB從節(jié)點讀取數據，數據經處理后再寫入MongoDB主服務器。

2實驗

2.1實驗數據與實驗基準

本文采用的實驗測試數據為某國歷年航班數據[19]，該數據每條記錄擁有29個屬性包括起飛時間、起飛地點、目的地、到達時間、航班號等。在MongoDB中每條記錄約500個字節(jié)。在Mongo-Hadoop中，通過對航班數據進行三種具有代表性的應用來模擬不同的場景:1 Filter,統(tǒng)計各個地方某一時間段的航班總數,該操作對數據集進行統(tǒng)計,得到結果遠遠小于輸入,用來模擬Read >> Write的應用場景。2 Recorder,將航班數據中年月日的分隔符“,”改為“-”,如“2000,12,05”改為“2000-12-05”,其余數據保持不變,用來模擬Read==Write的應用場景。3 Merge,每條記錄添加一個備注屬性,該屬性的值為一個隨機字符串,大小為1000字節(jié),用來模擬Read << Write的應用場景。

2.2實驗配置

實驗中使用的節(jié)點配置為Pentium(R) Duo-Core CPU T6300,內存4 GB,硬盤30 GB,而運行的操作系統(tǒng)為Ubuntu 12.04.2 LTS(64位)。節(jié)點間通過快速以太網相連。HDFS采用默認配置,塊大小設置為64 MB,副本因數設置為2。實驗采用的總節(jié)點數為19,其中包括NameNode,路由器,配置服務器各1個,Hadoop DataNode與TaskTrack與MongoDB分片重疊部署的節(jié)點有8個,MongoDB分片從節(jié)點8個。

2.3實驗結果與分析

2.3.1數據加載與導出性能

圖4、圖5中可以看出HDFS數據加載與導出性能要明顯優(yōu)于MongoDB,導致該性能差異的原因為,HDFS不需要讀取數據,然后進行解析,再進行序列化以數據庫內部格式存入磁盤,數據的加載與導出操作僅僅是文件的復制或移動。HDFS數據的導入導出性能與數據的大小大致呈正比,基本上穩(wěn)定在25 000條記錄/秒左右,而MongoDB的數據導入導出性能則隨著數據集的增大,其導入導出速率都有所下降,導入速率表現得尤為明顯,當數據為兩百萬的時候其速率為8620條記錄/秒,隨著數據集增大到800萬時,其速率下降到3532條記錄/秒,其原因為MongoDB對數據的存儲采用內存映射機制,當數據量增大,內存占用過大,數據導致導入導出速率下降。

圖4　HDFS、MongoDB加載不同記錄數量耗時對比　　　圖5　HDFS、MongoDB導出不同記錄數量耗時對比

2.3.2不同應用在不同整合方案下的性能對比分析

圖6展示了當輸入遠大于輸出時(約1萬∶1)數據的處理情況,如圖可知,處理400萬條記錄時,方案一比方案四快了0.3倍,而當記錄達到3200萬條時,快了0.6倍,隨著記錄的增大,該差距也逐漸增大。方案三與方案一相比,只是數據的輸入源不同,后者比前者平均快了0.4倍,因此可以判斷,從MongoDB讀取數據要比從HDFS中讀取數據開銷大。對于方案一與方案二以及方案三與方案四,其性能相差很小,原因是輸出數據非常小,數據寫入位置對性能造成的影響極小。

圖7展示了當輸入等于輸出的數據處理情況,其中在不同數據集下方案一比方案四快了1.1到2.7倍,比方案二快了0.9到2.3倍,而相比方案三只快了0.16到0.3倍,與圖6不同,在同樣的輸入下輸出結果的寫入位置對性能造成較大的影響,因此對同樣的數據集作同樣的處理但在不同的Mongo-Hadoop整合方案下,方案三在性能上最為接近方案一。

圖8展示了寫密集型的作業(yè),輸出為輸入的四倍。從圖中可以看出,數據的寫入位置對性能起了決定性的作用,將數據寫入到HDFS比將數據寫入到MongoDB整體性能平均將近快了5倍。因此,相比HDFS來說將數據寫入MongoDB開銷非常大。

在圖9中,由于3種不同類型的操作是對同一數據集作不同的處理,因此圖中顯示讀取數據集所花費的時間也一樣。而數據處理所花費的時間只占整個開銷中很小的一部分,因此寫是引起性能差異的主要因素。對比Filter操作和Merge操作,處理1600萬條數據,采用方案四,讀密集型作業(yè)比寫密集型作業(yè)在性能上高出了11倍。而采用方案三,在性能上則只高出3.3倍。在Recorder操作中,將數據寫入MongoDB的開銷是寫入HDFS的4倍,在Merge操作中達到了6.2倍。

圖9中的方案一表示從HDFS讀/寫入HDFS,方案二表示從HDFS讀/寫入MongoDB,方案三表示從MongoDB讀/寫入HDFS,方案四表示從MongoDB讀/寫入MongoDB。

2.3.3不同整合方案配置下的可擴展性測試

從圖10可以看出,當集群規(guī)模從4核擴展到8核時,方案一、方案二、方案三、方案四在整體性能上分別提高了94%、77%、99%、89%,從圖中可以明顯看出,各個方案下的讀寫時間和處理時間都接近減半。而從8核擴展到16核時,各方案下的性能分別只提高了59%、14%、55%、15%,其中數據寫入MongoDB的性能僅僅提高10%~15%,而從MongoDB讀取數據的性能提高55%~60%。集群規(guī)模為4核時,對1600萬條數據作不同的處理,通過對CPU和內存的監(jiān)控發(fā)現,其利用率都達到了90%~98%,如前所述,Mongo-Hadoop采用的是Hadoop TaskTracker、DataNode與MongoDB服務器重疊部署的方式來實現,因而在CPU和內存緊張的情況下,容易形成彼此之間對內存和CPU的競爭,從而使性能降低,當集群擴展到8核時,內存和CPU的利用率下降到55%~60%,因而緩解了CPU和內存的制約,性能獲得非常大的提高,由此可知對于內存和CPU的占用率過大造成的性能損失,Mongo-Hadoop可以很容易地通過橫向擴展添加節(jié)點的方式來彌補。集群規(guī)模從8核擴展到16核,從上面分析得知其性能提高得相對較少,原因是充足CPU和內存對性能的制約大大減少。在CPU和內存充足的情況下,方案四通過擴大集群規(guī)模能夠顯著減少讀取時間,其原因是隨著集群規(guī)模的增大,擁有更多的Map并發(fā)讀取本地MongoDB中的數據。而對于寫的情況,發(fā)生在Reduce階段,雖然擴大集群規(guī)模同樣能過增加Reduce的并發(fā)數,但是將數據分發(fā)到MongoDB各個分片服務器占用了很大的開銷,因此寫性能的提高相對很少。

圖10中的方案一表示從HDFS讀/寫入HDFS,方案二表示從HDFS讀/寫入MongoDB,方案三表示從MongoDB讀/寫入HDFS,方案四表示從MongoDB讀/寫入MongoDB。

圖10　Mongo-Hadoop進行Recorder操作的可擴展性測試

2.3.4整合方案的折衷使用

由上分析可知,將MongoDB代替HDFS成為數據的輸入源和輸出目標,都會引起讀寫性能的下降,而寫表現得最為明顯。在CPU和內存充足的情況下,通過橫向擴展的方式可以顯著提高數據的讀取性能,但對于寫性能的提高相對很少。由前面實驗推導,在利用Mongo-Hadoop對數據進行處理時,可得出以下結論:若采用方案一,對MongoDB中的數據進行處理時,必須先將數據導出到本地,然后再上傳到HDFS,經Hadoop處理后,再將結果從HDFS導入到MongoDB,這樣,數據的導入導出將引起巨大的開銷,因此該方案下對MongoDB中的數據作處理性能最低。若采用方案二,對于非MongoDB中的數據,或該數據集已存在于HDFS,需要對該數據進行讀密集型操作且數據處理結果需要靈活查詢時,該配置提供了最優(yōu)性能,原因是數據導入HDFS性能比MongoDB快了4~5倍,且Mongo-Hadoop從HDFS讀取數據要優(yōu)于從MongoDB讀取數據。若采用方案三,對于已經存在于MongoDB中的數據進行寫密集型操作,且結果集需要MapReduce作后續(xù)處理時,該方案提供了最優(yōu)性能。原因是將相對較大的結果集直接寫入MongoDB帶來的開銷巨大。若采用方案四,對于已經存在于MongoDB中的數據,需要對數據進行統(tǒng)計和聚合計算且對結果集進行靈活查詢時,該方案提供了最優(yōu)性能。其原因是對于讀密集型操作,Mongo-Hadoop具備良好的擴展性,能夠快捷讀取MongoDB分片中的數據經MapReduce處理后將相對較小的結果集輕松寫回到MongoDB。

3結語

整合MongoDB與Hadoop應對大型數據集的處理,使得MongoDB可以利用Hadoop MapRecue對自身數據進行復雜的分析計算,同時MongoDB可以對結果進行檢索和查詢。將MongoDB代替Hadoop HDFS作為Hadoop MapReduce的數據輸入源和輸出目標,針對不同的應用,其性能都會有所下降,對于讀密集型的操作,MongoDB作為數據源的性能略低于HDFS,其性能大致相當,但對于寫密集型作業(yè),其性能差異表現得非常明顯。針對此種情況,本文將HDFS,MongoDB配置成Hadoop MapReduce的可選輸入源和輸出目標,對不同的應用可以通過靈活配置來獲取最優(yōu)性能。

參考文獻

[1] Dean J,Ghemawat S.MapReduce:simplified data processing on large clusters[J].CACM,2008,51(1):107-113.

[2] Apache Hadoop[EB/OL].(2014-06-30).http://hadoop.apache.org.

[3] White T.Hadoop:the Definitive Guide[M].California:O’Reilly Media,2012.

[4] Pokorny J.Nosql databases:a step to database scalability in web environment[J].International Journal of Web Information Systems,2013,9(1):69-82.

[5] Amazon DynamoDB[EB/OL].http://aws.amazon.com/dynamodb/.

[6] MongoDB[EB/OL].http://www.mongodb.org.

[7] Plugge E,Hawkins T,Membrey P.The Definitive Guide to MongoDB:the NoSQL Database for Cloud and Desktop Computing[M].Berkely,CA,USA:Apress,2010.

[8] Chang F,Dean J,Ghemawat S,et al.Bigtable:A distributed storage system for structured data[J].ACM Transactions on Computer Systems,2008,26(2):4.

[9] Dede E,Sendir B,Kuzlu P,et al.An evaluation of Cassandra for Hadoop[C]//Cloud Computing (CLOUD),2013 IEEE Sixth International Conference on. IEEE,2013:494-501.

[10] Fadika Z,Dede E,Govindaraju M,et al.Benchmarking MapReduce implementations for application usage scenarios[C]//Grid Computing (GRID),2011 12th IEEE/ACM International Conference on.IEEE,2011:90-97.

[11] Liu Yimeng,Wang Yizhi,Jin Yi.Research on the improvement of MongoDB auto-sharding in cloud environment[C]//Computer Science & Education (ICCSE),2012 7th International Conference on.IEEE,2012:851-854.

[12] Fadika Z,Dede E,Hartog J,et al.MARLA:MapReduce for heterogeneous clusters[C]//Cluster,Cloud and Grid Computing (CCGrid),2012 12th IEEE/ACM International Symposium on.IEEE,2012:49-56.

[13] Fadika Z,Govindaraju M.DELMA:dynamically elastic MapReduce framework for CPU-intensive applications.Cluster[C]//Cloud and Grid Computing (CCGrid),2011 11th IEEE/ACM International Symposium on.IEEE,2011:454-463.

[14] Fadika Z,Govindaraju M,Canon R,et al.Evaluating Hadoop for data-intensive scientific operations[C]//Cloud Computing (CLOUD),2012 IEEE 5th International Conference on.IEEE,2012:67-74.

[15] Wei Jianwen,Zhao Yusu,Jiang Kaida,et al.Analysis farm:a cloud-based scalable aggregation and query platform for network log analysis[C]//Cloud and Service Computing (CSC),2011 International Conference on.IEEE,2011:354-359.

[16] SpiderMonkey[EB/OL].https://developer.mozilla.org/en/SpiderMonkey.

[17] Dede E,Govindaraju M,Gunter D,et al.Performance evaluation of a MongoDB and Hadoop platform for scientific data analysis[C]//Proceedings of the 4th ACM workshop on Scientific cloud computing,2013:13-20.

[18] Bonnet L,Laurent A,Sala M,et al.Reduce,you say:what NoSQL can do for data aggregation and BI in large repositories[C]//Database and Expert Systems Applications (DEXA),2011 22nd International Workshop on.IEEE,2011:483-488.

[19] Hacking Airline DataSet with H2O[EB/OL].(2013-04-12).https://github.com/0xdata/po/wiki/Hacking-Airline-DataSet-with-H2O.

中圖分類號TP311.5

文獻標識碼A

DOI:10.3969/j.issn.1000-386x.2016.02.005

收稿日期：2014-06-20。國家自然科學基金項目(61272546)。曾強，碩士生，主研領域：分布式，云計算?？娏Γ苯淌?。秦拯，教授。