柚子快報(bào)激活碼778899分享：HBase 進(jìn)階

http://yzkb.51969.com/

前言

1、HBase 進(jìn)階

1.1、Master 架構(gòu)

????????HBase 的主要進(jìn)程，具體實(shí)現(xiàn)類為 HMaster，通常部署在 NameNode（它倆都是管理元數(shù)據(jù)的）；

????????RegionServer 并不能夠直接和 Master 直接通信，因?yàn)?Master 必須和 RegionServer 滿足分布一致性，而讓 HBase 自己來實(shí)現(xiàn)就比較復(fù)雜了，所以 HBase 的分布一致性是由 Zookeeper 來保證的：每個 RegionServer 把自己的信息注冊到 Zookeeper 上；同理，Master 也會注冊一些信息到 Zookeeper 中；

? ? ? ? Master 除了和 zk 交互之外，還會與 HDFS 進(jìn)行交互，因?yàn)?Hbase 的元數(shù)據(jù)存儲在 HDFS 的 "/hbase/data/hbase/meta" 路徑下，該路徑下存儲著 HBase 的元數(shù)據(jù)信息（每個 RegionServer 存儲著那些 Region 信息）；Master 的負(fù)載均衡器組件會通過讀取 meta 表來了解 Region 的一個分布情況，通過 zk 了解 RegionServer 的啟動情況。每五分鐘進(jìn)行一次分配平衡；

? ? ? ? Master 的組件元數(shù)據(jù)表管理器（相當(dāng)于 HMaster 進(jìn)程中的一個線程），它會定期整理元數(shù)據(jù)表里的數(shù)據(jù)（比如哪些版本過期了就清理掉）；

? ? ? ? WAL 預(yù)寫日志管理器，比如當(dāng) Master 要創(chuàng)建一張表的時候，會走一個比較復(fù)雜的流程，為了防止因?yàn)楣?jié)點(diǎn)故障造成任務(wù)失敗丟失，它會把這個任務(wù)先寫入到日志當(dāng)中才會開始執(zhí)行（一般預(yù)寫日志存儲在 hdfs 的 "/hbase/MasterData/WALs"，為了避免產(chǎn)生小文件問題，一般每小時寫入一次或者達(dá)到32M寫入一次）；

1.1.1、Meta 表

全稱 hbase:meta，只是在 list 命令中被過濾掉了，本質(zhì)上和 HBase 的其他表格一樣，也是每個 rowkey 標(biāo)識一行，一行存在多列；

?meta 表的 rowKey：

?meta 表的列：

info:regioninfo 為 region 信息，存儲一個 HRegionInfo 對象。info:server 當(dāng)前 region 所處的 RegionServer 信息，包含端口號。info:serverstartcode 當(dāng)前 region 被分到 RegionServer 的起始時間。

如果一個表處于切分的過程中，即 region 切分，還會多出兩列 info：splitA 和 info：splitB， 存儲值也是 HRegionInfo 對象，拆分結(jié)束后，刪除這兩列。

注意：在客戶端對元數(shù)據(jù)進(jìn)行操作的時候才會連接 master（Admin 連接的是 Master，Table 連接的是 RegionServer），如果對元數(shù)據(jù)進(jìn)行讀寫，直接連接 zookeeper 讀取目錄/hbase/meta-region-server 節(jié)點(diǎn)信息，會記錄 meta 表格的位置。直接讀取即可，不需要訪問 master，這樣可以減輕 master 的壓力，相當(dāng)于 master 專注 meta 表的 寫操作，客戶端可直接讀取 meta 表。

???????? 在 HBase 的 2.3 版本更新了一種新模式：Master Registry?？蛻舳丝梢栽L問 master 來讀取 meta 表信息。加大了 master 的壓力，減輕了 zookeeper 的壓力。

1.2、RegionServer 架構(gòu)

