Hbase基礎

• Hbase基礎
  • Hbase定義
  • 行存儲 v s 列存儲
  • Hbase數據模型
  • Hbase物理模型
  • Hbase系統架構
  • Hbase的容錯
  • Hbase特殊的表
  • 合並
  • Hbase的Compaction和Split

Hbase定義

• HBase是一個開源的非關系型分布式數據庫（NoSQL），它參考了谷歌的BigTable建模，實現的編程語言為 Java。

• 是Apache軟件基金會的Hadoop項目的一部分，運行於HDFS文件系統之上，因此可以容錯地存儲海量稀疏的數據

行存儲 v s 列存儲

• 行存儲：
  – 優點：寫入一次性完成，保持數據完整性
  – 缺點：數據讀取過程中產生冗余數據，若有少量數據可以忽略

• 列存儲
  – 優點：讀取過程，不會產生冗余數據，特別適合對數據完整性要求不高的大數據領域
  – 缺點：寫入效率差，保證數據完整性方面差

Hbase數據模型

• RowKey：是Byte array，是表中每條記錄的“主鍵”，方便快速查找，Rowkey的設計非常重要。
• Column Family：列族，擁有一個名稱(string)，包含一個或者多個相關列
• Column：屬於某一個columnfamily，familyName:columnName，每條記錄可動態添加
• Version Number：類型為Long，默認值是系統時間戳，可由用戶自定義
• Value(Cell)：Byte array

Hbase物理模型

• Hbase一張表由一個或多個Hregion(Region)組成

• 記錄之間按照Row Key的字典序排列

  如圖
  

• Region按大小分割的，每個表一開始只有一個region，隨著數據不斷插入表，region不斷增大，當增大到一個閥值的時候，Hregion就會等分會兩個新的Hregion。當table中的行不斷增多，就會有越來越多的Hregion。
  如圖:
  

• Region配置，默認大小10GB，如果在沒有自定義配置的情況下，超過10GB就會自動分裂

• 當對某一行進行修改時，會鎖定一整行數據，也就是對這一樣進行加鎖，當對某一行的某一個字段進行讀操作時，其他字段也不允許被操作，

• 一個RegionServer可以包含多個Region，內部管理了一系列的HRegion
  如圖：
  

• saf
  表 -> HTable
  ? 按RowKey範圍分的Region-> HRegion ->Region Servers
  ? HRegion按列族（Column Family） ->多個HStore
  ? HStore -> memstore(默認128M，超過128M就會自動往磁盤上split) + HFiles(均為有序的KV)
  ? HFiles -> HDFS

• HRegion是Hbase中分布式存儲和負載均衡的最小單元，最小單元就表示不同的
  Hregion可以分布在不同的HRegion server上，但一個Hregion是不會拆分到
  多個server上的
  如圖：
  

• HRegion雖然是分布式存儲的最小單元，但並不是存儲的最小單元
  如圖：
  

Hbase系統架構

• Client
  – 訪問Hbase的接口，並維護Cache加速Region Server的訪問

• Master(主)
  – 負載均衡，分配Region到RegionServer
  – DLL,增刪查改 -> table,cf,namespace
  – 類似namenode,管理一些元數據
  – ACL權限控制

• HRegionServer(從)
  1. 維護Region，負責Region的IO請求
  2. 管理和存放本地的HRegion
  3. 讀寫HDFS，提供IO操作
  4. 本地化：HRegion的數據盡量和數據所屬的DataNode在一起，但是這個本地化不能夠總是滿足和實現

• Zookeeper
  – 保證集群中只有一個Master
  – 存儲所有Region的入口（ROOT）地址
  – 實時監控Region Server的上下線信息，並通知Master

Hbase的容錯

• ZooKeeper協調集群所有節點的共享信息，在HMaster和HRegionServer連接到ZooKeeper後創建Ephemeral節點，並使用Heartbeat機制維持這個節點的存活狀態，如果某個Ephemeral節點實效，則HMaster會收到通知，並做相應的處理。

• 除了HDFS存儲信息，HBase還在Zookeeper中存儲信息，其中的znode信息：

1. /hbase/root-region-server ，Root region的位置
2. /hbase/table/-ROOT-，根元數據信息
3. /hbase/table/.META.，元數據信息
4. /hbase/master，當選的Mater
5. /hbase/backup-masters，備選的Master
6. /hbase/rs ，Region Server的信息
7. /hbase/unassigned，未分配的Region

