[[329164]]

前言

在我還不了解分布式和大數(shù)據(jù)的時候已經(jīng)聽說過HBase了，但對它一直都半知不解，這篇文章來講講吧。

在真實生活中，最開始聽到這個詞是我的一場面試，當(dāng)年我還是個『小垃圾』，現(xiàn)在已經(jīng)是個『大垃圾』了。

面試官當(dāng)時給了一個場景題問我，具體的題目我忘得差不多了，大概就是考試與試題的一個場景，問我數(shù)據(jù)庫要如何設(shè)計。

我答了關(guān)系型數(shù)據(jù)庫的設(shè)計方案，他大概說：這個場景比較復(fù)雜多變，為什么不考慮一下HBase這種NoSQL的數(shù)據(jù)庫來存儲呢?

我就說：“對對對，可以的” (雖然我當(dāng)時不知道HBase是什么，但是氣勢一定要有，你們說是不是)

 

最后面試官還是給我發(fā)了offer，但我沒去，原因就是離家太遠(yuǎn)了。

一、介紹HBase

Apache HBase™ is the Hadoop database, a distributed, scalable, big data store.

HBase is a type of "NoSQL" database.

Apache HBase 是 Hadoop 數(shù)據(jù)庫，一個分布式、可伸縮的大數(shù)據(jù)存儲。

HBase是依賴Hadoop的。為什么HBase能存儲海量的數(shù)據(jù)?因為HBase是在HDFS的基礎(chǔ)之上構(gòu)建的，HDFS是分布式文件系統(tǒng)。

二、為什么要用HBase

截至到現(xiàn)在，我已經(jīng)學(xué)了不少的組件了，比如說分布式搜索引擎「Elasticsearch」、分布式文件系統(tǒng)「HDFS」、分布式消息隊列「Kafka」、緩存數(shù)據(jù)庫「Redis」等等...

能夠處理數(shù)據(jù)的中間件(系統(tǒng))，這些中間件基本都會有持久化的功能。為什么?如果某一個時刻掛了，那還在內(nèi)存但還沒處理完的數(shù)據(jù)不就涼了?

Redis有AOF和RDB、Elasticsearch會把數(shù)據(jù)寫到translog然后結(jié)合FileSystemCache將數(shù)據(jù)刷到磁盤中、Kafka本身就是將數(shù)據(jù)順序?qū)懙酱疟P....

這些中間件會實現(xiàn)持久化(像HDFS和MySQL我們本身就用來存儲數(shù)據(jù)的)，為什么我們還要用HBase呢?

雖然沒有什么可比性，但是在學(xué)習(xí)的時候總會有一個疑問：「既然已學(xué)過的系統(tǒng)都有類似的功能了，那為啥我還要去學(xué)這個玩意?」

我是這樣理解的：

• MySQL?MySQL數(shù)據(jù)庫我們是算用得最多了的吧?但眾所周知，MySQL是單機(jī)的。MySQL能存儲多少數(shù)據(jù)，取決于那臺服務(wù)器的硬盤大小。以現(xiàn)在互聯(lián)網(wǎng)的數(shù)據(jù)量，很多時候MySQL是沒法存儲那么多數(shù)據(jù)的。比如我這邊有個系統(tǒng)，一天就能產(chǎn)生1TB的數(shù)據(jù)，這數(shù)據(jù)是不可能存MySQL的。(如此大的量數(shù)據(jù)，我們現(xiàn)在的做法是先寫到Kafka，然后落到hive中)
• Kafka?Kafka我們主要用來處理消息的(解耦異步削峰)。數(shù)據(jù)到Kafka，Kafka會將數(shù)據(jù)持久化到硬盤中，并且Kafka是分布式的(很方便的擴(kuò)展)，理論上Kafka可以存儲很大的數(shù)據(jù)。但是Kafka的數(shù)據(jù)我們不會「單獨(dú)」取出來。持久化了的數(shù)據(jù)，最常見的用法就是重新設(shè)置offset，做「回溯」操作
• Redis?Redis是緩存數(shù)據(jù)庫，所有的讀寫都在內(nèi)存中，速度賊快。AOF/RDB存儲的數(shù)據(jù)都會加載到內(nèi)存中，Redis不適合存大量的數(shù)據(jù)(因為內(nèi)存太貴了!)。
• Elasticsearch?Elasticsearch是一個分布式的搜索引擎，主要用于檢索。理論上Elasticsearch也是可以存儲海量的數(shù)據(jù)(畢竟分布式)，我們也可以將數(shù)據(jù)用『索引』來取出來，似乎已經(jīng)是非常完美的中間件了。但是如果我們的數(shù)據(jù)沒有經(jīng)?！笝z索」的需求，其實不必放到Elasticsearch，數(shù)據(jù)寫入Elasticsearch需要分詞，無疑會浪費(fèi)資源。
• HDFS?顯然HDFS是可以存儲海量的數(shù)據(jù)的，它就是為海量數(shù)據(jù)而生的。它也有明顯的缺點(diǎn)：不支持隨機(jī)修改，查詢效率低，對小文件支持不友好。

