Region自動(dòng)切分是HBase能夠擁有良好擴(kuò)張性的最重要因素之一，也必然是所有分布式系統(tǒng)追求***擴(kuò)展性的一副良藥。HBase系統(tǒng)中Region自動(dòng)切分是如何實(shí)現(xiàn)的?這里面涉及很多知識(shí)點(diǎn)，比如Region切分的觸發(fā)條件是什么?Region切分的切分點(diǎn)在哪里?如何切分才能***的保證Region的可用性?如何做好切分過(guò)程中的異常處理?切分過(guò)程中要不要將數(shù)據(jù)移動(dòng)?等等，這篇文章將會(huì)對(duì)這些細(xì)節(jié)進(jìn)行基本的說(shuō)明，一方面可以讓大家對(duì)HBase中Region自動(dòng)切分有更加深入的理解，另一方面如果想實(shí)現(xiàn)類似的功能也可以參考HBase的實(shí)現(xiàn)方案。

Region切分觸發(fā)策略

在***穩(wěn)定版(1.2.6)中，HBase已經(jīng)有多達(dá)6種切分觸發(fā)策略。當(dāng)然，每種觸發(fā)策略都有各自的適用場(chǎng)景，用戶可以根據(jù)業(yè)務(wù)在表級(jí)別選擇不同的切分觸發(fā)策略。常見(jiàn)的切分策略如下圖：

ConstantSizeRegionSplitPolicy：0.94版本前默認(rèn)切分策略。這是最容易理解但也最容易產(chǎn)生誤解的切分策略，從字面意思來(lái)看，當(dāng)region大小大于某個(gè)閾值(hbase.hregion.max.filesize)之后就會(huì)觸發(fā)切分，實(shí)際上并不是這樣，真正實(shí)現(xiàn)中這個(gè)閾值是對(duì)于某個(gè)store來(lái)說(shuō)的，即一個(gè)region中***store的大小大于設(shè)置閾值之后才會(huì)觸發(fā)切分。另外一個(gè)大家比較關(guān)心的問(wèn)題是這里所說(shuō)的store大小是壓縮后的文件總大小還是未壓縮文件總大小，實(shí)際實(shí)現(xiàn)中store大小為壓縮后的文件大小(采用壓縮的場(chǎng)景)。ConstantSizeRegionSplitPolicy相對(duì)來(lái)來(lái)說(shuō)最容易想到，但是在生產(chǎn)線上這種切分策略卻有相當(dāng)大的弊端：切分策略對(duì)于大表和小表沒(méi)有明顯的區(qū)分。閾值(hbase.hregion.max.filesize)設(shè)置較大對(duì)大表比較友好，但是小表就有可能不會(huì)觸發(fā)分裂，極端情況下可能就1個(gè)，這對(duì)業(yè)務(wù)來(lái)說(shuō)并不是什么好事。如果設(shè)置較小則對(duì)小表友好，但一個(gè)大表就會(huì)在整個(gè)集群產(chǎn)生大量的region，這對(duì)于集群的管理、資源使用、failover來(lái)說(shuō)都不是一件好事。

