Hbase compact和split跟蹤舉例分析

本篇內(nèi)容主要講解“Hbase compact和split跟蹤舉例分析”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Hbase compact和split跟蹤舉例分析”吧!

為了準確了解HBASE內(nèi)部工作原理，我們需要做一些測試，在大量數(shù)據(jù)插入的情況下，HBASE內(nèi)部到底有什么表現(xiàn)？  比如插入速度，  hstore compact，split等相關(guān)活動，了解了這些才能更好的維護HBASE系統(tǒng)本身。

此次測試會有幾輪，所以測試到哪里就寫到哪里，我隨便找了一張大概120W來的表，我會寫一個mapreduce任務，來讀取這張表，再寫入另外一個測試表: test2, 沒有選擇更大的表是因為畢竟整個拷貝是需要時間，通常20分鐘-30分鐘，太大的表，不太利于跟蹤。 拷貝過程，HBASE會針對此表有相關(guān)的活動日志，依據(jù)日志，我們來看看HBASE到底在干什么。

測試開始, 下面是我的mapreduce任務進度，reduce開始的時間，實際就是寫入HBASE的時間，那么從11:36開始，應該HBASE在插入

17/06/29 11:31:41 INFO mapreduce.Job:  map 71% reduce 0%
17/06/29 11:32:07 INFO mapreduce.Job:  map 81% reduce 0%
17/06/29 11:32:08 INFO mapreduce.Job:  map 86% reduce 0%
17/06/29 11:32:19 INFO mapreduce.Job:  map 86% reduce 29%
17/06/29 11:36:07 INFO mapreduce.Job:  map 95% reduce 29%
17/06/29 11:36:11 INFO mapreduce.Job:  map 96% reduce 29%

跟蹤日志過程

1.  11:36分日志顯示flush一個memstore,大小為129M， 這個和設(shè)置的參數(shù)值是一樣的，hbase.hregion.memstore.flush.size=128M, flush之后，會生產(chǎn)一個hfile，實際文件大小為48.9M， 另外注意最后的compaction requested=false

2017-06-29 11:36:34,505 INFO org.apache.hadoop.hbase.regionserver.HRegion: Flushing 1/1 column families, memstore=129.14 MB
2017-06-29 11:36:36,157 INFO org.apache.hadoop.hbase.regionserver.DefaultStoreFlusher: Flushed, sequenceid=54, memsize=129.1 M, hasBloomFilter=true, into tmp file hdfs://nameservice1/hbase/data/default/test2/786ef51a9c89f0e31073ba8aafc7ef94/.tmp/047e3c0dad4940788b97b203495c1536
2017-06-29 11:36:36,182 INFO org.apache.hadoop.hbase.regionserver.HStore: Added hdfs://nameservice1/hbase/data/default/test2/786ef51a9c89f0e31073ba8aafc7ef94/cf/047e3c0dad4940788b97b203495c1536, entries=644303, sequenceid=54, filesize=48.9 M
2017-06-29 11:36:36,185 INFO org.apache.hadoop.hbase.regionserver.HRegion: Finished memstore flush of ~129.14 MB/135411576, currentsize=36.78 MB/38569776 for region test2,,1498706810880.786ef51a9c89f0e31073ba8aafc7ef94. in 1681ms, sequenceid=54, compaction requested=false

2. 第二次刷新， 注意最后的compaction requested=false,

2017-06-29 11:36:41,766 INFO org.apache.hadoop.hbase.regionserver.DefaultStoreFlusher: Flushed, sequenceid=107, memsize=128.7 M, hasBloomFilter=true, into tmp file hdfs://nameservice1/hbase/data/default/test2/786ef51a9c89f0e31073ba8aafc7ef94/.tmp/57d95a2f46454109b336161e9ae9bc14
2017-06-29 11:36:41,786 INFO org.apache.hadoop.hbase.regionserver.HStore: Added hdfs://nameservice1/hbase/data/default/test2/786ef51a9c89f0e31073ba8aafc7ef94/cf/57d95a2f46454109b336161e9ae9bc14, entries=636412, sequenceid=107, filesize=49.5 M
2017-06-29 11:36:41,788 INFO org.apache.hadoop.hbase.regionserver.HRegion: Finished memstore flush of ~128.74 MB/134994216, currentsize=26.27 MB/27549840 for region test2,,1498706810880.786ef51a9c89f0e31073ba8aafc7ef94. in 1318ms, sequenceid=107, compaction requested=false


3. 第三次刷新, 此時日志明確的表示，要進行合并， 當有3個HFILE的時候，HBASE會合并，這是因為默認我們的參數(shù)hbase.hstore.compactionThreshold=3  ，此時發(fā)生的是minor合并

2017-06-29 11:36:48,023 INFO org.apache.hadoop.hbase.regionserver.DefaultStoreFlusher: Flushed, sequenceid=160, memsize=128.7 M, hasBloomFilter=true, into tmp file hdfs://nameservice1/hbase/data/default/test2/786ef51a9c89f0e31073ba8aafc7ef94/.tmp/1fa335caa3144c8da5e0ca7697f551cf
2017-06-29 11:36:48,041 INFO org.apache.hadoop.hbase.regionserver.HStore: Added hdfs://nameservice1/hbase/data/default/test2/786ef51a9c89f0e31073ba8aafc7ef94/cf/1fa335caa3144c8da5e0ca7697f551cf, entries=636412, sequenceid=160, filesize=49.9 M
2017-06-29 11:36:48,054 INFO org.apache.hadoop.hbase.regionserver.HRegion: Finished memstore flush of ~128.74 MB/134994216, currentsize=31.53 MB/33059808 for region test2,,1498706810880.786ef51a9c89f0e31073ba8aafc7ef94. in 1343ms, sequenceid=160, compaction requested=true

