目錄

1 Hbase簡介

1.1 初識Hbase

1.2 Hbase的特性

2 HDFS專項模塊

2.1 HDFS的基本架構

2.1.1 HDFS各組件的功能：

2.2 HFDFS多種機制

2.2.1 分塊機制

2.2.2 副本機制

2.2.3 容錯機制

2.2.4 讀寫機制

3 Hbase組件及其功能

3.1 客戶端

3.2 Zookeeper

3.3 HMaster

3.4 RegionServer

4 Hbase資料模型及Hbase Shell

5 Hbase原理實作

5.1 Region定位

5.1.1 Region

5.1.2 Meta表

5.1.3 Region查找

5.2 Region再細分

5.2.1 Hbase寫資料

5.2.2 Hbase讀資料

5.2.3 HFile的合并(Minor|Major)

5.3 WAL機制

5.4 Region拆分

5.5 Region合并

1 Hbase簡介

1.1 初識Hbase

Hbase全拼為Hadoop database即分布式存盤資料庫，是一個可以進行隨機訪問的存盤和檢索資料的平臺，用于存盤結構化和半結構化的資料，如果資料量不是非常龐大的情況下，Hbase甚至可以存盤非結構化的資料，Hbase作為Apache基金會Hadoop專案的一部分，使用Java語言實作，將HDFS作為底層檔案存盤系統，在此基礎上運行MapReduce分布式批量處理資料，為Hadoop提供海量的資料管理服務，

Hbase是典型的NoSQL資料庫，通常被描述為稀疏的、分布式的、持久化的，由行鍵、列鍵和時間戳進行索引的多維有序映射資料庫，主要用來儲存結構化和半結構化的資料，Hbase是Google的Bigtable的開源實作，

1.2 Hbase的特性

🌈容量巨大

🌈列存盤

🌈稀疏性

傳統的關型資料庫中，每一行的資料型別都是事先定義好的，會占用固定的記憶體空間，在此情況下NULL值也會占用一定的存盤空間，而在Hbase中的資料都是以字串形式存盤，資料為空的情況下列并不占用存盤空間，因為會有部分資料有真實值，部分資料為NULL，故稱為稀疏性，

🌈擴展性強

Hbase構建在HDFS之上，理所當然的支持分布式表，也繼承了HDFS的可擴展性，Hbase是橫向擴展的，所謂的橫向擴展是指在擴展時不需要提過服務器本身的性能，只需要添加不同的服務器節點到現有的集群即可，Hbase根據Region的大小進行磁區，分別存在集群中的不同節點，當添加新節點時，集群自動重新調整，在新的節點啟動Hbase服務器，實作動態擴展，Hbase的擴展是熱擴展，即在不停掉現有服務的情況下進行服務節點的增加和洗掉，

🌈高可靠性

Hbase同時繼承了HDFS的高可靠性，HDFS的多副本機制可以讓它在出現故障時自動恢復，同時Hbase內部也提供了預寫日志(Write-Ahead-Log,WAL)和Replication機制，

2 HDFS專項模塊

HDFS即Hadoop Distributed File System(Hadoop分布式檔案系統)，HDFS是參考Google公司的GFS實作的，不管是HDFS還是GFS計算機節點都會很容易出現硬體故障，HDFS的資料分塊儲存在不同節點，當某個節點出現故障時，HDFS相關組件會快速檢測出節點故障并提供容錯機制完成資料的自動恢復，

2.1 HDFS的基本架構

三個組件：NameNode、DataNode、SecondaryNameNode

一個架構：主從架構(Master/Slave模式)

HDFS集群一般由一個NameNode(運行在Master節點)、一個SecondaryNameNode(運行在Master節點)和許多個DataNode(運行在Salve節點)組成，在HDFS中資料是被分塊進行儲存，一個檔案可以被分為許多個塊，每個塊被存盤在不同的DataNode上，

2.1.1 HDFS各組件的功能：

