HBase簡介

HBase是一個分布式的、面向列的開源數(shù)據(jù)庫存儲系統(tǒng)，是對Google論文BigTable的實現(xiàn)，具有高可靠性、高性能和可伸縮性，它可以處理分布在數(shù)千臺通用服務器上的PB級的海量數(shù)據(jù)。BigTable的底層是通過GFS(Google文件系統(tǒng))來存儲數(shù)據(jù)，而HBase對應的則是通過HDFS(Hadoop分布式文件系統(tǒng))來存儲數(shù)據(jù)的。

HBase不同于一般的關系型數(shù)據(jù)庫，它是一個適合于非結(jié)構(gòu)化數(shù)據(jù)存儲的數(shù)據(jù)庫。HBase不限制存儲的數(shù)據(jù)的種類，允許動態(tài)的、靈活的數(shù)據(jù)模型。HBase可以在一個服務器集群上運行，并且能夠根據(jù)業(yè)務進行橫向擴展。

HBase特點

海量存儲：HBase適合存儲PB級別的海量數(shù)據(jù)，在PB級別的數(shù)據(jù)以及采用廉價PC存儲的情況下，能在幾十到百毫秒內(nèi)返回數(shù)據(jù)。這與HBase的記憶擴展性息息相關。正是因為HBase的良好擴展性，才為海量數(shù)據(jù)的存儲提供了便利。

列式存儲：列式存儲，HBase是根據(jù)列族來存儲數(shù)據(jù)的。列族下面可以有非常多的列，列族在創(chuàng)建表的時候就必須指定，而不用指定列。

極易擴展：HBase的擴展性主要體現(xiàn)在兩個方面，一個是基于上層處理能力(RegionServer)的擴展，一個是基于存儲能力(HDFS)的擴展。

高并發(fā)：目前大部分使用HBase的架構(gòu)，都是采用廉價PC，因此單個IO的延遲其實并不小，一般在幾十到上百ms之間。這里說的高并發(fā)，主要是在并發(fā)的情況下，HBase的單個IO延遲下降并不多。

稀疏：稀疏主要是針對HBase列的靈活性，在列族中，可以指定任意多的列，在列數(shù)據(jù)為空的情況下，是不會占用存儲空間。

HBase與關系型數(shù)據(jù)庫對比

HBase數(shù)據(jù)模型

• Namespace(表命名空間)：表命名空間不是強制的，如果想把多個表分到一個組去統(tǒng)一管理的時候才會用到表命名空間。
• Table(表)：一個表由一個或者多個列族組成。
• Row(行)：一個行包含了多個列，這些列通過列族來分類。行中的數(shù)據(jù)所屬列族只能從該表所定義的列族中選取，不能定義這個表中不存在的列族。
• Column Family(列族)：列族是多個列的集合。
• Column Qualifier(列)：多個列組成一個行。列族和列用：Column Family:Column Qualifier表示。列是可以隨意定義的，一個行中的列不限名字，不限數(shù)量，只限定列族。
• Cell(單元格)：一個列中可以存儲多個版本的數(shù)據(jù)，每個版本就稱為一個Cell。也就是說在HBase中一個列可以保存多個版本的數(shù)據(jù)。
• Timestamp(時間戳/版本號)：用來標定同一個列中多個Cell的版本號。當在插入數(shù)據(jù)的時候，如果不指定版本號，系統(tǒng)會自動采用系統(tǒng)的當前時間戳來作為版本號，也可以手動指定一個數(shù)字作為版本號。
• Rowkey(行鍵)：用來標識表中唯一的一行數(shù)據(jù)，以字節(jié)數(shù)組形式存儲，類似關系型數(shù)據(jù)庫中表的主鍵。rowkey在HBase中時嚴格按照字典序排序的。

物理視圖

在物理存儲上，數(shù)據(jù)是以Key-Vaule對形式存儲，每個Key-Value只存儲一個Cell里面的數(shù)據(jù)，不同的列族存儲在不同的文件中，每個邏輯單元格(Cell)會對應一行數(shù)據(jù)，有Timestamp標記版本，每次插入、刪除都會生成一行數(shù)據(jù)(append-only，寫效率高)。

HBase體系架構(gòu)

HBase的服務器體系結(jié)構(gòu)遵循簡單的主從服務器架構(gòu)，一般一個HBase集群由一個Master服務(高可用的話，至少兩個)和1個或多個RegionServer服務組成。Master服務負責維護表結(jié)構(gòu)信息，實際的數(shù)據(jù)是保存在RegionServer上，最終RegionServer保存的表數(shù)據(jù)會直接存儲在HDFS上。HBase的體系架構(gòu)圖如下圖所示：

