基于海量數(shù)據(jù)的HBase寫入性能測(cè)試與優(yōu)化

青欣 文偉軍 金星 姜鎮(zhèn)

摘要：HBase解決了大規(guī)模數(shù)據(jù)的結(jié)構(gòu)化存儲(chǔ)和實(shí)時(shí)的隨機(jī)讀寫訪問，但HBase提供的API在大規(guī)模數(shù)據(jù)批量寫入等方面存在著性能瓶頸，不能很好地滿足應(yīng)用需求。本文提出了基于MapReduce架構(gòu)實(shí)現(xiàn)HBase的性能優(yōu)化方案，并設(shè)計(jì)了分布式程序進(jìn)行驗(yàn)證，實(shí)驗(yàn)表明在海量數(shù)據(jù)應(yīng)用條件下采用MapReduce計(jì)算框架能夠利用HBase集群的計(jì)算性能，相比傳統(tǒng)的單線程和多線程數(shù)據(jù)寫入方式具有更好的實(shí)用性和有效性，同時(shí)結(jié)合這三類數(shù)據(jù)寫入方式的性能特征提出了以寫入數(shù)據(jù)量為依據(jù)的選擇策略。

關(guān)鍵詞：MapReduce，Hadoop，HBase，海量數(shù)據(jù)

中圖分類號(hào)：TP392 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044（2019）06-0009-05

Testing and optimization of HBase writing performance based on massive data

QING Xin1，， WEN Wei-jun1， JIN Xing1， JIANG Zhen1

（75837 Troops， Guangzhou 510000， China）

Abstract： HBase solves the structured storage of massive data and real-time random read and write access. But， There is a performance bottleneck of HBase API in large scale data batch write， and it cannot meet the demands of application. This paper realized performance optimization of HBase based on MapReduce architecture， and designs the distributed programs. The Experiments show that in the massive data application condition， MapReduce can take the advantage of the calculating capacity of HBase cluster， and more practical and effective than traditional single thread and multi-thread data writing method. Combined with The performance characteristics of the three types of data write mode， this paper proposed a selection policy based on data amount.

Key words： MapReduce； Hadoop； HBase； massive data

云計(jì)算[1][2]實(shí)際是以商業(yè)應(yīng)用為背景結(jié)合了之前學(xué)術(shù)界所提到的如“網(wǎng)格計(jì)算”、“互聯(lián)網(wǎng)計(jì)算”、“按需計(jì)算”等概念發(fā)展而來的一種分布式計(jì)算模式，也正是因?yàn)槠湟陨虡I(yè)應(yīng)用為依托，云計(jì)算在近幾年提到了快速的發(fā)展。云計(jì)算因其實(shí)用價(jià)值在工業(yè)界和學(xué)術(shù)界得到了一致的認(rèn)可。作為一種全新的應(yīng)用模式，云計(jì)算已成為人們提供服務(wù)、存儲(chǔ)數(shù)據(jù)、進(jìn)行數(shù)據(jù)挖掘等應(yīng)用和研究的主要方式。

云數(shù)據(jù)庫(kù)HBase[3][4][17]是Hadoop[5]的Apache頂層項(xiàng)目，它是BigTable[6]的開源實(shí)現(xiàn)。作者在實(shí)驗(yàn)室搭建了一個(gè)基于HBase的數(shù)據(jù)注冊(cè)和發(fā)布的管理平臺(tái)，在應(yīng)用中發(fā)現(xiàn)HBase在海量數(shù)據(jù)的寫入時(shí)，由于HBase提供的API接口是單線程操作，不能有效的利用HBase集群的計(jì)算資源，不能滿足平臺(tái)的性能要求。