I ncreasingToUpperBoundRegionSplitPolicy : 0.94版本~2.0版本默認(rèn)切分策略。這種切分策略微微有些復(fù)雜，總體來(lái)看和ConstantSizeRegionSplitPolicy思路相同，一個(gè)region中***store大小大于設(shè)置閾值就會(huì)觸發(fā)切分。但是這個(gè)閾值并不像ConstantSizeRegionSplitPolicy是一個(gè)固定的值，而是會(huì)在一定條件下不斷調(diào)整，調(diào)整規(guī)則和region所屬表在當(dāng)前regionserver上的region個(gè)數(shù)有關(guān)系 ：(#regions) * (#regions) * (#regions) * flush size * 2，當(dāng)然閾值并不會(huì)***增大，***值為用戶設(shè)置的MaxRegionFileSize。這種切分策略很好的彌補(bǔ)了ConstantSizeRegionSplitPolicy的短板，能夠自適應(yīng)大表和小表。而且在大集群條件下對(duì)于很多大表來(lái)說(shuō)表現(xiàn)很優(yōu)秀，但并不***，這種策略下很多小表會(huì)在大集群中產(chǎn)生大量小region，分散在整個(gè)集群中。而且在發(fā)生region遷移時(shí)也可能會(huì)觸發(fā)region分裂。

SteppingSplitPolicy: 2.0版本默認(rèn)切分策略。這種切分策略的切分閾值又發(fā)生了變化，相比 IncreasingToUpperBoundRegionSplitPolicy 簡(jiǎn)單了一些，依然和待分裂region所屬表在當(dāng)前regionserver上的region個(gè)數(shù)有關(guān)系，如果region個(gè)數(shù)等于1，切分閾值為flush size * 2，否則為MaxRegionFileSize。這種切分策略對(duì)于大集群中的大表、小表會(huì)比 IncreasingToUpperBoundRegionSplitPolicy 更加友好，小表不會(huì)再產(chǎn)生大量的小region，而是適可而止。

另外，還有一些其他分裂策略，比如使用DisableSplitPolicy:可以禁止region發(fā)生分裂;而KeyPrefixRegionSplitPolicy，DelimitedKeyPrefixRegionSplitPolicy對(duì)于切分策略依然依據(jù)默認(rèn)切分策略，但對(duì)于切分點(diǎn)有自己的看法，比如KeyPrefixRegionSplitPolicy要求必須讓相同的PrefixKey待在一個(gè)region中。

在用法上，一般情況下使用默認(rèn)切分策略即可，也可以在cf級(jí)別設(shè)置region切分策略，命令為：

create ’table’, {NAME => ‘cf’, SPLIT_POLICY => ‘org.apache.hadoop.hbase.regionserver. ConstantSizeRegionSplitPolicy'} 

Region切分準(zhǔn)備工作-尋找SplitPoint

region切分策略會(huì)觸發(fā)region切分，切分開(kāi)始之后的***件事是尋找切分點(diǎn)-splitpoint。所有默認(rèn)切分策略，無(wú)論是ConstantSizeRegionSplitPolicy、 IncreasingToUpperBoundRegionSplitPolicy 抑或是SteppingSplitPolicy，對(duì)于切分點(diǎn)的定義都是一致的。當(dāng)然，用戶手動(dòng)執(zhí)行切分時(shí)是可以指定切分點(diǎn)進(jìn)行切分的，這里并不討論這種情況。

那切分點(diǎn)是如何定位的呢? 整個(gè)region中***store中的***文件中最中心的一個(gè)block的***rowkey 。這是一句比較消耗腦力的語(yǔ)句，需要細(xì)細(xì)品味。另外，HBase還規(guī)定，如果定位到的rowkey是整個(gè)文件的***rowkey或者***一個(gè)rowkey的話，就認(rèn)為沒(méi)有切分點(diǎn)。

什么情況下會(huì)出現(xiàn)沒(méi)有切分點(diǎn)的場(chǎng)景呢?最常見(jiàn)的就是一個(gè)文件只有一個(gè)block，執(zhí)行split的時(shí)候就會(huì)發(fā)現(xiàn)無(wú)法切分。很多新同學(xué)在測(cè)試split的時(shí)候往往都是新建一張新表，然后往新表中插入幾條數(shù)據(jù)并執(zhí)行一下flush，再執(zhí)行split，奇跡般地發(fā)現(xiàn)數(shù)據(jù)表并沒(méi)有真正執(zhí)行切分。原因就在這里，這個(gè)時(shí)候仔細(xì)的話你翻看debug日志是可以看到這樣的日志滴:

Region核心切分流程

HBase將整個(gè)切分過(guò)程包裝成了一個(gè)事務(wù)，意圖能夠保證切分事務(wù)的原子性。整個(gè)分裂事務(wù)過(guò)程分為三個(gè)階段：prepare – execute – (rollback) ，操作模版如下：

• prepare階段：在內(nèi)存中初始化兩個(gè)子region，具體是生成兩個(gè)HRegionInfo對(duì)象，包含tableName、regionName、startkey、endkey等。同時(shí)會(huì)生成一個(gè)transaction journal，這個(gè)對(duì)象用來(lái)記錄切分的進(jìn)展，具體見(jiàn)rollback階段。
• execute階段：切分的核心操作。見(jiàn)下圖(來(lái)自 Hortonworks )：

1. regionserver 更改ZK節(jié)點(diǎn) /region-in-transition 中該region的狀態(tài)為SPLITING。
2. master通過(guò)watch節(jié)點(diǎn)/region-in-transition檢測(cè)到region狀態(tài)改變，并修改內(nèi)存中region的狀態(tài)，在master頁(yè)面RIT模塊就可以看到region執(zhí)行split的狀態(tài)信息。
3. 在父存儲(chǔ)目錄下新建臨時(shí)文件夾.split保存split后的daughter region信息。
4. 關(guān)閉parent region：parent region關(guān)閉數(shù)據(jù)寫(xiě)入并觸發(fā)flush操作，將寫(xiě)入region的數(shù)據(jù)全部持久化到磁盤(pán)。此后短時(shí)間內(nèi)客戶端落在父region上的請(qǐng)求都會(huì)拋出異常NotServingRegionException。
5. 核心分裂步驟：在.split文件夾下新建兩個(gè)子文件夾，稱之為daughter A、daughter B，并在文件夾中生成reference文件，分別指向父region中對(duì)應(yīng)文件。這個(gè)步驟是所有步驟中最核心的一個(gè)環(huán)節(jié)，生成reference文件日志如下所示：

2017-08-12 11:53:38,158 DEBUG [StoreOpener-0155388346c3c919d3f05d7188e885e0-1] regionserver.StoreFileInfo: reference 'hdfs://hdfscluster/hbase-rsgroup/data/default/music/0155388346c3c919d3f05d7188e885e0/cf/d24415c4fb44427b8f698143e5c4d9dc.00bb6239169411e4d0ecb6ddfdbacf66' to region=00bb6239169411e4d0ecb6ddfdbacf66 hfile=d24415c4fb44427b8f698143e5c4d9dc。 

其中reference文件名為d24415c4fb44427b8f698143e5c4d9dc.00bb6239169411e4d0ecb6ddfdbacf66，格式看起來(lái)比較特殊，那這種文件名具體什么含義呢?那來(lái)看看該reference文件指向的父region文件，根據(jù)日志可以看到，切分的父region是00bb6239169411e4d0ecb6ddfdbacf66，對(duì)應(yīng)的切分文件是d24415c4fb44427b8f698143e5c4d9dc，可見(jiàn)reference文件名是個(gè)信息量很大的命名方式，如下所示：

除此之外，還需要關(guān)注reference文件的文件內(nèi)容，reference文件是一個(gè)引用文件(并非linux鏈接文件)，文件內(nèi)容很顯然不是用戶數(shù)據(jù)。文件內(nèi)容其實(shí)非常簡(jiǎn)單，主要有兩部分構(gòu)成：其一是切分點(diǎn) splitkey，其二是一個(gè)boolean類型的變量(true或者false)，true表示該reference文件引用的是父文件的上半部分(top)，而false表示引用的是下半部分 (bottom)。為什么存儲(chǔ)的是這兩部分內(nèi)容?且聽(tīng)下文分解。

看官可以使用hadoop命令 親自來(lái)查看reference文件的具體內(nèi)容：

hadoop dfs -cat /hbase-rsgroup/data/default/music/0155388346c3c919d3f05d7188e885e0/cf/d24415c4fb44427b8f698143e5c4d9dc.00bb6239169411e4d0ecb6ddfdbacf66 

6. 父region分裂為兩個(gè)子region后， 將daughter A、daughter B拷貝到HBase根目錄下，形成兩個(gè)新的region。

7. parent region通知修改 hbase.meta 表后下線，不再提供服務(wù)。下線后parent region在meta表中的信息并不會(huì)馬上刪除，而是標(biāo)注split列、offline列為true，并記錄兩個(gè)子region。為什么不立馬刪除?且聽(tīng)下文分解。

8. 開(kāi)啟daughter A、daughter B兩個(gè)子region。通知修改 hbase.meta 表，正式對(duì)外提供服務(wù)。

rollback階段：如果execute階段出現(xiàn)異常，則執(zhí)行rollback操作。為了實(shí)現(xiàn)回滾，整個(gè)切分過(guò)程被分為很多子階段，回滾程序會(huì)根據(jù)當(dāng)前進(jìn)展到哪個(gè)子階段清理對(duì)應(yīng)的垃圾數(shù)據(jù)。代碼中使用 JournalEntryType 來(lái)表征各個(gè)子階段，具體見(jiàn)下圖：

Region切分事務(wù)性保證

整個(gè)region切分是一個(gè)比較復(fù)雜的過(guò)程，涉及到父region中HFile文件的切分、兩個(gè)子region的生成、系統(tǒng)meta元數(shù)據(jù)的更改等很多子步驟，因此必須保證整個(gè)切分過(guò)程的事務(wù)性，即要么切分完全成功，要么切分完全未開(kāi)始，在任何情況下也不能出現(xiàn)切分只完成一半的情況。

為了實(shí)現(xiàn)事務(wù)性，hbase設(shè)計(jì)了使用狀態(tài)機(jī)(見(jiàn)SplitTransaction類)的方式保存切分過(guò)程中的每個(gè)子步驟狀態(tài)，這樣一旦出現(xiàn)異常，系統(tǒng)可以根據(jù)當(dāng)前所處的狀態(tài)決定是否回滾，以及如何回滾。遺憾的是，目前實(shí)現(xiàn)中這些中間狀態(tài)都只存儲(chǔ)在內(nèi)存中，因此一旦在切分過(guò)程中出現(xiàn)regionserver宕機(jī)的情況，有可能會(huì)出現(xiàn)切分處于中間狀態(tài)的情況，也就是RIT狀態(tài)。這種情況下需要使用hbck工具進(jìn)行具體查看并分析解決方案。在2.0版本之后，HBase實(shí)現(xiàn)了新的分布式事務(wù)框架Procedure V2(HBASE-12439)，新框架將會(huì)使用HLog存儲(chǔ)這種單機(jī)事務(wù)(DDL操作、Split操作、Move操作等)的中間狀態(tài)，因此可以保證即使在事務(wù)執(zhí)行過(guò)程中參與者發(fā)生了宕機(jī)，依然可以使用HLog作為協(xié)調(diào)者對(duì)事務(wù)進(jìn)行回滾操作或者重試提交，大大減少甚至杜絕RIT現(xiàn)象。這也是是2.0在可用性方面最值得期待的一個(gè)亮點(diǎn)!!!

Region切分對(duì)其他模塊的影響

通過(guò)region切分流程的了解，我們知道整個(gè)region切分過(guò)程并沒(méi)有涉及數(shù)據(jù)的移動(dòng)，所以切分成本本身并不是很高，可以很快完成。切分后子region的文件實(shí)際沒(méi)有任何用戶數(shù)據(jù)，文件中存儲(chǔ)的僅是一些元數(shù)據(jù)信息-切分點(diǎn)rowkey等，那通過(guò)引用文件如何查找數(shù)據(jù)呢?子region的數(shù)據(jù)實(shí)際在什么時(shí)候完成真正遷移?數(shù)據(jù)遷移完成之后父region什么時(shí)候會(huì)被刪掉?

1. 通過(guò)reference文件如何查找數(shù)據(jù)?

這里就會(huì)看到reference文件名、文件內(nèi)容的實(shí)際意義啦。整個(gè)流程如下圖所示：

(1)根據(jù)reference文件名(region名+真實(shí)文件名)定位到真實(shí)數(shù)據(jù)所在文件路徑

(2)定位到真實(shí)數(shù)據(jù)文件就可以在整個(gè)文件中掃描待查KV了么?非也。因?yàn)閞eference文件通常都只引用了數(shù)據(jù)文件的一半數(shù)據(jù)，以切分點(diǎn)為界，要么上半部分文件數(shù)據(jù)，要么下半部分?jǐn)?shù)據(jù)。那到底哪部分?jǐn)?shù)據(jù)?切分點(diǎn)又是哪個(gè)點(diǎn)?還記得上文又提到reference文件的文件內(nèi)容吧，沒(méi)錯(cuò)，就記錄在文件中。

