Hbase

1. 概念

base 是分布式、面向列的開源數(shù)據(jù)庫（其實(shí)準(zhǔn)確的說是面向列族）。HDFS 為 Hbase 提供可靠的
底層數(shù)據(jù)存儲服務(wù)，MapReduce 為 Hbase 提供高性能的計(jì)算能力，Zookeeper 為 Hbase 提供
穩(wěn)定服務(wù)和 Failover 機(jī)制，因此我們說 Hbase 是一個(gè)通過大量廉價(jià)的機(jī)器解決海量數(shù)據(jù)的高速存
儲和讀取的分布式數(shù)據(jù)庫解決方案。

2. 列式存儲

列方式所帶來的重要好處之一就是，由于查詢中的選擇規(guī)則是通過列來定義的，因此整個(gè)數(shù)據(jù)庫
是自動(dòng)索引化的。

image.png

這里的列式存儲其實(shí)說的是列族存儲，Hbase 是根據(jù)列族來存儲數(shù)據(jù)的。列族下面可以有非常多
的列，列族在創(chuàng)建表的時(shí)候就必須指定。為了加深對 Hbase 列族的理解，下面是一個(gè)簡單的關(guān)系
型數(shù)據(jù)庫的表和 Hbase 數(shù)據(jù)庫的表：

image.png

3. Hbase 核心概念

3.1. Column Family 列族

Column Family 又叫列族，Hbase 通過列族劃分?jǐn)?shù)據(jù)的存儲，列族下面可以包含任意多的列，實(shí)
現(xiàn)靈活的數(shù)據(jù)存取。Hbase 表的創(chuàng)建的時(shí)候就必須指定列族。就像關(guān)系型數(shù)據(jù)庫創(chuàng)建的時(shí)候必須
指定具體的列是一樣的。Hbase 的列族不是越多越好，官方推薦的是列族最好小于或者等于 3。我
們使用的場景一般是 1 個(gè)列族。

3.2. Rowkey（Rowkey 查詢，Rowkey 范圍掃描，全表掃描）

Rowkey 的概念和 mysql 中的主鍵是完全一樣的，Hbase 使用 Rowkey 來唯一的區(qū)分某一行的數(shù)
據(jù)。Hbase 只支持 3 中查詢方式：基于 Rowkey 的單行查詢，基于 Rowkey 的范圍掃描，全表掃
描。

3.3. Region 分區(qū)

• Region：Region 的概念和關(guān)系型數(shù)據(jù)庫的分區(qū)或者分片差不多。Hbase 會將一個(gè)大表的數(shù)
  據(jù)基于 Rowkey 的不同范圍分配到不通的 Region 中，每個(gè) Region 負(fù)責(zé)一定范圍的數(shù)據(jù)訪問
  和存儲。這樣即使是一張巨大的表，由于被切割到不通的 region，訪問起來的時(shí)延也很低。

3.4. TimeStamp 多版本

• TimeStamp 是實(shí)現(xiàn) Hbase 多版本的關(guān)鍵。在 Hbase 中使用不同的 timestame 來標(biāo)識相同
  rowkey 行對應(yīng)的不通版本的數(shù)據(jù)。在寫入數(shù)據(jù)的時(shí)候，如果用戶沒有指定對應(yīng)的
  timestamp，Hbase 會自動(dòng)添加一個(gè) timestamp，timestamp 和服務(wù)器時(shí)間保持一致。在
  Hbase 中，相同 rowkey 的數(shù)據(jù)按照 timestamp 倒序排列。默認(rèn)查詢的是最新的版本，用戶
  可同指定 timestamp 的值來讀取舊版本的數(shù)據(jù)。

4. Hbase 核心架構(gòu)

Hbase 是由 Client、Zookeeper、Master、HRegionServer、HDFS 等幾個(gè)組建組成。

image.png

4.1. Client：

• Client 包含了訪問 Hbase 的接口，另外 Client 還維護(hù)了對應(yīng)的 cache 來加速 Hbase 的
  訪問，比如 cache 的.META.元數(shù)據(jù)的信息。

4.2. Zookeeper：

• Hbase 通過 Zookeeper 來做 master 的高可用、RegionServer 的監(jiān)控、元數(shù)據(jù)的入口
  以及集群配置的維護(hù)等工作。具體工作如下：

1. 通過 Zoopkeeper 來保證集群中只有 1 個(gè) master 在運(yùn)行，如果 master 異
   常，會通過競爭機(jī)制產(chǎn)生新的 master 提供服務(wù)
2. 通過 Zoopkeeper 來監(jiān)控 RegionServer 的狀態(tài)，當(dāng) RegionSevrer 有異常的
   時(shí)候，通過回調(diào)的形式通知 Master RegionServer 上下限的信息
3. 通過 Zoopkeeper 存儲元數(shù)據(jù)的統(tǒng)一入口地址。

4.3. Hmaster

• master 節(jié)點(diǎn)的主要職責(zé)如下：

1. 為 RegionServer 分配 Region
2. 維護(hù)整個(gè)集群的負(fù)載均衡
3. 維護(hù)集群的元數(shù)據(jù)信息發(fā)現(xiàn)失效的 Region，并將失效的 Region 分配到正常
   RegionServer 上當(dāng) RegionSever 失效的時(shí)候，協(xié)調(diào)對應(yīng) Hlog 的拆分