本文結(jié)合實(shí)際問題，為了能提高HBase數(shù)據(jù)管理系統(tǒng)的效率，特別是在海量數(shù)據(jù)條件下的寫入性能，采用MapReduce[7]編程模型與HBase相結(jié)合的方法進(jìn)行性能優(yōu)化，并進(jìn)行了讀寫性能的測(cè)試。實(shí)驗(yàn)結(jié)果表明，MapReduce計(jì)算模型充分利用HBase集群中各個(gè)節(jié)點(diǎn)的計(jì)算資源， HBase的數(shù)據(jù)寫入性能得到了極大的提高。

1 相關(guān)知識(shí)

1.1 MapReduce編程模型

MapReduce是Google提出的在分布式集群中并行處理少量數(shù)據(jù)的編程模型，把在大規(guī)模的數(shù)據(jù)集的操作分發(fā)給主節(jié)點(diǎn)管理下的集群中的各個(gè)資源節(jié)點(diǎn)來完成，極大地簡(jiǎn)化了分布式程序的結(jié)構(gòu)和編寫。MapReduce執(zhí)行一個(gè)任務(wù)的過程可以分解為Job的分解和結(jié)果的匯總，這處理過程被MapReduce抽象為兩個(gè)函數(shù)：map和reduce，map負(fù)責(zé)把任務(wù)分解成多個(gè)任務(wù)，reduce負(fù)責(zé)把分解后多任務(wù)處理的結(jié)果進(jìn)行匯總，圖1顯示了MapReduce任務(wù)邏輯過程[8]。

從圖中可以看出整個(gè)計(jì)算模型的核心部分是Map（）和Reduce（），這兩個(gè)函數(shù)的具體功能和操作是由用戶根據(jù)需求自己來設(shè)計(jì)實(shí)現(xiàn)，只要能按用戶自定義的規(guī)則，將輸入的對(duì)轉(zhuǎn)換成另一個(gè)或一批對(duì)輸出。

在Map階段，MapReduce框架首先將輸入的數(shù)據(jù)分割成大小固定的數(shù)據(jù)塊（Splits），隨后將每個(gè)Split分解為一批鍵值對(duì)作為Map（）的輸入，經(jīng)過處理計(jì)算得到中間結(jié)果，再按照key2進(jìn)行排序，并把具有相同key值的value集中形成一個(gè)新列表，形成作為Reduce（）的輸入數(shù)據(jù)。

在Reduce階段，Reduce（）以為輸入數(shù)據(jù)，按照用戶自定義的操作進(jìn)行計(jì)算，得到最終的結(jié)果并輸出。

可以看出MapReduce計(jì)算過程充分地利用了分布式集群資源，使整個(gè)集群的計(jì)算具有了更高的效率。HBase是目前比較流行的云數(shù)據(jù)管理平臺(tái)，具有分布式特性，那么利用MapReduce來進(jìn)行性能優(yōu)化是一個(gè)有效的選擇。

1.2 HBase云數(shù)據(jù)庫(kù)

HBase是基于HDFS的開源數(shù)據(jù)庫(kù)，它以Google的BigTable為原型，設(shè)計(jì)并實(shí)現(xiàn)了具有高可靠性、高性能、列存儲(chǔ)、可伸縮、實(shí)時(shí)讀寫的數(shù)據(jù)庫(kù)系統(tǒng)，用于存儲(chǔ)粗粒度的結(jié)構(gòu)化數(shù)據(jù)。HBase以表的形式存儲(chǔ)數(shù)據(jù)，每個(gè)表由行和列組成，每個(gè)列屬于一個(gè)特定的列族（Column Family）。表中由行和列確定的存儲(chǔ)單元稱為一個(gè)元素（Cell），每個(gè)元素保存了同一份數(shù)據(jù)的多個(gè)版本，由時(shí)間戳（Time Stamp）來標(biāo)識(shí)，在邏輯上HBase是一張超大規(guī)模的稀疏表，如表1所示。

