[[396349]]

本文轉(zhuǎn)載自微信公眾號「大數(shù)據(jù)技術(shù)與數(shù)倉」，作者西貝。轉(zhuǎn)載本文請聯(lián)系大數(shù)據(jù)技術(shù)與數(shù)倉公眾號。

本文會對HBase的基本原理進(jìn)行剖析，通過本文你可以了解到：

• CAP理論
• NoSQL出現(xiàn)的原因
• HBase的特點(diǎn)及使用場景
• HBase的數(shù)據(jù)模型和基本原理
• 客戶端API的基本使用
• 易混淆知識點(diǎn)面試總結(jié)

溫馨提示:本文內(nèi)容較長，如果覺得有用，建議收藏。另外記得分享、點(diǎn)贊、在看，素質(zhì)三連哦!

從BigTable說起

HBase是在谷歌BigTable的基礎(chǔ)之上進(jìn)行開源實(shí)現(xiàn)的，是一個(gè)高可靠、高性能、面向列、可伸縮的分布式數(shù)據(jù)庫，可以用來存儲非結(jié)構(gòu)化和半結(jié)構(gòu)化的稀疏數(shù)據(jù)。HBase支持超大規(guī)模數(shù)據(jù)存儲，可以通過水平擴(kuò)展的方式處理超過10億行數(shù)據(jù)和百萬列元素組成的數(shù)據(jù)表。

BigTable是一個(gè)分布式存儲系統(tǒng)，利用谷歌提出的MapReduce分布式并行計(jì)算模型來處理海量數(shù)據(jù)，使用谷歌分布式文件系統(tǒng)GFS作為底層的數(shù)據(jù)存儲，并采用Chubby提供協(xié)同服務(wù)管理，具備廣泛的應(yīng)用型、可擴(kuò)展性、高可用性及高性能性等特點(diǎn)。關(guān)于BigTable與HBase的對比，見下表：

依賴	BigTbale	HBase
數(shù)據(jù)存儲	GFS	HDFS
數(shù)據(jù)處理	MapReduce	Hadoop的MapReduce
協(xié)同服務(wù)	Chubby	Zookeeper

CAP理論

2000年，Berkerly大學(xué)有位Eric Brewer教授提出了一個(gè)CAP理論，在2002年，麻省理工學(xué)院的Seth Gilbert(賽斯·吉爾伯特)和Nancy Lynch(南希·林奇)發(fā)表了布魯爾猜想的證明，證明了CAP理論的正確性。所謂CAP理論，是指對于一個(gè)分布式計(jì)算系統(tǒng)來說，不可能同時(shí)滿足以下三點(diǎn)：

• 一致性(Consistency)

等同于所有節(jié)點(diǎn)訪問同一份最新的數(shù)據(jù)副本。即任何一個(gè)讀操作總是能夠讀到之前完成的寫操作的結(jié)果，也就是說，在分布式環(huán)境中，不同節(jié)點(diǎn)訪問的數(shù)據(jù)是一致的。

• 可用性(Availability)

每次請求都能獲取到非錯(cuò)的響應(yīng)——但是不保證獲取的數(shù)據(jù)為最新數(shù)據(jù)。即快速獲取數(shù)據(jù)，可以在確定的時(shí)間內(nèi)返回操作結(jié)果。

• 分區(qū)容錯(cuò)性(Partition tolerance)

以實(shí)際效果而言，分區(qū)相當(dāng)于對通信的時(shí)限要求。系統(tǒng)如果不能在時(shí)限內(nèi)達(dá)成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在C和A之間做出選擇。即指當(dāng)出現(xiàn)網(wǎng)絡(luò)分區(qū)時(shí)(系統(tǒng)中的一部分節(jié)點(diǎn)無法與其他的節(jié)點(diǎn)進(jìn)行通信)，分離的系統(tǒng)也能夠正常運(yùn)行，即可靠性。

如上圖所示：一個(gè)分布式的系統(tǒng)不可能同時(shí)滿足一致性、可用性和分區(qū)容錯(cuò)性，最多同時(shí)滿足兩個(gè)。當(dāng)處理CAP的問題時(shí)，可以有一下幾個(gè)選擇：

• 滿足CA，不滿足P。將所有與事務(wù)相關(guān)的內(nèi)容都放在同一個(gè)機(jī)器上，這樣會影響系統(tǒng)的可擴(kuò)展性。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫。如MySQL、SQL Server 、PostgresSQL等都采用了此種設(shè)計(jì)原則。
• 滿足AP，不滿足C。不滿足一致性(C)，即允許系統(tǒng)返回不一致的數(shù)據(jù)。其實(shí)，對于WEB2.0的網(wǎng)站而言，更加關(guān)注的是服務(wù)是否可用，而不是一致性。比如你發(fā)了一篇博客或者寫一篇微博，你的一部分朋友立馬看到了這篇文章或者微博，另一部分朋友卻要等一段時(shí)間之后才能刷出這篇文章或者微博。雖然有延時(shí)，但是對于一個(gè)娛樂性質(zhì)的Web 2.0網(wǎng)站而言，這幾分鐘的延時(shí)并不重要，不會影響用戶體驗(yàn)。相反，當(dāng)發(fā)布一篇文章或微博時(shí)，不能夠立即發(fā)布(不滿足可用性)，用戶對此肯定不爽。所以呢，對于WEB2.0的網(wǎng)站而言，可用性和分區(qū)容錯(cuò)性的優(yōu)先級要高于數(shù)據(jù)一致性，當(dāng)然，并沒有完全放棄一致性，而是最終的一致性(有延時(shí))。如Dynamo、Cassandra、CouchDB等NoSQL數(shù)據(jù)庫采用了此原則。
• 滿足CP，不滿足A。強(qiáng)調(diào)一致性性(C)和分區(qū)容錯(cuò)性(P)，放棄可用性性(A)。當(dāng)出現(xiàn)網(wǎng)絡(luò)分區(qū)時(shí)，受影響的服務(wù)需要等待數(shù)據(jù)一致，在等待期間無法對外提供服務(wù)。如Neo4J、HBase 、MongoDB、Redis等采用了此種設(shè)計(jì)原則。

