一：hbase現(xiàn)有硬件資源的理論性能

1.集群容量規(guī)劃公式：

優(yōu)化調整，發(fā)揮硬件的最大優(yōu)勢；

Disk Size / Java Heap=RegionSize / MemstoreSize * ReplicationFactor * HeapFractionForMemstore *2

按照默認配置，

1. RegionSize = 10G，對應參數(shù)為hbase.hregion.max.filesize；
2. MemstoreSize = 128M，對應參數(shù)為hbase.hregion.memstore.flush.size；
3. ReplicationFactor = 3，對應參數(shù)為dfs.replication；
4. HeapFractionForMemstore = 0.4，對應參數(shù)為hbase.regionserver.global.memstore.lowerLimit；

推導公式;

• 硬盤容量緯度下Region個數(shù)：
  Disk Size / (RegionSize * ReplicationFactor)
• Java Heap緯度下Region個數(shù)：
  Java Heap * HeapFractionForMemstore / (MemstoreSize / 2 )

Disk Size / (RegionSize * ReplicationFactor)  ＝ Java Heap * HeapFractionForMemstore / (MemstoreSize / 2 )
＝>   Disk Size / Java Heap = RegionSize / MemstoreSize * ReplicationFactor * HeapFractionForMemstore * 2

2.hbase對于cpu要求高，越多core越好

3.軟硬件獨立的hbase集群

其他硬件配置，

1. 集群使用萬兆網卡（千兆對于大數(shù)據(jù)集群來說實在太小，很容易打滿，影響較大），
2. 磁盤盡可能大，
3. 內存不用太高，一般128G就已經特別多了HBase本身對內存的需求并不是配的越大越好。
4. CPU核數(shù)越多越好，HBase本身壓縮數(shù)據(jù)、compaction線程等都是很吃CPU資源的。

二：hbase現(xiàn)集群調優(yōu)參數(shù)

三：根據(jù)實際場景的hbase優(yōu)化;

1.冷熱數(shù)據(jù)

現(xiàn)有業(yè)務：數(shù)據(jù)更新頻繁；冷數(shù)據(jù)；
基于數(shù)據(jù)更新頻繁，blockcache比例減少；如果數(shù)據(jù)不頻，開啟blockcache同時使用bucketcache，減少blockcache比例，設置bucketcache；.

2.數(shù)據(jù)get 、scan操作

• 現(xiàn)有業(yè)務：get操作比較多；
• scan操作少
• 用來表設計參考；

3.數(shù)據(jù)讀寫比例

• 現(xiàn)有業(yè)務：hbase數(shù)據(jù)讀大于寫
• 根據(jù)業(yè)務調整memstore、blockcache或者bucketcache比例；
• 設置數(shù)據(jù)的compact隊列及flush隊列參數(shù)，預防隊列過大，調整性能；

4.數(shù)據(jù)的版本、過期時間、bloom filter、表設計

原則：盡量在表結構設計就考慮性能問題，而不是通過設置參數(shù)在調整

• version：根據(jù)業(yè)務，具體調整數(shù)據(jù)版本version應該幾個？
• TTL,MINVERSION根據(jù)數(shù)據(jù)使用調整數(shù)據(jù)過期時間TTL；及數(shù)據(jù)最小版本號minversion；
• bloom filter：根據(jù)數(shù)據(jù)的使用場景設計bloom filter：行級布隆過濾器，因為它在額外的空間開銷和利用過濾存儲文件提升性能之間取得了更好的平衡。設置數(shù)據(jù)bllomfilter的開啟及設計；
• IN_MEMORY屬性；可以將meta表設置為true；
• 設置rowkey、column長度越短越好，數(shù)據(jù)定義規(guī)則
• 針對get與scan頻繁的字段：盡量使常用查詢的域放入ROWKEY（最重要的放在前面，然后依次拼接），合理設置rowkey，
• 盡量高表使用，通常比寬表性能高50%以上；
• hbase建表預分區(qū)；
• 行記錄：建議多行存儲（不是去增加一個列），更好的get及scan性能，太長的行記錄不易region的split

5.gc優(yōu)化：

GC參數(shù)：

-Xmx50g 
-Xms50g 
-XX:+UseG1GC 
-XX:+UnlockExperimentalVMOptions 
-XX:MaxGCPauseMillis={50/90/500} for SSD/HDD/offline cluster 
-XX:G1NewSizePercent={2/5} for normal/heavy load cluster 
-XX:InitiatingHeapOccupancyPercent=65 
-XX:+ParallelRefProcEnabled
-XX:MaxTenuringThreshold=1 
-XX:G1HeapRegionSize=16m 

GC日志打印添加參數(shù)：
-verbose:gc 
-XX:+PrintGC 
-XX:+PrintGCDetails 
-XX:+PrintGCApplicationStoppedTime 
-XX:+PrintHeapAtGC 
-XX:+PrintGCDateStamps 
-XX:+PrintAdaptiveSizePolicy 
-XX:+PrintTenuringDistribution 
-XX:+PrintSafepointStatistics 
-XX:PrintSafepointStatisticsCount=1 
-XX:PrintFLSStatistics=1

6.hbase讀優(yōu)化客戶端

• scan.setcaching :
  大scan場景下將scan緩存從100增大到500或者1000，用以減少RPC次數(shù)
• scan.setbatch
  每次請求返回的列數(shù)
• scan:
  指定列族、startrow、endrow、filter
• get :
  多get請求采用批量請求；get請求可以指定列族及列；
• scan.setBlockCache(false)：
  如果離線批量讀取請求的話；否則會從cache擠出其他熱點數(shù)據(jù)；
• filter
  優(yōu)先使用keyfilter，而不是valuefilter
• cache
  使用redis等緩存系統(tǒng)

7.hbase寫性能問題：

• HBase理論平均寫延時 < 10ms，時間復雜度O(1)
• 沒有可用的handler響應
  • 考慮增加handler數(shù)目或硬件資源
• 更常見的情況是95%－99%的寫入都很快，但有些 寫入非常慢，甚至上萬倍，一般問題在服務端：
  • 寫入Memstore慢
    • HLog寫入超時——考慮HDFS及硬盤異常
    • GC——考慮優(yōu)化內存使用（GC參數(shù)及算法調優(yōu)有限）
  • Flush慢
    • HFile寫入超時——考慮HDFS及硬盤異常
    • Compaction被觸發(fā)且運行時間長——優(yōu)化高峰期Compaction 策略

8.hbase 客戶端緩存元數(shù)據(jù)

• 客戶端自己發(fā)現(xiàn)自己的緩存是錯的，再去拿新meta信息后重試；hbase客戶端使用重試的方式解決這個問題，本地有緩存的情況下
• 按照緩存直接訪問hregionserver
• regionserver報regionnot online異常
• 客戶端知道了我訪問錯了
• 客戶端去取meta
• 客戶端更新緩存，拿到正確地址
• 客戶端使用正確地址