行鍵是數(shù)據(jù)行在表中的唯一標(biāo)識(shí)，并作為檢索記錄的主鍵。在HBase中訪問表中的行只有三種方式：通過單個(gè)行鍵訪問、給定行鍵的范圍訪問和全表掃描。行鍵可以是任意字符串（最大長(zhǎng)度64KB）[6]，并按照字典序進(jìn)行存儲(chǔ)。

HBase是按照列存儲(chǔ)的稀疏行/列矩陣，在物理存儲(chǔ)中就是把邏輯模型中的一個(gè)行進(jìn)行分割，并按照列族存儲(chǔ)，同時(shí)表中的空值不會(huì)被存儲(chǔ)。每個(gè)表被建立的時(shí)候都只有一個(gè)Region（HBase存儲(chǔ)的單元），隨著表中的記錄數(shù)不斷增加直到數(shù)據(jù)量超過Region定義的閾值時(shí)，Region就會(huì)被分割形成兩個(gè)新的Region，每個(gè)Region存儲(chǔ)大表中某個(gè)行范圍的數(shù)據(jù)。所以當(dāng)數(shù)據(jù)記錄不斷增加后，整個(gè)表將會(huì)由多個(gè)Region組成，而Region作為HBase分布式存儲(chǔ)的最小單位，將會(huì)被分配到集群中各個(gè)Region服務(wù)器上，以達(dá)到負(fù)載均衡的目的。每個(gè)Region由一個(gè)或多個(gè)Store組成，每個(gè)Store保存一個(gè)列族的所有數(shù)據(jù)。每個(gè)Store又是由一個(gè)memStore和零個(gè)或多個(gè)StoreFile組成，StoreFile則是以HFile的格式存儲(chǔ)在HDFS上的，如圖2所示。

可以看到，HBase是以Region作為最小的單位實(shí)現(xiàn)負(fù)載均衡，多個(gè)Regions分配到集群中的各個(gè)資源節(jié)點(diǎn)從而使數(shù)據(jù)達(dá)到分布式存儲(chǔ)的目的。并且在Region內(nèi)部也是采用了分塊存儲(chǔ)的機(jī)制。那么，這種存儲(chǔ)機(jī)制對(duì)于MapReduce的應(yīng)用起到了很好的支撐作用，并且MapReduce能夠識(shí)別每個(gè)Region的存儲(chǔ)節(jié)點(diǎn)，從而把該Region的計(jì)算任務(wù)分配它存儲(chǔ)的節(jié)點(diǎn)，達(dá)到了移到計(jì)算而不移動(dòng)數(shù)據(jù)的目的，經(jīng)證明這種方式能最大程度的利用集群性能和節(jié)約開銷。

2 HBase寫入性能測(cè)試與優(yōu)化

HBase數(shù)據(jù)寫入功能可以分為單數(shù)據(jù)寫入和批量數(shù)據(jù)導(dǎo)入，其運(yùn)用場(chǎng)景分別為數(shù)據(jù)注冊(cè)和發(fā)布的管理平臺(tái)中普通用戶數(shù)據(jù)發(fā)布與注冊(cè)、用戶注冊(cè)和數(shù)據(jù)修改等和傳統(tǒng)RDBMS向云數(shù)據(jù)庫(kù)的數(shù)據(jù)轉(zhuǎn)移以及批量數(shù)據(jù)導(dǎo)入，本文對(duì)HBase這兩種方式的性能進(jìn)行了測(cè)試。

2.1 集群結(jié)構(gòu)

首先在實(shí)驗(yàn)室搭建了HBase集群，并設(shè)計(jì)了針對(duì)性的應(yīng)用，來對(duì)比使用MapReduce前后的性能差異。

