調(diào)整參數(shù)

入門級(jí)的調(diào)優(yōu)可以從調(diào)整參數(shù)開(kāi)始。投入小，回報(bào)快。

1. Write Buffer Size

快速配置

Java代碼  

HTable htable = new HTable(config, tablename);   
htable.setWriteBufferSize(6 * 1024 * 1024);   
htable.setAutoFlush(false);   

設(shè)置buffer的容量，例子中設(shè)置了6MB的buffer容量。

* 必須禁止auto flush。

* 6MB是經(jīng)驗(yàn)值，可以上下微調(diào)以適應(yīng)不同的寫(xiě)場(chǎng)景。

原理

HBase Client會(huì)在數(shù)據(jù)累積到設(shè)置的閾值后才提交Region Server。這樣做的好處在于可以減少RPC連接次數(shù)。

2. RPC Handler

快速配置

修改hbase-site.xml的hbase.regionserver.handler.count配置項(xiàng)：

Xml代碼  

<property>   
<name>hbase.regionserver.handler.count</name>   
<value>100</value>   
</property>   

原理

該配置定義了每個(gè)Region Server上的RPC Handler的數(shù)量。Region Server通過(guò)RPC Handler接收外部請(qǐng)求并加以處理。所以提升RPC Handler的數(shù)量可以一定程度上提高HBase接收請(qǐng)求的能力。當(dāng)然，handler數(shù)量也不是越大越好，這要取決于節(jié)點(diǎn)的硬件情況。

3. Compression

快速配置

Java代碼  

HColumnDescriptor hcd = new HColumnDescriptor(familyName);    
hcd.setCompressionType(Algorithm.SNAPPY);  

原理

數(shù)據(jù)量大，邊壓邊寫(xiě)也會(huì)提升性能的，畢竟IO是大數(shù)據(jù)的最嚴(yán)重的瓶頸，哪怕使用了SSD也是一樣。眾多的壓縮方式中，推薦使用SNAPPY。從壓縮率和壓縮速度來(lái)看，性價(jià)比最高。

4. WAL

快速配置

Put put = new Put(rowKey);   
put.setWriteToWAL(false);   

原理

其實(shí)不推薦關(guān)閉WAL，不過(guò)關(guān)了的確可以提升性能...因?yàn)镠Base在寫(xiě)數(shù)據(jù)前會(huì)先把操作持久化在WAL中，以保證在異常情況下，HBase可以按照WAL的記錄來(lái)恢復(fù)還未持久化的數(shù)據(jù)。

5. Replication

雖然推薦replica=3，不過(guò)當(dāng)數(shù)據(jù)量很夸張的時(shí)候，一般會(huì)把replica降低到2。當(dāng)然也不推薦隨便降低replica。

6. Compaction

在插數(shù)據(jù)時(shí)，打開(kāi)HMaster的web界面，查看每個(gè)region server的request數(shù)量。確保大部分時(shí)間，寫(xiě)請(qǐng)求在region server層面大致平均分布。在此前提下，我們?cè)倏紤]compaction的問(wèn)題。繼續(xù)觀察request數(shù)量，你會(huì)發(fā)現(xiàn)在某個(gè)時(shí)間段，若干region server接收的請(qǐng)求數(shù)為0（當(dāng)然這也可能是client根本沒(méi)有向這個(gè)region server寫(xiě)數(shù)據(jù)，所以之前說(shuō)，要確保請(qǐng)求在各region server大致平均分布）。這很有可能是region server在做compaction導(dǎo)致。compaction的過(guò)程會(huì)block寫(xiě)。 優(yōu)化的思路有兩種，一是提高compaction的效率，二是減少compaction發(fā)生的頻率。

提高以下兩個(gè)屬性的值，以增加執(zhí)行compaction的線程數(shù)：

hbase.regionserver.thread.compaction.large

hbase.regionserver.thread.compaction.small

推薦設(shè)置為2。

優(yōu)化Client設(shè)計(jì)

以上都是些常見(jiàn)的參數(shù)調(diào)整。但是寫(xiě)性能差一般是源于Client端的糟糕設(shè)計(jì)。

1. 避免region split

不得不說(shuō)，region split是提升寫(xiě)性能的一大障礙。減少region split次數(shù)可以從兩方面入手。首先是預(yù)分配region。

預(yù)分配region

不在此重復(fù)region split的原理，請(qǐng)參見(jiàn)http://blog.sina.com.cn/s/blog_9cee0fd901018vu2.html。按數(shù)據(jù)量，row key的規(guī)則預(yù)先設(shè)計(jì)并分配好region，可以大幅降低region split的次數(shù), 甚至不split。這點(diǎn)非常重要。

適當(dāng)提升hbase.hregion.max.filesize

提升region的file容量也可以減少split的次數(shù)。具體的值需要按照你的數(shù)據(jù)量，region數(shù)量，row key分布等情況具體考量。一般來(lái)說(shuō)，3~4G是不錯(cuò)的選擇。

2. 均勻分布每個(gè)Region Server的寫(xiě)壓力