Master HBase的管理節(jié)點，在一個集群中Master一般是主備的，主備的選擇是由Zookeeper實現(xiàn)的。

HBase Master主要職責：

• 為RegionServer分配Region;
• 負責RegionServer的負載均衡;
• 發(fā)現(xiàn)失效的RegionServer并重新分配其上的Region;
• 處理Schema更新請求(表的創(chuàng)建、刪除、修改、列族的增加等)。

RegionServer

RegionServer主要負責服務和管理Region。在分布式集群中，建議RegionServer和DataNode按照1:1比例部署，這樣RegionServer中的數(shù)據(jù)文件可以存儲一個副本于本機的DataNode節(jié)點中，從而在讀取數(shù)據(jù)時可以利用HDFS的"短路徑讀取(Short Circuit)"來繞過網(wǎng)絡請求，降低讀延時。

RegionServer內(nèi)部管理一個或多個Region。Region許多Store組成。每個Store對用Table中的一個列族存儲，即一個Store管理一個Region上的一個列族。每個Store包含一個MemStore和0到多個StoreFile。

RegionServer的主要職責：

• RegionServe維護Master分配給它的Region，處理Client對這些Region的IO請求;
• RegionServer還負責Region的Split、Compaction。

Zookeeper

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

• 為HBase提供Failover機制，選舉master，避免master單點故障問題;
• 存儲所有Region的尋址入口，保存hbase:meta表信息;
• 實時監(jiān)控RegionServer的狀態(tài)，將RegionServer的上線和下線信息實時通知給master;
• 存儲HBase的Schema，包括有哪些Table，每個Table有哪些Column Family。

HDFS

HDFS為HBase提供最終的底層數(shù)據(jù)存儲服務，同時為HBase提供高可用(HLog)的支持。HBase底層存儲并非必須是HDFS文件系統(tǒng)，但是HDFS是最佳選擇，也是目前應用最廣泛的選擇。HDFS具體功能如下：

• 提供元數(shù)據(jù)和表數(shù)據(jù)的底層分布式存儲服務;
• 數(shù)據(jù)多副本，保證了高可靠和高可用性

Client

Client使用HBase的RPC機制與HMaster、RegionServer進行通信，Client與Master進行管理類通信，與RegionServer進行數(shù)據(jù)操作類通信。Client包含了訪問HBase的接口，另外Client還維護了對應的cache來加速HBase的訪問，比如.META.元數(shù)據(jù)信息。

RegionServer內(nèi)部結(jié)構(gòu)

1. WAL：預寫日志(Write Ahead Log)。當操作到達Region的時候，HBase先把數(shù)據(jù)寫到WAL中，再把數(shù)據(jù)寫到MemStore中，等數(shù)據(jù)達到閾值時才會被刷寫(flush)到最終存儲的HFile中。WAL是一個保險機制，這樣在Region的機器宕機時，由于WAL的數(shù)據(jù)是存儲在HDFS中的，可以從WAL中恢復數(shù)據(jù)，所以數(shù)據(jù)并不會丟失。
2. BlockCache：讀緩存，用于在內(nèi)存中緩存經(jīng)常被讀的數(shù)據(jù)。Least Recently Used (LRU) 數(shù)據(jù)在存滿時會被失效。
3. Region：Region相當于一個數(shù)據(jù)的分片。每一個Region都有起始rowkey和結(jié)束rowkey，這表示了Region的存儲的row的范圍。一個RegionServer包含多個Region，一個表的一段鍵值在一個RegionServer上會產(chǎn)生一個Region。在一個RegionServer中有一個或多個Region。
4. Store：一個Region包含多個Store，一個列族分為一個Store，如果一個表只有一個列族，那么這個表在這臺機器上的每一個Region里面都只有一個Store。Store是HBase的存儲核心，一個Store里面有一個MemStore和一個或多個HFile。
5. MemStore：有序的內(nèi)存緩沖區(qū)，用于緩存還未被持久化到磁盤的數(shù)據(jù)，在持久化之前會先將數(shù)據(jù)排序，每個Region的每個列族(Store)都有一個 MemStore。
6. HFile：真正存在硬盤上的，對數(shù)據(jù)按照Rowkey排好序的鍵值對文件。每次MemStore的flush會產(chǎn)生新的HFile文件。

