HBase在資源緊張時降低IO的方案彙總
阿新 • • 發佈：2018-12-21
| Hbase在資源緊張時降低IO的手段 | ||||
| 以下優化手段的前提 | 1、一切都是瓶頸的時候(記憶體、cpu、IO)，所有手段都作用不大 2、沒有絕對的有效手段，必須針對具體業務場景去分析 3、大多數情況下，都是磁碟IO存在問題(CPU和記憶體其實問題都不大，除非配置太差) | |||
| 優化分類 | 優化手段 | 優化原理 | 適用場景(前提) | 注意事項 |
| 表設計 | 適當增加列族個數，一起讀寫的列放在一個列族 | family多，獲取單個cell資料時就不會去掃描同一rowkey的所有資料(按列族儲存)，明顯降低IO | 1、讀多寫少(多family反而增加寫的開銷，甚至帶來過多的split)
2、經常是某些欄位一起讀（有規律的）
3、記憶體較為充裕
每個region的每個family對應一個store，每個store對應一個memstore |
1、family不要超過3個 2、如果讀少寫多，反而整體上增加了IO 3、一般建議單列族，除非IO確實成為瓶頸 |
| 預建分割槽 | 一定要預建分割槽，可以分散IO壓力，同時各節點儲存也是均勻的，否則一旦形成熱點，不光讀寫受影響，甚至還要來回遷移儲存的資料，造成更多的IO和網路開銷(昨天說的想寫入時就在幾個節點上，從而不預建分割槽是不可行的，應該採用其他手段解決) | 一般場景都比較適合 | 分散IO，起到區域性降低IO的作用 | |
| 合理規劃hfile大小，減少split | 頻繁的split會帶來額外的開銷，所以hfile的maxsize應該根據資料規模來預估，使其儘量不分裂 |
一般場景都比較適合 | ||
| maxversion設定為1 | 儲存一個版本較少儲存，可緩解IO | 1、不需要儲存多版本且存在重複寫入的場景 | 僅能緩解IO | |
| 高寬表結合 | 對於隨時間變化的指標資料可以採用寬表，以時間段作為列名；為避免太寬導致單條資料過大，可以高寬表結合，比如以10分鐘為一個時間段，每天在單起一行記錄 | 時間線查詢 | 對於時間線查詢的場景可降低IO | |
| rowkey設計 | 將(Long.MAX_VALUE – timestamp)加到rowkey | 如果最近寫入HBase表中的資料是最可能被訪問的，可以考慮將時間戳作為row key的一部分，由於是字典序排序，所以可以使用Long.MAX_VALUE – timestamp作為row key，這樣能保證新寫入的資料在讀取時可以被快速命中。 |
最近寫入資料最可能被訪問的場景 | 緩解IO |
| 讀寫操作 | 使用寫快取(以位元組為單位) | 較少寫入次數 | 較少網路和磁碟IO | |
| 批量讀寫(put(list)) | 只有一次IO開銷 | 實時性要去高，網路和IO壓力較大 | 降低IO開銷 | |
| 使用第三方前段快取 | 如果最近的資料經常會讀，比如半小時內的資料，前段加上快取，可以較少對磁碟讀寫 | 可容忍部分資料差異 | 降低IO開銷 採用合理的淘汰演算法甚至是TTL redis貌似有六種淘汰策略+TTL | |
| bulkload入庫 | 基於mr思想，直接生成Hbase底層的資料檔案，不寫wal，降低大量IO，幾乎不影響讀 | 1、適合入庫實時性要求不高的場景 2、IO很緊張 | ||
| blockcache | 以額外的記憶體開銷換取IO的下降 | 採用LRU淘汰 | ||
| 適當放寬flush門欄 | 寫資料先寫入memstore，超多大小才flush到磁碟，可以把閾值適當調大，使剛寫入的熱資料在記憶體裡待一會，增大快取命中率，同時也降低了寫磁碟的次數 | 1、剛寫入的資料讀寫最頻繁 2、記憶體不是瓶頸 | 閾值不能太大，否則flush比較慢 hbase.regionserver.global.memstore.upperLimit | |
| 關閉WAL(慎用) | 寫入時關閉WAL可以省下一筆IO開銷 | 1、允許丟少量資料的場景 | 不到萬不得已不建議使用 | |
| 資料角度 | 忙時關閉major compact，閒時開啟major compact | 一般的業務場景都是有忙閒時的，可能在凌晨讀寫壓力會很小，所以完全有可能把major compact放到閒時去做，以緩解忙時的IO | 1、業務場景有忙閒時 | 只是緩解忙時的IO，把他轉移到閒時,效果應該蠻明顯 |
| 合理使用壓縮演算法(檔案級別) | gzip壓縮可以降低儲存需求，緩解IO壓力 | 1、cpu沒有壓力但IO壓力很大 | 會帶來額外的CPU開銷，一般推薦snappy，IO特別緊用gzip | |
| 使用PrefixTreeCompression | HBase的KeyValue儲存是按照Row/Family/Qualifier/TimeStamp/Value的形式儲存的，Row/Family/Qualifier這些相當於字首，如果每一行都按照原始資料進行儲存會導致佔據儲存空間比較大 | 對IO有緩解作用 | ||
| 使用Bloomfilter | 對於某個region的隨機讀，HBase會遍歷讀memstore及storefile（按照一定的順序），將結果合併返回給客戶端。如果你設定了bloomfilter，那麼在遍歷讀storefile時，就可以利用bloomfilter，忽略某些storefile | 1、記憶體不是很緊張一般都建議使用 | Bloomfilter是一個列族（cf）級別的配置屬性，如果你在表中設定了Bloomfilter，那麼HBase會在生成StoreFile時包含一份bloomfilter結構的資料，稱其為MetaBlock；MetaBlock與DataBlock（真實的KeyValue資料）一起由LRUBlockCache維護。所以，開啟bloomfilter會有一定的儲存及記憶體cache開銷 | |
| Hbase本身 | 使用較新的版本 | 新版本對IO讀寫等各方面有優化的 | 不要用最新版，需要嚴格測試，或者參考其他公司的使用情況 | |