????????RegionServer 同樣會有一個 WAL? 的組件，一方面是為了防止節(jié)點(diǎn)掛了導(dǎo)致數(shù)據(jù)丟失，第二方面是為了使文件有序（rowKey），畢竟一次 put 命令只能寫入一個單元格；

? ? ? ? RegionServer 還有一個讀緩存的組件，為的是加速讀?。ò炎x取過的數(shù)據(jù)寫進(jìn)緩存，方便下次讀?。?，數(shù)量只有一個；此外，還有一個寫緩存的組件，每個 store 都會有一個對應(yīng)的寫緩存，同樣為的是寫入有序；

除了主要的組件之外，RegionServer 還會啟動多個線程去監(jiān)控一些必要的服務(wù)：

Region 拆分：當(dāng)一個 Region 體積過大，RegionServer 需要把它拆分成兩個 RegionRegion 合并：一些 Region 中的數(shù)據(jù)可能比較少（由于部分?jǐn)?shù)據(jù)刪除等原因），需要進(jìn)行合并MemStore 刷寫：寫緩存，由于 HFile 中的數(shù)據(jù)要求是有序的，所以數(shù)據(jù)是先存儲在?MemStore 中，排好序后，等到達(dá)刷寫時機(jī)才會刷寫到 HFile，每次刷寫都會形成一個新的 HFile，寫入到對應(yīng)的 文件夾 store 中。WAL 預(yù)寫日志滾動（和 Master 差不多）因?yàn)閿?shù)據(jù)要經(jīng) MemStore 排序后才能刷寫到 HFile，但把數(shù)據(jù)保存在內(nèi)存中會有很高的 概率導(dǎo)致數(shù)據(jù)丟失，為了解決這個問題，數(shù)據(jù)會先寫到 WAL 文件中，然后再寫入 MemStore 中。所以在系統(tǒng)出現(xiàn)故障的時候，數(shù)據(jù)可以通過這個日志文件重建。

1.2.1、寫流程

HBase 的寫流程從客戶端創(chuàng)建連接開始，刷寫到 HDFS 結(jié)束；

1、創(chuàng)建連接

客戶端向 zk 發(fā)送請求創(chuàng)建連接（連接hbase就得連接zk）向 zk 詢問?meta 表的存儲位置（zk 只存儲 meta 表的位置，不存儲 meta 表的數(shù)據(jù)，畢竟這個表是個 hbase 類型的表）訪問 meta 表將 meta 表中的數(shù)據(jù)緩存到連接中（重量級操作，如果元數(shù)據(jù)發(fā)生變化，還需要再次更新元數(shù)據(jù)）

2、寫入數(shù)據(jù)

發(fā)送 put 命令給目標(biāo) RegionServer（通過 rowKey 并對照?meta 表，得知寫入到哪個 RegionServer）將寫請求持久化到 WAL 日志中（保存在 hdfs 的 /hbase/MasterData/WALs，防止丟失）將寫請求寫入到對應(yīng) MemStore （根據(jù) rowKey 和 columnFamily?確定寫入的 Store，從而確定寫入到哪個寫緩存）等待觸發(fā)寫緩存刷寫，寫入到對應(yīng)的 Store（只能保證每次刷寫的文件是有序的，store 下的多個文件之間并不有序）

3、MemStore Flush

MemStore 刷寫由多個線程控制，條件互相獨(dú)立：

主要的刷寫規(guī)則是控制刷寫文件的大小，在每一個刷寫線程中都會進(jìn)行監(jiān)控

（1）當(dāng)某個 memstroe 的大小達(dá)到了 hbase.hregion.memstore.flush.size（默認(rèn)值 128M）， 其所在 region 的所有 memstore 都會刷寫（一個 region 包含多個 store，一個 store 對應(yīng)一個 memstore），因?yàn)椴煌?store 存儲著不同的列，而一般一行數(shù)據(jù)是均勻分布的（每列基本都有數(shù)據(jù)），所以即使刷寫多個 memstore 也不用太擔(dān)心小文件問題。memstore 內(nèi)的數(shù)據(jù)都差不多大。