• 🌈NameNode
  • 將檔案的元資料資訊存盤在edits和fsimage檔案中(元資料資訊記錄了檔案系統中的檔案名和目錄名，以及它們之間的層級關系，同時也記錄了每個檔案目錄的所有者以及權限，甚至還記錄了每個檔案是由哪些塊組成)
  • 接收客戶端的請求并提供元資料(當客戶端請求讀取檔案時，會先從NameNode獲取檔案的元資料資訊，然后再往元資料中對應的DataNode讀取資料塊)
  • 通過心跳機制檢測DataNode的狀態，當出現節點故障時，重新分配失敗的任務，
• 🌈SecondaryNameNode
  • 定期合并edits和fsimage檔案

edits檔案(編輯日志)用來記錄檔案的增、刪、改操作資訊，

fsimage檔案(鏡像檔案)用來維護HDFS的檔案和檔案夾的元資料資訊，

每次系統啟動時，NameNode會讀取fsimage檔案的資訊并保存到內從中，在HDFS運行期間，新的操作日志不會立即與fsimage檔案進行合并，也不會存到NameNode記憶體中，而是先寫到edits檔案中，當edits檔案達到一定的閾值或者間隔一定時間(默認為3600s或者達到64MB)后會觸發SecondaryNameNode作業，這個時間點被稱為checkpoint，具體的合并步驟如下：

1. (停用和新記錄)在合并之前SecondaryNameNode通知NameNode停用當前editlog檔案，并將新的操作日志寫入到新的editlog.new檔案，
2. (請求并復制)SecondaryNameNode從NameNode請求并復制fsimage和edits檔案，
3. (合并)SecondaryNameNode把fsimage和edits檔案合并，并重命名為fsimage.ckpt，
4. (兩次替換)NameNode從SecondaryNameNode獲取fsimage.ckpt檔案，并替換掉fsimage檔案，同時用edits.new檔案替換舊的edits檔案，
5. (更新)更新checkpoint的時間，自此，fsimage檔案中保存的是上一個checkpoint的元資料資訊，而edits檔案保存的是從上一個checkpoint開始的操作日志，

• 🌈DataNode
  • 存盤資料塊
  • 為客戶端提供資料塊的讀寫服務
  • 相應NameNode的相關指令(資料塊的增、刪、改等操作)
  • 定時發送心跳資訊給NameNode

2.2 HFDFS多種機制

2.2.1 分塊機制

在HDFS中資料是被分塊進行儲存，一個檔案可以被分為許多個塊，每個塊被存盤在不同的DataNode上，HDFS資料塊大小默認為64MB，而一般磁盤塊的大小為512B，

2.2.2 副本機制

HDFS中資料塊的副本數默認為3個，當然也可以設定更多的副本集，在默認副本集為3的情況下，0.17版本之前，會把第一個副本放在一個機架的一個DataNode上，第二個副本放在這個機架的另一個DataNode上，而第三個副本會放在不同的機架上；0.17版本之后，會把第一個副本放在一個機架的一個DataNode上，第二個副本放在另一個機架的DataNode上，而第三個副本會放在第二個副本的同機架的不同DataNode上，(機架的概念參照上圖2-4)

2.2.3 容錯機制

NameNode出錯：從SecondaryNameNode備份的fsimage檔案進行恢復，

DataNode出錯：當出現節點故障時，重新分配失敗的任務，

資料出錯：資料寫入的同時保存總和校驗碼，讀取資料時進行校驗，

2.2.4 讀寫機制

🌈讀檔案

1. (發送請求)客戶端向NameNode發送讀檔案請求
2. (得到地址)NameNode回傳檔案的元資料(檔案對應的資料塊資訊及各資料塊位置及其副本位置)資訊
3. (讀取資料)客戶端按照元資料資訊與DataNode進行通信，并讀取資料塊，

🌈寫檔案

