HBase之二：Hbase優化

1.    預先分區

默認狀況下，在建立 HBase 表的時候會自動建立一個 Region 分區，當導入數據的時候，全部的 HBase 客戶端都向這一個 Region 寫數據，直到這個 Region 足夠大了才進行切分。一種能夠加快批量寫入速度的方法是經過預先建立一些空的 Regions，這樣當數據寫入 HBase 時，會按照 Region 分區狀況，在集羣內作數據的負載均衡。

HBase之五：hbase的region分區

2.    Rowkey優化

HBase 中 Rowkey 是按照字典序存儲，所以，設計 Rowkey 時，要充分利用排序特色，將常常一塊兒讀取的數據存儲到一塊，將最近可能會被訪問的數據放在一塊。

此外，Rowkey 如果遞增的生成，建議不要使用正序直接寫入 Rowkey，而是採用 reverse 的方式反轉Rowkey，使得 Rowkey 大體均衡分佈，這樣設計有個好處是能將 RegionServer 的負載均衡，不然容易產生全部新數據都在一個 RegionServer 上堆積的現象，這一點還能夠結合 table 的預切分一塊兒設計。

HBase之六：HBase的RowKey設計

3.    減小列族數量

不要在一張表裏定義太多的 ColumnFamily。目前 Hbase 並不能很好的處理超過 2~3 個 ColumnFamily 的表。由於某個 ColumnFamily 在 flush 的時候，它鄰近的 ColumnFamily 也會因關聯效應被觸發 flush，最終致使系統產生更多的 I/O。

4.    緩存策略

建立表的時候，能夠經過 HColumnDescriptor.setInMemory(true) 將表放到 RegionServer 的緩存中，保證在讀取的時候被 cache 命中。

5.    設置存儲生命期

建立表的時候，能夠經過 HColumnDescriptor.setTimeToLive(int timeToLive) 設置表中數據的存儲生命期，過時數據將自動被刪除。

6.    硬盤配置

每臺 RegionServer 管理 10~1000 個 Regions，每一個 Region 在 1~2G，則每臺 Server 最少要 10G，最大要1000*2G=2TB，考慮 3 備份，則要 6TB。方案一是用 3 塊 2TB 硬盤，二是用 12 塊 500G 硬盤，帶寬足夠時，後者能提供更大的吞吐率，更細粒度的冗餘備份，更快速的單盤故障恢復。

7.    分配合適的內存給RegionServer服務

在不影響其餘服務的狀況下，越大越好。例如在 HBase 的 conf 目錄下的 hbase-env.sh 的最後添加 export HBASE_REGIONSERVER_OPTS="-Xmx16000m$HBASE_REGIONSERVER_OPTS」

其中 16000m 爲分配給 RegionServer 的內存大小。

8.    寫數據的備份數

備份數與讀性能成正比，與寫性能成反比，且備份數影響高可用性。有兩種配置方式，一種是將 hdfs-site.xml拷貝到 hbase 的 conf 目錄下，而後在其中添加或修改配置項 dfs.replication 的值爲要設置的備份數，這種修改對全部的 HBase 用戶表都生效，另一種方式，是改寫 HBase 代碼，讓 HBase 支持針對列族設置備份數，在建立表時，設置列族備份數，默認爲 3，此種備份數只對設置的列族生效。

9.    WAL（預寫日誌）

可設置開關，表示 HBase 在寫數據前用不用先寫日誌，默認是打開，關掉會提升性能，可是若是系統出現故障(負責插入的 RegionServer 掛掉)，數據可能會丟失。配置 WAL 在調用 JavaAPI 寫入時，設置 Put 實例的WAL，調用 Put.setWriteToWAL(boolean)。

10. 批量寫

HBase 的 Put 支持單條插入，也支持批量插入，通常來講批量寫更快，節省來回的網絡開銷。在客戶端調用JavaAPI 時，先將批量的 Put 放入一個 Put 列表，而後調用 HTable 的 Put(Put 列表) 函數來批量寫。

11. 客戶端一次從服務器拉取的數量

經過配置一次拉去的較大的數據量能夠減小客戶端獲取數據的時間，可是它會佔用客戶端內存。有三個地方可進行配置：

1）在 HBase 的 conf 配置文件中進行配置 hbase.client.scanner.caching；

2）經過調用 HTable.setScannerCaching(intscannerCaching) 進行配置；

3）經過調用 Scan.setCaching(intcaching) 進行配置。三者的優先級愈來愈高。

12. RegionServer的請求處理I/O線程數

較少的 IO 線程適用於處理單次請求內存消耗較高的 Big Put 場景 (大容量單次 Put 或設置了較大 cache 的Scan，均屬於 Big Put) 或 ReigonServer 的內存比較緊張的場景。

較多的 IO 線程，適用於單次請求內存消耗低，TPS 要求 (每秒事務處理量 (TransactionPerSecond)) 很是高的場景。設置該值的時候，以監控內存爲主要參考。

在 hbase-site.xml 配置文件中配置項爲 hbase.regionserver.handler.count。

13. Region的大小設置

配置項爲 hbase.hregion.max.filesize，所屬配置文件爲 hbase-site.xml.，默認大小 256M。