實(shí)驗(yàn)環(huán)境中共有6臺(tái)服務(wù)器，搭建完全分布式HDFS與HBase環(huán)境，采用的Hadoop與HBase版本為hadoop0.20.2[9]與HBase0.92.0[10]，其中一臺(tái)節(jié)點(diǎn)做為NameNode和Master，另一臺(tái)做為Master備份節(jié)點(diǎn)，剩余四臺(tái)則做為DataNode和RegionServer節(jié)點(diǎn)，并且在其上運(yùn)行Zookeeper服務(wù)，整個(gè)實(shí)驗(yàn)環(huán)境結(jié)構(gòu)如圖3所示。

2.2 單線程數(shù)據(jù)寫入性能

2.2.1 單個(gè)數(shù)據(jù)寫入

單個(gè)數(shù)據(jù)寫入實(shí)驗(yàn)的目的在于測(cè)試一條隨機(jī)數(shù)據(jù)的寫入性能，從而模擬用戶在使用數(shù)據(jù)注冊(cè)和發(fā)布管理平臺(tái)時(shí)的數(shù)據(jù)寫入操作，檢測(cè)HBase性能是否滿足平臺(tái)設(shè)計(jì)要求，實(shí)驗(yàn)結(jié)果如圖 4所示。

經(jīng)過測(cè)試分析單個(gè)數(shù)據(jù)寫入時(shí)間在200ms左右，可以看出測(cè)試性能完全滿足實(shí)際運(yùn)用，保證了系統(tǒng)性能良好。對(duì)其過程進(jìn)行跟蹤分析，發(fā)現(xiàn)數(shù)據(jù)寫入時(shí)間主要消耗在客戶端與HBase服務(wù)器建立數(shù)據(jù)連接，而實(shí)際的一條數(shù)據(jù)寫入時(shí)間為1至2毫秒。

2.2.2 大數(shù)據(jù)的批量導(dǎo)入

數(shù)據(jù)注冊(cè)和發(fā)布的管理平臺(tái)[15][16]除了對(duì)普通用戶提供數(shù)據(jù)訪問外，還要對(duì)外部程序或系統(tǒng)提供批量數(shù)據(jù)寫入和同步功能，實(shí)驗(yàn)測(cè)試了HBase導(dǎo)入不同規(guī)模數(shù)據(jù)所用的時(shí)間，導(dǎo)入數(shù)據(jù)為根據(jù)數(shù)據(jù)表格式隨機(jī)生成的數(shù)據(jù)，其規(guī)模從10000條到1000萬條，這樣能夠很好地測(cè)試HBase在各種條件下批量數(shù)據(jù)導(dǎo)入所需要時(shí)間。

生成數(shù)據(jù)為TXT文檔，命名為MetaData+數(shù)據(jù)量。實(shí)驗(yàn)中記錄用HBase提供的單線程API將各數(shù)據(jù)集寫入HBase所用時(shí)間，結(jié)果如表2所示。

實(shí)驗(yàn)結(jié)果表明，數(shù)據(jù)寫入時(shí)間隨著數(shù)據(jù)集增大線性增加，經(jīng)過計(jì)算，數(shù)據(jù)的寫入速度平均為600條/秒（單次數(shù)據(jù)寫入只需建立一個(gè)HBase數(shù)據(jù)連接）。如表中所示，在海量數(shù)據(jù)寫入時(shí)將需要大量時(shí)間，當(dāng)導(dǎo)入1000萬條數(shù)據(jù)時(shí)要16688秒（4小時(shí)38分鐘）。

2.2.3 結(jié)果分析

在HBase數(shù)據(jù)寫入性能實(shí)驗(yàn)中，本文就HBase提供兩種數(shù)據(jù)寫入方式的性能進(jìn)行了詳細(xì)測(cè)試。一是單個(gè)數(shù)據(jù)的寫入性能，在HBase集群中重復(fù)數(shù)據(jù)寫入操作并記錄所需時(shí)間，結(jié)果表明HBase的單個(gè)數(shù)據(jù)寫入性能非常穩(wěn)定，大約為200毫秒，能滿足分布式資源虛擬化整合平臺(tái)的性能要求。二是批量數(shù)據(jù)寫入性能，由于HBase提供的數(shù)據(jù)寫入API是單線程的，不能很好地利用HBase的集群計(jì)算資源，在海量數(shù)據(jù)條件下其性能較差，不能要求系統(tǒng)對(duì)海量數(shù)據(jù)處理的要求。