文中的開頭已經(jīng)說了，HBase是基于HDFS分布式文件系統(tǒng)去構(gòu)建的。換句話說，HBase的數(shù)據(jù)其實也是存儲在HDFS上的。那肯定有好奇寶寶就會問：HDFS和HBase有啥區(qū)別阿?

HDFS是文件系統(tǒng)，而HBase是數(shù)據(jù)庫，其實也沒啥可比性?！改憧梢园袶Base當(dāng)做是MySQL，把HDFS當(dāng)做是硬盤。HBase只是一個NoSQL數(shù)據(jù)庫，把數(shù)據(jù)存在HDFS上」。

數(shù)據(jù)庫是一個以某種有組織的方式存儲的數(shù)據(jù)集合。

扯了這么多，那我們?yōu)樯兑肏Base呢?HBase在HDFS之上提供了高并發(fā)的隨機(jī)寫和支持實時查詢，這是HDFS不具備的。

我一直都說在學(xué)習(xí)某一項技術(shù)之前首先要了解它能干什么。如果僅僅看上面的”對比“，我們可以發(fā)現(xiàn)HBase可以以低成本來存儲海量的數(shù)據(jù)并且支持高并發(fā)隨機(jī)寫和實時查詢。

但HBase還有一個特點(diǎn)就是：存儲數(shù)據(jù)的”結(jié)構(gòu)“可以地非常靈活(這個下面會講到，這里如果沒接觸過HBase的同學(xué)可能不知道什么意思)。

三、入門HBase

聽過HBase的同學(xué)可能都聽過「列式存儲」這個詞。我最開始的時候覺得HBase很難理解，就因為它這個「列式存儲」我一直理解不了它為什么是「列式」的。

在網(wǎng)上也有很多的博客去講解什么是「列式」存儲，它們會舉我們現(xiàn)有的數(shù)據(jù)庫，比如MySQL。存儲的結(jié)構(gòu)我們很容易看懂，就是一行一行數(shù)據(jù)嘛。

 

 

轉(zhuǎn)換成所謂的列式存儲是什么樣的呢?

 

 

可以很簡單的發(fā)現(xiàn)，無非就是把每列抽出來，然后關(guān)聯(lián)上Id。這個叫列式存儲嗎?我在這打個問號。

轉(zhuǎn)換后的數(shù)據(jù)從我的角度來看，數(shù)據(jù)還是一行一行的。

這樣做有什么好處嗎?很明顯以前我們一行記錄多個屬性(列)，有部分的列是空缺的，但是我們還是需要空間去存儲。現(xiàn)在把這些列全部拆開，有什么我們就存什么，這樣空間就能被我們充分利用。

這種形式的數(shù)據(jù)更像什么?明顯是Key-Value嘛。那我們該怎么理解HBase所謂的列式存儲和Key-Value結(jié)構(gòu)呢?

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

在看HBase數(shù)據(jù)模型的時候，其實最好還是不要用「關(guān)系型數(shù)據(jù)庫」的知識去理解它。

In HBase, data is stored in tables, which have rows and columns. This is a terminology overlap withrelational databases (RDBMSs), but this is not a helpful analogy.

HBase里邊也有表、行和列的概念。

• 表沒什么好說的，就是一張表
• 一行數(shù)據(jù)由一個行鍵和一個或多個相關(guān)的列以及它的值所組成

好了，現(xiàn)在比較抽象了。在HBase里邊，定位一行數(shù)據(jù)會有一個唯一的值，這個叫做行鍵(RowKey)。而在HBase的列不是我們在關(guān)系型數(shù)據(jù)庫所想象中的列。

