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

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

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

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

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

1 相關知識

1.1 MapReduce編程模型

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

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

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

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

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

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

HBase是基于HDFS的開源數(shù)據(jù)庫，它以Google的BigTable為原型，設計并實現(xiàn)了具有高可靠性、高性能、列存儲、可伸縮、實時讀寫的數(shù)據(jù)庫系統(tǒng)，用于存儲粗粒度的結構化數(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服務器上，以達到負載均衡的目的。每個Region由一個或多個Store組成，每個Store保存一個列族的所有數(shù)據(jù)。每個Store又是由一個memStore和零個或多個StoreFile組成，StoreFile則是以HFile的格式存儲在HDFS上的，如圖2所示。

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

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

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

2.1 集群結構

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

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

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

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

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

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

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

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

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

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

2.2.3 結果分析

在HBase數(shù)據(jù)寫入性能實驗中，本文就HBase提供兩種數(shù)據(jù)寫入方式的性能進行了詳細測試。一是單個數(shù)據(jù)的寫入性能，在HBase集群中重復數(shù)據(jù)寫入操作并記錄所需時間，結果表明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ù)批量導入性能進行優(yōu)化，本文主要測試了數(shù)據(jù)量和線程數(shù)量這兩個條件對性能的影響。

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

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

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

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

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

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

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

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

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

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

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

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

3 結果分析

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

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

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

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

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

4 總結

本文對HBase數(shù)據(jù)寫入性能進行詳細測試，全面了解其性能特性。通過測試找到了HBase的不足，并根據(jù)HBase數(shù)據(jù)庫存在的性能缺陷。提出了采用多線程和MapReduce計算框架的并行處理方法來提高其性能，并對實驗結果進行總結分析，提出根據(jù)不同應用場景綜合運用不同數(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]陳全， 鄧倩妮. 云計算及其關鍵技術[J]. 計算機應用， 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)絡I/O密集型程序中的應用研究[J]. 計算機應用研究， 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]. 計算機光盤軟件與應用， 2014（8）：22-24.

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

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

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

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

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

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