為什么出現(xiàn)NoSQL

所謂NoSQL，即Not Only SQL的縮寫，意思是不只是SQL。上面提到的CAP理論正是NoSQL的設(shè)計(jì)原則。那么，為什么會興起NoSQL數(shù)據(jù)庫呢?因?yàn)閃EB2.0以及大數(shù)據(jù)時(shí)代的到來，關(guān)系型數(shù)據(jù)庫越來越不能滿足需求。大數(shù)據(jù)、物聯(lián)網(wǎng)、移動互聯(lián)網(wǎng)和云計(jì)算的發(fā)展，使得非結(jié)構(gòu)化的數(shù)據(jù)比例高達(dá)90%以上，關(guān)系型數(shù)據(jù)庫由于模型不靈活以及擴(kuò)展水平較差，在面對大數(shù)據(jù)時(shí)，暴露出了越來越多的缺陷。由此NoSQL數(shù)據(jù)庫應(yīng)運(yùn)而生，更好地滿足了大數(shù)據(jù)時(shí)代及WEB2.0的需求。

面對WEB2.0以及大數(shù)據(jù)的挑戰(zhàn)，關(guān)系型數(shù)據(jù)庫在以下幾個(gè)方面表現(xiàn)欠佳：

• 對于海量數(shù)據(jù)的處理性能較差

WEB2.0時(shí)代，尤其是移動互聯(lián)網(wǎng)的發(fā)展，UGC(用戶生成內(nèi)容，User Generated Content)以及PGC(公眾生成內(nèi)容，Public Generated Content)占據(jù)了我們的日?！，F(xiàn)如今，自媒體發(fā)展遍地開花，幾乎每個(gè)人都成了內(nèi)容的創(chuàng)造者，比如博文、評論、意見、新聞消息、視頻等等，不一而足?？梢?，這些數(shù)據(jù)產(chǎn)生的速度之快，數(shù)據(jù)量之大。比如微博、公眾號、抑或是淘寶，在一分鐘內(nèi)產(chǎn)生的數(shù)據(jù)可能就會非常的驚人，面對這些千萬級、億級的數(shù)據(jù)記錄，關(guān)系型數(shù)據(jù)庫的查詢效率顯然是不能接受的。

• 無法滿足高并發(fā)需求

WEB1.0時(shí)代，大部分是靜態(tài)網(wǎng)頁(即提供什么就看什么)，從而在大規(guī)模用戶訪問時(shí)，可以實(shí)現(xiàn)較好的響應(yīng)能力。但是，在WEB2.0時(shí)代，強(qiáng)調(diào)的是用戶的交互性(用戶創(chuàng)造內(nèi)容)，所有信息都需要事實(shí)動態(tài)生成，會造成高并發(fā)的數(shù)據(jù)庫訪問，可能每秒上萬次的讀寫請求，對于很多關(guān)系型數(shù)據(jù)庫而言，這顯示是難以承受的。

• 無法滿足擴(kuò)展性和高可用性的需求

在當(dāng)今娛樂至死的時(shí)代，熱點(diǎn)問題(吸引人眼球，滿足獵奇心理)會引來一窩蜂的流量，比如微博曝出某明星出軌，熱搜榜會迅速引來大批用戶圍觀(俗稱吃瓜群眾)，從而產(chǎn)生大量的互動交流(蹭熱點(diǎn))，這些都會造成數(shù)據(jù)庫的讀寫負(fù)荷急劇增加，從而需要數(shù)據(jù)庫能夠在短時(shí)間內(nèi)迅速提升性能以應(yīng)對突發(fā)需求(畢竟宕機(jī)會非常影響戶體驗(yàn))。但是關(guān)系型數(shù)據(jù)庫通常難以水平擴(kuò)展，不能夠像網(wǎng)頁服務(wù)器和應(yīng)用服務(wù)器那樣簡單地通過增加更多的硬件和服務(wù)節(jié)點(diǎn)來擴(kuò)展性能和負(fù)載能力。

綜上，NoSQL數(shù)據(jù)庫應(yīng)運(yùn)而生，是IT發(fā)展的必然。

HBase的特點(diǎn)及使用場景

特點(diǎn)

• 強(qiáng)一致性讀寫