2.3 基于多線程的HBase寫入性能優(yōu)化

采用多線程對(duì)數(shù)據(jù)批量導(dǎo)入性能進(jìn)行優(yōu)化，本文主要測(cè)試了數(shù)據(jù)量和線程數(shù)量這兩個(gè)條件對(duì)性能的影響。

首先，測(cè)試在固定數(shù)據(jù)量的基礎(chǔ)上通過增加單機(jī)線程數(shù)對(duì)性能的影響，開始使用單線程，然后逐步增加線程數(shù)量，實(shí)驗(yàn)中使用MetaData1000000數(shù)據(jù)集，具體的結(jié)果如圖 5所示。

可以看出，當(dāng)保持?jǐn)?shù)據(jù)量不變時(shí)，隨著線程數(shù)量增加導(dǎo)入數(shù)據(jù)所需時(shí)間越來越少。當(dāng)線程數(shù)量為1時(shí)需要大約1800秒，當(dāng)線程數(shù)量為2時(shí)需要大約1000秒，性能提高了約80%，但是隨著線程不斷地增加性能提高的幅度起來越來越小。通過分析，實(shí)驗(yàn)所用服務(wù)器CPU為四核，那么當(dāng)線程的數(shù)量達(dá)到4以后，程序不再保證每個(gè)線程分配一個(gè)處理核心，而只能在系統(tǒng)中搶占CPU時(shí)間片來完成任務(wù)，進(jìn)程數(shù)為10時(shí)的性能提高大約為320%。實(shí)驗(yàn)表明在多核服務(wù)器中多線程方式對(duì)大規(guī)模數(shù)據(jù)批量導(dǎo)入性能具有一定的提升能力，但是受到單機(jī)計(jì)算能力的影響和限制。

其次，測(cè)試在固定線程數(shù)量條件下不同數(shù)據(jù)量的導(dǎo)入時(shí)間，由第一個(gè)實(shí)驗(yàn)可知，在大數(shù)據(jù)量的前提下多線程的性能要比單線程更好，為了全面研究多線程的適用范圍，下面實(shí)驗(yàn)測(cè)試了多線程與單線程在小數(shù)據(jù)量下的性能差異，實(shí)驗(yàn)中線程數(shù)目為5，結(jié)果如圖 6所示。

可以看出，當(dāng)數(shù)據(jù)量過小時(shí)多線程導(dǎo)入數(shù)據(jù)消耗的時(shí)間比單線程更多，這是因?yàn)槎嗑€程的初始化消耗了一定的時(shí)間，但當(dāng)程序啟動(dòng)之后多線程的導(dǎo)入速度要比單線程快，如圖中顯示隨著數(shù)據(jù)量的增加多線程的性能表現(xiàn)越來越好，當(dāng)達(dá)到約300條時(shí)兩種方式消耗的時(shí)間相等，之后多線程的效率超過了單線程。

2.4 基于MapReduce的HBase性能優(yōu)化

本節(jié)將測(cè)試運(yùn)用MapReduce對(duì)HBase的海量數(shù)據(jù)寫入性能優(yōu)化的特性，實(shí)驗(yàn)將從集群機(jī)器數(shù)和數(shù)據(jù)量這兩方面進(jìn)行分析，所用數(shù)據(jù)集要導(dǎo)入HDFS[12][13]。

首先，測(cè)試MapReduce在導(dǎo)入不同數(shù)據(jù)量的性能。實(shí)驗(yàn)時(shí)RegionServer數(shù)量為兩臺(tái)，并且每臺(tái)RegionServer運(yùn)行兩個(gè)Map任務(wù)，遞增導(dǎo)入數(shù)據(jù)的規(guī)模，并記錄所用時(shí)間，結(jié)果如表 3所示。

