作者：范欣欣

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

Region切分觸發(fā)策略

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

ConstantSizeRegionSplitPolicy：0.94版本前默認切分策略。這是最容易理解但也最容易產(chǎn)生誤解的切分策略，從字面意思來看，當region大小大于某個閾值（hbase.hregion.max.filesize）之后就會觸發(fā)切分，實際上并不是這樣，真正實現(xiàn)中這個閾值是對于某個store來說的，即一個region中最大store的大小大于設置閾值之后才會觸發(fā)切分。

另外一個大家比較關心的問題是這里所說的store大小是壓縮后的文件總大小還是未壓縮文件總大小，實際實現(xiàn)中store大小為壓縮后的文件大小（采用壓縮的場景）。ConstantSizeRegionSplitPolicy相對來來說最容易想到，但是在生產(chǎn)線上這種切分策略卻有相當大的弊端：切分策略對于大表和小表沒有明顯的區(qū)分。閾值（hbase.hregion.max.filesize）設置較大對大表比較友好，但是小表就有可能不會觸發(fā)分裂，極端情況下可能就1個，這對業(yè)務來說并不是什么好事。如果設置較小則對小表友好，但一個大表就會在整個集群產(chǎn)生大量的region，這對于集群的管理、資源使用、failover來說都不是一件好事。

IncreasingToUpperBoundRegionSplitPolicy:?0.94版本~2.0版本默認切分策略。這種切分策略微微有些復雜，總體來看和ConstantSizeRegionSplitPolicy思路相同，一個region中最大store大小大于設置閾值就會觸發(fā)切分。但是這個閾值并不像ConstantSizeRegionSplitPolicy是一個固定的值，而是會在一定條件下不斷調(diào)整，調(diào)整規(guī)則和region所屬表在當前regionserver上的region個數(shù)有關系 ：(#regions) * (#regions) * (#regions) *?flush size * 2，當然閾值并不會無限增大，最大值為用戶設置的MaxRegionFileSize。

這種切分策略很好地彌補了ConstantSizeRegionSplitPolicy的短板，能夠自適應大表和小表。而且在大集群條件下對于很多大表來說表現(xiàn)很優(yōu)秀，但并不完美，這種策略下很多小表會在大集群中產(chǎn)生大量小region，分散在整個集群中。而且在發(fā)生region遷移時也可能會觸發(fā)region分裂。

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

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

在用法上，一般情況下使用默認切分策略即可，也可以在cf級別設置region切分策略，命令為：

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

Region切分準備工作：尋找Splitpoint

region切分策略會觸發(fā)region切分，切分開始之后的第一件事是尋找切分點－splitpoint。所有默認切分策略，無論是ConstantSizeRegionSplitPolicy、IncreasingToUpperBoundRegionSplitPolicy抑或是SteppingSplitPolicy，對于切分點的定義都是一致的。當然，用戶手動執(zhí)行切分時是可以指定切分點進行切分的，這里并不討論這種情況。

那切分點是如何定位呢？整個region中最大store中的最大文件中最中心的一個block的首個rowkey。這是一句比較消耗腦力的語句，需要細細品味。另外，HBase還規(guī)定，如果定位到的rowkey是整個文件的首個rowkey或者最后一個rowkey的話，就認為沒有切分點。

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

Region核心切分流程

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

1、regionserver?更改ZK節(jié)點 /region-in-transition 中該region的狀態(tài)為SPLITING。

2、master通過watch節(jié)點/region-in-transition檢測到region狀態(tài)改變，并修改內(nèi)存中region的狀態(tài)，在master頁面RIT模塊就可以看到region執(zhí)行split的狀態(tài)信息。

3、在父存儲目錄下新建臨時文件夾.split保存split后的daughter region信息。

4、關閉parent region：parent region關閉數(shù)據(jù)寫入并觸發(fā)flush操作，將寫入region的數(shù)據(jù)全部持久化到磁盤。此后短時間內(nèi)客戶端落在父region上的請求都會拋出異常NotServingRegionException。

5、核心分裂步驟：在.split文件夾下新建兩個子文件夾，稱之為daughter A、daughter B，并在文件夾中生成reference文件，分別指向父region中對應文件。這個步驟是所有步驟中最核心的一個環(huán)節(jié)，生成reference文件日志如下所示：

其中reference文件名為

d24415c4fb44427b8f698143e5c4d9dc.00bb6239169411e4d0ecb6ddfdbacf66，格式看起來比較特殊，那這種文件名具體什么含義呢？那來看看該reference文件指向的父region文件，根據(jù)日志可以看到，切分的父region是00bb6239169411e4d0ecb6ddfdbacf66，對應的切分文件是d24415c4fb44427b8f698143e5c4d9dc，可見reference文件名是個信息量很大的命名方式，如下所示：

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

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

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

7. parent region通知修改 hbase.meta 表后下線，不再提供服務。下線后parent region在meta表中的信息并不會馬上刪除，而是標注split列、offline列為true，并記錄兩個子region。為什么不立馬刪除？且聽下文分解。

8. 開啟daughter A、daughter B兩個子region。通知修改 hbase.meta 表，正式對外提供服務。

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

?Region切分事務性保證

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

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

Region切分對其它模塊的影響通過region切分流程的了解，我們知道整個region切分過程并沒有涉及數(shù)據(jù)的移動，所以切分成本本身并不是很高，可以很快完成。切分后子region的文件實際沒有任何用戶數(shù)據(jù)，文件中存儲的僅是一些元數(shù)據(jù)信息－切分點rowkey等，那通過引用文件如何查找數(shù)據(jù)呢？子region的數(shù)據(jù)實際在什么時候完成真正遷移？數(shù)據(jù)遷移完成之后父region什么時候會被刪掉？

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

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

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

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

3.?父region什么時候會被刪除？

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

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

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

其中最常見的問題是 ：

簡單解釋一下，這個錯誤是說reference文件所引用的父region文件不存在了，如果查看日志的話有可能看到如下異常：

父region文件為什么會莫名其妙不存在？經(jīng)過和朋友的討論，確認有可能是因為官方bug導致，詳見HBASE-13331。這個jira是說HMaster在確認父目錄是否可以被刪除時，如果檢查引用文件（檢查是否存在、檢查是否可以正常打開）拋出IOException異常，函數(shù)就會返回沒有引用文件，導致父region被刪掉。正常情況下應該保險起見返回存在引用文件，保留父region，并打印日志手工介入查看。如果大家也遇到類似的問題，可以看看這個問題，也可以將修復patch打到線上版本或者升級版本。

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。