HBase 不是 最終一致性(eventually consistent) 數(shù)據(jù)存儲. 這讓它很適合高速計(jì)數(shù)聚合類任務(wù)

• 自動分片(Automatic sharding)

HBase 表通過region分布在集群中。數(shù)據(jù)增長時(shí)，region會自動分割并重新分布

• RegionServer 自動故障轉(zhuǎn)移
• Hadoop/HDFS 集成

HBase 支持本機(jī)外HDFS 作為它的分布式文件系統(tǒng)

• MapReduce集成

HBase 通過MapReduce支持大并發(fā)處理， HBase 可以同時(shí)做源(Source)和匯(Sink)

• Java 客戶端 API

HBase 支持易于使用的 Java API 進(jìn)行編程訪問

• Thrift/REST API

支持Thrift 和 REST 的方式訪問HBase

• Block Cache 和 布隆過濾器(Bloom Filter)

HBase支持 Block Cache 和 布隆過濾器進(jìn)行查詢優(yōu)化，提升查詢性能

• 運(yùn)維管理

HBase提供內(nèi)置的用于運(yùn)維的網(wǎng)頁和JMX 指標(biāo)

使用場景

HBase并不適合所有場景

首先，**數(shù)據(jù)量方面 **。確信有足夠多數(shù)據(jù)，如果有上億或十億行數(shù)據(jù)，至少單表數(shù)據(jù)量超過千萬，HBase會是一個(gè)很好的選擇。如果只有上千或上百萬行，用傳統(tǒng)的RDBMS可能是更好的選擇。

其次，關(guān)系型數(shù)據(jù)庫特性方面。確信可以不依賴所有RDBMS的額外特性 (如列數(shù)據(jù)類型、二級索引、事務(wù)、高級查詢語言等) 。一個(gè)建立在RDBMS上應(yīng)用，并不能通過簡單的改變JDBC驅(qū)動就能遷移到HBase，需要一次完全的重新設(shè)計(jì)。

再次，硬件方面。確信你有足夠硬件。比如由于HDFS 的默認(rèn)副本是3，所以一般至少5個(gè)數(shù)據(jù)節(jié)點(diǎn)才能夠發(fā)揮其特性，另外 還要加上一個(gè) NameNode節(jié)點(diǎn)。

最后，數(shù)據(jù)分析方面。數(shù)據(jù)分析是HBase的弱項(xiàng)，因?yàn)閷τ贖Base乃至整個(gè)NoSQL生態(tài)圈來說，基本上都是不支持表關(guān)聯(lián)的。如果主要需求是數(shù)據(jù)分析，比如做報(bào)表，顯然HBase是不太合適的。

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

基本術(shù)語

HBase是一個(gè)稀疏、多維、持久化存儲的映射表，采用的row key、列族、列限定符合時(shí)間戳進(jìn)行索引，每個(gè)cell的值都是字節(jié)數(shù)組byte[]。了解HBase需要先知道下面的一些概念：

• Namespace

Namespace，即命名空間，是表的邏輯分組，類似于關(guān)系型數(shù)據(jù)庫管理系統(tǒng)的database。HBase存在兩個(gè)預(yù)定義的特殊的命名空間：hbase和default，其中hbase屬于系統(tǒng)命名空間，用來存儲HBase的內(nèi)部的表。default屬于默認(rèn)的命名空間，即如果建表時(shí)不指定命名空間，則默認(rèn)使用default。

• 表

由行和列組成，列劃分為若干個(gè)列族

• 行

row key是未解釋的字節(jié)數(shù)組，在HBase內(nèi)部，row key是按字典排序由低到高存儲在表中的。每個(gè)HBase的表由若干行組成，每個(gè)行由行鍵(row key)標(biāo)識。可以利用這一特性，將經(jīng)常一起讀取的行存儲在一起。

• 列族

HBase中，列是由列族進(jìn)行組織的。一個(gè)列族所有列成員是有著相同的前綴，比如，列courses:history 和 courses:math都是 列族 courses的成員。冒號(:)是列族的分隔符，用來區(qū)分前綴和列名。列族必須在表建立的時(shí)候聲明，而列則可以在使用時(shí)進(jìn)行聲明。另外，存儲在一個(gè)列族中的所有數(shù)據(jù)，通常都具有相同的數(shù)據(jù)類型，這可以極大提高數(shù)據(jù)的壓縮率。在物理上，一個(gè)的列族成員在文件系統(tǒng)上都是存儲在一起。

• 列

列族里面的數(shù)據(jù)通過列限定符來定位。列通常不需要在創(chuàng)建表時(shí)就去定義，也不需要在不同行之間保持一致。列沒有明確的數(shù)據(jù)類型，總是被視為字節(jié)數(shù)組byte[]。

• cell

單元格，即通過row key、列族、列確定的具體存儲的數(shù)據(jù)。單元格中存儲的數(shù)據(jù)也沒有明確的數(shù)據(jù)類型，總被視為字節(jié)數(shù)組byte[]。另外，每個(gè)單元格的數(shù)據(jù)是多版本的，每個(gè)版本會對應(yīng)一個(gè)時(shí)間戳。

• 時(shí)間戳