對(duì)表中數(shù)據(jù)進(jìn)行分析，當(dāng)數(shù)據(jù)量為10時(shí)，MapReduce程序用時(shí)約14秒，這是MapReduce程序啟動(dòng)的消耗，當(dāng)數(shù)據(jù)量增加時(shí)MapReduce程序時(shí)間隨之增加，這里MapReduce程序仍然只有一個(gè)Map在工作，但是當(dāng)數(shù)據(jù)量大于64M（MapReduce默認(rèn)處理的數(shù)據(jù)塊為64M）以后，MapReduce程序?qū)a(chǎn)生多個(gè)Map任務(wù)，從表中數(shù)據(jù)可知當(dāng)數(shù)據(jù)量為50W和100W時(shí)消耗的時(shí)間基本相同，這是因?yàn)樵趯?shí)驗(yàn)集群中默認(rèn)可以同時(shí)運(yùn)行4個(gè)Map任務(wù)，而這50W和100W數(shù)據(jù)分別運(yùn)行了2個(gè)和3個(gè)Map任務(wù)，所以整個(gè)Job的運(yùn)行時(shí)間為耗時(shí)最長(zhǎng)的Map任務(wù)所用時(shí)間。當(dāng)數(shù)據(jù)量更大時(shí)，同時(shí)運(yùn)行了4個(gè)以上Map就達(dá)到了集群的最好性能，表中可以看出1000萬數(shù)據(jù)的導(dǎo)入時(shí)間約為500W的兩倍。

實(shí)驗(yàn)中單Map任務(wù)時(shí)，HBase的導(dǎo)入速度比單線程的速度要快，這是因?yàn)椴捎肕apReduce方式時(shí)，實(shí)驗(yàn)數(shù)據(jù)已經(jīng)導(dǎo)入到HDFS中，并且根據(jù)MapReduce計(jì)算框架中Map任務(wù)分配策略（移動(dòng)計(jì)算比移動(dòng)數(shù)據(jù)更有效）確保了Map任務(wù)在數(shù)據(jù)所在服務(wù)器上進(jìn)行運(yùn)行，而單線程方式是通過客戶端方式訪問HBase提供的數(shù)據(jù)接口，數(shù)據(jù)導(dǎo)入需要通過網(wǎng)絡(luò)通信。

其次，測(cè)試不同集群機(jī)器數(shù)量對(duì)HBase性能的影響。上一個(gè)實(shí)驗(yàn)指出，在小數(shù)據(jù)規(guī)模時(shí)，由于MapReduce分布式計(jì)算在集群中啟動(dòng)非常耗時(shí)，所以不適用于小規(guī)模的數(shù)據(jù)導(dǎo)入應(yīng)用。本實(shí)驗(yàn)中增加集群機(jī)器數(shù)量，設(shè)置每臺(tái)服務(wù)器可以同時(shí)啟動(dòng)2個(gè)Map任務(wù)，測(cè)試了不同集群規(guī)模在不同數(shù)據(jù)集中的性能，實(shí)驗(yàn)結(jié)果如圖 7所示。

從圖中可以看出，集群機(jī)器越多，導(dǎo)入等量數(shù)據(jù)所用的時(shí)間越短。當(dāng)數(shù)據(jù)量越大時(shí)，這種差距越明顯。在1000萬條數(shù)據(jù)的時(shí)候，三臺(tái)機(jī)器是10分鐘左右，五臺(tái)機(jī)器是6分20秒，時(shí)間縮短了約36%。集群機(jī)器越多，能夠并行執(zhí)行Map任務(wù)的機(jī)器就越多，因此數(shù)據(jù)寫入時(shí)間就越短。

