作者: 大圓那些事 | 文章可以轉載，請以超鏈接形式標明文章原始出處和作者信息

網址: http://www.rzrgm.cn/panfeng412/archive/2013/06/08/hbase-slow-query-troubleshooting.html

最近HBase集群遇到過一次慢查詢請求的問題，下面是對這一問題的具體描述及排查解決過程。

1. 發現問題

項目中有一張HBase表，每天凌晨以后會集中批量導入一批數據，導入數據量很大，在千萬到億的量級，然后白天為用戶提供查詢服務。某天突然發現，該表按照各個region（共計256個）分別僅scan少數幾條數據時，部分region的查詢請求的響應時間很慢，長達10秒甚至幾十秒不等。

2. 排查問題

首先，通過查看HBase自帶的region server監控界面上，看到這張表的每個region下面只有1~3個StoreFile，排除了由于StoreFile過多導致查詢響應慢的情況。

接著排查，發現這張表的TTL為5天，因此會有大量過期數據存在。同時，由于這張表每天早上會導入一批數據（其中上周3.22那天集中導入了7億多條記錄），而集群的major compact周期配置是7天，雖然到今天為止3.22號的數據已經過期了，但是還沒有經過major compact觸發清除過期的數據，因此，存在大量過期但尚未被清除的數據，導致即使按照各個region分別僅scan少數幾條數據，仍需要過濾掉一大批過期的數據（從監控看到當時的Block Cache訪問量比平時高了一倍左右，如下圖所示），才能掃到實際有用的數據，所以查詢響應時間很慢。

3. 解決問題

針對這一問題，有以下兩種解決方法：

1）每天早上導入數據后，強制觸發一次major compact操作（見HBaseAdmin的majorCompct方法，異步執行），使得表中每個region中的過期數據可以被及時清除掉。

2）由于集群的major compact周期為7天，而表的TTL為5天，因此可以將major compact周期調小（配置參數為hbase.hregion.majorcompaction，單位為毫秒；同時，hbase.offpeak.start.hour可以設置major compact啟動的小時，例如，設置為1，可保證在1點后觸發），從集群級別保證major compact盡早觸發執行。