用戶寫入的數(shù)據(jù)先寫入WAL，然后寫入MemStore，當MemStore滿了以后會Flush成一個StoreFile(存儲為HFile)，當StoreFile數(shù)量到達一定閾值，會觸發(fā)Compact合并，將多個StoreFile合并成一個StoreFile。StoreFiles合并后會逐漸形成越來越大的StoreFile，當Region內(nèi)的所有的StoreFiles的總的大小超過閾值(hbase.hregion.max.filesize)會觸發(fā)Split操作。會把當前Region Split成兩個Region，父Region下線，新Split的兩個子Region被Master分配到合適的RegionServer上，使得原先一個Region的壓力分流到兩個Region上。

Region尋址方式

在進行數(shù)據(jù)操作的時候，首先要定位需要對哪個Region進行操作，或者從哪個Region上讀取數(shù)據(jù)，因此HBase數(shù)據(jù)讀取的第一步是Region尋址。

Region尋址步驟：

• 首先Client請求Zookeeper，獲取hbase:meta表所在的RegionServer的地址(/hbase/meta-region-server)。
• Client連接hbase:meta表所在的RegionServer，獲取需要訪問的數(shù)據(jù)所在的RegionServer地址。Client會將hbase:meta表的相關信息緩存起來，以便下一次能夠快速訪問。hbase:meta表存儲了所有Region的行鍵范圍信息，通過這個表可以查詢出你要操作的Rowkey屬于哪個Region的范圍里面，以及這個Region是屬于哪個RegionServer。
• Client請求數(shù)據(jù)所在的RegionServer，獲取所需要的數(shù)據(jù)

HBase讀寫流程

HBase寫流程

• Client通過Region尋址定位到需要訪問的RegionServer;
• 將更新寫入WAL HLog，然后將更新寫入MemStore，兩者寫入完成即返回ACK到Client;
• 判斷MemStore的大小是否達到閾值，是否需要flush為StoreFile。

細節(jié)：

HBase使用MemStore和StoreFile存儲對象表的更新，數(shù)據(jù)在更新的時候首先寫入HLog和MemStore。MemStore中的數(shù)據(jù)時排序的，當MemStore累積到一定閾值時，就會創(chuàng)建一個新的MemStore并將老的MemStore添加到flush隊列，由單獨的線程flush到磁盤上，成為一個StoreFile。同時，系統(tǒng)會在Zookeeper中記錄一個checkpoint，表示這個時刻之前的更新已經(jīng)持久化了，當系統(tǒng)出現(xiàn)意外時，可能導致MemStore中的數(shù)據(jù)丟失，此時使用HLog來恢復chckpoint之后的數(shù)據(jù)。

HBase讀流程

• Client通過Region尋址定位到需要訪問的RegionServer
• 先從BlockCache中查找數(shù)據(jù)，找不到再去MemStore和StoreFile中查詢數(shù)據(jù)

在對HBase進行寫操作的時候，進行Put和Update操作的時候，其實是新增了一條數(shù)據(jù)，即使是在進行Delete操作的時候，也是新增一條數(shù)據(jù)，只是這條數(shù)據(jù)沒有value，類型為DELETE，這條數(shù)據(jù)叫做墓碑標記(Tobstone)。數(shù)據(jù)的真正刪除是在compact操作時進行的。

WAL機制

WAL(Write-Ahead Log，預寫日志)主要用來來解決宕機之后的操作恢復問題的。數(shù)據(jù)到達Region的時候會先寫入WAL，然后再被寫入MemStore。就算Region的機器宕掉了，由于WAL的數(shù)據(jù)時存儲在HDFS中的，所以數(shù)據(jù)并不會丟失，還可以從WAL中恢復。

HLog的生命周期

產(chǎn)生

所有涉及到數(shù)據(jù)的變更都會先寫到HLog中，除非是關閉了HLog。

滾動

HLog的大小可以通過參數(shù)hbase.regionserver.logroll.period來控制，默認是1小時，時間達到該參數(shù)設置的時間，HBase會創(chuàng)建一個新的HLog文件。這就實現(xiàn)了HLog滾動的目的。HBase通過hbase.regionserver.maxlogs參數(shù)控制HLog的個數(shù)。滾動的目的是為了避免單個HLog文件過大的情況，方便后續(xù)的過期和刪除。

過期

HLog的過期依賴于sequenceid的判斷。HBase會將HLog的sequenceid和HFile最大的sequenceid(刷新到的最新位置)進行比較，如果該HLog文件中的sequenceid比刷新的最新位置的sequenceid都要小，那么這個HLog就過期了，對應HLog會被移動到/hbase/oldWALs目錄。

因為HBase有主從同步的功能，這個是依賴于HLog來同步HBase的變更，所以HLog雖然過期，也不會立即刪除，而是移動到別的目錄中。再增加對應的檢查和保留時間機制。

刪除

