你想要的 HBase 原理都在這了

時間 2019-12-23

標籤想要 hbase 原理都在欄目 Hadoop 简体版

原文原文鏈接

目錄html

在前面的文章中，介紹過 HBase 的入門操做知識，但對於正考慮將 HBase 用於生產系統的項目來講仍是遠遠不夠。
通常在對 HBase 作選型以前，還須要學習一些它的架構原理、彈性擴展及可靠性方面的知識。
本文來自筆者此前對 HBase 作的學習歸納，可方便於對 HBase 的技術全景進行快速的掌握。git

1、集羣架構

儘管HBase能夠工做在本地文件系統之上，但在生產環境中，HBase須要依託 HDFS 做爲其底層的數據存儲，而HDFS提供了默認的3副原本實現數據文件的高可靠。
整個HBase 集羣主要由 Zookeeper、Master、RegionServer、HDFS所組成，以下圖：github

集羣角色

Master
HBase Master 用於管理多個 Region Server，包括監測各個 Region Server 的狀態、分配 Region及自動均衡等。具體職責包括：算法

負責管理全部的RegionServer，實現RegionServer的高可用
管理全部的數據分片(Region)到RegionServer的分配，包括自動均衡
執行建表/修改表/刪除表等DDL操做

HBase 容許多個 Master 節點共存，當多個 Master 節點共存時，只有一個 Master 是提供服務的，這種主備角色的"仲裁"由 ZooKeeper 實現。sql

Region Server
Region Server 是真正的數據讀寫服務器，即客戶端會直接鏈接 Region Server 進行操做。
一個 Region Server 會包括了多個 Region，這裏的 Region 則是真正存放 HBase 數據的區域單元，當一個表很大時，會拆分紅不少個 Region 進行存放。
能夠說，Region 是 HBase 分佈式的基本單位。shell

Zookeeper
Zookeeper 對於 HBase的做用是相當重要的。數據庫

Zookeeper 提供了 HBase Master 的高可用實現，並保證同一時刻有且僅有一個主 Master 可用。
Zookeeper 保存了 Region 和 Region Server 的關聯信息(提供尋址入口)，並保存了集羣的元數據(Schema/Table)。
Zookeeper 實時監控Region server的上線和下線信息，並實時通知Master。

就目前來講，Zookeeper 已經成爲了分佈式系統架構中最經常使用的標準框架之一。除了 HBase以外，有許多分佈式大數據相關的開源框架，都依賴於 Zookeeper 實現 HA。apache

HDFS
HDFS 是 Hadoop 的分佈式文件系統，提供了高可靠高擴展的文件存儲能力。其內部也是一個集羣結構，包含 NameNode、DataNode 角色。
其中 NameNode存儲的是 HDFS文件目錄樹的元數據，包含文件與Block的關聯信息，而DataNode 則是HDFS的數據存放節點。緩存

HDFS做爲一個分佈式文件系統，天然須要文件目錄樹的元數據信息，另外，在HDFS中每個文件都是按照Block存儲的，文件與Block的關聯也經過元數據信息來描述。NameNode提供了這些元數據信息的存儲。安全

工做機制

在一個完整的HBase 分佈式集羣中，各個組件的交互工做以下圖所示：

首先 Zookeeper 維護了 Master 與各個 Region Server 之間的關係及狀態。當一個 Client 須要訪問 HBase 集羣時，會先和 Zookeeper 進行通訊，並獲得 Master和 RegionServer的地址信息。
對於建立表/刪除表/修改表來講，客戶端會經過 Master 來進行操做，而正常的表數據讀寫，則是經過找到對應的 Region Server來操做。

Region Server 的做用

每個 Region Server 會管理不少個 Region(區域), 這個就是以前提到的 HBase 數據分佈式及高可靠的一個單元。每一個 Region 只會存儲一個表中的的一段數據，這是按 RowKey 的區間來分隔的。
並且，一個 Region 的存儲空間有一個上限(Threshold)，當存放數據的大小達到該上限時，Region 就會進行分裂併產生多個新的 Region，隨着一個Region Server 上的 Region 愈來愈多，Master 能夠監測到不均衡的狀況，並自動將Region進行從新分配。
所以，數據能夠源源不斷的寫入到 HBase時，經過這種 Region的分裂、自動均衡來支持海量數據的存儲。

