當一個組件到了優化部分的時候，基本上這個組件的內容就到了結尾部分了，本文我們給HBase收收尾，來講一下HBase的優化，關注專欄《破繭成蝶——大資料篇》，查看更多相關的內容~

一、HBase的高可用

二、預磁區

2.1 使用命令列添加預磁區

2.2 使用JavaAPI添加預磁區

2.2.1 代碼實作

2.2.2 測驗

三、RowKey設計

四、引數調優

一、HBase的高可用

在HBase中HMaster負責監控Region Server的生命周期，均衡Region Server的負載，如果HMaster掛掉了，那么整個HBase集群將陷入不健康的狀態，并且此時的作業狀態并不會維持太久，所以HBase支持對HMaster的高可用配置，這里需要注意的是，如果HMaster掛掉，HBase集群只是會進入不健康的狀態，說明并不是所有的操作都用得到HMaster，下面一起來看一下怎樣配置HBase的高可用，

1、關閉HBase集群

bin/stop-hbase.sh

2、在HBase的conf目錄下創建備用Master檔案，并將備用節點添加到檔案中，

3、將組態檔分發到其他節點

xsync backup-masters

4、啟動HBase集群，在瀏覽器中打開頁面查看是否生效，

我們試著殺死master節點的HMaster，看看slave01節點的HMaster是否生效：

說明高可用已經生效，我們的配置沒有問題，

二、預磁區

每一個Region維護著startRowKey與endRowKey，如果加入的資料符合某個Region維護的rowkey范圍，則該資料交給這個Region維護，那么依照這個原則，我們可以將資料所要投放的磁區提前大致的規劃好，以提高HBase性能，

2.1 使用命令列添加預磁區

1、手動設定預磁區

create 'emp','info','partition1',SPLITS => ['1000','2000','3000','4000']

2、生成16進制序列預磁區

create 'emp2','info','partition2',{NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}

3、按照檔案中的規則預磁區

創建檔案，并添加磁區內容，如下所示：

create 'emp3','partition3',SPLITS_FILE => '/root/files/partitions.txt'

2.2 使用JavaAPI添加預磁區

2.2.1 代碼實作

package com.xzw.hbase_partitions;

import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.hbase.HBaseConfiguration;
import org.apache.hadoop.hbase.HColumnDescriptor;
import org.apache.hadoop.hbase.HTableDescriptor;
import org.apache.hadoop.hbase.TableName;
import org.apache.hadoop.hbase.client.*;
import org.apache.hadoop.hbase.util.Bytes;

import java.io.IOException;

/**
 * @author: xzw
 * @create_date: 2021/4/8 10:06
 * @desc: 使用代碼的方式創建HBase預磁區
 * @modifier:
 * @modified_date:
 * @desc:
 */
public class HBasePartitionsAPI {

    /**
     * 生成磁區號
     *
     * @param rowkey      初始rowkey
     * @param regionCount 磁區數
     * @return 回傳生成的磁區號
     */
    public static String genRegionNum(String rowkey, int regionCount) {
        int regionNum;
        int hash = rowkey.hashCode();

        if (regionCount > 0 && (regionCount & (regionCount - 1)) == 0) {
            // 2 n
            regionNum = hash & (regionCount - 1);
        } else {
            regionNum = hash % regionCount;
        }

        return regionNum + "_" + rowkey;
    }

    /**
     * 生成磁區鍵
     *
     * @param regionCount 磁區數
     * @return
     */
    public static byte[][] genRegionKeys(int regionCount) {
        byte[][] bytes = new byte[regionCount - 1][];

        for (int i = 0; i < regionCount - 1; i++) {
            bytes[i] = Bytes.toBytes(i + "|");
        }

        return bytes;
    }

    public static void main(String[] args) throws IOException {
        //1、創建配置物件，獲取HBase連接
        Configuration conf = HBaseConfiguration.create();
        conf.set("hbase.zookeeper.quorum", "master,slave01,slave02");
        conf.set("hbase.zookeeper.property.clientPort", "2181");

        //2、獲取HBase連接物件
        Connection conn = ConnectionFactory.createConnection(conf);

        //3、獲取操作物件
        Admin admin = conn.getAdmin();

        //4、創建表，同時增加預磁區
        HTableDescriptor emp_api = new HTableDescriptor(TableName.valueOf("emp_api"));
        HColumnDescriptor info = new HColumnDescriptor("info");
        emp_api.addFamily(info);

        byte[][] bytes = genRegionKeys(3);
        admin.createTable(emp_api, bytes);//創建表的時候添加預磁區

        //5、增加資料
        String rowkey = "xzw";
        String rk = genRegionNum(rowkey, 3);
        Put put = new Put(Bytes.toBytes(rk));
        put.addColumn(Bytes.toBytes("info"), Bytes.toBytes("loc"), Bytes.toBytes("qd"));

        Table table = conn.getTable(TableName.valueOf("emp_api"));
        table.put(put);
    }
}