由于HBase的表數(shù)據(jù)是具有版本的，這些版本是通過時(shí)間戳進(jìn)行標(biāo)識的。每次對一個(gè)單元格進(jìn)行修改或刪除時(shí)，HBase會自動為其生成并存儲一個(gè)時(shí)間戳。一個(gè)單元格的不同版本是根據(jù)時(shí)間戳降序的順序進(jìn)行存儲的，即優(yōu)先讀取最新的數(shù)據(jù)。

關(guān)于HBase的數(shù)據(jù)模型，詳見下圖：

概念模型

在HBase概念模型中，一個(gè)表可以被看做是一個(gè)稀疏的、多維的映射關(guān)系，如下圖所示：

如上表所示：

該表包含兩行數(shù)據(jù)，分別為com.cnn.www和com.example.www;

三個(gè)列族，分別為：contents, anchor 和people。

對于第一行數(shù)據(jù)(對應(yīng)的row key為com.cnn.www),列族anchor包含兩列：anchor:cssnsi.com和anchor:my.look.ca;列族contents包含一列：contents:html;

對于第一行數(shù)據(jù)(對應(yīng)的row key為com.cnn.www),包含5個(gè)版本的數(shù)據(jù)

對于第二行數(shù)據(jù)(對應(yīng)的row key為com.example.www),包含1個(gè)版本的數(shù)據(jù)

上表中可以通過一個(gè)四維坐標(biāo)定位一個(gè)單元格數(shù)據(jù)：[row key,列族,列,時(shí)間戳]，比如[com.cnn.www,contents,contents:html,t6]

物理模型

從概念模型上看，HBase的表是稀疏的。在物理存儲的時(shí)候，是按照列族進(jìn)行存儲的。一個(gè)列限定符(column_family:column_qualifier)可以被隨時(shí)添加到已經(jīng)存在的列族上。

從物理模型上看，概念模型中存在的空單元格是不會被存儲的。比如要訪問contents:html，時(shí)間戳為t8,則不會返回值。值得注意的是，如果訪問數(shù)據(jù)時(shí)沒有指定時(shí)間戳，則默認(rèn)訪問最新版本的數(shù)據(jù)，因?yàn)閿?shù)據(jù)是按照版本時(shí)間戳降序排列的。

如上表：如果訪問行com.cnn.www，列contents:html，在沒有指定時(shí)間戳的情況下，則返回t6對應(yīng)的數(shù)據(jù);同理如果訪問anchor:cnnsi.com,則返回t9對應(yīng)的數(shù)據(jù)。

HBase的原理及運(yùn)行機(jī)制

整體架構(gòu)

通過上面的描述，應(yīng)該對HBase有了一定的了解。現(xiàn)在我們在來看一下HBase的宏觀架構(gòu)，如下圖：

我們先從宏觀的角度看一下HBase的整體架構(gòu)。從HBase的部署架構(gòu)上來說，HBase有兩種服務(wù)器：Master服務(wù)器和RegionServer服務(wù)器。一般一個(gè)HBase集群有一個(gè)Master服務(wù)器和幾個(gè)RegionServer服務(wù)器。

Master服務(wù)器負(fù)責(zé)維護(hù)表結(jié)構(gòu)信息，實(shí)際的數(shù)據(jù)都存儲在RegionServer服務(wù)器上。在HBase的集群中，客戶端獲取數(shù)據(jù)由客戶端直連RegionServer的，所以你會發(fā)現(xiàn)Master掛掉之后你依然可以查詢數(shù)據(jù)，但是不能創(chuàng)建新的表了。

• Master

我們都知道，在Hadoop采用的是master-slave架構(gòu)，即namenode節(jié)點(diǎn)為主節(jié)點(diǎn)，datanode節(jié)點(diǎn)為從節(jié)點(diǎn)。namenode節(jié)點(diǎn)對于hadoop集群而言至關(guān)重要，如果namenode節(jié)點(diǎn)掛了，那么整個(gè)集群也就癱瘓了。

但是，在HBase集群中，Master服務(wù)的作用并沒有那么的重要。雖然是Master節(jié)點(diǎn)，其實(shí)并不是一個(gè)leader的角色。Master服務(wù)更像是一個(gè)‘打雜’的，類似于一個(gè)輔助者的角色。因?yàn)楫?dāng)我們連接HBase集群時(shí)，客戶端會直接從Zookeeper中獲取RegionServer的地址，然后從RegionServer中獲取想要的數(shù)據(jù)，不需要經(jīng)過Master節(jié)點(diǎn)。除此之外，當(dāng)我們向HBase表中插入數(shù)據(jù)、刪除數(shù)據(jù)等操作時(shí)，也都是直接跟RegionServer交互的，不需要Master服務(wù)參與。

那么，Master服務(wù)有什么作用呢?Master只負(fù)責(zé)各種協(xié)調(diào)工作，比如建表、刪表、移動Region、合并等操作。這些操作有一個(gè)共性的問題：就是需要跨RegionServer。所以，HBase就將這些工作分配給了Master服務(wù)。這種結(jié)構(gòu)的好處是大大降低了集群對Master的依賴。而Master節(jié)點(diǎn)一般只有一個(gè)到兩個(gè)，一旦宕機(jī)，如果集群對Master的依賴度很大，那么就會產(chǎn)生單點(diǎn)故障問題。在HBase中即使Master宕機(jī)了，集群依然可以正常地運(yùn)行，依然可以存儲和刪除數(shù)據(jù)。

