HBase在存儲時, 使用了LSM樹來進行數據存儲, 會定期將文件進行合并, 以提升數據的查詢效率, LSM樹都是這么處理的. 那么到這里就有一個問題了, HBase在進行文件合并的時候, 勢必會占用大量 IO, 難道不會對正常的業務產生影響么? 抱著這個疑問, 我去找了找HBase文件合并的方式.

在HBase中, 負責文件合并的模塊叫做: ‘Compaction’. 分別看了看合并的類型、觸發條件、執行過程、優缺點等, 算是簡單了解了一下吧.

合并類型

根據文件合并的規模, 可以分為兩種.

Minor

規模較小的合并, 選取相鄰的幾個小的 HFile, 合并成一個更大的 HFile.

Minor 合并的時候, 將多個小文件進行合并, 那么在執行之前, 需要進行待合并文件的選擇, 選取的文件一般來說不能太大, 同時也不能太多, 否則會占用過多系統資源. 最好的情況是把文件較小查詢較多的文件進行合并, 這樣才能達到最好的效果.

Major

將一個 store 中的所有HFile 合并為一個大的 HFile.

這里問了, store是是什么呢? 在HBase中, 根據row key, 會將表水平切分為多個 region, 在每個region中, 又會根據列族對表進行垂直切分為多個store.

這里多說一句, 在每個store中, 并不是所有數據都存在HFile中, 其中部分數據在內存中, 還沒有進行落盤, 所以每個store由兩部分組成: 1. 內存中的有序結構 2. 磁盤中的HFile

同時, 在進行所有文件合并的時候, 還會進行數據清理, 以減少文件占用空間, 清理內容包括:

被刪除的數據

TTL過期的數據

版本號過期的數據

所以可以通過執行全文件合并來進行存儲空間的優化.

優缺點

文件合并也就意味著需要進行文件的讀寫以及生成等操作, 勢必會占用系統資源及網絡帶寬(讀寫要經過 HDFS), 尤其是Major全文件合并也意味著會占用大量系統資源, 所以在合并過程中, 會對上層業務造成一定的影響.

而合并文件的優點也很明顯:

優化查詢速度. 畢竟查詢的時候, 讀取1個文件和讀取100個文件的速度自然不一樣.

減少文件體積. 可以減少文件占用磁盤空間

提高文件的本地化率. 在進行文件合并的時候, 合并后的文件先放到本地, 然后再更新的 HDFS 上, 也就意味著查詢可以直接讀取本地文件. 極端情況下, Major后可以達到100%的本地化. 就剩一個文件了嘛

其中優化查詢速度是合并文件最主要的目的了.

觸發條件

文件合并雖好, 但也不能一直進行合并, 否則占用太多資源, 根本吃不住來自業務的壓力. 那么什么時候會觸發文件合并呢?

1. 文件落盤

store中的內存數據進行落盤的時候, 會觸發文件合并檢查, 當store下的HFile數量超過 n 時, 會觸發Minor.

其中數量n由配置: hbase.hstore.compaction.min

2. 周期性檢查

有一個線程在后臺周期性的進行檢查, 會進行一系列檢查, 比如文件數量、最早文件的更新時間等. 當符合條件的時候, 就會觸發文件合并.

3. 手動觸發

可以在業務低峰期手動觸發Major來進行優化.

合并流程

文件合并一般分為以下幾步:

分別讀取待合并文件的數據, 進行歸并處理, 寫到臨時文件中

將臨時文件挪到store的數據目錄中

將合并信息存到 HLog 中, 并推送文件到 HDFS

將合并前的小文件刪除

其中在步驟1和2出錯的話, 不用任何處理, 因為數據還沒有落盤, 下一次重新合并即可. 在后面出錯, 可以根據HLog繼續執行后面的任務.

---

你要是問我知道這玩意有什么用的話, 我想了想, 唯一的用處就是, 下次如果遇到HBase 占用資源突然劇增的時候, 可以多一個查找的方向吧.

總結

以上是生活随笔為你收集整理的HBase 文件合并的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。