HBase的列(Column)都得歸屬到列族(Column Family)中。在HBase中用列修飾符(Column Qualifier)來標(biāo)識每個列。

在HBase里邊，先有列族，后有列。

什么是列族?可以簡單理解為：列的屬性類別

什么是列修飾符?先有列族后有列，在列族下用列修飾符來標(biāo)識一列。

還很抽象是不是?來畫個圖：

 

 

我們再放點(diǎn)具體的值去看看，就更加容易看懂了：

 

 

這張表我們有兩個列族，分別是UserInfo和OrderInfo。在UserInfo下有兩個列，分別是UserInfo:name和UserInfo:age，在OrderInfo下有兩個列，分別是OrderInfo:orderId和OrderInfo:money。

UserInfo:name的值為：UserInfo:age的值為24。OrderInfo:orderId的值為23333。OrderInfo:money的值為30。這些數(shù)據(jù)的主鍵(RowKey)為1

上面的那個圖看起來可能不太好懂，我們再畫一個我們比較熟悉的：

 

 

HBase表的每一行中，列的組成都是靈活的，行與行之間的列不需要相同。如圖下：

 

 

 

 

換句話說：一個列族下可以任意添加列，不受任何限制

數(shù)據(jù)寫到HBase的時候都會被記錄一個時間戳，這個時間戳被我們當(dāng)做一個版本。比如說，我們修改或者刪除某一條的時候，本質(zhì)上是往里邊新增一條數(shù)據(jù)，記錄的版本加一了而已。

比如現(xiàn)在我們有一條記錄：

 

 

現(xiàn)在要把這條記錄的值改為40，實際上就是多添加一條記錄，在讀的時候按照時間戳讀最新的記錄。在外界「看起來」就是把這條記錄改了。

 

 

3.2 HBase 的Key-Value

HBase本質(zhì)上其實就是Key-Value的數(shù)據(jù)庫，那在HBase里邊，Key是什么?Value是什么?

我們看一下下面的HBaseKey-Value結(jié)構(gòu)圖：

 

 

Key由RowKey(行鍵)+ColumnFamily(列族)+Column Qualifier(列修飾符)+TimeStamp(時間戳--版本)+KeyType(類型)組成，而Value就是實際上的值。

對比上面的例子，其實很好理解，因為我們修改一條數(shù)據(jù)其實上是在原來的基礎(chǔ)上增加一個版本的，那我們要準(zhǔn)確定位一條數(shù)據(jù)，那就得(RowKey+Column+時間戳)。

KeyType是什么?我們上面只說了「修改」的情況，你們有沒有想過，如果要刪除一條數(shù)據(jù)怎么做?實際上也是增加一條記錄，只不過我們在KeyType里邊設(shè)置為“Delete”就可以了。

3.3 HBase架構(gòu)

扯了這么一大堆，已經(jīng)說了HBase的數(shù)據(jù)模型和Key-Value了，我們還有一個問題：「為什么經(jīng)常會有人說HBase是列式存儲呢?」

其實HBase更多的是「列族存儲」，要談列族存儲，就得先了解了解HBase的架構(gòu)是怎么樣的。

我們先來看看HBase的架構(gòu)圖：

 

 

1、Client客戶端，它提供了訪問HBase的接口，并且維護(hù)了對應(yīng)的cache來加速HBase的訪問。

2、Zookeeper存儲HBase的元數(shù)據(jù)(meta表)，無論是讀還是寫數(shù)據(jù)，都是去Zookeeper里邊拿到meta元數(shù)據(jù)告訴給客戶端去哪臺機(jī)器讀寫數(shù)據(jù)

3、HRegionServer它是處理客戶端的讀寫請求，負(fù)責(zé)與HDFS底層交互，是真正干活的節(jié)點(diǎn)。

總結(jié)大致的流程就是：client請求到Zookeeper，然后Zookeeper返回HRegionServer地址給client，client得到Zookeeper返回的地址去請求HRegionServer，HRegionServer讀寫數(shù)據(jù)后返回給client。

 

 

3.4 HRegionServer內(nèi)部

我們來看下面的圖：

 

 

前面也提到了，HBase可以存儲海量的數(shù)據(jù)，HBase是分布式的。所以我們可以斷定：HBase一張表的數(shù)據(jù)會分到多臺機(jī)器上的。那HBase是怎么切割一張表的數(shù)據(jù)的呢?用的就是RowKey來切分，其實就是表的橫向切割。

 

 

