【51CTO.com原創(chuàng)稿件】 Apache HBase 是 Hadoop 的大數(shù)據(jù)存儲(chǔ)數(shù)據(jù)庫(kù)，一個(gè)分布式、可伸縮的大數(shù)據(jù)存儲(chǔ)，是依賴(lài) Hadoop。

[[398652]]

圖片來(lái)自 Pexels

HBase 該技術(shù)來(lái)源于 Fay Chang 所撰寫(xiě)的 Google 論文“Bigtable：一個(gè)結(jié)構(gòu)化數(shù)據(jù)的分布式存儲(chǔ)系統(tǒng)”。

就像 Bigtable 利用了 Google 文件系統(tǒng)(File System)所提供的分布式數(shù)據(jù)存儲(chǔ)一樣，HBase 在 Hadoop 之上提供了類(lèi)似于 Bigtable 的能力。

BATJ 公司為什么用 HBase 能存儲(chǔ)海量的數(shù)據(jù)?

• 因?yàn)?HBase 是在 HDFS 的基礎(chǔ)之上構(gòu)建的，HDFS 是分布式文件系統(tǒng)。
• Hbase 設(shè)計(jì)上屬于列式存儲(chǔ)，在存儲(chǔ)上將業(yè)務(wù)的數(shù)據(jù)按照水平分割的模式來(lái)劃分，因此在查詢(xún)與插入的時(shí)候比較聚焦。
• HBase 不同于一般的關(guān)系數(shù)據(jù)庫(kù)，它是一個(gè)適合于非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)庫(kù)，特別是 HBase 基于列的而不是基于行的模式存儲(chǔ)

為什么要用 HBase

①分布式存儲(chǔ)引擎分類(lèi)

分布式存儲(chǔ)引擎大概分類(lèi)如下：

• 分布式搜索(Elasticsearch)
• 分布式文件系統(tǒng)(HDFS)
• 分布式消息隊(duì)列(Kafka)
• 緩存數(shù)據(jù)庫(kù)(Redis)
• 非關(guān)系型分布式數(shù)據(jù)庫(kù)(Hbase\Mongodb\Cloudant)
• 等等...

②存儲(chǔ)引擎的存儲(chǔ)方式

存儲(chǔ)引擎的存儲(chǔ)方式如下：

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

這些中間件都能夠?qū)崿F(xiàn)持久化(比如 HDFS 和 MySQL 我們本身就用來(lái)存儲(chǔ)數(shù)據(jù)的)，那用 HBase 干啥呢?

③各種存儲(chǔ)引擎優(yōu)缺點(diǎn)

HDFS 可以保存海量數(shù)據(jù)，容錯(cuò)性高，適合批處理，適合保存大量數(shù)據(jù)，可以流式數(shù)據(jù)訪問(wèn)，對(duì)于服務(wù)器的要求也不高，但是他也有一些不足如，不適合低延時(shí)數(shù)據(jù)訪問(wèn)。

比如毫秒級(jí)的存儲(chǔ)數(shù)據(jù)，是做不到的，也沒(méi)辦法高效的對(duì)大量小文件進(jìn)行保存處理，而且一個(gè)文件只能有一個(gè)線程寫(xiě)入，不允許多個(gè)線程同時(shí)寫(xiě)入，也不支持文件的隨機(jī)修改。

MySQL 是我們?nèi)粘Ｖ杏玫谋容^多的關(guān)系型數(shù)據(jù)庫(kù)了，但是大家都知道 MySQL，他是單機(jī)的。

單機(jī) MySQL 他最大的容量，完全取決于服務(wù)器的硬盤(pán)容量的大小。其最致命的弱點(diǎn)就是當(dāng)有大量數(shù)據(jù)需要存儲(chǔ)時(shí)，MySQL 很難扛得住。

Elasticsearch 大家都知道他是一個(gè)分布式搜索引擎，在搜索效率上還是比較快的。

因?yàn)?Elasticsearch 基于分布式所以理論上也是可以保存大量的數(shù)據(jù)的，我們也可以根據(jù)索引來(lái)取出來(lái)，那這就是我們心目中最完美的存儲(chǔ)方式了嗎?