如果HBase開啟了replication，當replication執(zhí)行完一個HLog的時候，會刪除Zookeeper上的對應HLog節(jié)點，在HLog被移動到/hbase/oldWALs目錄后，HBase每隔hbase.master.cleaner.interval(默認60秒)時間會去檢查/hbase/oldWALs目錄下的所有HLog，確認對應的Zookeeper的HLog節(jié)點是否被刪除，如果Zookeeper上不存在對應的HLog節(jié)點，那么久直接刪除對應的HLog。

hbase.master.logcleaner.ttl(默認10分鐘)這個參數(shù)用來控制HLog在/hbase/oldWALs目錄保留的最長時間。

MemStore刷盤

為了提高HBase的寫入性能，當寫請求寫入MemStore后，不會立即刷盤，而是會等到一定的時候再進行刷盤操作。

發(fā)生MemStore刷盤場景：

1. 全局內(nèi)存控制

當整個RegionServer中所有MemStore占用的內(nèi)存達到閾值的時候，會觸發(fā)刷盤的操作。

2. MemStore達到上限

當MemStore占用內(nèi)存的大小達到hbase.hregion.memstore.flush.size的值的時候會觸發(fā)刷盤，默認128M。

3. RegionServer的HLog數(shù)量達到上限

如果HLog太多的話，會導致故障恢復的時間過長，因此HBase會對HLog的最大個數(shù)做限制。當達到HLog的最大個數(shù)的時候，會強制刷盤(hbase.regionserver.max.logs，默認32個)。

4. MemStore達到刷寫時間間隔

當MemStore達到時間間隔的閾值，會觸發(fā)刷寫操作，hbase.regionserver.optionalcacheflushinterval，默認3600000，即1小時，如果設置為0，則意味著關閉定時自動刷寫。

5. 手工觸發(fā)

可以通過hbase shell或者java api手工觸發(fā)flush的操作

6. 關閉RegionServer觸發(fā)

當正常關閉RegionServer會觸發(fā)刷盤的操作，全部數(shù)據(jù)刷盤后就不需要再使用HLog恢復數(shù)據(jù)

7. Region使用HLog恢復完數(shù)據(jù)后觸發(fā)

當RegionServer出現(xiàn)故障的時候，其上面的Region會遷移到其他正常的RegionServer上，在恢復完Region的數(shù)據(jù)后，會觸發(fā)刷盤，當刷盤完成后才會提供給業(yè)務訪問。

Region拆分

隨著業(yè)務的發(fā)展，在表中的數(shù)據(jù)會越來越多，Region會越來越大，這樣會嚴重影響數(shù)據(jù)讀取效率。所以當一個Region變的過大后，會觸發(fā)Split操作，將一個Region分裂成兩個子Region。Region的拆分分為自動拆分和手動拆分兩種。

Region拆分流程

1. RegionServer自身決定region拆分，并準備發(fā)起拆分。作為第一步，它將在zookeeper的分區(qū)/hbase/region-in-transition/region-name下中創(chuàng)建一個znode。
2. 因為Master是父region-in-transition的znode節(jié)點的觀察者，所以它知曉這個znode的建立。
3. RegionServer在HDFS的父region目錄下創(chuàng)建一個名為“.splits”的子目錄。
4. RegionServer關閉父region，強制cache刷盤并在本地數(shù)據(jù)結(jié)構(gòu)中將這個region標記為offline。此時，父region的client請求將拋出NotServingRegionException，client將重試。
5. RegionServer為子region A和B分別在.splits目錄下的region目錄，并創(chuàng)建必要的數(shù)據(jù)結(jié)構(gòu)。然后拆分存儲文件，即先在父region中創(chuàng)建每個存儲文件兩個reference文件。這兩個reference文件將指向父region文件。
6. RegionServer在HDFS中創(chuàng)建實際的region目錄，并為每個子region更新相應的reference文件。
7. RegionServer發(fā)起Put請求到.META.表，并在.META.表中將父region設置為offline，表并添加有關子region的信息。此時，.META.表中不會有每個子region的單獨的條目。client可以通過scan .META.表來知曉父region正在拆分，但是除非子region信息記錄到.META.表，否則client是看不到子region的。如果前面的Put操作成功寫入到.META.表，則標志父region拆分完成。如果RegionServer在put操作前返回失敗，則Master和打開這個region的RegionServer將會清除region拆分的錯誤狀態(tài)，如果.META.表成功更新，則region拆分狀態(tài)會被Master向前翻。
8. RegionServer打開子region并行地接受寫入請求。
9. RegionServer將子region A和B，以及它們的承載者信息分別添加到.META.表。之后，client就可以發(fā)現(xiàn)新的region，并訪問之。client本地緩存.META.表信息，但是當它們訪問RegionServer或者.META.表時，本地緩存失效，client從.META.表獲取新的region信息。
10. RegionServer更新zookeeper的/hbase/region-in-transition/region-name節(jié)點中的region狀態(tài)到SPLIT，以便master感知其狀態(tài)變化。如果需要的話，負載器可以將子region自由地指定到其它region。
11. region拆分完成后，其元數(shù)據(jù)和HDFS仍將包含對父region的引用。這些引用將在子region壓縮重寫數(shù)據(jù)文件時被刪除。Master的GC任務會定期檢查子region是否仍然引用父文件，如果沒有，父region將被刪除。

