作者: 大圓那些事 | 文章可以轉載，請以超連結形式標明文章原始出處和作者資訊
網址: http://www.cnblogs.com/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儘早觸發執行。