1. (暫寫資料)先將資料寫入本地的臨時檔案
2. (發送請求)等臨時檔案大小達到系統設定的塊大小時，開始向NameNode發送寫檔案請求
3. (獲取地址)NameNode檢查集群中每個DataNode的狀態資訊，獲取空閑節點并檢查客戶端的權限符合后再創建檔案，然后回傳資料塊及其對應DataNode的地址串列給客戶端，串列中包括副本的存放地址，
4. (寫資料并發送確認資訊)客戶端將臨時檔案的資料塊寫入串列的第一個DataNode，同時第一個DataNode以副本的形式傳送至第二個DataNode，第二個DataNode以副本的形式傳送至第三個DataNode，每一個DataNode在接收到資料后都會向前一個節點發送確認資訊，資料傳輸完成后，第一個DataNode會向客戶端發送確認資訊，
5. (錯誤處理)客戶端收到確認資訊表示資料塊已經永久化的存盤在所有的DataNode中，此時客戶端會向NameNode發送確認資訊，一旦上一步的任何一個DataNode存盤失敗未發送確認資訊，客戶端就會告知NameNode，將資料備份到新的DataNode中，

3 Hbase組件及其功能

3.1 客戶端

客戶端包含訪問Hbase的介面，是整個Hbase系統的入口，使用者通過客戶端操作Hbase，客戶端使用Hbase的RPC機制與HMaster和RegionServer進行通信，

3.2 Zookeeper

Zookeeper是一個高性能、集中化、分布式的應用程式協調服務，主要用來解決分布式應用中用戶遇到的資料管理問題，在Hadoop中Zookeeper主要用于實作高可靠性(High Availability，HA)，包括HDFS的NameNode和YARN的ResourceManager的HA，以HDFS為例，NameNode作為HDFS的主節點，負責管理檔案系統的命名空間以及客戶端對檔案的訪問，同時還需要監控整個HDFS中每個DataNode的狀態，實作負載均衡和容錯，為了實作HA需要由多個NameNode并存，一個處于活躍狀態其他則是備用狀態，當處于活躍狀態的NameNode無法正常作業時，處于備用狀態的節點會通過競爭選舉產生新的活躍節點，Zookeeper在Hbase中的功能如下：

• Master選舉

與HDFS中的競選機制一樣，Hbase中有多個Master并存，但只有一個HMaster處于活躍狀態，當處于活躍狀態的HMaster無法正常作業時，從其余備用Master中通過選舉出一個新的HMaster，保證集群的高可靠性，

• 系統容錯

在Hbase啟動時，每個RegionServer在加入集群時都需要到Zookeeper中進行注冊，創建一個狀態節點，Zookeeper會實時監控每個RegionServer狀態，當某個RegionServer掛掉時,Zookeeper會因為一段時間內沒有接收到其心跳資訊而洗掉該RegionServer對應的節點，并給HMaster發送節點洗掉通知，HMaster得知有RegionServer斷開，會立即開啟RegionServer容錯機制參考博客

• Region元資料管理

在Hbase集群中，Region元資料被存盤在Zookeeper中的Meta表里，每次客戶端發起新的請求時，需要先查詢Meta表中的Region的位置，當Region發生任何變更時，就能通過Zookeeper的Mate表來感知這一變化，保證客戶端能夠獲取到正確的Region元資料資訊，

• Region狀態管理

Hbase中的Region會經常發生變更，其原因可能是系統故障、配置修改、Region的分裂及合并，只要Region發生任何變化，就需要使集群中的所有節點都知曉，然而集群中的Region數量會達到十萬級甚至更多，如果交由Hbase處理則負擔過大，所以只能依賴Zookeeper來完成，

• 提供Mate表存盤位置

Mate表中存盤的資料庫資訊、列族資訊、列族存盤位置資訊都屬于元資料，而Mate表的位置入口由Zookeeper提供，

3.3 HMaster

