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

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

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

中圖分類號：TP392 文獻標識碼：A 文章編號：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

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

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

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

1 相關(guān)知識

1.1 MapReduce編程模型

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.3 結(jié)果分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 結(jié)果分析

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

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

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

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

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

4 總結(jié)

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

參考文獻：

[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]陳全， 鄧倩妮. 云計算及其關(guān)鍵技術(shù)[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]. 計算機應(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]. 計算機光盤軟件與應(yīng)用， 2014（8）：22-24.

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

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

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

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

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

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