說白了就是一個HRegion上，存儲HBase表的一部分?jǐn)?shù)據(jù)。

 

 

HRegion下面有Store，那Store是什么呢?我們前面也說過，一個HBase表首先要定義列族，然后列是在列族之下的，列可以隨意添加。

一個列族的數(shù)據(jù)是存儲在一起的，所以一個列族的數(shù)據(jù)是存儲在一個Store里邊的。

看到這里，其實我們可以認(rèn)為HBase是基于列族存儲的(畢竟物理存儲，一個列族是存儲到同一個Store里的)

 

 

Store里邊有啥?有Mem Store、Store File、HFile，我們再來看看里邊都代表啥含義。

 

 

HBase在寫數(shù)據(jù)的時候，會先寫到Mem Store，當(dāng)MemStore超過一定閾值，就會將內(nèi)存中的數(shù)據(jù)刷寫到硬盤上，形成StoreFile，而StoreFile底層是以HFile的格式保存，HFile是HBase中KeyValue數(shù)據(jù)的存儲格式。

所以說：Mem Store我們可以理解為內(nèi)存 buffer，HFile是HBase實際存儲的數(shù)據(jù)格式，而StoreFile只是HBase里的一個名字。

回到HRegionServer上，我們還漏了一塊，就是HLog。

 

 

這里其實特別好理解了，我們寫數(shù)據(jù)的時候是先寫到內(nèi)存的，為了防止機(jī)器宕機(jī)，內(nèi)存的數(shù)據(jù)沒刷到磁盤中就掛了。我們在寫Mem store的時候還會寫一份HLog。

這個HLog是順序?qū)懙酱疟P的，所以速度還是挺快的(是不是有似曾相似的感覺)...

稍微總結(jié)一把：

HRegionServer是真正干活的機(jī)器(用于與hdfs交互)，我們HBase表用RowKey來橫向切分表

HRegion里邊會有多個Store，每個Store其實就是一個列族的數(shù)據(jù)(所以我們可以說HBase是基于列族存儲的)

Store里邊有Men Store和StoreFile(HFile)，其實就是先走一層內(nèi)存，然后再刷到磁盤的結(jié)構(gòu)

3.5 被遺忘的HMaster

我們在上面的圖會看到有個Hmaster，它在HBase的架構(gòu)中承擔(dān)一種什么樣的角色呢?讀寫請求都沒經(jīng)過Hmaster呀。

 

 

那HMaster在HBase里承擔(dān)什么樣的角色呢??

• HMaster is the implementation of the Master Server. The Master server is responsible for monitoring all RegionServer instances in the cluster, and is the interface for all metadata changes.

HMaster會處理 HRegion 的分配或轉(zhuǎn)移。如果我們HRegion的數(shù)據(jù)量太大的話，HMaster會對拆分后的Region重新分配RegionServer。(如果發(fā)現(xiàn)失效的HRegion，也會將失效的HRegion分配到正常的HRegionServer中)

HMaster會處理元數(shù)據(jù)的變更和監(jiān)控RegionServer的狀態(tài)。

四、RowKey的設(shè)計

到這里，我們已經(jīng)知道RowKey是什么了。不難理解的是，我們肯定是要保證RowKey是唯一的，畢竟它是行鍵，有了它我們才可以唯一標(biāo)識一條數(shù)據(jù)的。

在HBase里邊提供了三種的查詢方式：

1. 全局掃描
2. 根據(jù)一個RowKey進(jìn)行查詢
3. 根據(jù)RowKey過濾的范圍查詢

4.1 根據(jù)一個RowKey查詢

首先我們要知道的是RowKey是會按字典序排序的，我們HBase表會用RowKey來橫向切分表。

無論是讀和寫我們都是用RowKey去定位到HRegion，然后找到HRegionServer。這里有一個很關(guān)鍵的問題：那我怎么知道這個RowKey是在這個HRegion上的?

HRegion上有兩個很重要的屬性：start-key和end-key。

我們在定位HRegionServer的時候，實際上就是定位我們這個RowKey在不在這個HRegion的start-key和end-key范圍之內(nèi)，如果在，說明我們就找到了。

這個時候會帶來一個問題：由于我們的RowKey是以字典序排序的，如果我們對RowKey沒有做任何處理，那就有可能存在熱點(diǎn)數(shù)據(jù)的問題。

