HBase 面試題

HBase的基本介紹

Hbase 是建立在hdfs之上的一個數據庫，不支持join等SQL複雜操作.支持的數據類型：byte[]，依靠橫向擴展

一個表可以有上十億行，上百萬列。

面向列(族)的存儲和權限控制

對於爲空(null)的列，並不佔用存儲空間，是一個稀疏表。

HBASE的適用場景

海量數據、精確查詢、快速返回

海量數據：指的是數據量的背景

精確查詢：業務場景

快速返回：是業務對時效性的要求

Hbase和Hadoop之間的關係

HDFS

海量數據存儲，適合一次性掃描大量數據。

適合一次寫入多次讀取

不適合頻繁更新的數據

HBASE

不適合一次性掃描大量數據。適用一次掃描少量數據。

適合多次寫入多次讀取

habse

支持數據更新

支持刪除數據

Hbase與RDBMS的關係

RDBMS

支持SQL查詢

支持事務

支持Join

HBASE

不支持SQL查詢

不支持事務

不支持Join

Hbase特徵簡要說明

1、 海量存儲

Hbase適合存儲PB級別的海量數據，在幾十到百毫秒內返回數據。

2、列式存儲

這裏的列式存儲其實說的是列族存儲

列族理論上可以很多，但實際上建議不要超過6個

3、 極易擴展

處理能力（RegionServer）的擴展，一個是基於存儲的擴展（HDFS）

hbase在最初設計的時候就考慮了擴展性。

4、高併發

這裏說的高併發，主要是在併發的情況下，Hbase的單個IO延遲下降並不多

5、稀疏

在列數據爲空的情況下，是不會佔用存儲空間的。

hbase的基礎架構

1、Client

2 ZOOKEEPER

3 Master 管理者

4 Regionserver 工作者

HBase的底層原理

詳細架構

$[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-ypPWJkVA-1576574636380)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576142410861.png)]$

Client：

訪問數據的入口，包含訪問hbase的API接口,維護着一些cache來加快對hbase的訪問

Zookeeper：

1 zookeeper的選舉機制保證任何時候，集羣中只有一個master

2 實時監控Region Server的狀態，將Region server的上線和下線信息實時通知給Master

3 存儲Hbase的schema,

4 存貯所有Region的尋址入口

Master職責

1 爲Region server分配region

2 負責region server的負載均衡

3 發現失效的region server並重新分配其上的region

4 處理schema更新請求

說明：Hmaster短時間下線，hbase集羣依然可用，長時間不行。

Region server的作用

1、 Region server維護Master分配給它的region，處理對這些region的IO請求

2、Region server負責切分在運行過程中變得過大的region

HBase的表數據模型

$ [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-fFUrQdIf-1576574636380)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576221183717.png)]$

Row Key

最大長度是 64KB，完全可以自行設計。Hbase會對錶中的數據按照rowkey排序（字典序）

row的設計是最有技術含量的工作

列族Column Family

列族是表的schema的一部分，而列不是。（schema包含表名和列族）

每個列都所屬於某一個列族。一個列族可以包含多個列。一個列族與列的關係是一對多。

列 Column

列族下面的具體列。

時間戳

標記一個數據的不同版本

時間戳可以由hbase(在數據寫入時自動 )賦值，hbase支持工程師自己定義時間戳。

每個 cell中，不同版本的數據按照時間倒序排序

$ [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-WjF0yuYr-1576574636381)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576222927816.png)]$

hbase本身提供數據回收機制

1、保存數據的最後n個版本

2、保存最近一段時間內的版本

Cell存儲數據的最小單位

如何確定一個精確的數據

由{row key, column( = + ), version} 唯一確定的單元

VersionNum

數據的版本號，默認值爲系統時間戳。

hbase物理存儲

整體結構

$[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-9eFQWPQi-1576574636381)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576223773710.png)]$

一個regionserver內部可以有多個region,這多個region可能來自多個表或一個表。一個region只能屬於一個regionserver.

region的切分

region按大小分割的(默認10G)。每個表一開始只有一個region，隨着數據的增加，一個region逐漸變大，達到10G，進行分裂，等分成兩個region.

Hregion是Hbase中分佈式存儲和負載均衡的最小單元

HRegion由一個或者多個Store組成，每個store保存一個column family。每個Strore又由一個memStore和0至多個StoreFile組成

$[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-VnyacU8y-1576574636382)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576224286253.png)]$

$[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-7y0jA6Vz-1576574636383)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576224437317.png)]$

Memstore與storefile

一個region由多個store組成，每個store包含一個列族的所有數據 Store包括位於內存的memstore和位於硬盤的storefile

客戶端檢索數據時，先在memstore找，找不到再找storefile

HLog(WAL log)

每個Region Server維護一個Hlog,而不是每個Region一個.

Hlog的切分機制

1、當數據寫入hlog以後，hbase發生異常。關閉當前的hlog文件

2、當日志的大小達到HDFS數據塊的0.95倍的時候，關閉當前日誌，生成新的日誌

