日韩黑丝制服一区视频播放|日韩欧美人妻丝袜视频在线观看|九九影院一级蜜桃|亚洲中文在线导航|青草草视频在线观看|婷婷五月色伊人网站|日本一区二区在线|国产AV一二三四区毛片|正在播放久草视频|亚洲色图精品一区

分享

HBase學(xué)習(xí)之路 (七)HBase 原理

 HK123COM 2019-02-14

目錄

 

正文

系統(tǒng)架構(gòu)

錯(cuò)誤圖解

 

  這張圖是有一個(gè)錯(cuò)誤點(diǎn):應(yīng)該是每一個(gè) RegionServer 就只有一個(gè) HLog,而不是一個(gè) Region 有一個(gè) HLog。

正確圖解

  從HBase的架構(gòu)圖上可以看出,HBase中的組件包括Client、Zookeeper、HMaster、HRegionServer、HRegion、Store、MemStore、StoreFile、HFile、HLog等,接下來介紹他們的作用。

Client 

 1、HBase 有兩張?zhí)厥獗恚?/p>

.META.:記錄了用戶所有表拆分出來的的 Region 映射信息,.META.可以有多個(gè) Regoin

-ROOT-:記錄了.META.表的 Region 信息,-ROOT-只有一個(gè) Region,無論如何不會(huì)分裂

2、Client 訪問用戶數(shù)據(jù)前需要首先訪問 ZooKeeper,找到-ROOT-表的 Region 所在的位置,然 后訪問-ROOT-表,接著訪問.META.表,最后才能找到用戶數(shù)據(jù)的位置去訪問,中間需要多次 網(wǎng)絡(luò)操作,不過 client 端會(huì)做 cache 緩存。

ZooKeeper 

 1、ZooKeeper 為 HBase 提供 Failover 機(jī)制,選舉 Master,避免單點(diǎn) Master 單點(diǎn)故障問題

 2、存儲(chǔ)所有 Region 的尋址入口:-ROOT-表在哪臺(tái)服務(wù)器上。-ROOT-這張表的位置信息

 3、實(shí)時(shí)監(jiān)控 RegionServer 的狀態(tài),將 RegionServer 的上線和下線信息實(shí)時(shí)通知給 Master

 4、存儲(chǔ) HBase 的 Schema,包括有哪些 Table,每個(gè) Table 有哪些 Column Family

Master 

1、為 RegionServer 分配 Region

2、負(fù)責(zé) RegionServer 的負(fù)載均衡

3、發(fā)現(xiàn)失效的 RegionServer 并重新分配其上的 Region

4、HDFS 上的垃圾文件(HBase)回收

5、處理 Schema 更新請(qǐng)求(表的創(chuàng)建,刪除,修改,列簇的增加等等)

RegionServer 

1、RegionServer 維護(hù) Master 分配給它的 Region,處理對(duì)這些 Region 的 IO 請(qǐng)求

2、RegionServer 負(fù)責(zé) Split 在運(yùn)行過程中變得過大的 Region,負(fù)責(zé) Compact 操作

可以看到,client 訪問 HBase 上數(shù)據(jù)的過程并不需要 master 參與(尋址訪問 zookeeper 和 RegioneServer,數(shù)據(jù)讀寫訪問 RegioneServer),Master 僅僅維護(hù)者 Table 和 Region 的元數(shù)據(jù)信息,負(fù)載很低。

.META. 存的是所有的 Region 的位置信息,那么 RegioneServer 當(dāng)中 Region 在進(jìn)行分裂之后 的新產(chǎn)生的 Region,是由 Master 來決定發(fā)到哪個(gè) RegioneServer,這就意味著,只有 Master 知道 new Region 的位置信息,所以,由 Master 來管理.META.這個(gè)表當(dāng)中的數(shù)據(jù)的 CRUD

所以結(jié)合以上兩點(diǎn)表明,在沒有 Region 分裂的情況,Master 宕機(jī)一段時(shí)間是可以忍受的。