不，他不是，因?yàn)槿绻覀兇鎯?chǔ)的數(shù)據(jù)沒(méi)有經(jīng)常需要查詢(xún)的需求，其實(shí)放到 Elasticsearch 就是一種浪費(fèi)，因?yàn)閿?shù)據(jù)在寫(xiě)入 Elasticsearch 時(shí)需要進(jìn)行分詞，從而大量消耗資源，造成沒(méi)必要的浪費(fèi)。

Redis 是近幾年最常用的緩存數(shù)據(jù)庫(kù)，讀與寫(xiě)的操作都在內(nèi)存中進(jìn)行，其速度響應(yīng)非?？欤珹OF/RDB 保存的相關(guān)數(shù)據(jù)全會(huì)加載到我們機(jī)器的內(nèi)存中，從而導(dǎo)致 Redis 并不適合保存大量的數(shù)據(jù)，畢竟內(nèi)存還是相對(duì)有限。

Kafka 在我們項(xiàng)目工作中主要用來(lái)處理消息的解耦于異步削峰，當(dāng)數(shù)據(jù)到達(dá) Kafka，此時(shí)就會(huì)將數(shù)據(jù)持久化到服務(wù)器硬盤(pán)中，且很方便的擴(kuò)展因?yàn)樗欠植际降?，按照這個(gè)邏輯 Kafka 是可以存儲(chǔ)大量數(shù)據(jù)。

但是 Kafka 持久化了的數(shù)據(jù)，最常見(jiàn)的用法就是直接重新設(shè)置 offset 進(jìn)行操作。

④Hbase 的使用場(chǎng)景

Hbase 適合需對(duì)數(shù)據(jù)進(jìn)行隨機(jī)讀操作或者隨機(jī)寫(xiě)操作、大數(shù)據(jù)上高并發(fā)操作，比如每秒對(duì) PB 級(jí)數(shù)據(jù)進(jìn)行上千次操作以及讀寫(xiě)訪問(wèn)均是非常簡(jiǎn)單的操作。

淘寶指數(shù)是 Hbase 在淘寶的一個(gè)典型應(yīng)用。交易歷史紀(jì)錄查詢(xún)很適合用 Hbase 作為底層數(shù)據(jù)庫(kù)。

入門(mén) HBase

①HBase 特性

Hbase 作為一種 NoSQL 數(shù)據(jù)庫(kù)，而這就說(shuō)明他不是傳統(tǒng)的 RDBMS 數(shù)據(jù)庫(kù)，且 SQL 語(yǔ)句也是不支持的。

對(duì)于 Hbase 是一種分布式存儲(chǔ)的數(shù)據(jù)庫(kù)，在技術(shù)層面來(lái)講，它是屬于分布式存儲(chǔ)，因?yàn)槿鄙俸芏?RDBMS 數(shù)據(jù)庫(kù)的特性。

那 Hbase 有什么特點(diǎn)呢?如下：

大，他容量巨大，HBase 的單表可以有百億行、百萬(wàn)列，可以在橫向和縱向兩個(gè)維度插入數(shù)據(jù)，具有很大的彈性。

稀疏性，這主要體現(xiàn)在 Hbase 針對(duì)列有著很高的靈活性，比如對(duì)于為 NULL 的列中，是不會(huì)占用存儲(chǔ)空間的，所以表可以設(shè)計(jì)的很稀疏。

易擴(kuò)展，因?yàn)榍懊嫖乙仓v到過(guò) HBase 是工作在 HDFS 之上的，所以自然是支持分布式表，同時(shí)也繼承了 HDFS 的可擴(kuò)展性。

而且 HBase 的擴(kuò)展是橫向擴(kuò)展的，所謂的橫向擴(kuò)展是指在擴(kuò)展的時(shí)候不需要提高服務(wù)器性能，只需要添加服務(wù)器到現(xiàn)有的集群即可。

高并發(fā)，如果項(xiàng)目使用 Hbase 的架構(gòu)，那么使用的 PC 都可以很便宜，因此高 IO 也是常事。

而我所說(shuō)的高并發(fā)，主要是他和其他 NoSQL 一樣，Hbase 不支持復(fù)雜的 SQL 語(yǔ)句，這就給性能優(yōu)化帶來(lái)更多可能，并且主要是在內(nèi)存中工作，支持大并發(fā)應(yīng)該是沒(méi)問(wèn)題的。

還有別忘了，HBase 是天然支持分布式的，所以還可以利用集群等方法提高并發(fā)量。