對於一個Region來講，其內部是由多個Store構成的，而一個Store 對應於一個ColumnFamily(列族)。
在實現上一個Store對象會包含一個MemStore以及多個StoreFile。當數據寫入 Region時，先寫入MemStore(保持有序)。
當MemStore 寫滿了以後就會 Flush 到StoreFile，這裏的 StoreFile 就對應了一個HDFS中的 HFile文件。
最終 Region會對應到多個持久化的 HFile，當這些 HFile 愈來愈多時，Region Server 會執行合併操做(Compaction)來合併爲一個大的HFile，以此來優化讀取性能，這個機制則是基於LSM的原理實現的。

HLog 和可靠性

HBase 提供了HLog來保證數據寫入的可靠性，HLog 本質上就是一種 WAL(事務機制中常見的預寫日誌)，其一樣是經過HDFS來持久化的(對應於一個Sequence文件)。每一個Region Server 都包含一個HLog，其中記錄了全部發生在Region Server上的數據變動操做。
當數據發生寫入時，會先記錄日誌到 HLog中，而後再寫入 MemStore，最終才持久化到 HFile中。這樣當 Region Server 宕機時，儘管 MemStore中的數據會丟失，但還能夠經過 HLog來恢復以前的數據，從而保證了高可靠。
那麼，HFile 是否可靠呢？這點則是由 HDFS 來保證的，一個HFile 默認會有3個副本。

除此以外，HLog 也是HBase 實現集羣同步複製的關鍵手段。

2、存儲機制

接下來，咱們看看HBase中的數據是怎樣被存儲及管理的。

A. 存儲模型

首先須要澄清的一點是，Region 和 Column Family (簡稱CF) 的區別。

Region 是HBase 分佈式存儲的基本單位，其本質上是一種水平切分單位，能夠理解爲數據的分片；而Column Family(列族)則是垂直切分的單位，可理解爲一種列的分組。
這二者的區別能夠參考下圖：

不管是Region、仍是CF，都是邏輯上的一個概念，對於物理上的實現則以下圖所示：

存儲模塊說明

一個 Region 包含多個Store,一個store對應一個CF
Store包括位於內存中的 Memstore 和多個持久化的 Storefile;
寫操做先寫入 Memstore，當 Memstore 中的數據大小達到某個閾值後會Flush到一個單獨的 Storefile
當 Storefile 文件的數量增加到必定閾值後，系統會進行合併，造成更大的 Storefile(Compaction)
當一個 Region 全部 Storefile 的大小總和超過必定閾值後，會把當前的 Region 分割爲兩個(分裂)
Master 自動檢測RegionServer 上Region的分配狀況，自動進行均衡遷移
客戶端檢索數據，優先從 Memstore查詢，而後再查詢 Storefile

HFile 結構

HFile 是HDFS 的存儲單元，其結構以下圖：

HFile 由不少個數據塊（Block）組成，而且有一個固定的結尾塊。其中的數據塊是由一個 Header 和多個 Key-Value 的鍵值對組成。
在結尾的數據塊中包含了數據相關的索引信息，系統也是經過結尾的索引信息找到 HFile 中的數據。

HFile 中的數據塊大小默認爲 64KB。若是訪問 HBase 數據庫的場景多爲有序的訪問，那麼建議將該值設置的大一些。
若是場景多爲隨機訪問，那麼建議將該值設置的小一些。通常狀況下，經過調整該值能夠提升 HBase 的性能

B. LSM 與 Compaction

HBase 在存儲上是基於LSM樹實現的，與傳統的B/B+樹原理不一樣的是，LSM樹很是適用於寫入要求很是高的場景。

LSM的原理