• 管理用戶對表的增、刪、改、查操作，HMaster提供了對所有元資料增刪改查的介面，便于用戶與Hbase進行互動，
• 管理RegionServer的負載均衡，調整Region的分布，
• Region的分配與移除，
• 處理RegionServer的故障轉移，

3.4 RegionServer

RegionServer主要負責回應用戶的請求，向HDFS讀寫資料，一般在分布式集群中，RegionServer運行在DataNode服務器上，實作資料的本地性，

• 處理分配給它的Region
• 處理客戶DAU你的讀寫請求
• 重繪快取到HDFS
• 處理Region分片
• 執行壓縮

4 Hbase資料模型及Hbase Shell

Hbase資料模型及Hbase Shell_扎哇太棗糕的博客-CSDN博客

5 Hbase原理實作

5.1 Region定位

5.1.1 Region

在Hbase中，表中的行都是按照RowKey的字典順序進行排序，表在行的方向上被分割成多個Region，每一張表一開始就只有一個Region，隨著資料的不斷插入，Hbase會根據一定的規則將表進行水平拆分最終形成多個Region，Region過多一臺機器無法存盤的下時，可分布式存盤到多臺機器上，HMaster將不同的Region分配到不同的RegionServer上，

客戶端在對表彰資料進行增刪改查時需要知道資料存盤在哪個RegionServer上，這個查找Region的程序就叫做Region定位，Region識別符號可以唯一標志一個Region，Region識別符號 = 表名+起始行鍵+時間戳+RegionID，其中RegionID等于(表名+起始行鍵+時間戳)進行MD5加密，其中第一個Region沒有首行，最后一個Region沒有末行，

5.1.2 Meta表

Meta映射表的每個條目包含兩項內容：Region標識、RegionServer標識，該條目表示了Region與RegionServer之間的對應關系，可以讓用戶知道該Region存盤在哪個RegionServer上，總而言之，Meta表記錄了元資料資訊，使Region的定位變得精準且快速，

5.1.3 Region查找

早期的Region查找使用三層架構：首先訪問zookeeper的/hbase/root-region-server節點來得知ROOT表在哪個RegionServer上，然后訪問ROOT表獲取資料所在Meta表以及Meta表所在RegionServer的位置，接著訪問META表找到資料所在的Region去訪問，后來改為二層架構：客戶端先通過查找ZooKeeper的Meta表，獲取到查詢的資料的Region元資料資訊，按照元資料資訊獲取到相應的資料，

參考博客：HBase查詢機制--Region定位_Fys的博客-CSDN博客_查看hbase 表的region

5.2 Region再細分

Hbase的核心模塊是RegionServer，RegionServer又由HLog和Region構成，Region存盤著一系列連續的資料集，Region對應著和多個的Store，每個Store對應著表中的一個列族的存盤，Store又是由一個MemStore和零到多個的StoreFile組成，StoreFile的底層是用HFile實作，也可以說StoreFile就是HFile，

5.2.1 Hbase寫資料

1. (獲取元資料)客戶端訪問Zookeeper，從Meta表中得到資料寫入的Region和RegionServer的相關資訊
2. (兩次寫資訊)客戶端按照Zookeeper回傳的相關資訊，直接訪問RegionServer把資料分別寫入HLog和MemStore，
3. (持久化資料)當MemStore的存盤量達到一定閾值(默認64M)時，會把資料寫入磁盤檔案StoreFile中，并在HLog中寫入一個標記表示MemStore中的快取資料寫入到StoreFile中，如果MemStore中的資料丟失，則可以在HLog中恢復，
4. (StoreFile合并分裂)StoreFile檔案的數量達到一定的數量時，會觸發合并成一個大的StoreFile，當StoreFile的檔案大小超過一定的閾值時，大StoreFile會分裂成兩個StoreFile，同時，當前父Region會分裂成兩個子Region，父Region下線，兩個子Region被Master分配到相應的RegionServer(父Region拆分的原因參考 5.4Region拆分)，

5.2.2 Hbase讀資料

