HBase 常用優化策略
阿新 • • 發佈：2019-02-14
什麼導致HBase效能下降？
- jvm記憶體分配和GC回收策略
- 與HBase執行機制相關配置不合理 （hbase-site.xml配置優化）
- 表結構設計不合理以及使用者使用方式不合理
HBase資料儲存過程
- HBase寫入的時候會先寫入memstore達到一定大小，會flush到磁碟儲存成HFile，當HFile小檔案太多會執行compact操作進行合併。對HBase來說，當每一個store，僅僅包含一個檔案的時候 查詢效率才是最高的，因為如果小檔案太多了，查詢的時候需要的定址時間就越長，因此HBase會合並小檔案，從而減少磁碟尋道時間，從而提高讀取速度，這個過程就成為compact。但是執行compact器間，可能會阻塞資料的寫入和讀取，那麼合適執行compact是一個複雜的操作，compat的時候選擇哪些檔案，選擇哪些合適執行緒池才能達到最大的效能，是一個很重要的決策。
- 如果region太大，會將region進行split，分配到不同的region進行管理。這裡其實也是非常耗費效能的操作，可能會造成當前的region不能讀取，也不能寫入。
split概念
- split：將一個region，且分為兩個region
compact概念
- minor compaction：
選取一些小的，相鄰的storefile將他們合併成一個更大的storefile。 - major compaction：
將所有的storefile合併成一個storefile，清理無意義的資料：
（1）被刪除的資料（被刪除的資料只是被標記刪除，並沒有真正的刪除）。
（2）TTL過期的資料。
（3） 版本號超過設定版本號的資料。
HBase Compact檢查
- 當MemStore 被flush到磁碟
- 使用者執行shell命令compact，major_compact或者呼叫相應的API
- HBase後臺執行緒週期性觸發檢查
HBase 優化
常用服務端配置優化
- jvm設定與GC設定
可以適當增加regionserver記憶體，regionserver記憶體設定大一些， 可以有效避免full gc，
並且對block cache 支援也會好一點。 - hbase-site.xml部分屬性配置
| HBase properties | 簡介 |
|---|---|
| hbase.regionserver.handler.count | rpc請求的執行緒數量，預設值是10，提升handler大小，可以有效提升regionserver接收請求的能力，但是也不是越大越好，取決於硬體效能 |
| hbase.hregion.max.filesize | 當region的大小大於設定值後hbase就開始split，預設大小是10G， 可以根據儲存的內容，合理配置，建議手動進行split操作 |
| hbase.hregion.majorcompaction | major compaction的執行週期，預設為1天，建議設定為0，禁止major compaction，生產環境中，進行major compaction可能會執行一天之久，可以在業務低峰的時候，進行手動合併，或者通過指令碼，定期執行合併操作。 |
| hbase.hstore.compaction.min | 任何一個store，裡面的storefile超過該值，會觸發預設的合併操作，預設值是3 |
| hbase.hstore.compaction.max | 一次最多合併多少個storefile，如果storefile比較大， 應該把這個值，設定小一點，避免記憶體溢位 |
| hbase.hstore.blockingStoreFiles | 一個region中的store內有超過XXX個storefile時候，則block所有的寫請求進行compaction |
| hbase.hregion.memstore.flush.size | memstore 超過該值會被flush，根據記憶體大小，可以適當調整大一點 |
| hbase.hregion.memstore.block.multiplier | 如果memstore記憶體大小超過flush.size*multiplier，會阻塞該memstore的寫操作，建議將這個值設定為5，如果設定太大，可能會出現記憶體溢位 |
| hbase.block.cache.size | regionserver的block cache的記憶體大小限制，在偏向讀的業務中可以適當調大一些 |
一般我們會手動執行split和compact，以降低這些操作可能對正常業務造成的不必要的影響，我們也可以開發指令碼，來在業務低峰，定時執行split和compact 操作。
常用優化策略（以實際需求為主）
- 預先分割槽
HBase在建表的時候，預設在一個regionserver自動建立一個region，當region太大的時候，會執行split操作，將一個region split 成兩個region，併發送到不同的regionserver進行維護 以實現負載均衡，但是split又是一個比較耗時的操作。
建立HBase表的時候預先建立一些空的Regions，並指定Region的儲存範圍，這樣資料會被寫入到指定的region裡面，我們可以減少很多的IO操作，通過預先分割槽，還可以有效解決資料傾斜的問題，我們可以把頻繁訪問的資料，放到多個region中，把不常訪問資料，放入到一個或者幾個region中。 - RowKey的優化
1.可以根據三維對資料快速定位rowkey+cf:qualifer+timestamp
rowkey可以快速定位一條記錄，兩種方式，get 根據rowkey獲取某一條記錄，也可以scan 通過startrow 和stoprow進行範圍查詢
2.利用HBase預設排序的特點，將一起訪問的資料放到一起
3.防止熱點問題，避免使用時序或者單調遞增或者遞減等。
熱點問題，就是在分散式系統中，大量的client去訪問叢集中的一個或者極少數的幾臺機器，造成熱點機器，超出自身處理能力，從而造成整個叢集出現問題。
如果解決熱點問題呢？ 可以通過加鹽，也就是加隨機數，或者hash，反轉等方式，來解決rowkey可能存在的熱點問題。
4.rowkey的長度應該儘可能短，過長對regionserver的磁碟，記憶體都會過大的消耗。 - Column的優化
1.列明和列描述名稱儘可能短
2.HBase對多個cf的支援並不好，建議一個表中的cf 最好不要超過三個 - Schema的優化
HBase表在設計的時候，很可能根據業務設定成寬表（一種“列多行少的設計”）或者高表（一種“行少列多”的設計）
高表：查詢效能高，吞吐量大，快取更多的行，元資料開銷更大（rowkey多，region多）
寬表：事務性更好，HBase事務是建立在行上的，寬表，一個行有多個列，可以有效保證事務性。
設計表的時候，沒必要追求高表，寬表，要根據業務進行選擇。
HBase 讀寫效能優化
HBase寫優化策略
- 同步批量提交 or 非同步批量提交
預設是同步提交，要麼全部成功，要麼丟擲異常，非同步提交，有可能會丟失資料，如果為了提高效能，又能夠忍受異常情況下部分資料丟失，可以使用非同步提交方式，可以大大提升，寫入效能。 - WAL優化，是否必須，持久化等級
WAL有兩個作用，一個是防止memstore中資料丟失了，可以根據memstore中的資料進行恢復，另一個就是叢集中不同HBase節點間的非同步複製，預設是開啟WAL的。如果業務允許，對於異常情況下的部分資料丟失可以忍受，更關係寫入的吞吐量，這個時候可以考慮關閉掉WAL，或者採用非同步寫入WAL，這些都能夠提升寫入效能，但是對於寫入資料的完整性無法保證。
HBase讀優化策略
- 客戶端：Scan快取設定，批量獲取
客戶端在讀取的時候，可以設定快取大小，通常來說，一次讀取，會返回大量的資料，客戶端在通過scan檢索資料的時候，實際上不會一次就返回所有的資料，而是會多次通過rpc請求載入，這樣設計一方面是因為大量的io請求，可以會導致網路頻寬嚴重消耗，進而影響其他，業務，另一方面，一次返回太多的資料，導致客戶端發生記憶體溢位。客戶端首先載入一部分資料到本地，然後遍歷，然後再去載入一部分資料，然後遍歷。。。
如果資料量非常大，可以適當調大一點cache的大小，減少rpc請求的次數。
檢索的時候，我們需要指定列簇，因為一個表，可能有多個列簇，每一個列簇儲存在不同的region中，如果不指定列簇，那麼檢索的資料量就比較大了。 - 服務端：BlockCache配置是否合理，HFile是否過多
如果BlcokCache 如果不能夠命中，那麼HFile 如果過多，那麼又會非常影響效能，因為多個HFile會增加磁碟定址時間，因此需要執行compact，對檔案進行合併。 - 表結構設計問題：根據具體業務，對錶結構進行設計 優化。