hbase調優

目錄

一、phoenix調優

1.建立索引超時，查詢超時

修改配置文件，hbase-site.xml

兩個位置
/usr/local/soft/phoenix-4.15.0/bin
/usr/local/soft/hbase-1.4.6/conf/ 所有節點

增加配置

<property>
    <name>hbase.rpc.timeout</name>
    <value>60000000</value>
</property>
<property>
    <name>hbase.client.scanner.timeout.period</name>
    <value>60000000</value>
</property>
<property>
    <name>phoenix.query.timeoutMs</name>
    <value>60000000</value>
</property>

需要重啟hbase

2.預分區

默認情況下，在創建HBase表的時候會自動創建一個region分區，當導入數據的時候，所有的HBase客戶端都向這一個region寫數據，直到這個region足夠大了才進行切分。 一種可以加快批量寫入速度的方法是通過預先創建一些空的regions，這樣當數據寫入 HBase時，會按照region分區情況，在集群內做數據的負載均衡。

如果知道hbase數據表key的分布情況，就可以在建表時就進行region的預分區，這樣做的好處就是防止大量數據插入時產生的熱點問題，提高數據插入的效率。

**base shell中建分區表，指定分區文件 **
可以通過指定SPLITS_FILE的值指定分區文件,如果分區資訊比較少，也可以直接用SPLITS分區。我們可以通過如下命令建一個分區表，指定第一步中生成的分區文件：
create ‘table’, ‘cf’, {SPLITS_FILE => ‘指定分區文件的路徑’}

hbase shell預分區

hbase shell 預分區
hbase shell預分區方式二

phoenix預分區

CREATE TABLE IF NOT EXISTS STUDENT2 (
id VARCHAR NOT NULL PRIMARY KEY,
name VARCHAR,
age BIGINT,
gender VARCHAR ,
clazz VARCHAR
)split on(‘15001006|’,’15001007|’,’15001008|’) ;

| ：|的ACSII碼比所有字母都大，表示所有比15001006小的都在前面

3.在創建表的時候指定salting。

會在rowkey前面加上一個隨機的前綴。
優點：不需要知道rowkey的分步情況
缺點：不能再hbase中對數據進行查詢和修改

CREATE TABLE IF NOT EXISTS STUDENT3 (
id VARCHAR NOT NULL PRIMARY KEY,
name VARCHAR,
age BIGINT,
gender VARCHAR ,
clazz VARCHAR
)salt_buckets=6;

upsert into STUDENT3 values(‘1500100004′,’葛德曜’,24,’男’,’理科三班’);
upsert into STUDENT3 values(‘1500100005′,’宣谷芹’,24,’男’,’理科六班’);
upsert into STUDENT3 values(‘1500100006′,’羿彥昌’,24,’女’,’理科三班’);

在這裡插入圖片描述
在這裡插入圖片描述

4.二級索引 建立行鍵與列值的映射關係

全局索引：讀多寫少， 會單獨建立索引表
本地索引：讀少寫多， 索引數據和原數據保存在同一台機器上

二、hbase調優-rowkey的設計

HBase是三維有序存儲的，通過rowkey（行鍵），column key（column family和qualifier）和TimeStamp（時間戳）這個三個維度可以對HBase中的數據進行快速定位。

HBase中rowkey可以唯一標識一行記錄，在HBase查詢的時候，有三種方式：

  1. 通過get方式，指定rowkey獲取唯一一條記錄
  2. 通過scan方式，設置startRow和stopRow參數進行範圍匹配.
  3. 全表掃描，即直接掃描整張表中所有行記錄

1.rowkey唯一原則

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

2.rowkey長度原則

rowkey是一個二進位碼流，可以是任意字元串，最大長度 64kb ，實際應用中一般為10-100bytes，以 byte[] 形式保存，一般設計成定長。

建議越短越好，不要超過100個位元組，原因如下：
數據的持久化文件HFile中是按照KeyValue存儲的，如果rowkey過長，比如超過100位元組，1000w行數據，光rowkey就要佔用100*1000w=10億個位元組，將近1G數據，這樣會極大影響HFile的存儲效率；
MemStore將快取部分數據到記憶體，如果rowkey欄位過長，記憶體的有效利用率就會降低，系統不能快取更多的數據，這樣會降低檢索效率。

3.rowkey散列原則

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

4.熱點問題

HBase中的行是按照rowkey的字典順序排序的，這種設計優化了scan操作，可以將相關的行以及會被一起讀取的行存取在臨近位置，便於scan。然而糟糕的rowkey設計是熱點的源頭。 熱點發生在大量的client直接訪問集群的一個或極少數個節點（訪問可能是讀，寫或者其他操作）。大量訪問會使熱點region所在的單個機器超出自身承受能力，引起性能下降甚至region不可用，這也會影響同一個RegionServer上的其他region，由於主機無法服務其他region的請求。 設計良好的數據訪問模式以使集群被充分，均衡的利用。

為了避免寫熱點，設計rowkey使得不同行在同一個region，但是在更多數據情況下，數據應該被寫入集群的多個region，而不是一個。

5.常見的避免熱點的方法:

5.1 加鹽

這裡所說的加鹽不是密碼學中的加鹽，而是在rowkey的前面增加隨機數，具體就是給rowkey分配一個隨機前綴以使得它和之前的rowkey的開頭不同。分配的前綴種類數量應該和你想使用數據分散到不同的region的數量一致。加鹽之後的rowkey就會根據隨機生成的前綴分散到各個region上，以避免熱點。

5.2 哈希

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

對rowkey計算hash值，拼接到rowkey前面，過程是可以預測的，當一個值的rowkey過多時，也會造成熱點問題。與加鹽可以互補使用，加鹽是隨機的，hasn是固定的。

5.3 反轉

第三種防止熱點的方法時反轉固定長度或者數字格式的rowkey。這樣可以使得rowkey中經常改變的部分（最沒有意義的部分）放在前面。這樣可以有效的隨機rowkey，但是犧牲了rowkey的有序性。可以預測的。

反轉rowkey的例子以手機號為rowkey，可以將手機號反轉後的字元串作為rowkey，這樣的就避免了以手機號那樣比較固定開頭導致熱點問題

5.4 時間戳”反轉”

rowkey :時間戳_user_id
rowkey是字典升序的，那麼越新的數據就會被排在後面，不容易被獲取到。

需求：讓最新的數據排在前面
大數 — 小數
大數：9999999999
1638584124_user_id ==>8361415875_user_id
1638584135_user_id ==>8361415864_user_id
1638584146_user_id ==>8361415853_user_id

6.其他一些建議

盡量減少rowkey和列的大小，當具體的值在系統間傳輸時，它的rowkey，列簇、列名，時間戳也會一起傳輸。如果你的rowkey、列簇名、列名很大，甚至可以和具體的值相比較，那麼將會造成大量的冗餘，不利於數據的儲存與傳輸

列族儘可能越短越好，最好是一個字元

列名也儘可能越短越好，冗長的列名雖然可讀性好，但是更短的列名存儲在HBase中會更好

Tags:

VirMach 便宜 VPS

QNews

QNews