1. (獲取元資料)客戶端訪問Zookeeper，從Meta表中得到讀取資料的Region和RegionServer的相關資訊
2. (發送請求)客戶端向對應的RegionServer發送讀取資料請求
3. (查找資料)RegionServer在就收到請求訊息之后，現在MemStore中查找資料，如果沒有就到StoreFile中讀取，最后將資料回傳給客戶端，

5.2.3 HFile的合并(Minor|Major)

Minor合并(滿足條件的小HFile進行合并)

執行合并時，Hbase將多個小HFile的內容讀出并寫入到一個新的檔案中，然后激活新檔案，舊檔案標記為洗掉，被標記后的舊檔案只有在下一次Major合并時才會被洗掉，在此之前仍會出現在HFile中，HFile的Minor合并是觸發式的，觸發條件很多，比如在將MemStore中的資料重繪到HFile中時會申請對符合條件的HFile進行合并，定期合并等，除此之外，對選擇進行合并的HFile檔案也是有條件的，條件如下：

也就是說，一次Minor合并的HFile檔案的個數在3~10個之間，

Major合并(無差別合并)

Major合并會對Store中的所有HFile檔案進行無差別的合并，甚至有時會將整個表中同一列族的HFile進行合并，這是一個耗時且耗費資源的操作，很影響集群的性能，故一般情況下都只做Minor合并，不做甚至有些集群干脆就禁止Major合并，只有在集群負載較小時才進行手動的Major合并，或者配置Major的合并中期，默認為7天，

5.3 WAL機制

WAL就是(Write Ahead Log)，字面翻譯就是預寫日志檔案機制，如下圖所示，每個RegionServer中的所有Region共用一個HLog檔案，HLog就是上面說到的預寫日志檔案，也就是說，每當客戶端更寫資料必須先寫入到HLog檔案后才能被寫入到MemStore中，

故障轉移：Zookeeper會實時監控每個Regionserver的狀態，當某個RegionServer故障時，RegionServer在Zookeeper上的臨時節點就會過期，Zookeeper會首先通知Master，Master會第一時間處理該RegionServer上的HLog檔案，對其按照Region進行拆分并放到相應Region的目錄下，等到Region被重新分配到可用的RegionServer上時，按照Region目錄下的HLog進行資料恢復，

5.4 Region拆分

一旦Region的負載過大或者超過閾值時（Region中最大的Store的大小大于設定的閾值時就會觸發Region拆分），它就會被拆分成兩個新的Region，這個程序是由RegionServer來完成的，具體流程如下：

1. (下線并阻止請求)下線需要拆分的Region，阻止所有對該Region的客戶端請求，Master檢測到Region的狀態為SPLITING，
2. (建立參考檔案并指向)在父Region的下面建立兩個參考檔案，分別指向父Region的首行與末行，此時并不會開始復制資料，
3. (建立目錄并復制)在HDFS上建立兩個子Region的目錄，分別復制上一步建立的參考檔案，每個子Region分別占用父Region的一半資料，復制完成后洗掉兩個參考檔案，
4. (更新Meta表元資料)完成子Region的創建后，向Meta表發送新產生的兩個Region的元資料資訊，洗掉父Region的元資料資訊，
5. (更新狀態)將Region的拆分資訊更新到HMaster中，并且每個Region進入可用狀態，

5.5 Region合并

1. (發送請求)客戶端發送Region合并請求給Master，
2. (聚堆并發送請求)Master在RegionServer上將Region移到一起，并發起一個Region合并操作的請求，
3. (下線并合并)RegionServer將準備合并的Region下線，然后進行合并，
4. (更新元資料)從Meta表上洗掉被合并的Region的元資料，并寫入新的Region的元資料，
5. (更新狀態及資訊)新的Region設定上線，同時更新Region資訊到Master，

Region合并的必要性：Region過多會導致Meta表過大，Zookeeper管理不過來，從而影響客戶端的請求回應，