3、每隔一小時生成一個新的日誌文件

讀寫過程

讀請求過程

前提：什麼是meta表？

meta表述hbase系統自帶的一個表。裏面存儲了hbase用戶表的元信息。

元信息爲：meta表內記錄一行數據是用戶表一個region的start key 到endkey的範圍。

meta表存在什麼地方？

meta表存儲在regionserver裏。具體存儲在哪個regionserver裏？zookeeper知道。

$[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-blriqNHs-1576574636383)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576229218108.png)]$

1 到zookeeper詢問meta表在哪

2 到meta所在的節點（regionserver）讀取meta表的數據

3 找到region 獲取region和regionserver的對應關係，直接到regionserver讀取region數據

寫請求過程

$ [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-2ZAF2Z7S-1576574636385)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576456747119.png)]$

1、Client先訪問zookeeper，找到Meta表，並獲取Meta表元數據。確定當前將要寫入的數據所對應的HRegion和HRegionServer服務器。

2、Client向該HRegionServer服務器發起寫入數據請求。

2.1 Client先把數據寫入到HLog，以防止數據丟失。
2.2 然後將數據寫入到Memstore。

3、Memstore達到閾值，會把Memstore中的數據flush到Storefile中

4、當Storefile越來越多，達到一定數量時，會觸發Compact合併操作，將多個小文件合併成一個大文件。

5、Storefile越來越大，Region也會越來越大，達到閾值後，會觸發Split操作，變成兩個文件。

說明：hbasez 支持數據修改（僞修改），實際上是相同rowkey數據的添加。hbase只顯示最後一次的添加。

region的管理

region的分配過程

前提：一個region只能分配給一個region server

1、master記錄了當前有哪些可用的region server。以及當前哪些region分配給了哪些region server，哪些region還沒有分配。

2、當需要分配的新的region，並且有一個region server上有可用空間時，master就給這個region server發送一個裝載請求，把region分配給這個region server。

3、region server得到請求後，就開始對此region提供服務。

$[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-O7zwBk8B-1576574636385)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576457883580.png)]$

region server上線

前提：master使用zookeeper來跟蹤region server狀態。

1、當某個region server啓動時，首先在zookeeper上的/hbase/rs目錄下建立代表自己的znode。

2、 master訂閱了/hbase/rs目錄上的變更消息，當/hbase/rs目錄下的文件出現新增或刪除操作時，master可以得到來自zookeeper的實時通知。因此一旦region server上線，master能馬上得到消息。

region server下線

前提：master使用zookeeper來跟蹤region server狀態。

1、當region server下線時，它和zookeeper的會話斷開。

2、zookeeper而自動釋放代表這臺server的文件上的獨佔鎖（znode）

3、zookeeper將變化發送給master

4、master 將掛掉的region server的region分配給其它還活着的regionserver。

Hmaster的上線

前提：hbase集羣中可以設置多個Hmaster，真正對外提供服務的只有一個

1 從zookeeper上獲取唯一一個代表active master的鎖，用來阻止其它master成爲真正的master。

2 掃描zookeeper上的/hbase/rs節點，獲得當前可用的region server列表。

3 master和每個region server通信，獲得當前已分配的region和region server的對應關係。

4 master掃描.META.表，計算得到當前還未分配的region，將他們放入待分配region列表。

問題一：如何確定哪個master是真正的master

看誰獲得到了active master的鎖

問題二： master如何知道有哪些regionserver,

掃描zookeeper上的/hbase/rs節點

問題三:master 如何知道region與regionserver之間的對應關係

master和每個region server通信，regionserver反饋對應關係

問題四：master如何知道哪些region還未分配

master掃描.META.表，計算得到當前還未分配的region

Hmaster下線

master只維護表和region的元數據，不參與表數據IO的過程，所以master下線短時間內對整個hbase集羣沒有影響。

表的數據讀寫還可以正常進行。

Hmaster下線後的影響：

無法創建刪除表，無法修改表的schema，無法進行region的負載均衡，無法處理region 上下線，無法進行region的合併（region的split可以正常進行）

當hmaster下線後，啓動Zookeeper的選舉機制，選出新的Hmaster,新的Hmaster上線，執行上線流程。

HBase三個重要機制

1、flush機制

hbase.regionserver.global.memstore.size：默認;堆大小的40%

regionServer的全局memstore的大小（多個CF的memstore-多個region），超過該大小會觸發flush到磁盤的操作，會阻塞客戶端讀寫

flush將所有的memstore全部flush.

hbase不建議配置過多列族：過多的列族會消耗大量的內存，同時數據在flush時消耗磁盤IO.

一個regionserver續寫操作可用堆內存的80%，讀取佔用40% ，寫入佔用40%。這兩個參數直接影響hbase讀寫性能。

什麼時候觸發flush

hbase.hregion.memstore.flush.size：默認：128M（單個region裏memstore的緩存大小）

