hbase屬于什么技術(shù)?HBase – Hadoop Database，是一個(gè)高可靠性、高性能、面向列、可伸縮的分布式存儲(chǔ)系統(tǒng)，利用HBase技術(shù)可在廉價(jià)PC Server上搭建起大規(guī)模結(jié)構(gòu)化存儲(chǔ)集群。

HBase是Google BigTable的開源實(shí)現(xiàn)，類似Google BigTable利用GFS作為其文件存儲(chǔ)系統(tǒng)，HBase利用Hadoop HDFS作為其文件存儲(chǔ)系統(tǒng);Google運(yùn)行MapReduce來(lái)處理Bigtable中的海量數(shù)據(jù)，HBase同樣利用Hadoop MapReduce來(lái)處理HBase中的海量數(shù)據(jù);Google Bigtable利用 Chubby作為協(xié)同服務(wù)，HBase利用Zookeeper作為對(duì)應(yīng)。

Hbase的特點(diǎn)

1、海量存儲(chǔ)，Hbase適合存儲(chǔ)PB級(jí)別的海量數(shù)據(jù)，在PB級(jí)別的數(shù)據(jù)以及采用廉價(jià)PC存儲(chǔ)的情況下，能在幾十到百毫秒內(nèi)返回?cái)?shù)據(jù)，因?yàn)镠base良好的擴(kuò)展性，才為海量數(shù)據(jù)的存儲(chǔ)提供了便利。

2、列式存儲(chǔ)，這里的列式存儲(chǔ)其實(shí)說(shuō)的是列族存儲(chǔ)，Hbase是根據(jù)列族來(lái)存儲(chǔ)數(shù)據(jù)的。列族下面可以有非常多的列，列族在創(chuàng)建表的時(shí)候就必須指定。

3、極易擴(kuò)展，Hbase的擴(kuò)展性主要體現(xiàn)在兩個(gè)方面，一個(gè)是基于上層處理能力(RegionServer)的擴(kuò)展，一個(gè)是基于存儲(chǔ)的擴(kuò)展(HDFS)。

4、高并發(fā)，由于目前大部分使用Hbase的架構(gòu)，這里說(shuō)的高并發(fā)，主要是在并發(fā)的情況下，Hbase的單個(gè)IO延遲下降并不多。能獲得高并發(fā)、低延遲的服務(wù)。

5、稀疏，稀疏主要是針對(duì)Hbase列的靈活性，在列族中，你可以指定任意多的列，在列數(shù)據(jù)為空的情況下，是不會(huì)占用存儲(chǔ)空間的。

使用場(chǎng)景

HBase并不適合所有場(chǎng)景

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

其次，關(guān)系型數(shù)據(jù)庫(kù)特性方面。確信可以不依賴所有RDBMS的額外特性 (如列數(shù)據(jù)類型、二級(jí)索引、事務(wù)、高級(jí)查詢語(yǔ)言等) 。一個(gè)建立在RDBMS上應(yīng)用，并不能通過簡(jiǎn)單的改變JDBC驅(qū)動(dòng)就能遷移到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)閷?duì)于HBase乃至整個(gè)NoSQL生態(tài)圈來(lái)說(shuō)，基本上都是不支持表關(guān)聯(lián)的。如果主要需求是數(shù)據(jù)分析，比如做報(bào)表，顯然HBase是不太合適的。

什么時(shí)候使用 HBase

HBase作為一款NoSQL數(shù)據(jù)庫(kù)，前面也提及了并不能解決所有問題。關(guān)于我們?cè)趯?shí)際生產(chǎn)過程中滿足哪些條件的時(shí)候可以選擇HBase作為底層存儲(chǔ)，這里給出幾點(diǎn)建議：

1、數(shù)據(jù)量規(guī)模非常龐大

一般而言，單表數(shù)據(jù)量如果只有百萬(wàn)級(jí)或者更少，不是非常建議使用HBase而應(yīng)該考慮關(guān)系型數(shù)據(jù)庫(kù)是否能夠滿足需求;單表數(shù)據(jù)量超過千萬(wàn)或者十億百億的時(shí)候，并且伴有較高并發(fā)，可以考慮使用HBase。這主要是充分利用分布式存儲(chǔ)系統(tǒng)的優(yōu)勢(shì)，如果數(shù)據(jù)量比較小，單個(gè)節(jié)點(diǎn)就能有效存儲(chǔ)的話則其他節(jié)點(diǎn)的資源就會(huì)存在浪費(fèi)。

2、要求是實(shí)時(shí)的點(diǎn)查詢

HBase是一個(gè)Key-Value數(shù)據(jù)庫(kù)，默認(rèn)對(duì)Rowkey即行鍵做了索引優(yōu)化，所以即使數(shù)據(jù)量非常龐大，根據(jù)行鍵的查詢效率依然會(huì)很高，這使得HBase非常適合根據(jù)行鍵做單條記錄的查詢。值得說(shuō)明的是，允許根據(jù)行鍵的一部分做范圍查詢，這里涉及到Rowkey的設(shè)計(jì)問題，不再贅言。

3、能夠容忍N(yùn)oSQL短板

前面提及了NoSQL并不能解決所有問題，HBase也是一樣，如果業(yè)務(wù)場(chǎng)景是需要事務(wù)支持、表與表的關(guān)聯(lián)查詢等，不建議使用HBase。HBase有它適合的業(yè)務(wù)場(chǎng)景，我們不能苛求它能夠幫我們解決所有問題。

4、數(shù)據(jù)分析需求并不多

雖然說(shuō)HBase是一個(gè)面向列的數(shù)據(jù)庫(kù)，但它有別于真正的列式存儲(chǔ)系統(tǒng)比如Parquet、Kudu等，再加上自身存儲(chǔ)架構(gòu)的設(shè)計(jì)，使得HBase并不擅長(zhǎng)做數(shù)據(jù)分析，或者說(shuō)數(shù)據(jù)分析是HBase的弱項(xiàng)，所以如果主要的業(yè)務(wù)需求就是為了做數(shù)據(jù)分析，比如做報(bào)表，那么不建議直接使用HBase。

如果能夠滿足上訴的幾點(diǎn)，硬件條件也滿足的情況下，強(qiáng)烈建議考慮使用HBase作為底層存儲(chǔ)解決你的問題。