HRegion

table在行的方向上分隔為多個(gè)Region。Region是HBase中分布式存儲(chǔ)和負(fù)載均衡的最小單元,即不同的region可以分別在不同的Region Server上,但同一個(gè)Region是不會(huì)拆分到多個(gè)server上。
Region按大小分隔,每個(gè)表一般是只有一個(gè)region。隨著數(shù)據(jù)不斷插入表,region不斷增大,當(dāng)region的某個(gè)列族達(dá)到一個(gè)閾值時(shí)就會(huì)分成兩個(gè)新的region。
每個(gè)region由以下信息標(biāo)識(shí):< 表名,startRowkey,創(chuàng)建時(shí)間>
由目錄表(-ROOT-和.META.)記錄該region的endRowkey

Store

每一個(gè)region由一個(gè)或多個(gè)store組成,至少是一個(gè)store,hbase會(huì)把一起訪問的數(shù)據(jù)放在一個(gè)store里面,即為每個(gè) ColumnFamily建一個(gè)store,如果有幾個(gè)ColumnFamily,也就有幾個(gè)Store。一個(gè)Store由一個(gè)memStore和0或者 多個(gè)StoreFile組成。 HBase以store的大小來判斷是否需要切分region

MemStore

memStore 是放在內(nèi)存里的。保存修改的數(shù)據(jù)即keyValues。當(dāng)memStore的大小達(dá)到一個(gè)閥值(默認(rèn)128MB)時(shí),memStore會(huì)被flush到文 件,即生成一個(gè)快照。目前hbase 會(huì)有一個(gè)線程來負(fù)責(zé)memStore的flush操作。

StoreFile

memStore內(nèi)存中的數(shù)據(jù)寫到文件后就是StoreFile,StoreFile底層是以HFile的格式保存。

HFile

 HBase中KeyValue數(shù)據(jù)的存儲(chǔ)格式,HFile是Hadoop的 二進(jìn)制格式文件,實(shí)際上StoreFile就是對(duì)Hfile做了輕量級(jí)包裝,即StoreFile底層就是HFile

 HLog

HLog(WAL log):WAL意為write ahead log,用來做災(zāi)難恢復(fù)使用,HLog記錄數(shù)據(jù)的所有變更,一旦region server 宕機(jī),就可以從log中進(jìn)行恢復(fù)。
HLog文件就是一個(gè)普通的Hadoop Sequence File, Sequence File的value是key時(shí)HLogKey對(duì)象,其中記錄了寫入數(shù)據(jù)的歸屬信息,除了table和region名字外,還同時(shí)包括sequence number和timestamp,timestamp是寫入時(shí)間,sequence number的起始值為0,或者是最近一次存入文件系統(tǒng)中的sequence number。 Sequence File的value是HBase的KeyValue對(duì)象,即對(duì)應(yīng)HFile中的KeyValue。

物理存儲(chǔ)

整體的物理結(jié)構(gòu)

 

  1、Table 中的所有行都按照 RowKsey 的字典序排列。

  2、Table 在行的方向上分割為多個(gè) HRegion。

  3、HRegion 按大小分割的(默認(rèn) 10G),每個(gè)表一開始只有一個(gè) HRegion,隨著數(shù)據(jù)不斷插入 表,HRegion 不斷增大,當(dāng)增大到一個(gè)閥值的時(shí)候,HRegion 就會(huì)等分會(huì)兩個(gè)新的 HRegion。 當(dāng)表中的行不斷增多,就會(huì)有越來越多的 HRegion。

  4、HRegion 是 Hbase 中分布式存儲(chǔ)和負(fù)載均衡的最小單元。最小單元就表示不同的 HRegion 可以分布在不同的 HRegionserver 上。但一個(gè) HRegion 是不會(huì)拆分到多個(gè) server 上的。

  5、HRegion 雖然是負(fù)載均衡的最小單元,但并不是物理存儲(chǔ)的最小單元。事實(shí)上,HRegion 由一個(gè)或者多個(gè) Store 組成,每個(gè) Store 保存一個(gè) Column Family。每個(gè) Strore 又由一個(gè) memStore 和 0 至多個(gè) StoreFile 組成