將一個大的B(B+)樹拆分紅N棵小樹，數據首先寫入內存中(有序)，隨着數據寫入愈來愈多，內存中的數據會被flush到磁盤中造成一個文件；
在讀取數據時，則須要合併磁盤中歷史數據和內存中最近修改的操做後返回。因爲數據是順序寫入的，所以LSM的寫入性能很是高，但讀取時可能會訪問較多的磁盤文件，性能較差。
爲了緩解讀性能低下的問題，LSM樹會定時將磁盤中的多個文件(小樹)進行合併，以優化讀性能。

在HBase的實現中，內存中的數據則是對應於MemStore，而磁盤中的數據則對應於 StoreFile (HFile實現)。當MemStore寫滿後會Flush到一個HFile 中。
隨着HFile 文件的不斷增多，Region 的讀性能就會受到影響(IOPS 增長)。所以 HBase 的 Region Server 會按期進行Compaction操做，將多個HFile 合併爲一個大的有序的 HFile。
HBase 中運行的 Compaction 動做有兩種：

Minor Compaction，列族中小範圍的HFile文件合併，通常較快，佔用IO低
Major Compaction，列族中全部的HFile文件合併，同時清理TTL過時以及延遲刪除的數據，該過程會產生大量IO操做，性能影響較大。

具體的過程以下圖所示：

圖片出處：http://www.nosqlnotes.com/

Flush 性能影響

若是 Memstore 很小，意味着Flush 的次數會不少，一旦Compaction的速度跟不上就會產生大量的HFile 文件，這會致使讀性能惡化，爲了減緩這個問題，HBase 使用了 In Memory Flush And Compact 的方法，即數據在 MemStore 中先經分段(Segement)、Flush、Compaction 過程，到達必定大小後再 Flush 到 HFile。在這裏，MemStore 使用了 ConcurrentSkipListMap(併發跳躍表) 來保證必定的讀寫併發能力。ConcurrentSkipListMap 在容量超過必定大小後性能降低明顯，所以 MemStore 也不能設置得太大，當前的默認值在128MB。

觸發Flush 行爲的條件包括：

Memstore級別：Region中任意一個MemStore達到了 hbase.hregion.memstore.flush.size 控制的上限（默認128MB），會觸發Memstore的flush。
Region級別：Region中Memstore大小之和達到了 hbase.hregion.memstore.block.multiplier hbase.hregion.memstore.flush.size 控制的上限（默認 2 128M = 256M），會觸發Memstore的flush。
RegionServer級別：Region Server中全部Region的Memstore大小總和達到了 hbase.regionserver.global.memstore.upperLimit ＊ hbase_heapsize 控制的上限（默認0.4，即RegionServer 40%的JVM內存），將會按Memstore由大到小進行flush，直至整體Memstore內存使用量低於 hbase.regionserver.global.memstore.lowerLimit ＊ hbase_heapsize 控制的下限（默認0.38，即RegionServer 38%的JVM內存）。
RegionServer中HLog數量達到上限：將會選取最先的 HLog對應的一個或多個Region進行flush（經過參數hbase.regionserver.maxlogs配置）。
HBase按期flush：確保Memstore不會長時間沒有持久化，默認週期爲1小時。爲避免全部的MemStore在同一時間都進行flush致使的問題，按期的flush操做有20000左右的隨機延時。
手動執行flush：用戶能夠經過shell命令 flush ‘tablename’或者flush ‘region name’分別對一個表或者一個Region進行flush。

除此之外，爲了保證Compaction的進度與Flush對齊，HBase會在HFile數量到達必定閥值後阻塞Flush操做，以下面的參數：

hbase.hstore.blockingStoreFiles，觸發Flush阻塞等待的StoreFiles數量上限，2.x版本默認爲16
hbase.hstore.blockingWaitTime，阻塞Flush的時間，2.x版本默認爲90s

Compaction 策略

Compaction 的目的是優化讀性能，但會致使 IO 放大，這是由於在合併過程當中，文件須要不斷的被讀入、寫出，加上 HDFS 的多副本複製，則會再一次增長屢次的IO操做。
此外，Compaction 利用了緩衝區合併來避免對已有的 HFile 形成阻塞，只有在最後合併 HFile 元數據時會有一點點的影響，這幾乎能夠忽略不計。
但 Compaction 完成後會淘汰Block Cache，這樣便會形成短時間的讀取時延增大。