2. 父region的數(shù)據(jù)什么時(shí)候會(huì)遷移到子region目錄?

答案是子region發(fā)生major_compaction時(shí)。我們知道compaction的執(zhí)行實(shí)際上是將store中所有小文件一個(gè)KV一個(gè)KV從小到大讀出來(lái)之后再順序?qū)懭胍粋€(gè)大文件，完成之后再將小文件刪掉，因此compaction本身就需要讀取并寫(xiě)入大量數(shù)據(jù)。子region執(zhí)行major_compaction后會(huì)將父目錄中屬于該子region的所有數(shù)據(jù)讀出來(lái)并寫(xiě)入子region目錄數(shù)據(jù)文件中?？梢?jiàn)將數(shù)據(jù)遷移放到compaction這個(gè)階段來(lái)做，是一件順便的事。

3. 父region什么時(shí)候會(huì)被刪除?

實(shí)際上HMaster會(huì)啟動(dòng)一個(gè)線程定期遍歷檢查所有處于splitting狀態(tài)的父region，確定檢查父region是否可以被清理。檢測(cè)線程首先會(huì)在meta表中揪出所有split列為true的region，并加載出其分裂后生成的兩個(gè)子region(meta表中splitA列和splitB列)， 只需要檢查此兩個(gè)子region是否還存在引用文件，如果都不存在引用文件就可以認(rèn)為該父region對(duì)應(yīng)的文件可以被刪除?，F(xiàn)在再來(lái)看看上文中父目錄在meta表中的信息，就大概可以理解為什么會(huì)存儲(chǔ)這些信息了：