StoreFile 和 HFile 結(jié)構(gòu)

  StoreFile 以 HFile 格式保存在 HDFS 上,請(qǐng)看下圖 HFile 的數(shù)據(jù)組織格式:

  首先 HFile 文件是不定長(zhǎng)的,長(zhǎng)度固定的只有其中的兩塊:Trailer 和 FileInfo。

正如圖中所示:

  Trailer 中有指針指向其他數(shù)據(jù)塊的起始點(diǎn)。

  FileInfo 中記錄了文件的一些 Meta 信息,例如:AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY 等。

HFile 分為六個(gè)部分:

  Data Block 段–保存表中的數(shù)據(jù),這部分可以被壓縮

  Meta Block 段 (可選的)–保存用戶自定義的 kv 對(duì),可以被壓縮。

  File Info 段–Hfile 的元信息,不被壓縮,用戶也可以在這一部分添加自己的元信息。

  Data Block Index 段–Data Block 的索引。每條索引的 key 是被索引的 block 的第一條記錄的 key。

  Meta Block Index 段 (可選的)–Meta Block 的索引。

  Trailer 段–這一段是定長(zhǎng)的。保存了每一段的偏移量,讀取一個(gè) HFile 時(shí),會(huì)首先讀取 Trailer, Trailer保存了每個(gè)段的起始位置(段的Magic Number用來做安全check),然后,DataBlock Index 會(huì)被讀取到內(nèi)存中,這樣,當(dāng)檢索某個(gè) key 時(shí),不需要掃描整個(gè) HFile,而只需從內(nèi)存中找 到key所在的block,通過一次磁盤io將整個(gè)block讀取到內(nèi)存中,再找到需要的key。DataBlock Index 采用 LRU 機(jī)制淘汰。

  HFile 的 Data Block,Meta Block 通常采用壓縮方式存儲(chǔ),壓縮之后可以大大減少網(wǎng)絡(luò) IO 和磁 盤 IO,隨之而來的開銷當(dāng)然是需要花費(fèi) cpu 進(jìn)行壓縮和解壓縮。

目標(biāo) Hfile 的壓縮支持兩種方式:Gzip,LZO。

  Data Index 和 Meta Index 塊記錄了每個(gè) Data 塊和 Meta 塊的起始點(diǎn)。

  Data Block 是 HBase I/O 的基本單元,為了提高效率,HRegionServer 中有基于 LRU 的 Block Cache 機(jī)制。每個(gè) Data 塊的大小可以在創(chuàng)建一個(gè) Table 的時(shí)候通過參數(shù)指定,大號(hào)的 Block 有利于順序 Scan,小號(hào) Block 利于隨機(jī)查詢。 每個(gè) Data 塊除了開頭的 Magic 以外就是一個(gè) 個(gè) KeyValue 對(duì)拼接而成, Magic 內(nèi)容就是一些隨機(jī)數(shù)字,目的是防止數(shù)據(jù)損壞。

  HFile 里面的每個(gè) KeyValue 對(duì)就是一個(gè)簡(jiǎn)單的 byte 數(shù)組。但是這個(gè) byte 數(shù)組里面包含了很 多項(xiàng),并且有固定的結(jié)構(gòu)。我們來看看里面的具體結(jié)構(gòu): 

  開始是兩個(gè)固定長(zhǎng)度的數(shù)值,分別表示 Key 的長(zhǎng)度和 Value 的長(zhǎng)度。緊接著是 Key,開始是 固定長(zhǎng)度的數(shù)值,表示 RowKey 的長(zhǎng)度,緊接著是 RowKey,然后是固定長(zhǎng)度的數(shù)值,表示 Family 的長(zhǎng)度,然后是 Family,接著是 Qualifier,然后是兩個(gè)固定長(zhǎng)度的數(shù)值,表示 Time Stamp 和 Key Type(Put/Delete)。Value 部分沒有這么復(fù)雜的結(jié)構(gòu),就是純粹的二進(jìn)制數(shù)據(jù)了。