在性能壓測時一般能夠看到由 Compaction 致使的一些"毛刺"現象，但這是不可避免的，咱們只能是根據業務場景來選擇一些合理的 Compaction 策略。

通常，Minor Compaction 會配置爲按需觸發，其合併的範圍小，時間短，對業務性能的影響相對可控。
但 Major Compaction 則建議是在業務閒時手動觸發，以免業務形成嚴重的卡頓。

關於如何選擇合併文件的範圍，HBase 提供瞭如下幾種策略：

Stripe Compaction
將一個Region劃分爲多個子區域(Stripes)，Compaction嚴格控制在單個Stripe範圍內發生，這樣能夠有效下降Compaction對IO資源的佔用。
Stripe 範圍是根據RowKey來設定的，所以這適用於RowKey單調遞增寫入的場景
Date Tiered Compaction
與Stripe Compaction 相似，但倒是基於時間戳來決定子區域的範圍，適合時序數據的場景(僅按時間範圍檢索)
MOB Compaction
與 MOB 特性綁定的 Compaction，MOB 用於存儲文件數據，其將元數據與文件數據分離存儲，其中文件數據不參與Compaction，這樣就大大減小了Compaction帶來的IO放大的影響。
RatioBased Compaction
基於比例計算的 Compaction 策略，在0.96以前默認的策略，該策略會根據下列參數來選擇 Compaction 的文件。

hbase.hstore.compaction.ratio：最小待合併文件數
hbase.hstore.compaction.min：最小待合併文件數
hbase.hstore.compaction.max：最大待合併文件數
hbase.hstore.compaction.min.size最小合併文件總大小

通常因爲舊文件都是通過Compaction的會比較大，所以一般會基於新文件來作合併。
關於該策略的詳細討論可參考這裏

Exploring Compaction
RatioBased Compaction 演進後的默認版本，基本算法相似，但Exploring會根據性價比來進一步篩選，此時考慮的因素爲：

文件數量較多(讀性能增益)，整體大小偏小(下降IO放大)

C. Region 分裂

假設某個Region增加到了極限，將會切分爲兩個子Region(原來的Region稱爲父Region)該過程的步驟以下：

RegionServer 初始化兩個子Region信息，寫入一個ZK節點數據：/hbase/region-in-transition/region-name=SPLITING
Master 經過Watch機制獲知該region狀態改變，此時可經過Master的UI界面觀察到；
RegionServer 建立.split臨時目錄，用於保存split後的子Region信息；
RegionServer 關閉父Region並執行Flush操做，此後在短暫的時間內對於父Region的讀寫操做都會失敗；
RegionServer 在.split文件夾下新建兩個子Region的目錄，同時分別生成拆分後的reference文件(僅僅是引用信息);
RegionServer 將.split文件夾下的子Region的目錄拷貝到HBase根目錄下，造成兩個新的Region；
RegionServer 修改 hbase.meta 表(鏈接該元數據表對應的RegionServer)，將父Region 標記爲Split完成，Offline=true，即表示分裂完成後下線；
RegionServer 打開兩個子Region，表示可接收讀寫操做；
RegionServer 修改 hbase.meta 表，將子Region上線的信息寫入；
RegionServer 修改ZK節點數據：/hbase/region-in-transition/region-name=SPLIT，此後Master獲知分裂完成。若是有正在運行的均衡任務，則會考慮進一步處理；

能夠發現，整個分裂過程僅僅是建立了一些數據文件的引用及元數據更新操做，對於業務的影響是很是微小的。
那麼，在分裂後的一段時間內，引用數據文件還會持續存在，一直到當子Region發生Compaction操做時，纔會將父Region的HFile數據拷貝到子Region目錄。

關於 Region切分的細節分析進一步參考

http://hbasefly.com/2017/08/27/hbase-split/?dspinw=x0dnj2&uypslg=eyr0j3

D. 自動均衡

