Hbase問題小結(一)

1. Hbase讀寫優化

• 寫：
  批量寫、異步批量提交、多線程併發寫、使用BulkLoad寫入、表優化（壓縮算法、預分區、合理的rowkey設計、合理關閉WAL或異步WAL）

SKIP_WAL：只寫緩存，不寫HLog日誌。這種方式因爲只寫內存，因此可以極大的提升寫入性能，但是數據有丟失的風險。在實際應用過程中並不建議設置此等級，除非確認不要求數據的可靠性。
ASYNC_WAL：異步將數據寫入HLog日誌中。
SYNC_WAL：同步將數據寫入日誌文件中，需要注意的是數據只是被寫入文件系統中，並沒有真正落盤，默認。
FSYNC_WAL：同步將數據寫入日誌文件並強制落盤。最嚴格的日誌寫入等級，可以保證數據不會丟失，但是性能相對比較差。

• 讀：
  批量get請求、合理設置scan緩存大小、指定請求列族或者列名、設置只讀Rowkey過濾器、關閉ResultScanner、表優化（配置表的優先緩存、Block大小、數據編碼、壓縮方式）

---

2. bulkload入庫的hfile是否有限制，可以怎麼調整參數

• hbase.hregion.max.filesize:默認配置：10737418240（10G）

最大文件大小。
如果一個區域的HFiles的大小之和超過了這個值，那麼該區域將被一分爲二。
該選項的工作方式有兩種選擇，
第一種是當任何store的大小超過閾值時，然後分割，
另一種是整個區域的大小超過閾值，然後分割，它可以通過hbase.hregion.split.overallfiles進行配置。

• hbase.hregion.split.overallfiles: Default true

當檢查到分裂時，我們是否應該合計整個區域的文件大小。

• hbase.mapreduce.bulkload.max.hfiles.perRegion.perFamily:默認配置：100

允許的hfile的最大個數，但是在bulkload中默認爲32，可以調整這個參數進行修改

---

3. rowkey設計原則

• Rowkey的唯一原則
• Rowkey的排序原則:HBase的Rowkey是按照ASCII有序設計的
• Rowkey的散列原則：Rowkey應均勻的分佈在各個HBase節點上(Region熱點)

解決熱點問題：
Reverse反轉：（典型：手機號碼）；
Salt加鹽:將每一個Rowkey加一個前綴，前綴使用一些隨機字符，使得數據分散在多個不同的Region，達到Region負載均衡的目標。前綴是隨機的，讀這些數據時需要耗費更多的時間，所以Salt增加了寫操作的吞吐量，不過缺點是同時增加了讀操作的開銷。(當然這個缺點在很多情況下也是可以解決的，比如根據rowkey計算固定的Salt)；
Hash散列或者Mod：用Hash散列來替代隨機Salt前綴的好處是能讓一個給定的行有相同的前綴；

• Rowkey的長度原則：建議是越短越好，
  其一是HBase的持久化文件HFile是按照KeyValue存儲的，
  如果Rowkey過長，在大數據量情況下Rowkey本身就要佔據大量空間，會極大影響HFile的存儲效率。
  二是MemStore緩存部分數據到內存，
  如果Rowkey字段過長內存的有效利用率會降低，系統無法緩存更多的數據，這會降低檢索效率。

---

4. 簡單介紹Compaction

HBase是基於一種LSM-Tree（Log-Structured Merge Tree）存儲模型設計的，寫入過程如下

• Compaction作用：Compaction操作屬於資源密集型操作特別是IO密集型操作，以短時間內的IO消耗，以換取相對穩定的讀取性能。
• 分類：Minor Compaction 與 Major Compaction，通常我們簡稱爲小合併、大合併

類型	作用	刪除的內容
Minor Compaction	選取一些小的、相鄰的HFile將合併成一個大的HFile	1. 默認刪除選取HFile中的TTL過期數據
Major Compaction	將一個Store中所有的HFile合併成一個HFile	1.被刪除的數據（打了Delete標記的數據） 2.TTL過期數據 3.版本號超過設定版本號的數據

• 觸發條件：

觸發條件	header 2
memstore flush	compaction的根源就在於flush， memstore達到一定條件就會觸發flush生成HFile, compact的根本目的是控制HFile的數量。 所以每次flush之後，都會判斷是否要進行compaction
後臺線程週期性檢查	後臺線程 CompactionChecker 會定期檢查是否需要執行compaction hbase.server.thread.wakefrequency * hbase.server.compactchecker.interval.multiplier
手動觸發	HBase Shell、Master UI界面或者HBase API

• 相關參數

header 1	header 2
hbase.hregion.majorcompaction	Major compaction週期性時間間隔，默認值604800000，單位ms major compaction耗時、耗資源，一般禁用
hbase.hregion.majorcompaction.jitter	抖動參數，默認值0.5 避免major compaction同時在各個regionserver上同時發生 major compaction就會在+\- 兩者乘積的時間範圍內隨機發生
hbase.hstore.compaction.min	一次minor compaction最少合併的HFile數量，默認值 3
hbase.hstore.compaction.max	一次minor compaction最多合併的HFile數量，默認值 10
hbase.hstore.compaction.min.size	filesize < 該參數值的爲適合進行minor compaction文件， 默認值 128M（memstore flush size）
hbase.hstore.compaction.max.size	filesize > 該參數值的不會加入minor compaction 默認值Long.MAX_VALUE，表示沒有什麼限制
hbase.hstore.compaction.ratio	判斷filesize > hbase.hstore.compaction.min.size 的HFile是否也是適合進行minor compaction,默認值1.2。
hbase.hstore.compaction.ratio.offpeak	在非高峯時段是包含更大的StoreFiles壓縮比例 默認5.0，需要配合hbase.offpeak.start.hour hbase.offpeak.end.hour使用
hbase.regionserver.thread.compaction.throttle	compaction線程的選擇,默認2.5G(按官網應該是1.25G) 如果compaction大於此閾值，則將其放入largeCompactions， 否則放入smallCompaction hbase.hstore.compaction.max * hbase.hregion.memstore.flush.size
hbase.regionserver.thread.compaction.large hbase.regionserver.thread.compaction.small	largeCompactions與smallCompactions的線程池大小
hbase.hstore.blockingStoreFiles	每次刷新MemStore都會寫入一個StoreFile 在任何一個Store中存在超過這個數量的StoreFile， 該region的更新就會被阻塞，直到compaction完成， 或者超過hbase.hstore.blockingWaitTime。 默認：16
hbase.hstore.blockingWaitTime	在達到hbase.hstore.blockingStoreFiles定義的StoreFile限制後， 該region將阻塞更新一段時間。 在這段時間過後，即使compaction沒有完成，該region也將停止阻塞更新。 默認9000，15min

• Compaction 線程池
  HBase RegionServer內部專門有一個 CompactSplitThead，
  用於維護執行minor compaction、major compaction、split、merge操作線程池。
  其中compaction操作有關的線程池稱爲largeCompactions與smallCompactions，分別用於處理大規模compaction、小規模compaction。默認大小爲均爲1。

這裏的minor compaction、major compaction與largeCompactions、smallCompactions並不是對應的。參考上面參數說明

• Compaction 對讀寫請求的影響
  存儲上的寫入放大,特別是在寫多讀少的場景下，寫入放大就會比較明顯,
  隨着minor compaction以及major Compaction的發生，某些數據會被反覆讀寫多次