先給結論吧：HBase利用compaction機制，通過大量的讀延遲毛刺和一定的寫阻塞，來換取整體上的讀取延遲的平穩(wěn)。

1.為什么要compaction

在上一篇 HBase讀寫 中我們提到了，HBase在讀取過程中，會創(chuàng)建多個scanner去抓去數據。

其中，會創(chuàng)建多個storefilescanner去load HFile中的指定data block。所以，我們很容易就想到，如果說HFile太多的話，那么就會涉及到很多磁盤IO，這個就是常說的“讀放大”現象。

因此，就有了今天的主題，HBase的核心特性——compaction。

通過執(zhí)行compaction，可以使得HFile的數量基本穩(wěn)定，使得IO seek次數穩(wěn)定，然后每次的查詢rt才能穩(wěn)定在一定范圍內。

2.compaction的分類

compaction分為兩種，minor compaction和major compaction。

Minor compaction主要是將一些相鄰的小文件合并為大文件，這個過程僅僅做文件的合并，并不會刪除deleted type的數據和ttl過期的數據。

Major compaction是指將一個HStore下的所有文件合并為一個HFile，這個過程會消耗大量系統(tǒng)資源，一般線上會關閉自動定期major compaction的功能（將參數hbase.hregion.majorcompaction設為0即可關閉，但是flush的觸發(fā)還是會進行），改為手動低峰執(zhí)行。這個過程會刪除三類數據：標記為刪除的數據、TTL過期的數據、版本號不滿足要求的數據。

具體什么時候觸發(fā)哪種類型的compaction呢？

滿足以下任意條件會觸發(fā)major compaction，否則就是minor compaction：

• 用戶強制執(zhí)行major compaction
• 長時間沒有compact，且候選文件小于閾值（hbase.hstore.compaction.max）
• Store中含有reference文件（split產生的臨時文件），需要通過 major compact進行數據遷移，刪除臨時文件

3.compaction的觸發(fā)時機

compaction的觸發(fā)時機一共有三種：

1）MemStore flush:

這個在一開始就提到了，相信也很容易理解。因為每次MemStore flush會產生新的HFile文件，而文件數量超過限制，自然就觸發(fā)了compaction。這里需要注意的是，我們在 深入HBase架構 一文中已經提到，memstore是以region為單位進行flush的，也就是說，一個region內的任意一個HStore下面的memstore滿了，這個region下的所有HStore的memstore都會觸發(fā)flush。然后每個HStore都有可能觸發(fā)compaction。

2）后臺線程周期性檢查

HBase有一個后臺線程CompactionChecker，會定期巡檢觸發(fā)檢查，是否進行compaction。

這里和flush觸發(fā)的compaction有所不同，這里先檢查文件樹是否大于閾值，大于就觸發(fā)compaction。如果沒有大于閾值，還會檢查下HFile里面的最早更新時間，是否早于某個閾值（hbase.hregion.majorcompaction），如果早于，就觸發(fā)major compaction來達到清理無用數據的目的。

3）手動觸發(fā)：

由于我們擔心major compaction會影響業(yè)務，因此會選擇業(yè)務低峰期進行手動觸發(fā)。

還有一部分原因，是用戶執(zhí)行ddl后，希望理解生效，也會執(zhí)行手動觸發(fā)major compaction。

最后，可能是因為磁盤容量不夠了，需要major compaction來手動清理無效數據，合并文件。

4.HFile合并過程

1）讀取待合并的HFile的key value，寫入臨時文件中

2）將臨時文件移動到對應的region的數據目錄

3） 將compaction的輸入文件路徑和輸出文件路徑寫入WAL日志，然后強行執(zhí)行sync

4）將對應region數據目錄下的輸入文件全部刪除

5.compaction的副作用分析

當然，compaction本身也要涉及到大量文件的讀寫，在表現上就是會有一定的讀延遲毛刺。因此，我們可以認為，compaction過程是使用短時間的大量IO消耗來換取后續(xù)查詢的低延遲。

另一方面，假設處于長時間的高寫入量，HFile的數量一直增長，compaction的速度趕不上HFile增長的速度，那么，HBase會暫時阻塞寫請求。當每次memstore進行flush的時候，如果一個HStore中的HFile的數量超過了hbase.hstore.blockingStoreFIles（默認為7），那么就會暫時阻塞flush的動作，阻塞時間為abase.hstore.blockingWaitTime。當阻塞時間過去后，觀察HFile的數量下降到上述值，那么就會繼續(xù)flush的操作。這樣，就保證了HFile數量的穩(wěn)定，但是對寫入會有一定的速度影響。

都看到最后了，原創(chuàng)不易，點個關注，點個贊吧～
知識碎片重新梳理，構建Java知識圖譜：https://github.com/saigu/JavaKnowledgeGraph（歷史文章查閱非常方便）
掃碼關注我的公眾號“阿丸筆記”，第一時間獲取最新更新。同時能免費獲取海量Java技術棧電子書、各個大廠面試題哦。

總結

以上是生活随笔為你收集整理的hbase查询_【从零单排HBase】HBase高性能查询揭秘的全部內容，希望文章能夠幫你解決所遇到的問題。

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