• RegionServer

RegionServer就是存放Region的容器，直觀上說就是服務(wù)器上的一個(gè)服務(wù)。RegionServer是真正存儲數(shù)據(jù)的節(jié)點(diǎn)，最終存儲在分布式文件系統(tǒng)HDFS。當(dāng)客戶端從ZooKeeper獲取RegionServer的地址后，它會直接從RegionServer獲取數(shù)據(jù)。對于HBase集群而言，其重要性要比Master服務(wù)大。

• Zookeeper

RegionServer非常依賴ZooKeeper服務(wù)，ZooKeeper在HBase中扮演的角色類似一個(gè)管家。ZooKeeper管理了HBase所有RegionServer的信息，包括具體的數(shù)據(jù)段存放在哪個(gè)RegionServer上。客戶端每次與HBase連接，其實(shí)都是先與ZooKeeper通信，查詢出哪個(gè)RegionServer需要連接，然后再連接RegionServer。

我們可以通過zkCli訪問hbase節(jié)點(diǎn)的數(shù)據(jù)，通過下面命名可以獲取hbase:meta表的信息：

[zk: localhost:2181(CONNECTED) 17] get /hbase/meta-region-server

簡單總結(jié)Zookeeper在HBase集群中的作用如下：對于服務(wù)端，是實(shí)現(xiàn)集群協(xié)調(diào)與控制的重要依賴。對于客戶端，是查詢與操作數(shù)據(jù)必不可少的一部分。

需要注意的是：當(dāng)Master服務(wù)掛掉時(shí)，依然可以進(jìn)行能讀能寫操作;但是把ZooKeeper一旦掛掉，就不能讀取數(shù)據(jù)了，因?yàn)樽x取數(shù)據(jù)所需要的元數(shù)據(jù)表hbase:meata的位置存儲在ZooKeeper上?？梢妟ookeeper對于HBase而言是至關(guān)重要的。

Region

Region就是一段數(shù)據(jù)的集合。HBase中的表一般擁有一個(gè)到多個(gè)Region。Region不能跨服務(wù)器，一個(gè)RegionServer上有一個(gè)或者多個(gè)Region。當(dāng)開始創(chuàng)建表時(shí)，數(shù)據(jù)量小的時(shí)候，一個(gè)Region足以存儲所有數(shù)據(jù)，等到數(shù)據(jù)量逐漸增加，會拆分為多個(gè)region;當(dāng)HBase在進(jìn)行負(fù)載均衡的時(shí)候，也有可能會從一臺RegionServer上把Region移動到另一臺RegionServer上。Region是存儲在HDFS的，它的所有數(shù)據(jù)存取操作都是調(diào)用了HDFS的客戶端接口來實(shí)現(xiàn)的。一個(gè)Region就相當(dāng)于關(guān)系型數(shù)據(jù)庫中分區(qū)表的一個(gè)分區(qū)。

微觀架構(gòu)

上一小節(jié)對HBase的整體架構(gòu)進(jìn)行了說明，接下來再看一下內(nèi)部細(xì)節(jié)，如下圖所示：展示了一臺RegionServer的內(nèi)部架構(gòu)。

如上圖所示：一個(gè)RegionServer可以存儲多個(gè)region，Region相當(dāng)于一個(gè)數(shù)據(jù)分片。每一個(gè)Region都有起 始rowkey和結(jié)束rowkey，代表了它所存儲的row范圍。在一個(gè)region內(nèi)部，包括多個(gè)store，其中一個(gè)store對應(yīng)一個(gè)列族，每個(gè)store的內(nèi)部又包含一個(gè)MemStore，主要負(fù)責(zé)數(shù)據(jù)排序，等超過一定閾值之后將MemStore的數(shù)據(jù)刷到HFile文件，HFile文件時(shí)最終存儲數(shù)據(jù)的地方。

值得注意的是：一臺RegionServer共用一個(gè)WAL(Write-Ahead Log)預(yù)寫日志，如果開啟了WAL，那么當(dāng)寫數(shù)據(jù)時(shí)會先寫進(jìn)WAL，可以起到容錯(cuò)作用。WAL是一個(gè)保險(xiǎn)機(jī)制，數(shù)據(jù)在寫到Memstore之前，先被寫到WAL了。這樣當(dāng)故障恢復(fù)的時(shí)候可以從WAL中恢復(fù)數(shù)據(jù)。另外，每個(gè)Store都有一個(gè)MemStore，用于數(shù)據(jù)排序。一臺RegionServer也只有一個(gè)BlockCache，用于讀數(shù)據(jù)是進(jìn)行緩存。

• WAL預(yù)寫日志

**Write Ahead Log (WAL)**會記錄HBase中的所有數(shù)據(jù)，WAL起到容錯(cuò)恢復(fù)的作用，并不是必須的選項(xiàng)。在HDFS上，WAL的默認(rèn)路徑是/hbase/WALs/,用戶可以通過hbase.wal.dir進(jìn)行配置。