實(shí)驗(yàn)中HBase集群的寫入性能且有一種階梯式特性，這是因?yàn)镸apReduce執(zhí)行任務(wù)時(shí)，把整個(gè)Job分解成了多個(gè)Map任務(wù)執(zhí)行，并且集群同時(shí)運(yùn)行的Map數(shù)目是確定的，那么整個(gè)Job的完成須要等每一個(gè)Map任務(wù)完成，才能結(jié)束。例如，當(dāng)集群機(jī)器數(shù)量為四臺(tái)、數(shù)據(jù)量為600W時(shí)，整個(gè)Job被分解為18個(gè)Map任務(wù)，而系統(tǒng)可以同時(shí)運(yùn)行8個(gè)Map，那么運(yùn)行完16個(gè)Map之后，還剩下2個(gè)Map，其中有一個(gè)Map的數(shù)據(jù)量為64M，那么不管剩下的數(shù)據(jù)為多少，都必須與這個(gè)最慢的Map任務(wù)進(jìn)行同步，同理，當(dāng)數(shù)據(jù)量為700W時(shí)，當(dāng)運(yùn)行完16個(gè)Map之后，還剩下5個(gè)Map任務(wù)，由于集群可以同時(shí)運(yùn)行8個(gè)Map任務(wù)，那么運(yùn)行2個(gè)Map和5個(gè)Map的時(shí)間基本相同，五個(gè)Map任務(wù)同步通信更多[11]，時(shí)間會(huì)多消耗點(diǎn)。

3 結(jié)果分析

從多線程和MapReduce兩種并行處理方法出發(fā)，對(duì)HBase的海量數(shù)據(jù)批處理進(jìn)行了優(yōu)化，實(shí)驗(yàn)表明這兩種方式都能提高HBase批處理性能，但是也有各自的缺陷。

多線程方法隨著線程的增加性能呈線性提高，但是，當(dāng)線程數(shù)量大于服務(wù)器CPU內(nèi)核數(shù)量之后，其性能增加速度迅速降低，并且受到單臺(tái)計(jì)算機(jī)處理能力和網(wǎng)絡(luò)帶寬限制，多線程方法的性能提升能力有限。

MapReduce方法對(duì)于海量數(shù)據(jù)處理的優(yōu)化性能很好，因?yàn)镸apReduce程序是運(yùn)行在HBase集群上的，它充分的利用了集群的計(jì)算能力，隨著集群的擴(kuò)展MapReduce的計(jì)算能力也會(huì)提高。但是MapReduce任務(wù)的啟動(dòng)消耗非常大，并且在小規(guī)模數(shù)據(jù)時(shí)，由于并行啟動(dòng)的Map任務(wù)數(shù)據(jù)量不多，性能并沒有多線程好。假設(shè)單機(jī)多線程相比單線程的最大加速比為N，當(dāng)MapReduce處理的數(shù)據(jù)能夠同時(shí)啟動(dòng)大于N個(gè)Map任務(wù)時(shí)，采用MapReduce計(jì)算方式效率比多線程計(jì)算效率更高，結(jié)果如圖 8所示。

綜合單線程、多線程和MapReduce方法的性能，在批量數(shù)據(jù)處理任務(wù)中根據(jù)數(shù)據(jù)量大小來選擇合適的方法。當(dāng)數(shù)據(jù)量很小，約在300條以下時(shí)可以選擇單線程方法，實(shí)現(xiàn)簡(jiǎn)單而且性能也能達(dá)到要求，當(dāng)數(shù)據(jù)量較大但不夠MapReduce啟動(dòng)N（多線程最大加速比）個(gè)Map任務(wù)時(shí)建議采用多線程的方法，當(dāng)處理海量數(shù)據(jù)時(shí)，采用MapReduce方法可以最大程度利用集群的計(jì)算性能。