HBase 的 Region 分配和自動均衡是由 Master 節點控制的，在初始化表時會先分配一個Region，而後指定給某個Region Server。若是使用預分區，那麼Master 會按照輪詢的方式平均分配到每一個 Region Server。
此後，隨着Region不斷的增大和裂變，Region Server 上的 Region 數量開始變得不均衡。
若是開啓了自動均衡開關，Master 會經過定時器來檢查集羣中的Regions在各個RegionServer之間的負載是不是均衡。一旦檢測到不均衡的狀況，就會生成相應的Region遷移計劃。

關於均衡的方式，HBase 提供如下兩種策略：

DefaultLoadBalancer 默認的策略，根據 Region 個數來進行均衡
StochasticLoadBalancer 根據讀寫壓力評估來進行均衡

因爲HBase的的數據(包括HLog、StoreFile等)都是寫入到HDFS文件系統中的，所以 HBase 的 Region 遷移是很是輕量級的。
在作Region遷移時，Region所對應的HDFS文件是不變的，此時只須要將 Region 的元數據從新分配到目標 Region Server 就能夠了。
遷移過程的步驟包含：

1.建立Region 遷移計劃，指定 RegionID、源 Region Server 和目標 Region Server；
2.源 Region Server 解綁，此時會關閉 Region
3.目標 Region Server 綁定，從新打開 Region

3、訪問機制

HBase 支持多種讀寫客戶端訪問方式，具體包括：

基於Java Client，通常是經過 RPC 調用 HBase。
基於RestFul API，須要啓用 Rest Server 代理組件，該組件經過 Java Client 實現。
基於Thrift API，須要啓用 Thrift Server 代理組件，該組件經過 Java Client 實現。
基於 MapReduce 的批處理 API
基於HBase Shell，其內部也是經過 Java Client 實現的。

不管使用何種調用方式，始終仍是離不開最基礎的 RPC 調用流程。
該流程的交互邏輯以下圖所示：

鏈接 ZooKeeper
在進行數據操做以前，客戶端首先須要接入ZooKeeper，並初始化一個ZooKeeper Session。
該Session由ZooKeeper Client與ZooKeeper Server端之間建立，並經過心跳機制保持長鏈接
獲取meta Region路由信息
HBase 將Region分佈的元數據存放在hbase.meta這個表中，該表記錄了每個用戶表Region的路由以及狀態信息，它的 RowKey 包含以下的信息：

表名 Table Name
Region StartKey
Region ID
客戶端經過Zookeeper 先找到 meta Region 所在的 Region Server，而後得到 meta Region信息。
以後根據操做的 RowKey 就能夠定位到對應的Region ID，最後再經過 Zookeeper 的映射表就能夠獲得Region 所在的 Region Server了。
須要注意的是，客戶端通常會對 meta Region 信息進行緩存，避免每次都要耗費時間讀取。

讀寫 Region Server
在獲得真實數據所在的 Region Server 以後，客戶端便經過RPC接口向目標 Region Server 發起訪問。
對於一些批量請求，客戶端會先經過Region 進行分組，再併發的向多個 Region Server 發出請求。

對於使用 Rest Server 或是 Thrift Server 等中間組件的狀況，調用流程以下圖：

4、鑑權

HBase 的安全同時依賴於 Zookeeper、HDFS。

ACL權限

HBase 支持RWXCA權限模型設置：

讀取（R） - 能夠讀取給定範圍的數據。
寫入（W） - 能夠在給定範圍寫入數據。
執行（X） - 能夠在給定範圍內執行協處理器端點。
建立（C） - 能夠在給定範圍內建立表或刪除表（甚至不建立它們）。
管理員（A） - 能夠執行羣集操做，例如在給定的範圍內平衡羣集或分配區域。

須要以最小權限原則爲數據庫表配置對應的用戶權限

一樣，爲了保證總體的安全性，須要對ZooKeeper、HDFS都設定合理的ACL控制，包括文件系統。

身份認證和受權

HBase 集羣中可以使用KerberOS來實現節點之間的身份鑑權，包括：