WAL默認(rèn)是開啟的，如果關(guān)閉，可以使用下面的命令Mutation.setDurability(Durability.SKIP_WAL)。WAL支持異步和同步的寫入方式，異步方式通過調(diào)用下面的方法Mutation.setDurability(Durability.ASYNC_WAL)。同步方式通過調(diào)用下面的方法：Mutation.setDurability(Durability.SYNC_WAL)，其中同步方式是默認(rèn)的方式。

關(guān)于異步WAL，當(dāng)有Put、Delete、Append操作時(shí)，并不會立即觸發(fā)同步數(shù)據(jù)。而是要等到一定的時(shí)間間隔，該時(shí)間間隔可以通過參數(shù)hbase.regionserver.optionallogflushinterval進(jìn)行設(shè)定，默認(rèn)是1000ms。

• MemStore

每個(gè)Store中有一個(gè)MemStore實(shí)例。數(shù)據(jù)寫入WAL之后就會被放入MemStore。MemStore是內(nèi)存的存儲對象，只有當(dāng)MemStore滿了的時(shí)候才會將數(shù)據(jù)刷寫(flush)到HFile中。

為了讓數(shù)據(jù)順序存儲從而提高讀取效率，HBase使用了LSM樹結(jié)構(gòu)來存儲數(shù)據(jù)。數(shù)據(jù)會先在Memstore中 整理成LSM樹，最后再刷寫到HFile上。

關(guān)于MemStore，很容易讓人混淆。數(shù)據(jù)在被刷到HFile之前，已經(jīng)被存儲到了HDFS的WAL上了，那么為什么還要在放入MemStore呢?其實(shí)很簡單，我們都知道HDFS是不能修改的，而HBase的數(shù)據(jù)又是按照Row Key進(jìn)行排序的，其實(shí)這個(gè)排序的過程就是在MemStore中進(jìn)行的。值得注意的是：MemStore的作用不是為了加快寫速度，而是為了對Row Key進(jìn)行排序。

• HFile

HFile是數(shù)據(jù)存儲的實(shí)際載體，我們創(chuàng)建的所有表、列等數(shù)據(jù)都存儲在HFile里面。當(dāng)Memstore達(dá)到一定閥值，或者達(dá)到了刷寫時(shí)間間隔閥值的時(shí)候，HBaes會被這個(gè)Memstore的內(nèi)容刷寫到HDFS系統(tǒng)上，稱為一個(gè)存儲在硬盤上的HFile文件。至此，我們數(shù)據(jù)真正地被持久化到硬盤上。

Region的定位

在開始講解HBase的數(shù)據(jù)讀寫流程之前，先來看一下Region是怎么定位的。我們知道Region是HBase非常重要的一個(gè)概念，Region存儲在RegionServer中，那么客戶端在讀寫操作時(shí)是如何定位到所需要的region呢?關(guān)于這個(gè)問題，老版本的HBase與新版本的HBase有所不同。

老版本HBase(0.96.0之前)

老版本的HBase采用的是為三層查詢架構(gòu)，如下圖所示：

如上圖：第一層定位是Zookeeper中的節(jié)點(diǎn)數(shù)據(jù)，記錄了-ROOT-表的位置信息;

第二層-ROOT-表記錄了.META.region位置信息，-ROOT-表只有一個(gè)region，通過-ROOT-表可以訪問.META.表中的數(shù)據(jù)

第三層.META.表，記錄了用戶數(shù)據(jù)表的region位置信息，.META.表可以有多個(gè)region。

整個(gè)查詢步驟如下：

第一步：用戶通過查找zk(ZooKeeper)的/hbase/root-regionserver節(jié)點(diǎn)來知道-ROOT-表的RegionServer位置。

第二步：訪問-ROOT-表，查找所需要的數(shù)據(jù)表的元數(shù)據(jù)信息存在哪個(gè).META.表上，這個(gè).META.表在哪個(gè)RegionServer上。

第四步：訪問.META.表來看你要查詢的行鍵在什么Region范圍里面。

第五步：連接具體的數(shù)據(jù)所在的RegionServer，這個(gè)一步才開始在很正的查詢數(shù)據(jù)。

新版本HBase

老版本的HBase尋址存在很多弊端，在新版本中進(jìn)行了改進(jìn)。采用的是二級尋址的方式，僅僅使用 hbase:meta表來定位region，那么 從哪里獲取hbase:meta的信息呢，答案是zookeeper。在zookeeper中存在一個(gè)/hbase/meta-region-server節(jié)點(diǎn)，可以獲取hbase:meta表的位置信息，然后通過hbase:meta表查詢所需要數(shù)據(jù)所在的region位置信息。

整個(gè)查詢步驟如下：

第一步：客戶端先通過ZooKeeper的/hbase/meta-region-server節(jié)點(diǎn)查詢hbase:meta表的位置。

第二步：客戶端連接hbase:meta表所在的RegionServer。hbase:meta表存儲了所有Region的行鍵范圍信息，通過這個(gè)表就可以查詢出你要存取的rowkey屬于哪個(gè)Region的范圍里面，以及這個(gè)Region屬于哪個(gè) RegionServer。

第三步：獲取這些信息后，客戶端就可以直連擁有你要存取的rowkey的RegionServer，并直接對其操作。

第四步：客戶端會把meta信息緩存起來，下次操作就不需要進(jìn)行以上加載hbase:meta的步驟了。