當(dāng) memstore 的大小達(dá)到了 hbase.hregion.memstore.flush.size（默認(rèn)值 128M） * hbase.hregion.memstore.block.multiplier（默認(rèn)值 4） 時，會刷寫同時阻止繼續(xù)往該 memstore 寫數(shù)據(jù)（由于線程監(jiān)控是周期性的，所以有可能面對數(shù)據(jù)洪峰，盡管可能性比較??；返防止內(nèi)存溢出，數(shù)據(jù)丟失）

（2）由 HRegionServer 中的屬性 MemStoreFlusher 內(nèi)部線程 FlushHandler 控制。標(biāo)準(zhǔn)為 LOWER_MARK（低水位線）和 HIGH_MARK（高水位線），意義在于避免寫緩存使用過多的內(nèi) 存造成 OOM 當(dāng) region server 中 memstore 的總大小達(dá)到低水位線 java_heapsize * hbase.regionserver.global.memstore.size（默認(rèn)值 0.4）*hbase.regionserver.global.memstore.size.lower.limit（默認(rèn)值 0.95）

????????region 會按照其所有 memstore 的大小順序（由大到?。┮来芜M(jìn)行刷寫。直到 region server 中所有 memstore 的總大小減小到上述值以下。 當(dāng) region server 中 memstore 的總大小達(dá)到高水位線 java_heapsize *hbase.regionserver.global.memstore.size（默認(rèn)值 0.4） 時，會同時阻止繼續(xù)往所有的 memstore 寫數(shù)據(jù)。

（3）為了避免數(shù)據(jù)過長時間處于內(nèi)存之中，到達(dá)自動刷寫的時間，也會觸發(fā) memstore flush。由 HRegionServer 的屬性 PeriodicMemStoreFlusher 控制進(jìn)行，由于重要性比較低，5min才會執(zhí)行一次。 自動刷新的時間間隔由該屬性進(jìn)行配置 hbase.regionserver.optionalcacheflushinterval（默認(rèn) 1 小時）。

（4）當(dāng) WAL 文件的數(shù)量超過 hbase.regionserver.max.logs，region 會按照時間順序依次 進(jìn)行刷寫，直到 WAL 文件數(shù)量減小到 hbase.regionserver.max.logs?以下（該屬性名已經(jīng)廢棄， 現(xiàn)無需手動設(shè)置，最大值為 32）。

1.2.2、讀流程

1、HFile 結(jié)構(gòu)

????????HFile 是存儲在 HDFS 上面每一個 store 文件夾下實(shí)際存儲數(shù)據(jù)的文件。

????????里面存儲多種內(nèi) 容。包括數(shù)據(jù)本身（kv 鍵值對）、元數(shù)據(jù)記錄（記錄當(dāng)前存儲的數(shù)據(jù)在哪個表，哪個 Region）、文件信息、數(shù)據(jù)索引（數(shù)據(jù)的索引）、元數(shù)據(jù)索引和 一個固定長度的尾部信息（用于優(yōu)化讀取性能，記錄文件的版本）。

????????鍵值對按照塊大?。℉File 的塊大小，默認(rèn) 64K）保存在文件中，數(shù)據(jù)索引按照塊創(chuàng)建，塊越多，索引越大。每一個 HFile 還會維護(hù)一個布隆過濾器（就像是一個很大的地圖，文件中每有一種 key， 就在對應(yīng)的位置標(biāo)記，讀取時可以大致判斷（哈希判斷，存在哈希碰撞，所以說是大致判斷）要 get 的 key 是否存在 HFile 中）。

KeyValue 內(nèi)容如下:

rowlength -----------→ key 的長度row -----------------→ key 的值columnfamilylength --→ 列族長度columnfamily --------→ 列族columnqualifier -----→ 列名timestamp -----------→ 時間戳（默認(rèn)系統(tǒng)時間）keytype -------------→ Put

