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的發生，某些資料會被反覆讀寫多次