客戶端API基本使用

public class Example { 
 
  private static final String TABLE_NAME = "MY_TABLE_NAME_TOO"; 
  private static final String CF_DEFAULT = "DEFAULT_COLUMN_FAMILY"; 
 
  public static void createOrOverwrite(Admin admin, HTableDescriptor table) throws IOException { 
    if (admin.tableExists(table.getTableName())) { 
      admin.disableTable(table.getTableName()); 
      admin.deleteTable(table.getTableName()); 
    } 
    admin.createTable(table); 
  } 
 
  public static void createSchemaTables(Configuration config) throws IOException { 
    try (Connection connection = ConnectionFactory.createConnection(config); 
         Admin admin = connection.getAdmin()) { 
 
      HTableDescriptor table = new HTableDescriptor(TableName.valueOf(TABLE_NAME)); 
      table.addFamily(new HColumnDescriptor(CF_DEFAULT).setCompressionType(Algorithm.NONE)); 
 
      System.out.print("Creating table. "); 
      createOrOverwrite(admin, table); 
      System.out.println(" Done."); 
    } 
  } 
 
  public static void modifySchema (Configuration config) throws IOException { 
    try (Connection connection = ConnectionFactory.createConnection(config); 
         Admin admin = connection.getAdmin()) { 
 
      TableName tableName = TableName.valueOf(TABLE_NAME); 
      if (!admin.tableExists(tableName)) { 
        System.out.println("Table does not exist."); 
        System.exit(-1); 
      } 
 
      HTableDescriptor table = admin.getTableDescriptor(tableName); 
 
      // 更新table 
      HColumnDescriptor newColumn = new HColumnDescriptor("NEWCF"); 
      newColumn.setCompactionCompressionType(Algorithm.GZ); 
      newColumn.setMaxVersions(HConstants.ALL_VERSIONS); 
      admin.addColumn(tableName, newColumn); 
 
      // 更新column family 
      HColumnDescriptor existingColumn = new HColumnDescriptor(CF_DEFAULT); 
      existingColumn.setCompactionCompressionType(Algorithm.GZ); 
      existingColumn.setMaxVersions(HConstants.ALL_VERSIONS); 
      table.modifyFamily(existingColumn); 
      admin.modifyTable(tableName, table); 
 
      // 禁用table 
      admin.disableTable(tableName); 
 
      // 刪除column family 
      admin.deleteColumn(tableName, CF_DEFAULT.getBytes("UTF-8")); 
 
      // 刪除表，首先要禁用表 
      admin.deleteTable(tableName); 
    } 
  } 
 
  public static void main(String... args) throws IOException { 
    Configuration config = HBaseConfiguration.create(); 
 
    config.addResource(new Path(System.getenv("HBASE_CONF_DIR"), "hbase-site.xml")); 
    config.addResource(new Path(System.getenv("HADOOP_CONF_DIR"), "core-site.xml")); 
    createSchemaTables(config); 
    modifySchema(config); 
  } 
} 

易混淆知識點(diǎn)總結(jié)

Q1：MemStore的作用是什么?

在HBase中，一個(gè)表可以有多個(gè)列族，一個(gè)列族在物理上是存儲在一起的，一個(gè)列族會對應(yīng)一個(gè)store，在store的內(nèi)部會存在一個(gè)MemStore，其作用并不是為了提升讀寫速度，而是為了對RowKey進(jìn)行排序。我們知道，HBase的數(shù)據(jù)是存儲在HDFS上的，而HDFS是不支持修改的，HBase為了按RowKey進(jìn)行排序，首先會將數(shù)據(jù)寫入MemStore，數(shù)據(jù)會先在Memstore中整理成LSM樹，最后再刷寫到HFile上。

總之一句話：Memstore的實(shí)現(xiàn)目的不是加速數(shù)據(jù)寫入或讀取，而是維持?jǐn)?shù)據(jù)結(jié)構(gòu)。

Q2：讀取數(shù)據(jù)時(shí)會先從MemStore讀取嗎?

MemStore的作用是為了按RowKey進(jìn)行排序，其作用不是為了提升讀取速度的。讀取數(shù)據(jù)的時(shí)候是有專門的緩存叫BlockCache，如果開啟了BlockCache，就是先讀BlockCache，然后才是讀HFile+Memstore的數(shù)據(jù)。

Q3：BlockCache有什么用?

塊緩存(BlockCache)使用內(nèi)存來記錄數(shù)據(jù)，適用于提升讀取性能。當(dāng)開啟了塊緩存后，HBase會優(yōu)先從塊緩存中查詢是否有記錄，如果沒有才去檢索存儲在硬盤上的HFile。

值得注意的是，一個(gè)RegionServer只有一個(gè)BlockCache。BlockCache不是數(shù)據(jù)存儲的必須組成部分，只是用來優(yōu)化讀取性能的。

BlockCache的基本原理是：在讀請求到HBase之后，會先嘗試查詢BlockCache，如果獲取不到所需的數(shù)據(jù)，就去HFile和Memstore中去獲取。如果獲取到了，則在返回?cái)?shù)據(jù)的同時(shí)把Block塊緩存到BlockCache中。