????????由于 HFile 存儲經(jīng)過序列化，所以無法直接查看?？梢酝ㄟ^ HBase 提供的命令來查看存 儲在 HDFS 上面的 HFile 元數(shù)據(jù)內(nèi)容。

bin/hbase hfile -m -f /hbase/data/命名空間/表名/regionID/列族/HFile 名

2、讀流程

1）創(chuàng)建連接

客戶端向 zk 發(fā)送請求創(chuàng)建連接（連接hbase就得連接zk）向 zk 詢問?meta 表的存儲位置（zk 只存儲 meta 表的位置，不存儲 meta 表的數(shù)據(jù)，畢竟這個表是個 hbase 類型的表）訪問 meta 表將 meta 表中的數(shù)據(jù)緩存到連接中（重量級操作，如果元數(shù)據(jù)發(fā)生變化，還需要再次更新元數(shù)據(jù)）

2）讀取數(shù)據(jù)

讀取數(shù)據(jù)一共要去讀三個地方：讀緩存、寫緩存、store 文件（即使從讀緩存中讀到了，也還會去讀寫緩存和磁盤（即使讀取寫緩存也不能保證數(shù)據(jù)是最新的，因?yàn)閿?shù)據(jù)的 timestamp 字段是可以被指定的），因?yàn)椴荒鼙ＷC數(shù)據(jù)是最新版本的）；

發(fā)送 get 請求（通過 rowKey 并對照?meta 表，得知從哪個 RegionServer 讀?。⒆x請求持久化到 WAL （hdfs 的 WAL 目錄）先從讀緩存讀取，讀緩存中存儲的是元數(shù)據(jù)（索引文件，布隆過濾器和key值），其余內(nèi)存按照 64K 緩存原始數(shù)據(jù)（kv鍵值對），清理讀緩存時（根據(jù)活躍度），清理的是原始數(shù)據(jù)而不是元數(shù)據(jù)（版本可能發(fā)生變化，所以并不一定正確）讀取寫緩存，因?yàn)榭赡茏x取的是剛剛寫進(jìn)來的數(shù)據(jù)，還在 memstore 沒有來得及落盤的，讀取 store 下的 hfile 文件（非常慢，所以通過元數(shù)據(jù)中的索引、布隆過濾器（布隆過濾器可以簡單判斷文件里有沒有我們要找的那個 rowKey）進(jìn)行優(yōu)化），讀取到之后還會將讀取到的數(shù)據(jù)緩存到讀緩存合并所有數(shù)據(jù)返回（高版本覆蓋低版本）

3、合并讀取數(shù)據(jù)優(yōu)化

????????每次讀取數(shù)據(jù)都需要讀取三個位置，最后進(jìn)行版本的合并（即使是讀寫緩存中的數(shù)據(jù)也不能保證數(shù)據(jù)是最新的，因?yàn)?timestamp 是可以被手動指定的；所以不管什么時候都是讀取三個文件）。效率會非常低，所有系統(tǒng)需 要對此優(yōu)化（優(yōu)化的主要是讀緩存和讀磁盤文件的優(yōu)化）。

（1）HFile 帶有索引文件，讀取對應(yīng) RowKey 數(shù)據(jù)會比較快。

（2）Block Cache 會緩存之前讀取的內(nèi)容和元數(shù)據(jù)信息，如果 HFile 沒有發(fā)生變化（記錄在 HFile 尾信息中），則不需要再次讀取。

（3）使用布隆過濾器能夠快速過濾當(dāng)前 HFile 不存在需要讀取的 RowKey，從而避免讀取文件。（布隆過濾器使用 HASH 算法，不是絕對準(zhǔn)確的，出錯會造成多掃描一個文件，對讀取數(shù)據(jù)結(jié)果沒有影響）

布隆過濾器很長（常見的布隆過濾器基本上是 10 億個長度，但是它的一個長度才占用 1 bit，大約 100 多MB；HBase 的布隆過濾器要小一點(diǎn)，大約千百萬個長度）

