1. 程式人生 > >HBase Region自動切分的所有細節都在這裡了

HBase Region自動切分的所有細節都在這裡了

大資料

作者:範欣欣

Region自動切分是HBase能夠擁有良好擴張性的最重要因素之一,也必然是所有分散式系統追求無限擴充套件性的一副良藥。HBase系統中Region自動切分是如何實現的,這裡面涉及很多知識點,比如Region切分的觸發條件是什麼、Region切分的切分點在哪裡、如何切分才能最大的保證Region的可用性、如何做好切分過程中的異常處理、切分過程中要不要將資料移動等,這篇文章將會對這些細節進行基本的說明,一方面可以讓大家對HBase中Region自動切分有更加深入的理解,另一方面如果想實現類似的功能也可以參考HBase的實現方案。

Region切分觸發策略

在最新穩定版(1.2.6)中,HBase已經有多達6種切分觸發策略。當然,每種觸發策略都有各自的適用場景,使用者可以根據業務在表級別選擇不同的切分觸發策略。常見的切分策略如下圖:

大資料

ConstantSizeRegionSplitPolicy0.94版本前預設切分策略。這是最容易理解但也最容易產生誤解的切分策略,從字面意思來看,當region大小大於某個閾值(hbase.hregion.max.filesize)之後就會觸發切分,實際上並不是這樣,真正實現中這個閾值是對於某個store來說的,即一個region中最大store的大小大於設定閾值之後才會觸發切分。

另外一個大家比較關心的問題是這裡所說的store大小是壓縮後的檔案總大小還是未壓縮檔案總大小,實際實現中store大小為壓縮後的檔案大小(採用壓縮的場景)。ConstantSizeRegionSplitPolicy相對來來說最容易想到,但是在生產線上這種切分策略卻有相當大的弊端:切分策略對於大表和小表沒有明顯的區分。閾值(hbase.hregion.max.filesize)設定較大對大表比較友好,但是小表就有可能不會觸發分裂,極端情況下可能就1個,這對業務來說並不是什麼好事。如果設定較小則對小表友好,但一個大表就會在整個叢集產生大量的region,這對於叢集的管理、資源使用、failover來說都不是一件好事。