舉個例子，現(xiàn)在我們的RowKey如下：

java3y111 
java3y222 
java3y333 
java3y444 
java3y555 
aaa 
bbb 
java3y777 
java3y666 
java3y... 

Java3yxxx開頭的RowKey很多，而其他的RowKey很少。如果我們有多個HRegion的話，那么存儲Java3yxxx的HRegion的數(shù)據(jù)量是最大的，而分配給其他的HRegion數(shù)量是很少的。

關(guān)鍵是我們的查詢也幾乎都是以java3yxxx的數(shù)據(jù)去查，這會導(dǎo)致某部分?jǐn)?shù)據(jù)會集中在某臺HRegionServer上存儲以及查詢，而其他的HRegionServer卻很空閑。

如果是這種情況，我們要做的是什么?對RowKey散列就好了，那分配到HRegion的時候就比較均勻，少了熱點(diǎn)的問題。

HBase優(yōu)化手冊：

建表申請時的預(yù)分區(qū)設(shè)置，對于經(jīng)常使用HBase的小伙伴來說,HBase管理平臺里申請HBase表流程必然不陌生了。

'給定split的RowKey組例如:aaaaa,bbbbb,ccccc;或給定例如:startKey=00000000,endKey=xxxxxxxx,regionsNum=x'

第一種方式:

是自己指定RowKey的分割點(diǎn)來劃分region個數(shù).比如有一組數(shù)據(jù)RowKey為[1,2,3,4,5,6,7],此時給定split RowKey是3,6,那么就會劃分為[1,3),[3,6),[6,7)的三個初始region了.如果對于RowKey的組成及數(shù)據(jù)分布非常清楚的話,可以使用這種方式精確預(yù)分區(qū).

第二種方式 :

如果只是知道RowKey的組成大致的范圍,可以選用這種方式讓集群來均衡預(yù)分區(qū),設(shè)定始末的RowKey,以及根據(jù)數(shù)據(jù)量給定大致的region數(shù),一般建議region數(shù)最多不要超過集群的rs節(jié)點(diǎn)數(shù),過多region數(shù)不但不能增加表訪問性能,反而會增加master節(jié)點(diǎn)壓力.如果給定始末RowKey范圍與實際偏差較大的話,還是比較容易產(chǎn)生數(shù)據(jù)熱點(diǎn)問題.

最后:生成RowKey時,盡量進(jìn)行加鹽或者哈希的處理,這樣很大程度上可以緩解數(shù)據(jù)熱點(diǎn)問題.

4.2根據(jù)RowKey范圍查詢

上面的情況是針對通過RowKey單個查詢的業(yè)務(wù)的，如果我們是根據(jù)RowKey范圍查詢的，那沒必要上面那樣做。

HBase將RowKey設(shè)計為字典序排序，如果不做限制，那很可能類似的RowKey存儲在同一個HRegion中。那我正好有這個場景上的業(yè)務(wù)，那我查詢的時候不是快多了嗎?在同一個HRegion就可以拿到我想要的數(shù)據(jù)了。

舉個例子：我們會間隔幾秒就采集直播間熱度，將這份數(shù)據(jù)寫到HBase中，然后業(yè)務(wù)方經(jīng)常要把主播的一段時間內(nèi)的熱度給查詢出來。

我設(shè)計好的RowKey，將該主播的一段時間內(nèi)的熱度都寫到同一個HRegion上，拉取的時候只要訪問一個HRegionServer就可以得到全部我想要的數(shù)據(jù)了，那查詢的速度就快很多。

最后

最后再來帶著大家回顧一下這篇文章寫了什么：

HBase是一個NoSQL數(shù)據(jù)庫，一般我們用它來存儲海量的數(shù)據(jù)(因為它基于HDFS分布式文件系統(tǒng)上構(gòu)建的)

HBase的一行記錄由一個RowKey和一個或多個的列以及它的值所組成。先有列族后有列，列可以隨意添加。

HBase的增刪改記錄都有「版本」，默認(rèn)以時間戳的方式實現(xiàn)。

RowKey的設(shè)計如果沒有特殊的業(yè)務(wù)性，最好設(shè)計為散列的，這樣避免熱點(diǎn)數(shù)據(jù)分布在同一個HRegionServer中。

HBase的讀寫都經(jīng)過Zookeeper去拉取meta數(shù)據(jù)，定位到對應(yīng)的HRegion，然后找到HRegionServer