跟蹤HFILE合并， 日志顯示，3個文件合并在一起，一共148M，花費的時間為3秒，很顯然minor合并的速度還是很快的。

2017-06-29 11:36:48,058 INFO org.apache.hadoop.hbase.regionserver.HStore: Starting compaction of 3 file(s) in cf of test2,,1498706810880.786ef51a9c89f0e31073ba8aafc7ef94. into tmpdir=hdfs://nameservice1/hbase/data/default/test2/786ef51a9c89f0e31073ba8aafc7ef94/.tmp, totalSize=148.3 M

2017-06-29 11:36:51,792 INFO org.apache.hadoop.hbase.regionserver.CompactSplitThread: Completed compaction: Request = regionName=test2,,1498706810880.786ef51a9c89f0e31073ba8aafc7ef94., storeName=cf, fileCount=3, fileSize=148.3 M, priority=7, time=17006286308699473; duration=3sec

4. flush  

5. flush 

6. 要求合并（此時第一個合并之后只有一個文件，加上flush的2個文件，一共3個，達到了合并條件）

7. 要求split (split之后為2個文件）

8. flush

9. 要求合并（之前split為2個文件，加上flush的一個為3個文件，達到合并條件)

10. 要求split

以上是根據(jù)日志顯示得到的一個跟蹤過程。 我們可以看到minor compact速度很快，根據(jù)參數(shù)設(shè)置，每3個文件就會合并一次。 至于major compact由hbase.hregion.majorcompaction來控制,
默認是7天時間，0表示關(guān)閉major compact.  所以從理論來講，minor compact對于一個數(shù)據(jù)量大的系統(tǒng)，可能時時刻刻在合并， 因為memstore 默認128M可能1分鐘就滿了，刷出之后產(chǎn)生HFILE，然后達到合并條件就合并。

而split有3個策略，默認是IncreasingToUpperBoundRegionSplitPolicy ， 還有KeyPrefixRegionSplitPolicy， ConstantSizeRegionSplitPolicy， 根據(jù)規(guī)則在128M的時候就應該split，但是實際從日志來看，并沒有，后續(xù)再做觀察。

通常我們會提到手動拆分，也就是關(guān)閉自動拆分，從拆分策略來看，只有ConstantSizeRegionSplitPolicy能完全禁止自動拆分，設(shè)置這個策略之后，然后修改region的max filesize，比如100G，那么基本就可以關(guān)閉自動拆分。


根據(jù)以上合并以及拆分理論知識，我們假設(shè)有一個系統(tǒng)負載極大，不停的大量數(shù)據(jù)寫入，那么我們可以知道，HBASE內(nèi)部在不停的合并，達到拆分規(guī)則又拆分，又合并，又拆分，周而復始。
在拆分的時候，1個大region拆分成2個小region, 然后修改meta，再online2個小region,  刪除大的region. 但是在這過程，我們知道數(shù)據(jù)還在不停的寫入，hbase.hstore.blockingStoreFiles默認為10，這個參數(shù)是用來控制當一個region下超過多少個文件就BLOCK更新插入，等待合并結(jié)束，問題是這個參數(shù)不會一直BLOCK，hbase.hstore.blockingWaitTime 默認90秒，超過這個時間又會放行插入和更新。很顯然，出現(xiàn)這種情況之后，小region如果出現(xiàn)了需要split的情況怎么辦？ 開始的合并還沒有結(jié)束，大region還沒有offline, 小region又要拆分。 

如果出現(xiàn)了上面的情況，我不知道具體HBASE是什么規(guī)則，但是我想這是一個極度復雜的處理，簡單處理的話只有BLOCK插入和更新，等待合并或者拆分結(jié)束。目前我還沒找到有完全BLOCK HBASE插入和更新的參數(shù)， 所以為了更好管理HBASE， 建議關(guān)閉自動拆分，為什么？ 不僅僅是為了說SPLIT可能會影響性能，如果說SPLIT會影響，那么合并也會影響，更多的是，拆分和合并我們要有取舍，關(guān)閉了自動拆分，人為來控制，那么在HBASE內(nèi)部僅僅存在合并，至少不會出現(xiàn)上述極度復雜的情況。

最后，如果系統(tǒng)負載極大的時候，rowkey分配不規(guī)則，大量線程往一個region寫數(shù)據(jù)，默認單個memstore是128M，最大大小為128*2=256M, 這個時候按照規(guī)則會BLOCK寫入，甚至出現(xiàn)org.apache.hadoop.hbase.RegionTooBusyException: org.apache.hadoop.hbase.RegionTooBusyException: Above memstore limit  memstoreSize=269744800, blockingMemStoreSize=268435456 之類的錯誤。  

這里簡單說一下memstore block寫入規(guī)則，默認memstore size=128M,  結(jié)合hbase.hregion.memstore.block.multiplier=2 ，也就是說memstore最大大小為256M， 將BLOCK寫入，阻止大量寫入避免出現(xiàn)outofmemory錯誤. 上面你看到的above memstore size > 256M.

所以預先分區(qū)以及估算寫入量就顯的非常重要，如果你的系統(tǒng)負載并沒有那么大，那么就顯的不是那么重要了。

到此，相信大家對“Hbase compact和split跟蹤舉例分析”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學習！