1.2.3、StoreFile Compaction（HFile 文件的合并）

????????由于 memstore 每次刷寫都會生成一個新的 HFile（就像我們 MapReduce 的 map spill 階段），文件過多讀取不方便，所以會進(jìn)行文 件的合并，清理掉過期和刪除的數(shù)據(jù)，會進(jìn)行 StoreFile Compaction。

???????? Compaction 分為兩種，分別是 Minor Compaction（小合并） 和 Major Compaction（大合并）。Minor Compaction 會將臨近的若干個較小的 HFile 合并成一個較大的 HFile，并清理掉部分過期和刪除的數(shù)據(jù)， 有系統(tǒng)使用一組參數(shù)自動控制，Major Compaction 會將一個 Store 下的所有的 HFile 合并成 一個大 HFile，并且會清理掉所有過期和刪除的數(shù)據(jù)，由參數(shù) hbase.hregion.majorcompaction 控制，默認(rèn) 7 天。

小合并把相鄰的文件進(jìn)行合并，即使是 deleteAll 也不會把前面老的數(shù)據(jù)刪除掉，因?yàn)楝F(xiàn)在是小合并，只有在大合并才能波及到所有數(shù)據(jù)（就像 MapReduce 的 Conbiner）大合并會合并所有的文件，遇到 deleteAll 會直接把前面老的數(shù)據(jù)都刪除

小文件合并機(jī)制

參與到小合并的文件需要通過參數(shù)計(jì)算得到，有效的參數(shù)有 5 個

hbase.hstore.compaction.ratio（默認(rèn) 1.2F）合并文件選擇算法中使用的比率。hbase.hstore.compaction.min（默認(rèn) 3） 為 Minor Compaction 的最少文件個數(shù)。hbase.hstore.compaction.max（默認(rèn) 10） 為 Minor Compaction 最大文件個數(shù)。hbase.hstore.compaction.min.size（默認(rèn) 128M）為單個 Hfile 文件大小最小值，小于這個數(shù)會被合并。hbase.hstore.compaction.max.size（默認(rèn) Long.MAX_VALUE）為單個 Hfile 文件大小最大 值，高于這個數(shù)不會被合并（永遠(yuǎn)不會觸發(fā)）。

小合并機(jī)制為拉取當(dāng)前?store 中所有的文件，做成一個集合。之后按照從舊到新的順序遍歷。 判斷條件為：

① 過小合并，過大不合并（也就是小于 128MB 才合并，最大值因?yàn)槟J(rèn)是 Long.MAX_VALUE，所以永遠(yuǎn)不會觸發(fā)，除非我們自己設(shè)置）② 文件大小 / hbase.hstore.compaction.ratio < (剩余文件大小和，當(dāng)前選中的文件之外的其它文件) 則參與壓縮。所以把比值設(shè)置過大，如 10 會最終合并為 1 個特別大的文件，相反設(shè)置為 0.4，會最終產(chǎn)生 4個?storeFile。 不建議修改默認(rèn)值（1.2F 是大神調(diào)校過的）③ 滿足壓縮條件的文件個數(shù)達(dá)不到個數(shù)要求（3 <= count <= 10）則不壓縮。

1.2.4、Region 自定義切分

????????Region 切分分為兩種，創(chuàng)建表格時候的預(yù)分區(qū)即自定義分區(qū)，同時系統(tǒng)默認(rèn)還會啟動一 個切分規(guī)則，避免單個 Region 中的數(shù)據(jù)量太大（經(jīng)過刷寫合并之后，所有文件不可避免會成為一個特別大的文件，如果不切分還會越來越大）。

????????每一個 Region 維護(hù)著 startRow 與 endRowKey，如果加入的數(shù)據(jù)符合某個 Region 維護(hù)的 rowKey 范圍，則該數(shù)據(jù)交給這個 region 維護(hù)。那么依照這個原則，我們可以將數(shù)據(jù)所要投放的分區(qū)提前大致的規(guī)劃好，以提高 HBase 性能。