2.2.2 測驗

運行代碼發現已經創建預磁區：

資料也按照預期插入到了HBase中：

三、RowKey設計

一條資料的唯一標識就是rowkey，那么這條資料存盤于哪個磁區，取決于rowkey處于哪個一個預磁區的區間內，設計rowkey的主要目的，就是讓資料均勻的分布于所有的region中，在一定程度上防止資料傾斜，造成資料傾斜的原因可能有以下幾個：

1、HBase的中的資料是按照字典序排序的，當大量連續的rowkey集中寫在個別的region，各個region之間資料分布不均衡，

2、創建表時沒有提前預磁區，創建的表默認只有一個region，大量的資料寫入當前region，

3、創建表已經提前預磁區，但是設計的rowkey沒有規律可循，

可以通過以下幾個方法解決資料傾斜問題：

1、亂數+業務主鍵，如果想讓最近的資料快速get到，可以將時間戳加上，

2、Rowkey設計越短越好，不要超過10~100個位元組，

3、映射regionNo，這樣既可以讓資料均勻分布到各個region中，同時可以根據startkey和endkey可以get到同一批資料，

Rowkey設計時需要遵循三大原則：

1、唯一性原則

rowkey在設計上保證其唯一性，rowkey是按照字典順序排序存盤的，因此，設計rowkey的時候，要充分利用這個排序的特點，將經常讀取的資料存盤到一塊，將最近可能會被訪問的資料放到一塊，

2、長度原則

rowkey是一個二進制碼流，可以是任意字串，最大長度64kb，實際應用中一般為10-100bytes，以byte[]形式保存，一般設計成定長，建議越短越好，不要超過16個位元組，原因如下：資料的持久化檔案HFile中是按照KeyValue存盤的，如果rowkey過長，比如超過100位元組，1000w行資料，光rowkey就要占用100*1000w=10億個位元組，將近1G資料，這樣會極大影響HFile的存盤效率；MemStore將快取部分資料到記憶體，如果rowkey欄位過長，記憶體的有效利用率就會降低，系統不能快取更多的資料，這樣會降低檢索效率，目前作業系統都是64位系統，記憶體8位元組對齊，控制在16個位元組，8位元組的整數倍利用了作業系統的最佳特性，

3、散列原則

如果rowkey按照時間戳的方式遞增，不要將時間放在二進制碼的前面，建議將rowkey的高位作為散列欄位，由程式隨機生成，低位放時間欄位，這樣將提高資料均衡分布在每個RegionServer，以實作負載均衡的幾率，如果沒有散列欄位，首欄位直接是時間資訊，所有的資料都會集中在一個RegionServer上，這樣在資料檢索的時候負載會集中在個別的RegionServer上，造成熱點問題，會降低查詢效率，

（1）加鹽：如果rowkey按照時間戳的方式遞增，不要將時間放在二進制碼的前面，建議將rowkey的高位作為散列欄位，由程式隨機生成，低位放時間欄位，這樣將提高資料均衡分布在每個RegionServer，以實作負載均衡的幾率，如果沒有散列欄位，首欄位直接是時間資訊，所有的資料都會集中在一個RegionServer上，這樣在資料檢索的時候負載會集中在個別的RegionServer上，造成熱點問題，會降低查詢效率，這里所說的加鹽不是密碼學中的加鹽，而是在rowkey的前面增加亂數，具體就是給rowkey分配一個隨機前綴以使得它和之前的rowkey的開頭不同，分配的前綴種類數量應該和你想使用資料分散到不同的region的數量一致，加鹽之后的rowkey就會根據隨機生成的前綴分散到各個region上，以避免熱點，

（2）哈希：哈希會使同一行永遠用一個前綴加鹽，哈希也可以使負載分散到整個集群，但是讀卻是可以預測的，使用確定的哈希可以讓客戶端重構完整的rowkey，可以使用get操作準確獲取某一個行資料，

（3）反轉：第三種防止熱點的方法時反轉固定長度或者數字格式的rowkey，這樣可以使得rowkey中經常改變的部分（最沒有意義的部分）放在前面，這樣可以有效的隨機rowkey，但是犧牲了rowkey的有序性，反轉rowkey的例子以手機號為rowkey，可以將手機號反轉后的字串作為rowkey，這樣的就避免了以手機號那樣比較固定開頭導致熱點問題，

