hbase屬于什么技術?HBase – Hadoop Database，是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統，利用HBase技術可在廉價PC Server上搭建起大規模結構化存儲集群。

HBase是Google BigTable的開源實現，類似Google BigTable利用GFS作為其文件存儲系統，HBase利用Hadoop HDFS作為其文件存儲系統;Google運行MapReduce來處理Bigtable中的海量數據，HBase同樣利用Hadoop MapReduce來處理HBase中的海量數據;Google Bigtable利用 Chubby作為協同服務，HBase利用Zookeeper作為對應。

Hbase的特點

1、海量存儲，Hbase適合存儲PB級別的海量數據，在PB級別的數據以及采用廉價PC存儲的情況下，能在幾十到百毫秒內返回數據，因為Hbase良好的擴展性，才為海量數據的存儲提供了便利。

2、列式存儲，這里的列式存儲其實說的是列族存儲，Hbase是根據列族來存儲數據的。列族下面可以有非常多的列，列族在創建表的時候就必須指定。

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

4、高并發，由于目前大部分使用Hbase的架構，這里說的高并發，主要是在并發的情況下，Hbase的單個IO延遲下降并不多。能獲得高并發、低延遲的服務。

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

使用場景

HBase并不適合所有場景

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

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

再次，硬件方面。確信你有足夠硬件。比如由于HDFS 的默認副本是3，所以一般至少5個數據節點才能夠發揮其特性，另外 還要加上一個 NameNode節點。

最后，數據分析方面。數據分析是HBase的弱項，因為對于HBase乃至整個NoSQL生態圈來說，基本上都是不支持表關聯的。如果主要需求是數據分析，比如做報表，顯然HBase是不太合適的。

什么時候使用 HBase

HBase作為一款NoSQL數據庫，前面也提及了并不能解決所有問題。關于我們在實際生產過程中滿足哪些條件的時候可以選擇HBase作為底層存儲，這里給出幾點建議：

1、數據量規模非常龐大

一般而言，單表數據量如果只有百萬級或者更少，不是非常建議使用HBase而應該考慮關系型數據庫是否能夠滿足需求;單表數據量超過千萬或者十億百億的時候，并且伴有較高并發，可以考慮使用HBase。這主要是充分利用分布式存儲系統的優勢，如果數據量比較小，單個節點就能有效存儲的話則其他節點的資源就會存在浪費。

2、要求是實時的點查詢

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

3、能夠容忍NoSQL短板

前面提及了NoSQL并不能解決所有問題，HBase也是一樣，如果業務場景是需要事務支持、表與表的關聯查詢等，不建議使用HBase。HBase有它適合的業務場景，我們不能苛求它能夠幫我們解決所有問題。

4、數據分析需求并不多

雖然說HBase是一個面向列的數據庫，但它有別于真正的列式存儲系統比如Parquet、Kudu等，再加上自身存儲架構的設計，使得HBase并不擅長做數據分析，或者說數據分析是HBase的弱項，所以如果主要的業務需求就是為了做數據分析，比如做報表，那么不建議直接使用HBase。

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