在當前 ReigonServer 上單個 Reigon 的最大存儲空間，單個 Region 超過該值時，這個 Region 會被自動 split成更小的 Region。小 Region 對 split 和 compaction 友好，由於拆分 Region 或 compact 小 Region 裏的StoreFile 速度很快，內存佔用低。缺點是 split 和 compaction 會很頻繁，特別是數量較多的小 Region 不停地split, compaction，會致使集羣響應時間波動很大，Region 數量太多不只給管理上帶來麻煩，甚至會引起一些Hbase 的 bug。通常 512M 如下的都算小 Region。大 Region 則不太適合常常 split 和 compaction，由於作一次 compact 和 split 會產生較長時間的停頓，對應用的讀寫性能衝擊很是大。

此外，大 Region 意味着較大的 StoreFile，compaction 時對內存也是一個挑戰。若是你的應用場景中，某個時間點的訪問量較低，那麼在此時作 compact 和 split，既能順利完成 split 和 compaction，又能保證絕大多數時間平穩的讀寫性能。compaction 是沒法避免的，split 能夠從自動調整爲手動。只要經過將這個參數值調大到某個很難達到的值，好比 100G，就能夠間接禁用自動 split(RegionServer 不會對未到達 100G 的 Region 作split)。再配合 RegionSplitter 這個工具，在須要 split 時，手動 split。手動 split 在靈活性和穩定性上比起自動split 要高不少，並且管理成本增長很少，比較推薦 online 實時系統使用。內存方面，小 Region 在設置memstore 的大小值上比較靈活，大 Region 則過大太小都不行，過大會致使 flush 時 app 的 IO wait 增高，太小則因 StoreFile 過多影響讀性能。

14. 操做系統參數

Linux系統最大可打開文件數通常默認的參數值是1024,若是你不進行修改併發量上來的時候會出現「Too Many Open Files」的錯誤，致使整個HBase不可運行，你能夠用ulimit -n 命令進行修改，或者修改/etc/security/limits.conf和/proc/sys/fs/file-max 的參數，具體如何修改能夠去Google 關鍵字 「linux limits.conf 」

15. Jvm配置

修改 hbase-env.sh 文件中的配置參數，根據你的機器硬件和當前操做系統的JVM(32/64位)配置適當的參數

HBASE_HEAPSIZE 4000 HBase使用的 JVM 堆的大小

HBASE_OPTS "‐server ‐XX:+UseConcMarkSweepGC"JVM GC 選項

HBASE_MANAGES_ZKfalse 是否使用Zookeeper進行分佈式管理

16. 持久化

重啓操做系統後HBase中數據全無，你能夠不作任何修改的狀況下，建立一張表，寫一條數據進行，而後將機器重啓，重啓後你再進入HBase的shell中使用 list 命令查看當前所存在的表，一個都沒有了。是否是很杯具？沒有關係你能夠在hbase/conf/hbase-default.xml中設置hbase.rootdir的值，來設置文件的保存位置指定一個文件夾，例如：<value>file:///you/hbase-data/path</value>，你創建的HBase中的表和數據就直接寫到了你的磁盤上，一樣你也能夠指定你的分佈式文件系統HDFS的路徑例如:hdfs://NAMENODE_SERVER:PORT/HBASE_ROOTDIR，這樣就寫到了你的分佈式文件系統上了。

17. 緩衝區大小

hbase.client.write.buffer

這個參數能夠設置寫入數據緩衝區的大小，當客戶端和服務器端傳輸數據，服務器爲了提升系統運行性能開闢一個寫的緩衝區來處理它，這個參數設置若是設置的大了，將會對系統的內存有必定的要求，直接影響系統的性能。

18. 掃描目錄表

hbase.master.meta.thread.rescanfrequency

定義多長時間HMaster對系統表 root 和 meta 掃描一次，這個參數能夠設置的長一些，下降系統的能耗。

19. split/compaction時間間隔

hbase.regionserver.thread.splitcompactcheckfrequency

這個參數是表示多久去RegionServer服務器運行一次split/compaction的時間間隔，固然split以前會先進行一個compact操做.這個compact操做多是minorcompact也多是major compact.compact後,會從全部的Store下的全部StoreFile文件最大的那個取midkey.這個midkey可能並不處於所有數據的mid中.一個row-key的下面的數據可能會跨不一樣的HRegion。

20. 緩存在JVM堆中分配的百分比

hfile.block.cache.size

指定HFile/StoreFile 緩存在JVM堆中分配的百分比，默認值是0.2，意思就是20%，而若是你設置成0，就表示對該選項屏蔽。

21. ZooKeeper客戶端同時訪問的併發鏈接數

hbase.zookeeper.property.maxClientCnxns

這項配置的選項就是從zookeeper中來的，表示ZooKeeper客戶端同時訪問的併發鏈接數，ZooKeeper對於HBase來講就是一個入口這個參數的值能夠適當放大些。

22. memstores佔用堆的大小參數配置

hbase.regionserver.global.memstore.upperLimit

在RegionServer中全部memstores佔用堆的大小參數配置，默認值是0.4，表示40%，若是設置爲0，就是對選項進行屏蔽。

23. Memstore中緩存寫入大小

hbase.hregion.memstore.flush.size

Memstore中緩存的內容超過配置的範圍後將會寫到磁盤上，例如：刪除操做是先寫入MemStore裏作個標記，指示那個value, column 或 family等下是要刪除的，HBase會按期對存儲文件作一個major compaction，在那時HBase會把MemStore刷入一個新的HFile存儲文件中。若是在必定時間範圍內沒有作major compaction，而Memstore中超出的範圍就寫入磁盤上了。