hbase.regionserver.optionalcacheflushinterval：默認：1h

hbase.regionserver.global.memstore.size.lower.limit：默認：堆大小 0.95倍

hbase.hregion.preclose.flush.size：默認爲：5M 提前進行flush.(先flush一小部分，等後面數據達到閾值在flush後面的數據) 好處：比一次flush效率高

什麼時候觸發合併

hbase.hstore.compactionThreshold：默認：3個（flush文件的數量超過3個進行合併）

2、compact機制

默認3個

小的storeFile文件達到三個，合併成大的Storefile文件。

3、split機制

默認一個HFile達到10Gb的時候就會進行切分

hbase預分區

與分區的好處（優點）：

* 增加數據讀寫效率 : 數據分佈在多臺regionserver節點

* 負載均衡，防止數據傾斜：當數據時離散的發送時，預分區可以解決數據傾斜

* 方便集羣容災調度region ：分佈在多個節點便於調度

* 優化Map數量：

原本數據分區（分region）的過程：

一個數據表原本只有一個region(分區)，隨着數據量的增加，region慢慢變大，達到10G ，一個region變成兩個region。當數據量還沒有達到10G ，所有的數據全部寫入一個region。一個region只能屬於一個regionserver.

如何優化？方案：將一個10G的數據打散，儘量多的，儘量均勻的分散到不同的regionserver上。

如何實現上述方案：預分區（region） 預先設置每個region 的startkey和endkey

命令分區：

create ‘staff’,‘info’,‘partition1’,SPLITS => [‘1000’,‘2000’,‘3000’,‘4000’]

API創建分區

後續講API時創建

$ [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-ExsFOCCX-1576574636386)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1576468136709.png)]$

HBase的rowKey設計技巧

rowKey屬性，最大64K,按照字典序排序，可以自定義

hbase數據的獲取方式

1、通過rowkey直接查找

2、通過startkey endkey 範圍查找

3、全表掃描

1 rowkey長度原則

最大64K,建議越短越好(在保證業務需求的前提下)，不要超過16個字節.

2 rowkey散列原則

建議將rowkey的高位(左邊)作爲散列字段，低位（右邊）放時間字段，這樣將提高數據均衡分佈在每個RegionServer，以實現負載均衡的機率。

若不按照此原則：

讓時間戳作爲高位：數據將按照時間的順序進行存儲。

熱點問題：當有一點時間業務數據爆炸增長時，這個階段的數據將存儲在少數的節點上。

熱點爲題如何解決？？？？？

3 rowkey唯一原則

必須在設計上保證其唯一性，將經常讀取的數據存儲到一塊，將最近可能會被訪問的數據放到一塊。

熱點問題如何解決？？？？？

原則：將分散的數據，放在rowkey的高位

1、哈希（隨機數），將哈希值放在高位

2、反轉：反轉固定長度或者數字格式的數據（時間戳反轉、手機號反轉，訂單號反轉）

3、加鹽：本質時是加隨機數，並且放在高位。

2、通過startkey endkey 範圍查找

3、全表掃描

1 rowkey長度原則

最大64K,建議越短越好(在保證業務需求的前提下)，不要超過16個字節.

2 rowkey散列原則

建議將rowkey的高位(左邊)作爲散列字段，低位（右邊）放時間字段，這樣將提高數據均衡分佈在每個RegionServer，以實現負載均衡的機率。

若不按照此原則：

讓時間戳作爲高位：數據將按照時間的順序進行存儲。

熱點問題：當有一點時間業務數據爆炸增長時，這個階段的數據將存儲在少數的節點上。

熱點爲題如何解決？？？？？

3 rowkey唯一原則

必須在設計上保證其唯一性，將經常讀取的數據存儲到一塊，將最近可能會被訪問的數據放到一塊。

文章目錄

HBase的基本介紹

HBASE的適用場景

Hbase和Hadoop之間的關係

Hbase與RDBMS的關係

Hbase特徵簡要說明

hbase的基礎架構

HBase的底層原理

HBase的表數據模型

Row Key

列族Column Family

列 Column

時間戳

Cell存儲數據的最小單位

VersionNum

hbase物理存儲

region的切分

Memstore與storefile

HLog(WAL log)

讀寫過程

​ 讀請求過程

寫請求過程

region的管理

region server上線

region server下線

Hmaster的上線

​Hmaster下線

Hmaster下線後的影響：

​HBase三個重要機制

​ 1、flush機制

什麼時候觸發flush

什麼時候觸發合併

2、compact機制

3、split機制

hbase預分區

HBase的rowKey設計技巧

​ 1 rowkey長度原則

​ 2 rowkey散列原則

3 rowkey唯一原則

熱點問題如何解決？？？？？

​ 1 rowkey長度原則

​ 2 rowkey散列原則

3 rowkey唯一原則

讀請求過程

Hmaster下線

HBase三個重要機制

1、flush機制

1 rowkey長度原則

2 rowkey散列原則

1 rowkey長度原則

2 rowkey散列原則