為了減少對業(yè)務的影響，Region Split過程并不會真正將父Region中的HFile數(shù)據(jù)搬到子Region目錄中。Split過程僅僅是在子Region中創(chuàng)建了到父Region的HFile的引用文件，子Region1中的引用文件指向原HFile的上部，而子Region2的引用文件指向原HFile2的下部。數(shù)據(jù)的真正搬遷工作是在Compaction過程中完成的。

Region合并

Region的合并分為小合并(Minor Compaction)和大合并(Major Compaction)。

小合并(Minor Compaction)

當MemStore達到hbase.hregion.memstore.flush.size大小的時候會將數(shù)據(jù)刷寫到磁盤，生成StoreFile。隨著業(yè)務的發(fā)展，數(shù)據(jù)量會越來越大，會產(chǎn)生很多的小文件，對于HBase的數(shù)據(jù)讀取，如果要掃描大量的小文件，會導致性能很差，因此需要將這些小文件合并成一個大一點的文件。

所謂的小合并，就是把多個小的StoreFile組合在一起，形成一個較大的StoreFile，通常是累積到3個SotreFile后執(zhí)行。通過hbase.hstore.compationThreadhold參數(shù)配置，小合并的步驟如下：

• 分別讀取出待合并的StoreFile文件的KeyValues，并順序地寫入到位于/hbase/.tmp目錄下的臨時文件中;
• 將臨時文件移動到對應的Region目錄中;
• 將合并的輸入文件路徑和輸出路徑封裝成KeyValues寫入WAL日志，并打上compaction標記，最后強制執(zhí)行sync;
• 將對應region數(shù)據(jù)目錄下的合并的輸入文件全部刪除，合并完成。

這種小合并一般速度比較快，對業(yè)務的影響也比較小。本質(zhì)上，小合并就是使用短時間的IO消耗以及帶寬消耗換取后續(xù)查詢的低延遲。在Minor Compaction過程中，達到TTL(記錄保留時間)的數(shù)據(jù)會被移除，但是由墓碑標記的記錄不會被移除，因為墓碑標記可能存儲在不同HFile中，合并可能會跨過部分墓碑標記。

大合并(Major Compation)

大合并就是將一個Region下的所有StoreFile合并成一個大的StoreFile文件。在大合并的過程中，之前刪除的行和過期的版本都會被刪除。大合并一般一周做一次，由hbase.hregion.majorcompaction參數(shù)控制。大合并的影響一般比較大，盡量避免同一時間多個Region進行合并，因此HBase通過hbase.hregion.majorcompaction.jitter參數(shù)來進行控制，用于防止多個Region同時進行大合并。

具體算法：

• hbase.hregion.majorcompaction參數(shù)的值乘以一個隨機分數(shù)，這個隨機分數(shù)不能超過hbase.hregion.majorcompation.jitter的值(默認為0.5)。
• 通過hbase.hregion.majorcompaction參數(shù)的值加上或減去hbase.hregion.majorcompaction參數(shù)的值乘以一個隨機分數(shù)的值就確定下一次大合并的時間區(qū)間。
• 可以通過hbase.hregion.majorcompaction設置為0來禁用major compaction。

RegionServer故障恢復

在Zookeeper中保存著RegionServer的相關信息，在RegionServer啟動的時候，會在Zookeeper中創(chuàng)建對應的臨時節(jié)點。RegionServer通過Socket和Zookeeper建立session會話，RegionServer會周期性的向Zookeeper發(fā)送ping消息包，以此說明自己還處于存活狀態(tài)。而Zookeeper收到ping包后，則會更新對應Session的超時時間。

當Zookeeper超過session超時時間還未收到RegionServer的ping包，則Zookeeper會認為該RegionServer出現(xiàn)故障，Zookeeper會將該RegionServer對應的臨時節(jié)點刪除出，并通知Master，Master收到RegionServer掛掉的信息后就會啟動數(shù)據(jù)恢復流程。