HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，适用于结构化的存储，底层依赖于Hadoop的HDFS，利用HBase技术可在廉价PCServer上搭建起大规模结构化存储集群。因此HBase被广泛使用在大数据存储的解决方案中。
为何使用HBase
HBase的优点：
- 列可以动态增加，并且列为空就不存储数据，节省存储空间。
- Hbase自动切分数据，使得数据存储自动具有水平scalability。
- Hbase可以提供高并发读写操作的支持。
HBase的缺点：
- 不能支持条件查询，只支持按照Row key来查询。
- HBase并不适合传统的事物处理程序或关联分析，不支持复杂查询，一定程度上限制了它的使用，但是用它做数据存储的优势也同样非常明显。
因为HBase存储的是松散的数据，所以如果你的应用程序中，数据表每一行的结构是有差别的，那么可以考虑使用HBase。因为HBase的列可以动态增加，并且列为空就不存储数据，所以如果你需要经常追加字段，且大部分字段是NULL值的，那可以考虑HBase。因为HBase可以根据Rowkey提供高效的查询，所以如果你的数据（包括元数据、消息、二进制数据等）都有着同一个主键，或者你需要通过键来访问和修改数据，使用HBase是一个很好地选择。
HBase的数据结构
要使用HBase我们首先要了解HBase的数据结构：
HBase会存储系列的行记录，行记录有三个基本类型的定义：Row Key、Time Stamp、Column Family。
Row Key
与NoSQL数据库一样，Row Key是用来检索记录的主键。访问HBase table中的行，只有三种方式：
- 通过单个Row Key访问。
- 通过Row Key的range全表扫描。
- Row Key可以是任意字符串（最大长度是64KB，实际应用中长度一般为 10 ~ 100bytes），在HBase内部，Row Key保存为字节数组。
在存储时，数据按照Row Key的字典序（byte order）排序存储。设计Key时，要充分排序存储这个特性，将经常一起读取的行存储到一起（位置相关性）。
Column Family
HBase表中每个列都必须属于某个列族，列族必须作为表模式定义的一部分预先给出（有点像关系型数据库中的列名，定义完一般情况下就不会再去修改）；
列名以列族作为前缀，每个列族都可以有多个列成员。新的列族成员（也就是列）可以随后按需，动态加入。
Hbase把同一列族里面的数据存储在同一目录下，由几个文件保存。
Time Stamp
在HBase每个cell存储单元对同一份数据有多个版本，根据唯一的时间戳来区分每个版本之间的差异，不同版本的数据按照时间倒序排序，最新的数据版本排在最前面。
简述HBase的架构原理
1. HBase的模块
- Master
HBase Master用于协调多个Region Server，侦测各个Region Server之间的状态，并平衡Region Server之间的负载。HBase Master还有一个职责就是负责分配Region给Region Server。HBase允许多个Master 节点共存，但是这需要Zookeeper的帮助。不过当多个Master节点共存时，只有一个Master是提供服务的，其他的Master节点处于待命的状态。当正在工作的Master节点宕机时，其他的Master则会接管 HBase 的集群。
- Region Server
对于一个Region Server而言，其包括了多个Region。Region Server的作用只是管理表格，以及实现读写操作。Client 直接连接Region Server，并通信获取HBase中的数据。对于Region而言，则是真实存放HBase数据的地方，也就说Region是HBase可用性和分布式的基本单位。如果当一个表格很大，并由多个CF组成时，那么表的数据将存放在多个Region之间，并且在每个Region中会关联多个存储的单元（Store）。
- Zookeeper
对于HBase而言，Zookeeper的作用是至关重要的。首先Zookeeper是作为HBase Master的HA解决方案。也就是说，是Zookeeper保证了至少有一个HBase Master处于运行状态。并且Zookeeper负责Region和Region Server的注册。其实Zookeeper发展到目前为止，已经成为了分布式大数据框架中容错性的标准框架。不光是HBase，几乎所有的分布式大数据相关的开源框架，都依赖于Zookeeper实现HA。
2. HBase的原理
首先我们需要知道HBase的集群是通过Zookeeper来进行机器之前的协调，也就是说HBase Master与Region Server之间的关系是依赖Zookeeper来维护。当一个Client需要访问HBase集群时，Client需要先和Zookeeper来通信，然后才会找到对应的Region Server。每一个 Region Server管理着很多个Region。对于HBase来说，Region是HBase并行化的基本单元。因此，数据也都存储在Region中。
这里我们需要特别注意，每一个Region都只存储一个Column Family的数据，并且是该CF中的一段（按Row 的区间分成多个Region）。Region所能存储的数据大小是有上限的，当达到该上限时（Threshold），Region会进行分裂，数据也会分裂到多个Region中，这样便可以提高数据的并行化，以及提高数据的容量。
每个Region包含着多个Store对象。每个Store包含一个MemStore，和一个或多个HFile。MemStore便是数据在内存中的实体，并且一般都是有序的。当数据向Region写入的时候，会先写入MemStore。当MemStore中的数据需要向底层文件系统倾倒（Dump）时（例如MemStore中的数据体积到达MemStore配置的最大值），Store便会创建StoreFile，而StoreFile就是对HFile一层封装。所以MemStore中的数据会最终写入到HFile中，也就是磁盘IO。由于HBase底层依靠HDFS，因此HFile都存储在HDFS之中。这便是整个HBase工作的原理简述。
使用HBase时应注意的问题
基于Hbase的系统设计与开发中，需要考虑的因素不同于关系型数据库，Hbase模式本身很简单，但赋予你更多调整的空间，有一些模式写性能很好，但读取数据时表现不好，或者正好相反，类似传统数据库基于范式的OR建模，在实际项目中考虑Hbase设计模式是，我们需要从以下几方面内容着手：
- 这个表应该有多少个列簇
- 列簇使用什么数据
- 每个列簇应有多少个列
- 列名应该是什么，尽管列名不必在建表时定义，但是读写数据时是需要的
- 单元应该存放什么数据
- 每个单元存储什么时间版本
- 行健结构是什么，应该包括什么信息
总结
现如今各种数据存储方案层出不穷，本文仅仅是结合两个实战场景就基于HBase的大数据存储做了简单的分析，并对HBase的原理做了简单的阐述。如何使用好HBase，甚至于如何选择一个最优的数据存储方案，还需要我们根据场景需要具体分析和设计。
来源：oschina
链接：https://my.oschina.net/u/3730932/blog/4315266