hbase属于什么技术

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作为底层存储解决你的问题。