高可用，還是因?yàn)?HBase 是運(yùn)行在 HDFS 上的，HDFS 的多副本存儲(chǔ)，類(lèi)似于 MySQL 主備容災(zāi)，他可以在岀現(xiàn)故障時(shí)自行恢復(fù)，同時(shí) HBase 還有更多的策略如：Replication，WAL 等。

面向列，這個(gè)與我們常用的 MySQL 等關(guān)系型數(shù)據(jù)庫(kù)不同，HBase 是面向列的存儲(chǔ)控制的。

簡(jiǎn)單來(lái)說(shuō)就是每個(gè)列他都是是單獨(dú)存儲(chǔ)的，而且支持直接對(duì)列來(lái)進(jìn)行查詢(xún)，下面這張圖可以簡(jiǎn)單來(lái)理解下什么是對(duì)列的操作。

從圖上來(lái)理解，看下下面的行存儲(chǔ)于列存儲(chǔ)其中行存儲(chǔ)是保存在一塊的，而列存儲(chǔ)中的數(shù)據(jù)是分割的。

由上圖得知行存儲(chǔ)更適合插入與更新，而查詢(xún)操作時(shí)需要讀取其中所有的數(shù)據(jù)，此時(shí) HBase 列存儲(chǔ)則只需要讀取相關(guān)列即可，從而可以大幅降低系統(tǒng) I/O 吞吐量，達(dá)到快速讀取的目的。

②什么情況更適合使用 Hbase

首先 Hbase 不是萬(wàn)能的，他也有不適合的場(chǎng)景，有哪些不適合場(chǎng)景呢?

這主要也是根據(jù)其特點(diǎn)來(lái)說(shuō)的，首先一點(diǎn)就是數(shù)據(jù)量要大，如果你的數(shù)據(jù)只有區(qū)區(qū)幾百萬(wàn)條或者更少的數(shù)據(jù)量，那么關(guān)系型數(shù)據(jù)庫(kù)可能更適合你。

因?yàn)閿?shù)據(jù)量不大的話，根本體現(xiàn)不出 HBase 的優(yōu)勢(shì)，反而會(huì)成為累贅，因?yàn)橛写罅康臋C(jī)器空閑，浪費(fèi)資源。

再一個(gè)就是你對(duì)于列查詢(xún)的使用不是那么高，且你也不需要輔助索引，靜態(tài)類(lèi)型的列等 HBase 的特性，在現(xiàn)有項(xiàng)目中使用關(guān)系型數(shù)據(jù)庫(kù)已經(jīng)可以滿足其需求，則你完全沒(méi)必要為了技術(shù)而去使用。

如果非要使用對(duì)于以往的項(xiàng)目你還需要重新去設(shè)計(jì)重構(gòu)等，帶來(lái)不必要的麻煩。

最后雖然 Hbase 在單機(jī)環(huán)境也能運(yùn)行，但是最好請(qǐng)?jiān)陂_(kāi)發(fā)環(huán)境的時(shí)候使用。

③HBase 的 Key-Value

HBase 其實(shí)就與 Redis 一樣是 Key-Value 的數(shù)據(jù)庫(kù)，那在 HBase 里邊，Key 是什么?Value 是什么?

首先 KeyValue 的概念設(shè)計(jì)源自一片論文為"The log-structured merge-tree(LSM-Tree)"。

其中的每一行，每一列的數(shù)據(jù)，都被獨(dú)立包裝成特定結(jié)構(gòu)即 KeyValue，而 KeyValue 還包含了很多自我描述信息從而會(huì)導(dǎo)致數(shù)據(jù)膨脹 。

目前市面上所有項(xiàng)目主要數(shù)據(jù)結(jié)構(gòu)有：

• 結(jié)構(gòu)化數(shù)據(jù)
• 半結(jié)構(gòu)化數(shù)據(jù)
• 非結(jié)構(gòu)化數(shù)據(jù)

由于 HBase 的稀疏性，導(dǎo)致其對(duì)于非結(jié)構(gòu)化的數(shù)據(jù)存儲(chǔ)有著天然的優(yōu)勢(shì)，而在我們?nèi)粘ｍ?xiàng)目中， 關(guān)系型數(shù)據(jù)也就是結(jié)構(gòu)化數(shù)據(jù)是經(jīng)常使用到的 。