手動設(shè)定預(yù)分區(qū)?

# 創(chuàng)建表格時指定 region 的切分規(guī)則

create 'staff1','info', SPLITS => ['1000','2000','3000','4000']

這樣，當(dāng) rowKey < '1000' 的就會放到第一個分區(qū)，然后 [1000,2000),[2000,3000)... 以此類推?

生成 16 進(jìn)制序列預(yù)分區(qū)（不太好用）

create 'staff2','info',{NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}

按照文件中設(shè)置的規(guī)則預(yù)分區(qū)

其實(shí)和第一種手動設(shè)定預(yù)分區(qū)是一樣的，無非就是當(dāng)分區(qū)特多的時候命令行寫得難受，我們把它寫到文件里:

# split.txt

1000

2000

3000

4000

然后執(zhí)行：

create 'staff3', 'info',SPLITS_FILE => 'splits.txt'

使用 Java API 創(chuàng)建預(yù)分區(qū)

public class HBaseConnect {

public static void main(String[] args) throws IOException {

// 1.獲取配置類

Configuration conf = HBaseConfiguration.create();

// 2.給配置類添加配置

conf.set("hbase.zookeeper.quorum","hadoop102,hadoop103,hadoop104"

);

// 3.獲取連接

Connection connection =

ConnectionFactory.createConnection(conf);

// 3.獲取 admin

Admin admin = connection.getAdmin();

// 5.獲取 descriptor 的 builder

TableDescriptorBuilder builder =

TableDescriptorBuilder.newBuilder(TableName.valueOf("bigdata",

"staff4"));

// 6. 添加列族

builder.setColumnFamily(ColumnFamilyDescriptorBuilder.newBuilder(

Bytes.toBytes("info")).build());

// 7.創(chuàng)建對應(yīng)的切分

byte[][] splits = new byte[3][];

splits[0] = Bytes.toBytes("aaa");

splits[1] = Bytes.toBytes("bbb");

splits[2] = Bytes.toBytes("ccc");

// 8.創(chuàng)建表

admin.createTable(builder.build(),splits);

// 9.關(guān)閉資源

admin.close();

connection.close();

}

}

1.2.5、Region 系統(tǒng)切分

????????Region 的拆分是由 HRegionServer 完成的，在操作之前需要通過 ZK 匯報(bào) master，修改 對應(yīng)的 Meta 表信息添加兩列 info：splitA 和 info：splitB 信息。之后需要操作 HDFS 上面對 應(yīng)的文件，按照拆分后的 Region 范圍（rowKey 的范圍）進(jìn)行標(biāo)記區(qū)分，實(shí)際操作為創(chuàng)建文件引用，不會挪動數(shù)據(jù)。剛完成拆分的時候，兩個 Region 都由原先的 RegionServer 管理。之后匯報(bào)給 Master， 由Master將修改后的信息寫入到Meta表中。等待下一次觸發(fā)負(fù)載均衡機(jī)制，才會修改Region 的管理服務(wù)者，而數(shù)據(jù)要等到下一次合并時，才會實(shí)際進(jìn)行移動。

???????? 不管是否使用預(yù)分區(qū)，系統(tǒng)都會默認(rèn)啟動一套 Region 拆分規(guī)則。不同版本的拆分規(guī)則 有差別。系統(tǒng)拆分策略的父類為 RegionSplitPolicy。

Hbase 2.0 引入了新的 split 策略：如果當(dāng)前 RegionServer 上該表只有一個 Region， 按照 2 * hbase.hregion.memstore.flush.size （也就是 2*128=256MB）拆分，否則按照 hbase.hregion.max.filesize （10G） 分裂。?

也就是當(dāng)?shù)谝淮芜_(dá)到 256 MB 的時候一分為二，形成兩個 Region，之后達(dá)到?10 G 才去切分；

柚子快報(bào)激活碼778899分享：HBase 進(jìn)階

http://yzkb.51969.com/

相關(guān)鏈接