4. split模塊在生產(chǎn)線的一些坑?

有些時(shí)候會(huì)有同學(xué)反饋說(shuō)集群中部分region處于長(zhǎng)時(shí)間RIT，region狀態(tài)為spliting。通常情況下都會(huì)建議使用hbck看下什么報(bào)錯(cuò)，然后再根據(jù)hbck提供的一些工具進(jìn)行修復(fù)，hbck提供了部分命令對(duì)處于split狀態(tài)的rit region進(jìn)行修復(fù)，主要的命令如下：

-fixSplitParents  Try to force offline split parents to be online. 
  -removeParents    Try to offline and sideline lingering parents and keep daughter regions. 
  -fixReferenceFiles  Try to offline lingering reference store files 

其中最常見(jiàn)的問(wèn)題是 ：

ERROR: Found lingering reference file hdfs://mycluster/hbase/news_user_actions/3b3ae24c65fc5094bc2acfebaa7a56de/meta/0f47cda55fa44cf9aa2599079894aed6.b7b3faab86527b88a92f2a248a54d3dc” 

簡(jiǎn)單解釋一下，這個(gè)錯(cuò)誤是說(shuō)reference文件所引用的父region文件不存在了，如果查看日志的話有可能看到如下異常：

java.io.IOException: java.io.IOException: java.io.FileNotFoundException: File does not exist:/hbase/news_user_actions/b7b3faab86527b88a92f2a248a54d3dc/meta/0f47cda55fa44cf9aa2599079894aed 

父region文件為什么會(huì)莫名其妙不存在?經(jīng)過(guò)和朋友的討論，確認(rèn)有可能是因?yàn)楣俜絙ug導(dǎo)致，詳見(jiàn)HBASE-13331。這個(gè)jira是說(shuō)HMaster在確認(rèn)父目錄是否可以被刪除時(shí)，如果檢查引用文件(檢查是否存在、檢查是否可以正常打開(kāi))拋出IOException異常，函數(shù)就會(huì)返回沒(méi)有引用文件，導(dǎo)致父region被刪掉。正常情況下應(yīng)該保險(xiǎn)起見(jiàn)返回存在引用文件，保留父region，并打印日志手工介入查看。如果大家也遇到類似的問(wèn)題，可以看看這個(gè)問(wèn)題，也可以將修復(fù)patch打到線上版本或者升級(jí)版本。