（4）時間戳反轉：一個常見的資料處理問題是快速獲取資料的最近版本，使用反轉的時間戳作為rowkey的一部分對這個問題十分有用，可以用Long.Max_Value-timestamp追加到key的末尾，例如[key][reverse_timestamp] ，[key] 的最新值可以通過scan [key]獲得[key]的第一條記錄，因為HBase中rowkey是有序的，第一條記錄是最后錄入的資料，比如需要保存一個用戶的操作記錄，按照操作時間倒序排序，在設計rowkey的時候，可以這樣設計[userId反轉][Long.Max_Value-timestamp]，在查詢用戶的所有操作記錄資料的時候，直接指定反轉后的userId，startRow是[userId反轉][000000000000]，stopRow是[userId反轉][Long.Max_Value-timestamp]，如果需要查詢某段時間的操作記錄，startRow是[user反轉][Long.Max_Value-起始時間]，stopRow是[userId反轉][Long.Max_Value-結束時間]，

四、引數調優

1、允許在HDFS的檔案中追加內容

hdfs-site.xml、hbase-site.xml

屬性：dfs.support.append
解釋：開啟HDFS追加同步，可以優秀的配合HBase的資料同步和持久化，默認值為true，

2、優化DataNode允許的最大檔案打開數

hdfs-site.xml

屬性：dfs.datanode.max.transfer.threads
解釋：HBase一般都會同一時間操作大量的檔案，根據集群的數量和規模以及資料動作，設定為4096或者更高，默認值：4096，

3、優化延遲高的資料操作的等待時間

hdfs-site.xml

屬性：dfs.image.transfer.timeout
解釋：如果對于某一次資料操作來講，延遲非常高，socket需要等待更長的時間，建議把該值設定為更大的值（默認60000毫秒），以確保socket不會被timeout掉，

4、優化資料的寫入效率

mapred-site.xml

屬性：
mapreduce.map.output.compress
mapreduce.map.output.compress.codec
解釋：開啟這兩個資料可以大大提高檔案的寫入效率，減少寫入時間，第一個屬性值修改為true，第二個屬性值修改為：org.apache.hadoop.io.compress.GzipCodec或者其他壓縮方式，

5、設定RPC監聽數量

hbase-site.xml

屬性：hbase.regionserver.handler.count
解釋：默認值為30，用于指定RPC監聽的數量，可以根據客戶端的請求數進行調整，讀寫請求較多時，增加此值，

6、優化HStore檔案大小

hbase-site.xml

屬性：hbase.hregion.max.filesize
解釋：默認值10737418240（10GB），如果需要運行HBase的MR任務，可以減小此值，因為一個region對應一個map任務，如果單個region過大，會導致map任務執行時間過長，該值的意思就是，如果HFile的大小達到這個數值，則這個region會被切分為兩個Hfile，

7、優化hbase客戶端快取

hbase-site.xml

屬性：hbase.client.write.buffer
解釋：用于指定HBase客戶端快取，增大該值可以減少RPC呼叫次數，但是會消耗更多記憶體，反之則反之，一般我們需要設定一定的快取大小，以達到減少RPC次數的目的，

8、指定scan.next掃描HBase所獲取的行數

hbase-site.xml

屬性：hbase.client.scanner.caching
解釋：用于指定scan.next方法獲取的默認行數，值越大，消耗記憶體越大，

9、flush、compact、split機制

當MemStore達到閾值，將Memstore中的資料Flush進Storefile，compact機制則是把flush出來的小檔案合并成大的Storefile檔案，split則是當Region達到閾值，會把過大的Region一分為二，

涉及屬性：

hbase.hregion.memstore.flush.size：134217728

這個引數的作用是當單個HRegion內所有的Memstore大小總和超過指定值時，flush該HRegion的所有memstore，RegionServer的flush是通過將請求添加一個佇列，模擬生產消費模型來異步處理的，那這里就有一個問題，當佇列來不及消費，產生大量積壓請求時，可能會導致記憶體陡增，最壞的情況是觸發OOM，

hbase.regionserver.global.memstore.upperLimit：0.4
hbase.regionserver.global.memstore.lowerLimit：0.38

當MemStore使用記憶體總量達到hbase.regionserver.global.memstore.upperLimit指定值時，將會有多個MemStores flush到檔案中，MemStore flush 順序是按照大小降序執行的，直到重繪到MemStore使用記憶體略小于lowerLimit，

以上就是本文的所有內容，比較簡單，你們在此程序中遇到了什么問題，歡迎留言，讓我看看你們都遇到了哪些問題~

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/274176.html

標籤：其他

上一篇：榜樣的力量——揭秘新手程式員如何學習

下一篇：Hadoop集群環境搭建

五十六、HBase的優化

一、HBase的高可用

二、預磁區

2.1 使用命令列添加預磁區

2.2 使用JavaAPI添加預磁區

2.2.1 代碼實作

2.2.2 測驗

三、RowKey設計

四、引數調優