由于 HBase 目前只能提供基于 RowKey 的單維度索，在我們?nèi)粘ｍ?xiàng)目中還是有些吃力。

還需要基于 HBase 添加一些特殊功能，如：

• GeoMesa 時(shí)空數(shù)據(jù)存儲(chǔ)
• JanusGraph 圖數(shù)據(jù)存儲(chǔ)
• OpenTSDB 時(shí)序數(shù)據(jù)存儲(chǔ)

既然如此，不如專(zhuān)業(yè)的事情交給專(zhuān)業(yè)的的去做，既然 MySQL，Oracle，MSSQL 這些關(guān)系型數(shù)據(jù)庫(kù)這么擅長(zhǎng)處理結(jié)構(gòu)化數(shù)據(jù)，那就讓他們來(lái)處理好了。

他們既然不擅長(zhǎng)處理海量非結(jié)構(gòu)化數(shù)據(jù)，那就上 HBase，所以我的理解 HBase 不是萬(wàn)能的，他只是相對(duì)于傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)的一種補(bǔ)充。

④HBase 架構(gòu)

HBase 架構(gòu)如上圖：

• Zookeeper，主要作用是分布式協(xié)調(diào)。
• RegionServer，作為數(shù)據(jù)節(jié)點(diǎn)，用于存儲(chǔ)數(shù)據(jù)，也會(huì)把自己的信息寫(xiě)到 ZooKeeper 中。
• HDFS，是在這里主要作為 HBase 的基礎(chǔ)，是一個(gè) 分布式文件系統(tǒng)，為 HBase 提供服務(wù)。
• Master，主要負(fù)責(zé)管理所有的 RegionServer，管理所有的 Region 到 RegionServer 的分配，且自身也可以作為一個(gè) RegionServer 提供服務(wù)。

其大概流程就是：

• client 請(qǐng)求到 Zookeeper。
• Zookeeper 返回 HRegionServer 地址給 client。
• 當(dāng) client 獲取到 Zookeeper 返回的地址就去請(qǐng)求 HRegionServer。
• HRegionServer 讀寫(xiě)數(shù)據(jù)后再返回給 client。

⑤HMaster 大作用

看上面的流程我好像沒(méi)有提到 HMaster，那 HMaster 是不是沒(méi)啥用?那他主要是做什么的呢?

其實(shí)他的作用是不能被忽略的有：

• 負(fù)責(zé) Region server 分布式管理與負(fù)載均衡
• 為 Region server 分配 region
• 在 HRegion 分裂后，負(fù)責(zé)新 HRegion 的分配
• 將 HDFS 上的垃圾文件回收
• 處理 schema 更新請(qǐng)求

由此可以看來(lái) HMaster 相當(dāng)于指揮家，統(tǒng)籌大局，非常重要!

RowKey 的設(shè)計(jì)

RowKey 在查詢(xún)和保存方面有著很重要的作用，HBase 中如果設(shè)計(jì)好一個(gè) RowKey 將會(huì)影響到其中數(shù)據(jù)的分布，與我們的查詢(xún)速度。

由此得知設(shè)計(jì)好一個(gè)優(yōu)秀的 RowKey 是非常重要的，那么這么重要的 RowKey 我們?nèi)绾蝸?lái)設(shè)計(jì)呢?

首先要遵從以下幾個(gè)原則：

長(zhǎng)度原則：最短越好，最短越好，最短越好，重要的事情說(shuō)三遍，最大不能超過(guò) 64K。如果太長(zhǎng)主要影響有兩點(diǎn)，

首先特別影響 HFile 的存儲(chǔ)效果。其次 MemStore 將緩存部分?jǐn)?shù)據(jù)到內(nèi)存，如果 RowKey 字段過(guò)長(zhǎng)，內(nèi)存的有效利用率就會(huì)降低，系統(tǒng)不能緩存更多的數(shù)據(jù)，這樣會(huì)降低檢索效率。

總結(jié)：保存慢，查詢(xún)慢!

唯一原則：這個(gè)應(yīng)該很好理解，RowKey 存儲(chǔ)結(jié)構(gòu)是 Key-Value 形式，跟 Java 中的 Map 一樣，如果向同一個(gè) Map 保存相同的 Key 的值，后保存的值會(huì)覆蓋掉之前保存的值。

