HBase高性能查詢的示例分析

這篇文章主要介紹了HBase高性能查詢的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

1.為什么要compaction

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

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

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

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

2.compaction的分類

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

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

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

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

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

• 用戶強制執(zhí)行major compaction

• 長時間沒有compact，且候選文件小于閾值（hbase.hstore.compaction.max）

• Store中含有reference文件（split產(chǎn)生的臨時文件），需要通過 major compact進行數(shù)據(jù)遷移，刪除臨時文件

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

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

1）MemStore flush:

這個在一開始就提到了，相信也很容易理解。因為每次MemStore flush會產(chǎn)生新的HFile文件，而文件數(shù)量超過限制，自然就觸發(fā)了compaction。這里需要注意的是，我們在 深入HBase架構 一文中已經(jīng)提到，memstore是以region為單位進行flush的，也就是說，一個region內(nèi)的任意一個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來達到清理無用數(shù)據(jù)的目的。

3）手動觸發(fā)：

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

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

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

4.HFile合并過程

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

2）將臨時文件移動到對應的region的數(shù)據(jù)目錄

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

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

5.compaction的副作用分析

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

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

感謝你能夠認真閱讀完這篇文章，希望小編分享的“HBase高性能查詢的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業(yè)資訊頻道，更多相關知識等著你來學習!