原創(chuàng)文章，轉(zhuǎn)載請注明原作地址：http://www.reibang.com/p/895ab6511819
在介紹HBase Compaction之前饶辙，我們先來看一下HBase是如何存儲和操作數(shù)據(jù)乾戏。
如上圖所示合搅，HRegionServer負(fù)責(zé)打開region，并創(chuàng)建對應(yīng)的HRegion實例歧蕉。當(dāng)HRegion打開之后灾部，它會為每個表的HColumnFamily創(chuàng)建一Store實例，ColumnFamily是用戶在創(chuàng)建表時定義好的惯退，ColumnFamily在每個region中和Store實例一一對應(yīng)赌髓。每個Store實例包含一個或者多個StoreFile實例，StoreFile是對實際存儲數(shù)據(jù)文件HFile的輕量級封裝催跪。每個Store對應(yīng)一個MemStore（也就是寫內(nèi)存）锁蠕。一個HRegionServer共享一個HLog實例。
當(dāng)我們不停地往HBase中寫入數(shù)據(jù)懊蒸，也就是往MemStore寫入數(shù)據(jù)荣倾，HBase會檢查MemStore是否達(dá)到了需要刷寫到磁盤的閾值（更多關(guān)于MemStore刷寫的信息，可以參考HBase Reference Guide關(guān)于MemStore的介紹）骑丸。如果達(dá)到刷寫的條件舌仍，MemStore中的記錄就會被刷寫到磁盤，形成一個新的StoreFile通危≈恚可想而知，隨著MemStore的不斷刷寫菊碟，會形成越來越多的磁盤文件节芥。然而，對于HBase來說逆害，當(dāng)每個HStore僅包含一個文件時头镊，才會達(dá)到最佳的讀效率。因此HBase會通過合并已有的HFile來減少每次讀數(shù)據(jù)的磁盤尋道時間魄幕，從而提高讀速度相艇，這個文件合并過程就稱為Compaction。在這里需要說明的是梅垄，顯然磁盤IO也是有代價的厂捞，如果使用不慎的話输玷，不停地重寫數(shù)據(jù)可能會導(dǎo)致網(wǎng)絡(luò)和磁盤過載。換句話說靡馁，compaction其實就是用當(dāng)前更高的磁盤IO來換取將來更低的磁盤尋道時間欲鹏。因此，何時執(zhí)行compaction臭墨，其實是一個相當(dāng)復(fù)雜的決策赔嚎。
HBase的compaction分為minor和major兩種。minor合并負(fù)責(zé)將幾個小文件合并成一個較大的文件胧弛；major合并是將一個HStore中的所有文件合并成一個文件尤误。每次觸發(fā)compact檢查。系統(tǒng)會自動決定執(zhí)行哪一種compaction（合并）结缚。有三種情況會觸發(fā)compact檢查：
- MemStore被刷寫到磁盤损晤；
- 用戶執(zhí)行shell命令compact、major_compact或者調(diào)用了相應(yīng)的API红竭；
- HBase后臺線程周期性觸發(fā)檢查尤勋。
除非是用戶使用shell命令major_compact或者調(diào)用了majorCompact() API（這種情況會強制HBase執(zhí)行major合并），在其他的觸發(fā)情況下茵宪，HBase服務(wù)器會首先檢查上次運行到現(xiàn)在是否達(dá)到一個指定的時限最冰。如果沒有達(dá)到這個時限，系統(tǒng)會選擇執(zhí)行minor合并稀火，接著檢查是否滿足minor合并的條件暖哨。
major合并中會刪除那些被標(biāo)記為刪除的數(shù)據(jù)、超過TTL（time-to-live）時限的數(shù)據(jù)凰狞，以及超過了版本數(shù)量限制的數(shù)據(jù)篇裁，將HStore中所有的HFile重寫成一個HFile。如此多的工作量服球，理所當(dāng)然地茴恰，major合并會耗費更多的資源，合并進(jìn)行時也會影響HBase的響應(yīng)時間斩熊。在HBase 0.96之前，默認(rèn)每天對region做一次major compact伐庭，現(xiàn)在這個周期被改成了7天粉渠。然而，因為major compact可能導(dǎo)致某臺server短時間內(nèi)無法響應(yīng)客戶端的請求圾另，如果無法容忍這種情況的話霸株，可以關(guān)閉自動major compact，改成在請求低谷期手動觸發(fā)這一操作集乔。
minor合并的關(guān)鍵是去件，要如何挑選那些被合并的小文件？0.96版本之前，HBase的合并策略只有一個RatioBasedCompactionPolicy尤溜。這個策略中有三個重要參數(shù)：首先是hbase.hstore. compaction.min. size和hbase.hstore. compaction.max. size倔叼，在minor合并中，所有大小超過max. size的文件都會被排除在外宫莱，而min. size其實是一個閾值丈攒，minor合并會盡可能多地包括那些文件大小低于min. size的文件；在一次minor合并中授霸，合并的文件數(shù)量最多不能超過hbase.hstore. compaction.max巡验。另外，這個策略選擇需要合并的文件時碘耳，總是優(yōu)先選擇較老的文件显设，也就意味著，沿著時間軸從最老的文件開始掃描辛辨，HBase會選擇合并它掃描到的第一個滿足合并策略的文件集合敷硅。
然而，實際操作中發(fā)現(xiàn)RatioBasedCompactionPolicy的表現(xiàn)并不好愉阎，因為這個策略假設(shè)越老的文件大小越大绞蹦，而實際情況并不是這樣，比如bulkLoad導(dǎo)入的新文件大小就很可能大于舊文件榜旦。于是幽七，之后HBase加入了一個新策略ExploringCompactionPolicy。在這個策略中溅呢，HBase不是選擇第一個符合合并策略的文件集合澡屡，而是考慮了所有符合要求的文件集合，并從中選擇文件數(shù)量最多的集合（當(dāng)有多個這樣的文件集合時咐旧，選擇總文件大小最小的那個集合）驶鹉。這樣導(dǎo)致的影響是，HBase總是選擇合并會為IO帶來最佳改善的文件集合铣墨。
隨著compaction的進(jìn)行室埋，當(dāng)所有文件中最大的那個超過了配置的最大存儲文件大小，又會觸發(fā)region拆分（如果region拆分沒有被禁止的話）伊约。
參考鏈接：
http://blog.cloudera.com/blog/2013/12/what-are-hbase-compactions/
https://hbase.apache.org/book.html#compaction
《HBase權(quán)威指南》