之前也提到了RPC Handler的概念。好的Data Loader需要保證每個(gè)RPC Handlder都有活干，每個(gè)handler忙，但不至超載。注意region的壓力不能過(guò)大，否則會(huì)導(dǎo)致反復(fù)重試，并伴有超時(shí)異常(可以提高超時(shí)的時(shí)間設(shè)置)。

如何保證每個(gè)Region Server的壓力均衡呢？這和region 數(shù)量，startKey設(shè)計(jì)， client數(shù)據(jù)插入順序有關(guān)。

一般來(lái)說(shuō)，簡(jiǎn)單的數(shù)據(jù)插入程序應(yīng)該是多線程實(shí)現(xiàn)。讓每個(gè)線程負(fù)責(zé)一部分的row key范圍，而row key范圍又和region相關(guān)，所以可以在數(shù)據(jù)插入時(shí)，程序控制每個(gè)region的壓力，不至于有些region閑著沒(méi)事干。

那么，如何設(shè)計(jì)row key呢？舉個(gè)比較實(shí)際的例子，如果有張HBase表來(lái)記錄每天某城市的通話記錄， 常規(guī)思路下的row key是由電話號(hào)碼 + yyyyMMddHHmmSS + ... 組成。按電話號(hào)碼的規(guī)律來(lái)劃分region。但是這樣很容易導(dǎo)致數(shù)據(jù)插入不均勻(因?yàn)殡娫捦ㄔ挸孰S機(jī)性)。但是，如果把電話號(hào)碼倒序，數(shù)據(jù)在region層面的分布情況就大有改觀。

3. 分布式的數(shù)據(jù)插入程序

HBase客戶端在單節(jié)點(diǎn)上運(yùn)行，即使使用多線程，也受限于單節(jié)點(diǎn)的硬件資源，寫(xiě)入速度不可能很快。典型的思路是將客戶端部署在多個(gè)節(jié)點(diǎn)上運(yùn)行，提高寫(xiě)的并發(fā)度。MapReduce是個(gè)很好的選擇。使用MapReduce把寫(xiě)入程序分布到集群的各個(gè)節(jié)點(diǎn)上，并在每個(gè)mapper中運(yùn)行多線程的插入程序。這樣可以很好的提高寫(xiě)并發(fā)度。

注意，不要使用reducer。mapper到reducer需要走網(wǎng)絡(luò)，受限于集群帶寬。其次，實(shí)際的應(yīng)用場(chǎng)景一般是用戶從關(guān)系型數(shù)據(jù)庫(kù)中導(dǎo)出了文本類型的數(shù)據(jù)，然后希望能把導(dǎo)出的數(shù)據(jù)寫(xiě)到HBase里。在這種情況下，需要小心謹(jǐn)慎地設(shè)計(jì)和實(shí)現(xiàn)file split邏輯。

4. HBase Client太慢？BulkLoad!

請(qǐng)拿出HBase的API讀讀，HFileOutputFomart里有個(gè)叫configureIncrementalLoad的方法。API是這么介紹的：

Configure a MapReduce Job to perform an incremental load into the given table. This

Inspects the table to configure a total order partitioner

Uploads the partitions file to the cluster and adds it to the DistributedCache

Sets the number of reduce tasks to match the current number of regions

Sets the output key/value class to match HFileOutputFormat's requirements

Sets the reducer up to perform the appropriate sorting (either KeyValueSortReducer or PutSortReducer)

The user should be sure to set the map output value class to either KeyValue or Put before running this function.

這是HBase提供的一種基于MapReduce的數(shù)據(jù)導(dǎo)入方案，完美地繞過(guò)了HBase Client（上一節(jié)的分布式插入方法也是用mapreduce實(shí)現(xiàn)的，不過(guò)本質(zhì)上還是用hbase client來(lái)寫(xiě)數(shù)據(jù)）

 網(wǎng)上有不少文章敘述了使用命令行方式運(yùn)行BulkLoad，比如

但是，不得不說(shuō)，實(shí)際生產(chǎn)環(huán)境上很難使用這種方式。畢竟源數(shù)據(jù)不可能直接用來(lái)寫(xiě)HBase。在數(shù)據(jù)遷移的過(guò)程中會(huì)涉及到數(shù)據(jù)清洗、整理歸并等許多額外的工作。這顯然不是命令行可以做到的事情。按照API的描述， 可行的方案是自定義一個(gè)Mapper在mapper中清洗數(shù)據(jù)，Mapper的輸出value為HBase的Put類型，Reducer選用PutSortReducer。然后使用HFileOutputFormat#configureIncrementalLoad(Job, HTable);解決剩余工作。

不過(guò)，這種實(shí)現(xiàn)也存在局限性。畢竟Mapper到Reducer比較吃網(wǎng)絡(luò)。

至此，本文介紹了三種HBase數(shù)據(jù)寫(xiě)入的方法（1種多線程，2種mapreduce），并介紹了性能調(diào)優(yōu)的方法。希望能對(duì)大家有所幫助。本文提供的所有數(shù)據(jù)導(dǎo)入方法，作者均親手實(shí)現(xiàn)并使用TB級(jí)數(shù)據(jù)測(cè)試。限于篇幅，在此只提供實(shí)現(xiàn)思路。

原文鏈接：http://joshuasabrina.iteye.com/blog/1798239

【編輯推薦】