MemStore 和 StoreFile

  一個(gè) Hregion 由多個(gè) Store 組成,每個(gè) Store 包含一個(gè)列族的所有數(shù)據(jù)。

  Store 包括位于內(nèi)存的一個(gè) memstore 和位于硬盤的多個(gè) storefile 組成。

  寫操作先寫入 memstore,當(dāng) memstore 中的數(shù)據(jù)量達(dá)到某個(gè)閾值,HRegionServer 啟動(dòng) flushcache 進(jìn)程寫入 storefile,每次寫入形成單獨(dú)一個(gè) Hfile。

  當(dāng)總 storefile 大小超過一定閾值后,會(huì)把當(dāng)前的 region 分割成兩個(gè),并由 HMaster 分配給相 應(yīng)的 region 服務(wù)器,實(shí)現(xiàn)負(fù)載均衡。

  客戶端檢索數(shù)據(jù)時(shí),先在 memstore 找,找不到再找 storefile。

Hbase WAL HLog預(yù)寫

  WAL 意為 Write ahead log(http://en./wiki/Write-ahead_logging),類似 mysql 中的 binlog,用來做災(zāi)難恢復(fù)之用,Hlog 記錄數(shù)據(jù)的所有變更,一旦數(shù)據(jù)修改,就可以從 log 中 進(jìn)行恢復(fù)。

  每個(gè) Region Server 維護(hù)一個(gè) Hlog,而不是每個(gè) Region 一個(gè)。這樣不同 region(來自不同 table) 的日志會(huì)混在一起,這樣做的目的是不斷追加單個(gè)文件相對(duì)于同時(shí)寫多個(gè)文件而言,可以減 少磁盤尋址次數(shù),因此可以提高對(duì) table 的寫性能。帶來的麻煩是,如果一臺(tái) region server 下線,為了恢復(fù)其上的 region,需要將 region server 上的 log 進(jìn)行拆分,然后分發(fā)到其它 region server 上進(jìn)行恢復(fù)。

  HLog 文件就是一個(gè)普通的 Hadoop Sequence File(序列化文件):

  1、HLog Sequence File 的 Key 是 HLogKey 對(duì)象,HLogKey 中記錄了寫入數(shù)據(jù)的歸屬信息,除 了 table 和 region 名字外,同時(shí)還包括 sequence number 和 timestamp,timestamp 是”寫入 時(shí)間”,sequence number 的起始值為 0,或者是最近一次存入文件系統(tǒng)中 sequence number。

  2、HLog Sequece File 的 Value 是 HBase 的 KeyValue 對(duì)象,即對(duì)應(yīng) HFile 中的 KeyValue。

Region 尋址機(jī)制

  既然讀寫都在 RegionServer 上發(fā)生,我們前面有講到,每個(gè) RegionSever 為一定數(shù)量的 Region 服務(wù),那么 Client 要對(duì)某一行數(shù)據(jù)做讀寫的時(shí)候如何能知道具體要去訪問哪個(gè) RegionServer 呢?那就是接下來我們要討論的問題

老的 Region 尋址方式

  在 HBase-0.96 版本以前,HBase 有兩個(gè)特殊的表,分別是-ROOT-表和.META.表,其中-ROOT的位置存儲(chǔ)在 ZooKeeper 中,-ROOT-本身存儲(chǔ)了.META. Table 的 RegionInfo 信息,并且-ROOT不會(huì)分裂,只有一個(gè) Region。而.META.表可以被切分成多個(gè) Region。讀取的流程如下圖所示:

詳細(xì)步驟:

第 1 步:Client 請(qǐng)求 ZooKeeper 獲得-ROOT-所在的 RegionServer 地址

第 2 步:Client 請(qǐng)求-ROOT-所在的 RS 地址,獲取.META.表的地址,Client 會(huì)將-ROOT-的相關(guān) 信息 cache 下來,以便下一次快速訪問

第 3 步:Client 請(qǐng)求.META.表的 RegionServer 地址,獲取訪問數(shù)據(jù)所在 RegionServer 的地址, Client 會(huì)將.META.的相關(guān)信息 cache 下來,以便下一次快速訪問

第 4 步:Client 請(qǐng)求訪問數(shù)據(jù)所在 RegionServer 的地址,獲取對(duì)應(yīng)的數(shù)據(jù)

  從上面的路徑我們可以看出,用戶需要 3 次請(qǐng)求才能直到用戶 Table 真正的位置,這在一定 程序帶來了性能的下降。在 0.96 之前使用 3 層設(shè)計(jì)的主要原因是考慮到元數(shù)據(jù)可能需要很 大。但是真正集群運(yùn)行,元數(shù)據(jù)的大小其實(shí)很容易計(jì)算出來。在 BigTable 的論文中,每行 METADATA 數(shù)據(jù)存儲(chǔ)大小為 1KB 左右,如果按照一個(gè) Region 為 128M 的計(jì)算,3 層設(shè)計(jì)可以支持的 Region 個(gè)數(shù)為 2^34 個(gè),采用 2 層設(shè)計(jì)可以支持 2^17(131072)。那么 2 層設(shè)計(jì)的情 況下一個(gè)集群可以存儲(chǔ) 4P 的數(shù)據(jù)。這僅僅是一個(gè) Region 只有 128M 的情況下。如果是 10G 呢? 因此,通過計(jì)算,其實(shí) 2 層設(shè)計(jì)就可以滿足集群的需求。因此在 0.96 版本以后就去掉 了-ROOT-表了。

新的 Region 尋址方式

  如上面的計(jì)算,2 層結(jié)構(gòu)其實(shí)完全能滿足業(yè)務(wù)的需求,因此 0.96 版本以后將-ROOT-表去掉了。 如下圖所示:

訪問路徑變成了 3 步:

第 1 步:Client 請(qǐng)求 ZooKeeper 獲取.META.所在的 RegionServer 的地址。

第 2 步:Client 請(qǐng)求.META.所在的 RegionServer 獲取訪問數(shù)據(jù)所在的 RegionServer 地址,Client 會(huì)將.META.的相關(guān)信息 cache 下來,以便下一次快速訪問。

第 3 步:Client 請(qǐng)求數(shù)據(jù)所在的 RegionServer,獲取所需要的數(shù)據(jù)。

總結(jié)去掉-ROOT-的原因有如下 2 點(diǎn):

  其一:提高性能

  其二:2 層結(jié)構(gòu)已經(jīng)足以滿足集群的需求

  這里還有一個(gè)問題需要說明,那就是 Client 會(huì)緩存.META.的數(shù)據(jù),用來加快訪問,既然有緩 存,那它什么時(shí)候更新?如果.META.更新了,比如 Region1 不在 RerverServer2 上了,被轉(zhuǎn)移 到了 RerverServer3 上。Client 的緩存沒有更新會(huì)有什么情況?

  其實(shí),Client 的元數(shù)據(jù)緩存不更新,當(dāng).META.的數(shù)據(jù)發(fā)生更新。如上面的例子,由于 Region1 的位置發(fā)生了變化,Client 再次根據(jù)緩存去訪問的時(shí)候,會(huì)出現(xiàn)錯(cuò)誤,當(dāng)出現(xiàn)異常達(dá)到重試 次數(shù)后就會(huì)去.META.所在的 RegionServer 獲取最新的數(shù)據(jù),如果.META.所在的 RegionServer 也變了,Client 就會(huì)去 ZooKeeper 上獲取.META.所在的 RegionServer 的最新地址。

 讀寫過程

 讀請(qǐng)求過程

1、客戶端通過 ZooKeeper 以及-ROOT-表和.META.表找到目標(biāo)數(shù)據(jù)所在的 RegionServer(就是 數(shù)據(jù)所在的 Region 的主機(jī)地址)

2、聯(lián)系 RegionServer 查詢目標(biāo)數(shù)據(jù)

3、RegionServer 定位到目標(biāo)數(shù)據(jù)所在的 Region,發(fā)出查詢請(qǐng)求

4、Region 先在 Memstore 中查找,命中則返回

5、如果在 Memstore 中找不到,則在 Storefile 中掃描 為了能快速的判斷要查詢的數(shù)據(jù)在不在這個(gè) StoreFile 中,應(yīng)用了 BloomFilter

(BloomFilter,布隆過濾器:迅速判斷一個(gè)元素是不是在一個(gè)龐大的集合內(nèi),但是他有一個(gè) 弱點(diǎn):它有一定的誤判率)

(誤判率:原本不存在與該集合的元素,布隆過濾器有可能會(huì)判斷說它存在,但是,如果 布隆過濾器,判斷說某一個(gè)元素不存在該集合,那么該元素就一定不在該集合內(nèi))

 寫請(qǐng)求過程

1、Client 先根據(jù) RowKey 找到對(duì)應(yīng)的 Region 所在的 RegionServer

2、Client 向 RegionServer 提交寫請(qǐng)求

3、RegionServer 找到目標(biāo) Region

4、Region 檢查數(shù)據(jù)是否與 Schema 一致

5、如果客戶端沒有指定版本,則獲取當(dāng)前系統(tǒng)時(shí)間作為數(shù)據(jù)版本

6、將更新寫入 WAL Log

7、將更新寫入 Memstore

8、判斷 Memstore 的是否需要 flush 為 StoreFile 文件。

   Hbase 在做數(shù)據(jù)插入操作時(shí),首先要找到 RowKey 所對(duì)應(yīng)的的 Region,怎么找到的?其實(shí)這 個(gè)簡(jiǎn)單,因?yàn)?META.表存儲(chǔ)了每張表每個(gè) Region 的起始 RowKey 了。

   建議:在做海量數(shù)據(jù)的插入操作,避免出現(xiàn)遞增 rowkey 的 put 操作

   如果 put 操作的所有 RowKey 都是遞增的,那么試想,當(dāng)插入一部分?jǐn)?shù)據(jù)的時(shí)候剛好進(jìn)行分 裂,那么之后的所有數(shù)據(jù)都開始往分裂后的第二個(gè) Region 插入,就造成了數(shù)據(jù)熱點(diǎn)現(xiàn)象。

   細(xì)節(jié)描述:

     HBase 使用 MemStore 和 StoreFile 存儲(chǔ)對(duì)表的更新。

  數(shù)據(jù)在更新時(shí)首先寫入 HLog(WAL Log),再寫入內(nèi)存(MemStore)中,MemStore 中的數(shù)據(jù)是排 序的,當(dāng) MemStore 累計(jì)到一定閾值時(shí),就會(huì)創(chuàng)建一個(gè)新的 MemStore,并且將老的 MemStore 添加到 flush 隊(duì)列,由單獨(dú)的線程 flush 到磁盤上,成為一個(gè) StoreFile。于此同時(shí),系統(tǒng)會(huì)在 ZooKeeper 中記錄一個(gè) redo point,表示這個(gè)時(shí)刻之前的變更已經(jīng)持久化了。當(dāng)系統(tǒng)出現(xiàn)意外時(shí),可能導(dǎo)致內(nèi)存(MemStore)中的數(shù)據(jù)丟失,此時(shí)使用 HLog(WAL Log)來恢復(fù) checkpoint 之后的數(shù)據(jù)。

  StoreFile 是只讀的,一旦創(chuàng)建后就不可以再修改。因此 HBase 的更新/修改其實(shí)是不斷追加 的操作。當(dāng)一個(gè) Store 中的 StoreFile 達(dá)到一定的閾值后,就會(huì)進(jìn)行一次合并(minor_compact, major_compact),將對(duì)同一個(gè) key 的修改合并到一起,形成一個(gè)大的 StoreFile,當(dāng) StoreFile 的大小達(dá)到一定閾值后,又會(huì)對(duì) StoreFile 進(jìn)行 split,等分為兩個(gè) StoreFile。由于對(duì)表的更 新是不斷追加的,compact 時(shí),需要訪問 Store 中全部的 StoreFile 和 MemStore,將他們按 rowkey 進(jìn)行合并,由于 StoreFile 和 MemStore 都是經(jīng)過排序的,并且 StoreFile 帶有內(nèi)存中 索引,合并的過程還是比較快。

  major_compact 和 minor_compact 的區(qū)別:

    minor_compact 僅僅合并小文件(HFile)

    major_compact 合并一個(gè) region 內(nèi)的所有文件

  Client 寫入 -> 存入 MemStore,一直到 MemStore 滿 -> Flush 成一個(gè) StoreFile,直至增長(zhǎng)到 一定閾值 -> 觸發(fā) Compact 合并操作 -> 多個(gè) StoreFile 合并成一個(gè) StoreFile,同時(shí)進(jìn)行版本 合并和數(shù)據(jù)刪除 -> 當(dāng) StoreFiles Compact 后,逐步形成越來越大的 StoreFile -> 單個(gè) StoreFile 大小超過一定閾值后,觸發(fā) Split 操作,把當(dāng)前 Region Split 成 2 個(gè) Region,Region 會(huì)下線, 新 Split 出的 2 個(gè)孩子 Region 會(huì)被 HMaster 分配到相應(yīng)的 HRegionServer 上,使得原先 1 個(gè) Region 的壓力得以分流到 2 個(gè) Region 上由此過程可知,HBase 只是增加數(shù)據(jù),有所得更新 和刪除操作,都是在 Compact 階段做的,所以,用戶寫操作只需要進(jìn)入到內(nèi)存即可立即返 回,從而保證 I/O 高性能。

  寫入數(shù)據(jù)的過程補(bǔ)充:

  工作機(jī)制:每個(gè) HRegionServer 中都會(huì)有一個(gè) HLog 對(duì)象,HLog 是一個(gè)實(shí)現(xiàn) Write Ahead Log 的類,每次用戶操作寫入 Memstore 的同時(shí),也會(huì)寫一份數(shù)據(jù)到 HLog 文件,HLog 文件定期 會(huì)滾動(dòng)出新,并刪除舊的文件(已持久化到 StoreFile 中的數(shù)據(jù))。當(dāng) HRegionServer 意外終止 后,HMaster 會(huì)通過 ZooKeeper 感知,HMaster 首先處理遺留的 HLog 文件,將不同 Region 的 log數(shù)據(jù)拆分,分別放到相應(yīng) Region 目錄下,然后再將失效的 Region(帶有剛剛拆分的 log) 重新分配,領(lǐng)取到這些 Region 的 HRegionServer 在 load Region 的過程中,會(huì)發(fā)現(xiàn)有歷史 HLog 需要處理,因此會(huì) Replay HLog 中的數(shù)據(jù)到 MemStore 中,然后 flush 到 StoreFiles,完成數(shù)據(jù) 恢復(fù)。