Q4：HBase是怎么刪除數(shù)據(jù)的?

HBase刪除記錄并不是真的刪除了數(shù)據(jù)，而是標(biāo)識了一個(gè)墓碑標(biāo)記(tombstone marker)，把這個(gè)版本連同之前的版本都標(biāo)記為不可見了。這是為了性能著想，這樣HBase就可以定期去清理這些已經(jīng)被刪除的記錄，而不用每次都進(jìn)行刪除操作。所謂定期清理，就是按照一定時(shí)間周期在HBase做自動合并(compaction，HBase整理存儲文件時(shí)的一個(gè)操作，會把多個(gè)文件塊合并成一個(gè)文件)。這樣刪除操作對于HBase的性能影響被降到了最低，即便是在很高的并發(fā)負(fù)載下大量刪除記錄也是OK的。

合并操作分為兩種：Minor Compaction和Major Compaction。

其中Minor Compaction是將Store中多個(gè)HFile合并為一個(gè)HFile。在這個(gè)過程中達(dá)到TTL的數(shù)據(jù)會被移除，但是被手動刪除的數(shù)據(jù)不會被移除。這種合并觸發(fā)頻率較高。

而Major Compaction合并Store中的所有HFile為一個(gè)HFile。在這個(gè)過程中被手動刪除的數(shù)據(jù)會被真正地移除。同時(shí)被刪除的還有單元格內(nèi)超過MaxVersions的版本數(shù)據(jù)。這種合并觸發(fā)頻率較低，默認(rèn)為7天一次。不過由于Major Compaction消耗的性能較大，一般建議手動控制MajorCompaction的時(shí)機(jī)。

需要注意的是：Major Compaction刪除的是那些帶墓碑標(biāo)記的數(shù)據(jù)，而Minor Compaction合并的時(shí)候直接會忽略過期數(shù)據(jù)文件，所以過期的這些文件會在Minor Compaction的時(shí)候就被刪除。

Q5：為什么HBase具有高性能的讀寫能力?

因?yàn)镠Base使用了一種LSM的存儲結(jié)構(gòu)，在LSM樹的實(shí)現(xiàn)方式中，會在數(shù)據(jù)存儲之前先對數(shù)據(jù)進(jìn)行排序。LSM樹是Google BigTable和HBase的基本存儲算法，它是傳統(tǒng)關(guān)系型數(shù)據(jù)庫的B+樹的改進(jìn)。算法的核心在于盡量保證數(shù)據(jù)是順序存儲到磁盤上的，并且會有頻率地對數(shù)據(jù)進(jìn)行整理，確保其順序性。

LSM樹就是一堆小樹，在內(nèi)存中的小樹即memstore，每次flush，內(nèi)存中的memstore變成磁盤上一個(gè)新的storefile。這種批量的讀寫操作使得HBase的性能較高。

Q6：Store與列簇是什么關(guān)系?

Region是HBase的核心模塊，而Store則是Region的核心模塊。每個(gè)Store對應(yīng)了表中的一個(gè)列族存儲。每個(gè)Store包含一個(gè)MemStore和若干個(gè)HFile。

Q7：WAL是RegionServer共享的，還是Region級別共享的?

在HBase中，每個(gè)RegionServer只需要維護(hù)一個(gè)WAL，所有Region對象共用一個(gè)WAL，而不是每個(gè)Region都維護(hù)一個(gè)WAL。這種方式對于多個(gè)Region的更新操作所發(fā)生的的日志修改，只需要不斷地追加到單個(gè)日志文件中，不需要同時(shí)打開并寫入多個(gè)日志文件，這樣可以減少磁盤尋址次數(shù)，提高寫性能。

但是這種方式也存在一個(gè)缺點(diǎn)，如果RegionServer發(fā)生故障，為了恢復(fù)其上的Region對象，需要將RegionServer上的WAL按照其所屬的Region對象進(jìn)行拆分，然后分發(fā)到其他RegionServer上執(zhí)行恢復(fù)操作。

Q8：Master掛掉之后，還能查詢數(shù)據(jù)嗎?

可以的。Master服務(wù)主要負(fù)責(zé)表和Region的管理工作。主要作用有：

• 管理用戶對表的增加、刪除、修改操作
• 實(shí)現(xiàn)不同RegionServer之前的負(fù)載均衡
• Region的分裂與合并
• 對發(fā)生故障的RegionServer的Region進(jìn)行遷移

客戶端訪問HBase時(shí)，不需要Master的參與，只需要連接zookeeper獲取hbase:meta地址，然后直連RegionServer進(jìn)行數(shù)據(jù)讀寫操作，Master僅僅維護(hù)表和Region的元數(shù)據(jù)信息，負(fù)載很小。但是Master節(jié)點(diǎn)也不能長時(shí)間的宕機(jī)。

總結(jié)

本文首先從谷歌的BigTable說起，然后介紹了CAP相關(guān)理論，并分析了NoSQL出現(xiàn)的原因。接著對HBase的數(shù)據(jù)模型進(jìn)行了剖析，然后詳細(xì)描述了HBase的原理和運(yùn)行機(jī)制。最后給出了客戶端API的基本使用，并對常見的、易混淆的知識點(diǎn)進(jìn)行了解釋。