節點接入 Zookeeper
節點鏈接 Master、RegionServer
節點接入 HDFS
外加的 Rest Server、Thrift Server

Kerberos 是一個常見的身份認證及鑑權協議系統，使用 Kerberos 的系統在設計上採用C/S結構及AES對稱加密技術，而且可以進行雙方認證。
支持防止竊聽、防止replay攻擊、保護數據完整性等特性。 Kerberos 認證過程須要依賴於單獨的 Kerberos Server(KDC)，一個認證過程以下圖：

Kerberos Authentication: 客戶端請求認證服務器(AS)，得到Ticket Granting Ticket (TGT)
Kerberos Authorization: 客戶端經過TGT票據請求TGS(Ticket受權服務)，經過後會得到一個受權的Service Ticket
Service Request: 客戶端使用Service Ticket訪問目標服務，目標服務會對Service Ticket進行本地校驗，若是經過則表示認證成功。

關於KerberOS的詳細原理，能夠參考NoSQL漫談-圖解 KerberOS這篇文章

對於HBase集羣來講，各個節點使用KerberOS認證時，須要先配置keytab文件，該文件中就記錄了實體ID(pricipal)、以及密鑰的信息。
而這些實體ID及密鑰都是由KerberOS 服務生成並管理的。

傳輸層安全

對客戶端RPC 設置hbase.rpc.protection=privacy能夠開啓RPC加密功能，這對性能存在必定損失(約10%)
還可使用TLS傳輸協議進一步提高安全性。

5、高可靠

1.集羣高可靠

Zookeeper 高可靠

Zookeeper 自己是集羣多節點的架構，其內部使用 Paxos 算法來實現選舉和數據的強一致性。
在部署上一般能夠選擇3節點的架構來保證可靠性。

Master 高可靠

HBase 能夠開啓 Backup Master 來實現 Master 節點高可用，同一時間內只有主 Master 能夠工做，Master 宕機後由備Master 自動接管
Master 的 HA 機制是藉助 Zookeeper 完成的

RegionServer 高可靠

Region Server 一般會部署爲多個節點，每一個節點分別接管不一樣的 Region
而 Master 會對 Region Server 的狀態進行檢測，一旦發現 Region Server 宕機，則會將該 Server 上的 Region 列表從新指派給一個新的 Region Server。
此外，Master還會將已宕機的Region Server的HLog 作必定拆分，並分發到新的 Region Server 上作數據恢復。

該過程不涉及數據遷移，只是元數據的變動，操做數據量少並不會對業務形成很大的影響。

數據高可靠

Region Server 自己提供了 HLog(WAL) 來提供斷電保護，當Server 異常宕機時，MemStore內丟失的數據能夠經過 HLog 來回放恢復。

HDFS 高可靠

HDFS 自己提供了一系列的可靠性機制，包括：

NameNode能夠部署多個
DataNode能夠部署多個
HFile 存在多副本(默認3個)，保證了數據文件可靠性

2. 隔離性

在部署上，一般依據一些原則策略來保證可靠性：

控制節點與數據節點分離部署
主備Master、Region節點分離部署
NameNode之間、DataNode之間分離部署
數據節點磁盤物理隔離

3. 容災

儘管HDFS提供了三副本的機制，但對於關鍵業務來講，每每須要支持跨機房的容災能力。

HBase 支持 Replication 機制，該機制設計的主導思想是基於操做日誌 (put/get/delete) 作數據同步的功能，這相似於MySQL的BinLog，或者是MongoDB的OpLog。
Replication的關鍵就在於前面所提到過的 HLog，這個日誌除了用做數據斷電保護以外，還被用來實現集羣複製的功能。

以下圖：

客戶端的 put/delete 操做會先被 RegionServer 寫入本地的 HLog ，以後由一個獨立的線程將 HLog 內容以緩衝寫的形式推送到 Slave 集羣中的某個 Region Server 上。
整個複製的HLog信息、包括複製偏移量都會保存在 Zookeeper上，同時複製動做是異步的，即不會阻塞當前的客戶端讀寫。