RegionServer 工作機(jī)制

Region 分配

  任何時(shí)刻,一個(gè) Region 只能分配給一個(gè) RegionServer。master 記錄了當(dāng)前有哪些可用的 RegionServer。以及當(dāng)前哪些 Region 分配給了哪些 RegionServer,哪些 Region 還沒有分配。 當(dāng)需要分配的新的 Region,并且有一個(gè) RegionServer 上有可用空間時(shí),Master 就給這個(gè) RegionServer 發(fā)送一個(gè)裝載請(qǐng)求,把 Region 分配給這個(gè) RegionServer。RegionServer 得到請(qǐng) 求后,就開始對(duì)此 Region 提供服務(wù)。

RegionServer 上線

  Master 使用 zookeeper 來跟蹤 RegionServer 狀態(tài)。當(dāng)某個(gè) RegionServer 啟動(dòng)時(shí),會(huì)首先在 ZooKeeper 上的 server 目錄下建立代表自己的 znode。由于 Master 訂閱了 server 目錄上的變 更消息,當(dāng) server 目錄下的文件出現(xiàn)新增或刪除操作時(shí),Master 可以得到來自 ZooKeeper 的實(shí)時(shí)通知。因此一旦 RegionServer 上線,Master 能馬上得到消息。

RegionServer 下線

  當(dāng) RegionServer 下線時(shí),它和 zookeeper 的會(huì)話斷開,ZooKeeper 而自動(dòng)釋放代表這臺(tái) server 的文件上的獨(dú)占鎖。Master 就可以確定:

  1、RegionServer 和 ZooKeeper 之間的網(wǎng)絡(luò)斷開了。

  2、RegionServer 掛了。

  無論哪種情況,RegionServer都無法繼續(xù)為它的Region提供服務(wù)了,此時(shí)Master會(huì)刪除server 目錄下代表這臺(tái) RegionServer 的 znode 數(shù)據(jù),并將這臺(tái) RegionServer 的 Region 分配給其它還 活著的同志。