IncreasingToUpperBoundRegionSplitPolicy: 0.94版本~2.0版本預設切分策略。這種切分策略微微有些複雜,總體來看和ConstantSizeRegionSplitPolicy思路相同,一個region中最大store大小大於設定閾值就會觸發切分。但是這個閾值並不像ConstantSizeRegionSplitPolicy是一個固定的值,而是會在一定條件下不斷調整,調整規則和region所屬表在當前regionserver上的region個數有關係 :(#regions) * (#regions) * (#regions) * flush size * 2,當然閾值並不會無限增大,最大值為使用者設定的MaxRegionFileSize。

這種切分策略很好地彌補了ConstantSizeRegionSplitPolicy的短板,能夠自適應大表和小表。而且在大叢集條件下對於很多大表來說表現很優秀,但並不完美,這種策略下很多小表會在大叢集中產生大量小region,分散在整個叢集中。而且在發生region遷移時也可能會觸發region分裂。

SteppingSplitPolicy: 2.0版本預設切分策略。這種切分策略的切分閾值又發生了變化,相比IncreasingToUpperBoundRegionSplitPolicy簡單了一些,依然和待分裂region所屬表在當前regionserver上的region個數有關係,如果region個數等於1,切分閾值為flush size * 2,否則為MaxRegionFileSize。這種切分策略對於大叢集中的大表、小表會比IncreasingToUpperBoundRegionSplitPolicy更加友好,小表不會再產生大量的小region,而是適可而止。

另外,還有一些其它分裂策略,比如使用DisableSplitPolicy:可以禁止region發生分裂;而KeyPrefixRegionSplitPolicy,DelimitedKeyPrefixRegionSplitPolicy對於切分策略依然依據預設切分策略,但對於切分點有自己的看法,比如KeyPrefixRegionSplitPolicy要求必須讓相同的PrefixKey待在一個region中。

在用法上,一般情況下使用預設切分策略即可,也可以在cf級別設定region切分策略,命令為:

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

Region切分準備工作:尋找Splitpoint

region切分策略會觸發region切分,切分開始之後的第一件事是尋找切分點-splitpoint。所有預設切分策略,無論是ConstantSizeRegionSplitPolicy、IncreasingToUpperBoundRegionSplitPolicy抑或是SteppingSplitPolicy,對於切分點的定義都是一致的。當然,使用者手動執行切分時是可以指定切分點進行切分的,這裡並不討論這種情況。

那切分點是如何定位呢?整個region中最大store中的最大檔案中最中心的一個block的首個rowkey。這是一句比較消耗腦力的語句,需要細細品味。另外,HBase還規定,如果定位到的rowkey是整個檔案的首個rowkey或者最後一個rowkey的話,就認為沒有切分點。

什麼情況下會出現沒有切分點的場景呢?最常見的就是一個檔案只有一個block,執行split的時候就會發現無法切分。很多新同學在測試split的時候往往都是新建一張新表,然後往新表中插入幾條資料並執行一下flush,再執行split,奇蹟般地發現數據表並沒有真正執行切分。原因就在這裡,這個時候仔細的話你翻看debug日誌是可以看到這樣的日誌滴:

大資料

Region核心切分流程

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

大資料

    • prepare階段:在記憶體中初始化兩個子region,具體是生成兩個HRegionInfo物件,包含tableName、regionName、startkey、endkey等。同時會生成一個transaction journal,這個物件用來記錄切分的進展,具體見rollback階段。
    • execute階段:切分的核心操作。見下圖(來自Hortonworks):

大資料
1、regionserver 更改ZK節點 /region-in-transition 中該region的狀態為SPLITING。

2、master通過watch節點/region-in-transition檢測到region狀態改變,並修改記憶體中region的狀態,在master頁面RIT模組就可以看到region執行split的狀態資訊。

3、在父儲存目錄下新建臨時資料夾.split儲存split後的daughter region資訊。

4、關閉parent region:parent region關閉資料寫入並觸發flush操作,將寫入region的資料全部持久化到磁碟。此後短時間內客戶端落在父region上的請求都會丟擲異常NotServingRegionException。

5、核心分裂步驟:在.split資料夾下新建兩個子資料夾,稱之為daughter A、daughter B,並在資料夾中生成reference檔案,分別指向父region中對應檔案。這個步驟是所有步驟中最核心的一個環節,生成reference檔案日誌如下所示:

大資料其中reference檔名為

d24415c4fb44427b8f698143e5c4d9dc.00bb6239169411e4d0ecb6ddfdbacf66,格式看起來比較特殊,那這種檔名具體什麼含義呢?那來看看該reference檔案指向的父region檔案,根據日誌可以看到,切分的父region是00bb6239169411e4d0ecb6ddfdbacf66,對應的切分檔案是d24415c4fb44427b8f698143e5c4d9dc,可見reference檔名是個資訊量很大的命名方式,如下所示:

大資料
除此之外,還需要關注reference檔案的檔案內容,reference檔案是一個引用檔案(並非linux連結檔案),檔案內容很顯然不是使用者資料。檔案內容其實非常簡單,主要有兩部分構成:其一是切分點splitkey,其二是一個boolean型別的變數(true或者false),true表示該reference檔案引用的是父檔案的上半部分(top),而false表示引用的是下半部分 (bottom)。為什麼儲存的是這兩部分內容?且聽下文分解。

看官可以使用Hadoop命令親自來檢視reference檔案的具體內容:

大資料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階段出現異常,則執行rollback操作。為了實現回滾,整個切分過程被分為很多子階段,回滾程式會根據當前進展到哪個子階段清理對應的垃圾資料。程式碼中使用 JournalEntryType 來表徵各個子階段,具體見下圖:

大資料

 Region切分事務性保證

整個region切分是一個比較複雜的過程,涉及到父region中HFile檔案的切分、兩個子region的生成、系統meta元資料的更改等很多子步驟,因此必須保證整個切分過程的事務性,即要麼切分完全成功,要麼切分完全未開始,在任何情況下也不能出現切分只完成一半的情況。

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

Region切分對其它模組的影響通過region切分流程的瞭解,我們知道整個region切分過程並沒有涉及資料的移動,所以切分成本本身並不是很高,可以很快完成。切分後子region的檔案實際沒有任何使用者資料,檔案中儲存的僅是一些元資料資訊-切分點rowkey等,那通過引用檔案如何查詢資料呢?子region的資料實際在什麼時候完成真正遷移?資料遷移完成之後父region什麼時候會被刪掉?

1. 通過reference檔案如何查詢資料?

這裡就會看到reference檔名、檔案內容的實際意義啦。整個流程如下圖所示:

大資料

  1. 根據reference檔名(region名+真實檔名)定位到真實資料所在檔案路徑。
  2. 定位到真實資料檔案就可以在整個檔案中掃描待查KV了麼?非也。因為reference檔案通常都只引用了資料檔案的一半資料,以切分點為界,要麼上半部分檔案資料,要麼下半部分資料。那到底哪部分資料?切分點又是哪個點?還記得上文又提到reference檔案的檔案內容吧,沒錯,就記錄在檔案中。

2. 父region的資料什麼時候會遷移到子region目錄?

答案是子region發生major_compaction時。我們知道compaction的執行實際上是將store中所有小檔案一個KV一個KV從小到大讀出來之後再順序寫入一個大檔案,完成之後再將小檔案刪掉,因此compaction本身就需要讀取並寫入大量資料。子region執行major_compaction後會將父目錄中屬於該子region的所有資料讀出來並寫入子region目錄資料檔案中。可見將資料遷移放到compaction這個階段來做,是一件順便的事。

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

實際上HMaster會啟動一個執行緒定期遍歷檢查所有處於splitting狀態的父region,確定檢查父region是否可以被清理。檢測執行緒首先會在meta表中揪出所有split列為true的region,並加載出其分裂後生成的兩個子region(meta表中splitA列和splitB列),只需要檢查此兩個子region是否還存在引用檔案,如果都不存在引用檔案就可以認為該父region對應的檔案可以被刪除。現在再來看看上文中父目錄在meta表中的資訊,就大概可以理解為什麼會儲存這些資訊了:

大資料
4. split模組在生產線的一些坑?

有些時候會有同學反饋說叢集中部分region處於長時間RIT,region狀態為spliting。通常情況下都會建議使用hbck看下什麼報錯,然後再根據hbck提供的一些工具進行修復,hbck提供了部分命令對處於split狀態的rit region進行修復,主要的命令如下:

其中最常見的問題是 :

簡單解釋一下,這個錯誤是說reference檔案所引用的父region檔案不存在了,如果檢視日誌的話有可能看到如下異常:

父region檔案為什麼會莫名其妙不存在?經過和朋友的討論,確認有可能是因為官方bug導致,詳見HBASE-13331。這個jira是說HMaster在確認父目錄是否可以被刪除時,如果檢查引用檔案(檢查是否存在、檢查是否可以正常開啟)丟擲IOException異常,函式就會返回沒有引用檔案,導致父region被刪掉。正常情況下應該保險起見返回存在引用檔案,保留父region,並列印日誌手工介入檢視。如果大家也遇到類似的問題,可以看看這個問題,也可以將修復patch打到線上版本或者升級版本。

End.