• Master容錯：
• Zookeeper重新選擇一個新的Master
  1. 無Master過程中，數據讀取仍照常進行；
  2. 無master過程中，region切分、負載均衡等無法進行
• Region Server容錯：

• 定時向Zookeeper匯報心跳，如果一旦時間內未出現心跳Master將該RegionServer上的Region重新分配到其他RegionServer上，失效服務器上“預寫”日誌由主服務器進行分割並派送給新的RegionServer

• Zookeeper容錯：

• Zookeeper是一個可靠地服務，一般配置3或5個Zookeeper實例

• WAL(Write-Ahead-Log)預寫
  日誌

• 是Hbase的RegionServer在處理數據插入和刪除的過程中用來記錄操作內容的一種日誌

• 在每次Put、 Delete等一條記錄時，首先將其數據寫入到RegionServer對應的HLog文
  件的過程

• 客戶端往RegionServer端提交數據的時候，會寫WAL日誌，只有當WAL日誌寫成功以後，客戶端才會被告訴提交數據成功，如果寫WAL失敗會告知客戶端提交失敗

• 數據落地的過程

• 在一個RegionServer上的所有的Region都共享一個HLog，一次數據的提交是先寫WAL，寫入成功後，再寫memstore。當memstore值到達一定閾值，就會形成一個個StoreFile（理解為HFile格式的封裝，本質上還是以HFile的形式存儲的）

Hbase特殊的表

• ROOT- 表和.META.表是兩個比較特殊的表

• .META.記錄了用戶表的Region信息，.META.可以有多個regoin。

• -ROOT-記錄了.META.表的Region信息，-ROOT-只有一個region，Zookeeper中記錄了-ROOT-表的location

• Hbase 0.96之後去掉了-ROOT- 表，因為：

1. 三次請求才能直到用戶Table真正所在的位置也是性能低下的
2. 即使去掉-ROOT- Table，也還可以支持2^17(131072)個Hregion，對於集群來說，存儲空間也足夠

• 所以目前流程為：

1. 從ZooKeeper(/hbase/meta-region-server)中獲取hbase:meta的位置（HRegionServer的位置），緩存該位置信息【沒有圖中綠色的部分】
2. 從HRegionServer中查詢用戶Table對應請求的RowKey所在的HRegionServer，緩存該位置信息
3. 從查詢到HRegionServer中讀取Row。

合並

• region的合並：盡量把小的region合並到一個大的，理想情況下，每個region的請求量是一樣的(不能保證數據量一樣)

• storefile的合並

• 如果Hbase當做MapReduce的輸入源的話，一個map對應一個region

Hbase的Compaction和Split

• 問題：隨著寫入不斷增多，flush次數不斷增多，Hfile文件越來越多,所以Hbase需要對這些文件進行合並

• Compaction會從一個region的一個store中選擇一些hfile文件進行合並。合並說來原理很簡單，先從這些待合並的數據文件中讀出KeyValues，再按照由小到大排列後寫入一個新的文件中。之後，這個新生成的文件就會取代之前待合並的所有文件對外提供服務

• Minor Compaction：是指選取一些小的、相鄰的StoreFile將他們合並成一個更大的StoreFile，在這個過程中不會處理已經Deleted或Expired的Cell。一次Minor Compaction的結果是更少並且更大的StoreFile

• Major Compaction：是指將所有的StoreFile合並成一個StoreFile，這個過程還會清理三類無意義數據：被刪除的數據、 TTL過期數據、版本號超過設定版本號的數據

• Major Compaction時間會持續比較長，整個過程會消耗大量系統資源，對上層業務有比較大的影響

• 因此線上業務都會將關閉自動觸發Major Compaction功能，改為手動在業務低峰期觸發

• Compaction本質：使用短時間的IO消耗以及帶寬消耗換取後續查詢的低延遲

• compact的速度遠遠跟不上HFile生成的速度，這樣就會使HFile的數量會越來越多，導致讀性能急劇下降。為了避免這種情況，在HFile的數量過多的時候會限制寫請求的速度

• Split

• 當一個Region太大時，將其分裂成兩個Region

• Split和Major Compaction可以手動或者自動做

此筆記僅用於作者記錄復習使用，如有錯誤地方歡迎留言指正，作者感激不盡，如有轉載請指明出處

Hbase基礎(一)