排序原則：HBase 會(huì)把 RowKey 按照 ASCII 進(jìn)行自然有序排序，所以反過(guò)來(lái)我們?cè)谠O(shè)計(jì) RowKey 的時(shí)候可以根據(jù)這個(gè)特點(diǎn)來(lái)設(shè)計(jì)完美的 RowKey，好好的利用這個(gè)特性就是排序原則。

散列原則：如果 RowKey 按照時(shí)間戳的方式遞增，不要將時(shí)間放在二進(jìn)制碼的前面，建議將 RowKey 的高位作為散列字段，由程序隨機(jī)生成，低位放時(shí)間字段。

這樣將提高數(shù)據(jù)均衡分布在每個(gè) RegionServer，以實(shí)現(xiàn)負(fù)載均衡的幾率。

如果沒(méi)有散列字段，首字段直接是時(shí)間信息，所有的數(shù)據(jù)都會(huì)集中在一個(gè) RegionServer 上。

這樣在數(shù)據(jù)檢索的時(shí)候負(fù)載會(huì)集中在個(gè)別的 RegionServer 上，造成熱點(diǎn)問(wèn)題，會(huì)降低查詢(xún)效率。

①根據(jù) RowKey 模糊查詢(xún)

接下來(lái)直接上戰(zhàn)場(chǎng)，首先我們根據(jù)業(yè)務(wù)場(chǎng)景需求，肯定還是需要進(jìn)行在上 T 數(shù)據(jù)中查詢(xún)部分?jǐn)?shù)據(jù)的，那就是通過(guò) RowKey 的方式進(jìn)行模糊查詢(xún)。

hbase shell #首先登錄hbase 
list #查詢(xún)系統(tǒng)中所有數(shù)據(jù)庫(kù)表 
scan 'tablename',{STARTROW=>'rowkey1',STOPROW=>'rowkey2'} 

②根據(jù) RowKey 范圍查詢(xún)

這里演示的是時(shí)間范圍查詢(xún)，TIMERANGE 中的值為時(shí)間戳。

scan ‘tablename’,{TIMERANGE=>[1325654785652,1436524854295]} 

更多操作下次我在給大家出一篇關(guān)于 HBase 使用的相關(guān)文章進(jìn)行詳細(xì)講解。

HBase 調(diào)優(yōu)

①讀性能優(yōu)化

HBase 服務(wù)端優(yōu)化：

• 讀請(qǐng)求是否均衡?
• BlockCache 設(shè)置是否合理?
• 數(shù)據(jù)本地率是不是很低?
• HFile 文件是否太多?
• Compaction 是否影響太大?

HBase 客戶(hù)端優(yōu)化：

• scan 緩存是否設(shè)置合理?
• get 是否使用批量請(qǐng)求?
• 離線批量讀取請(qǐng)求是否設(shè)置禁止緩存?
• 請(qǐng)求是否可以顯示指定列簇或者列?

HBase 列簇優(yōu)化：

• 布隆過(guò)濾器是否設(shè)置?

②寫(xiě)性能優(yōu)化

HBase 服務(wù)端優(yōu)化：

• Region 是否太少?
• 寫(xiě)入請(qǐng)求是否均衡?

HBase 客戶(hù)端優(yōu)化：

• 是否可以使用 Bulkload 方案寫(xiě)入?
• 是否需要寫(xiě)入 WAL?
• WAL 是否需要同步寫(xiě)入?
• Put 是否可以同步批量提交?
• Put 是否可以異步批量提交?
• 寫(xiě)入 Key Value 數(shù)據(jù)是否太大?

大家可以帶著以上問(wèn)題去對(duì)自己的 HBase 逐個(gè)優(yōu)化。

參考資料：

• http://hbase.apache.org/

作者：劉永繼

簡(jiǎn)介：中國(guó)科學(xué)院大學(xué)博士，中國(guó)科學(xué)院信息工程所，主要從事大數(shù)據(jù)可視化，虛擬現(xiàn)實(shí)與數(shù)字孿生技術(shù)研究;精通 Java，Python 等主流的技術(shù)架構(gòu)，擅長(zhǎng)從架構(gòu)的角度思考及解決問(wèn)題。

編輯：陶家龍

征稿：有投稿、尋求報(bào)道意向技術(shù)人請(qǐng)?zhí)砑有【幬⑿?gordonlonglong 

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】