Master 工作機(jī)制

Master 上線

  Master 啟動(dòng)進(jìn)行以下步驟:

    1、從 ZooKeeper 上獲取唯一一個(gè)代表 Active Master 的鎖,用來阻止其它 Master 成為 Master。

    2、掃描 ZooKeeper 上的 server 父節(jié)點(diǎn),獲得當(dāng)前可用的 RegionServer 列表。

    3、和每個(gè) RegionServer 通信,獲得當(dāng)前已分配的 Region 和 RegionServer 的對(duì)應(yīng)關(guān)系。

    4、掃描.META. Region 的集合,計(jì)算得到當(dāng)前還未分配的 Region,將他們放入待分配 Region 列表。

Master 下線

  由于 Master 只維護(hù)表和 Region 的元數(shù)據(jù),而不參與表數(shù)據(jù) IO 的過程,Master 下線僅 導(dǎo)致所有元數(shù)據(jù)的修改被凍結(jié)(無法創(chuàng)建刪除表,無法修改表的 schema,無法進(jìn)行 Region 的負(fù)載均衡,無法處理 Region 上下線,無法進(jìn)行 Region 的合并,唯一例外的是 Region 的 split 可以正常進(jìn)行,因?yàn)橹挥?RegionServer 參與),表的數(shù)據(jù)讀寫還可以正常進(jìn)行。因此 Master 下線短時(shí)間內(nèi)對(duì)整個(gè) hbase 集群沒有影響。

  從上線過程可以看到,Master 保存的信息全是可以冗余信息(都可以從系統(tǒng)其它地方 收集到或者計(jì)算出來)

  因此,一般 HBase 集群中總是有一個(gè) Master 在提供服務(wù),還有一個(gè)以上的 Master 在等 待時(shí)機(jī)搶占它的位置。

 

    本站是提供個(gè)人知識(shí)管理的網(wǎng)絡(luò)存儲(chǔ)空間,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點(diǎn)。請(qǐng)注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購買等信息,謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請(qǐng)點(diǎn)擊一鍵舉報(bào)。
    轉(zhuǎn)藏 分享 獻(xiàn)花(0

    0條評(píng)論

    發(fā)表

    請(qǐng)遵守用戶 評(píng)論公約

    類似文章 更多