實(shí)驗(yàn)結(jié)果表明在實(shí)現(xiàn)分布式資源虛擬化整合平臺(tái)的過程中，必須結(jié)合系統(tǒng)功能和性能需求，合理選擇數(shù)據(jù)處理方法，這樣才能使系統(tǒng)性能達(dá)到最優(yōu)。

4 總結(jié)

本文對(duì)HBase數(shù)據(jù)寫入性能進(jìn)行詳細(xì)測(cè)試，全面了解其性能特性。通過測(cè)試找到了HBase的不足，并根據(jù)HBase數(shù)據(jù)庫(kù)存在的性能缺陷。提出了采用多線程和MapReduce計(jì)算框架的并行處理方法來提高其性能，并對(duì)實(shí)驗(yàn)結(jié)果進(jìn)行總結(jié)分析，提出根據(jù)不同應(yīng)用場(chǎng)景綜合運(yùn)用不同數(shù)據(jù)處理方法的策略。

參考文獻(xiàn)：

[1]Armbrust M， Fox A， Griffith R， et al. A view of cloud computing[J]. Communications of the ACM， 2010， 53（4）： 50-58.

[2]陳全， 鄧倩妮. 云計(jì)算及其關(guān)鍵技術(shù)[J]. 計(jì)算機(jī)應(yīng)用， 2009， 29（9）： 2562-2567.

[3]George L. HBase： the definitive guide[M]. O'Reilly Media， Incorporated， 2011.

[4]HBase [EB/OL]， https：//zh.wikipedia.org/wiki/HBase， 2013-04-10.

[5]Hadoop [EB/OL]， https：//zh.wikipedia.org/wiki/HBase， 2013-04-10.

[6]Chang F， Dean J， Ghemawat S， et al. Bigtable： A distributed storage system for structured data[J]. ACM Transactions on Computer Systems （TOCS）， 2008， 26（2）： 4.

[7]Dean J， Ghemawat S. MapReduce： simplified data processing on large clusters[J]. Communications of the ACM， 2008， 51（1）： 107-113.

[8]李明， 胥光輝， 戢瑤. MapReduce 編程模型在網(wǎng)絡(luò)I/O密集型程序中的應(yīng)用研究[J]. 計(jì)算機(jī)應(yīng)用研究， 2011， 28（9）：3372-3374.

[9]http：//hadoop.apache.org/docs/r0.20.0/releasenotes.html， 2011-03-13

[10]https：//issues.apache.org/jira/secure/ReleaseNote.jspa？projectId=12310753&version=12314223， 2013-03-13.

[11]Moise D， Shestakov D， Gudmundsson G T， et al. Indexing and Searching 100M Images with Map-Reduce[C]. ACM International Conference on Multimedia Retrieval. 2013.

[12]杜曉東. 大數(shù)據(jù)環(huán)境下基于Hbase的分布式查詢優(yōu)化研究[J]. 計(jì)算機(jī)光盤軟件與應(yīng)用， 2014（8）：22-24.

[13]王海豹. 基于Hadoop架構(gòu)的數(shù)據(jù)共享模型研究[D]. 北京工業(yè)大學(xué)， 2013.

[14]彭宇， 龐景月， 劉大同，等. 大數(shù)據(jù)：內(nèi)涵、技術(shù)體系與展望[J]. 電子測(cè)量與儀器學(xué)報(bào)， 2015（4）：469-482.

[15]孫知信， 黃涵霞. 基于云計(jì)算的數(shù)據(jù)存儲(chǔ)技術(shù)研究[J]. 南京郵電大學(xué)學(xué)報(bào)（自然科學(xué)版）， 2014， 34（4）：13-19.

[16]劉曉靜. 基于HBase的海量小視頻存儲(chǔ)與檢索系統(tǒng)的研究與實(shí)現(xiàn)[D]. 西安電子科技大學(xué)， 2014.

[17]Lars G. HBase ： the definitive guide ： [random access to your planet-size data][J]. 2011.

【通聯(lián)編輯：梁書】