4.4. HregionServer

• HregionServer 直接對接用戶的讀寫請求，是真正的“干活”的節(jié)點(diǎn)。它的功能概括如
  下：

1. 管理 master 為其分配的 Region
2. 處理來自客戶端的讀寫請求
3. 負(fù)責(zé)和底層 HDFS 的交互，存儲數(shù)據(jù)到 HDFS
4. 負(fù)責(zé) Region 變大以后的拆分
5. 負(fù)責(zé) Storefile 的合并工作

4.5. Region 尋址方式（通過 zookeeper .META）

第 1 步：Client 請求 ZK 獲取.META.所在的 RegionServer 的地址。
第 2 步：Client 請求.META.所在的 RegionServer 獲取訪問數(shù)據(jù)所在的 RegionServer 地
址，client 會將.META.的相關(guān)信息 cache 下來，以便下一次快速訪問。
第 3 步：Client 請求數(shù)據(jù)所在的 RegionServer，獲取所需要的數(shù)據(jù)。

image.png

4.6. HDFS

• HDFS 為 Hbase 提供最終的底層數(shù)據(jù)存儲服務(wù)，同時(shí)為 Hbase 提供高可用（Hlog 存儲在
  HDFS）的支持。

5. Hbase 的寫邏輯

5.1. Hbase 的寫入流程

image.png

從上圖可以看出氛圍 3 步驟：
獲取 RegionServer
第 1 步：Client 獲取數(shù)據(jù)寫入的 Region 所在的 RegionServer
請求寫 Hlog
第 2 步：請求寫 Hlog, Hlog 存儲在 HDFS，當(dāng) RegionServer 出現(xiàn)異常，需要使用 Hlog 來
恢復(fù)數(shù)據(jù)。
請求寫 MemStore
第 3 步：請求寫 MemStore,只有當(dāng)寫 Hlog 和寫 MemStore 都成功了才算請求寫入完成。
MemStore 后續(xù)會逐漸刷到 HDFS 中。

5.2. MemStore 刷盤

為了提高 Hbase 的寫入性能，當(dāng)寫請求寫入 MemStore 后，不會立即刷盤。而是會等到一
定的時(shí)候進(jìn)行刷盤的操作。具體是哪些場景會觸發(fā)刷盤的操作呢？總結(jié)成如下的幾個(gè)場景：
全局內(nèi)存控制

1. 這個(gè)全局的參數(shù)是控制內(nèi)存整體的使用情況，當(dāng)所有 memstore 占整個(gè) heap 的最大比
   例的時(shí)候，會觸發(fā)刷盤的操作。這個(gè)參數(shù)是
   hbase.regionserver.global.memstore.upperLimit，默認(rèn)為整個(gè) heap 內(nèi)存的 40%。
   但這并不意味著全局內(nèi)存觸發(fā)的刷盤操作會將所有的 MemStore 都進(jìn)行輸盤，而是通過
   另外一個(gè)參數(shù) hbase.regionserver.global.memstore.lowerLimit 來控制，默認(rèn)是整個(gè)
   heap 內(nèi)存的 35%。當(dāng) flush 到所有 memstore 占整個(gè) heap 內(nèi)存的比率為 35%的時(shí)
   候，就停止刷盤。這么做主要是為了減少刷盤對業(yè)務(wù)帶來的影響，實(shí)現(xiàn)平滑系統(tǒng)負(fù)載的
   目的。
   MemStore 達(dá)到上限
2. 當(dāng) MemStore 的大小達(dá)到 hbase.hregion.memstore.flush.size 大小的時(shí)候會觸發(fā)刷
   盤，默認(rèn) 128M 大小
   RegionServer 的 Hlog 數(shù)量達(dá)到上限
3. 前面說到 Hlog 為了保證 Hbase 數(shù)據(jù)的一致性，那么如果 Hlog 太多的話，會導(dǎo)致故障
   恢復(fù)的時(shí)間太長，因此 Hbase 會對 Hlog 的最大個(gè)數(shù)做限制。當(dāng)達(dá)到 Hlog 的最大個(gè)數(shù)
   的時(shí)候，會強(qiáng)制刷盤。這個(gè)參數(shù)是 hase.regionserver.max.logs，默認(rèn)是 32 個(gè)。
   手工觸發(fā)
4. 可以通過 hbase shell 或者 java api 手工觸發(fā) flush 的操作。
   關(guān)閉 RegionServer 觸發(fā)
5. 在正常關(guān)閉 RegionServer 會觸發(fā)刷盤的操作，全部數(shù)據(jù)刷盤后就不需要再使用 Hlog 恢
   復(fù)數(shù)據(jù)。
   Region 使用 HLOG 恢復(fù)完數(shù)據(jù)后觸發(fā)
6. ：當(dāng) RegionServer 出現(xiàn)故障的時(shí)候，其上面的 Region 會遷移到其他正常的
   RegionServer 上，在恢復(fù)完 Region 的數(shù)據(jù)后，會觸發(fā)刷盤，當(dāng)刷盤完成后才會提供給
   業(yè)務(wù)訪問。

6. HBase vs Cassandra

image.png

image.png