引言
hbase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，适用于结构化的存储，底层依赖于hadoop的hdfs，利用hbase技术可在廉价pcserver上搭建起大规模结构化存储集群。因此hbase被广泛使用在大数据存储的解决方案中。
为何使用hbase
hbase的优点：
列可以动态增加，并且列为空就不存储数据，节省存储空间。
hbase自动切分数据，使得数据存储自动具有水平scalability。
hbase可以提供高并发读写操作的支持。
hbase的缺点：
不能支持条件查询，只支持按照row key来查询。
hbase并不适合传统的事物处理程序或关联分析，不支持复杂查询，一定程度上限制了它的使用，但是用它做数据存储的优势也同样非常明显。
因为hbase存储的是松散的数据，所以如果你的应用程序中，数据表每一行的结构是有差别的，那么可以考虑使用hbase。因为hbase的列可以动态增加，并且列为空就不存储数据，所以如果你需要经常追加字段，且大部分字段是null值的，那可以考虑hbase。因为hbase可以根据rowkey提供高效的查询，所以如果你的数据(包括元数据、消息、二进制数据等)都有着同一个主键，或者你需要通过键来访问和修改数据，使用hbase是一个很好地选择。
如何使用hbase
场景一：卖家操作日志
卖家操作日志，顾名思义是用来记录商家操作的系统，从而可以保证商家可以精确查询自己的各种操作。京东有几十万的商家时时刻刻的进行着各种操作，因此卖家操作日志的特点是：数据量大、实时性强、增多查少。
图1
图2
我们在做卖家操作日志初期，将所有的操作日志存放在es中，操作日志的数据量是非常大的，但尴尬的是我们当时所能申请到的es资源有限。当把大量的数据存储到有限的es集群中时便导致了性能的下降。在这种情况下，我们选择了只在es集群中存储最近三个月的数据，对其提供灵活的查询，而长期的数据存储使用hbase来进行。这样的话我们便可以实现对近期操作灵活展现，对长期数据也有精确备份。
场景二：京麦消息日志的存储
京麦消息日志的存储是属于京麦筋斗云系统(用于打造京麦消息生态系统闭环)不可或缺的一部分。其中包含消息的全链路追踪以及消息的统计分析。京麦消息每天都会有几千万的消息量，如何对消息进行追踪和统计便成为了一个至关重要的问题。消息追踪要求实时性、多维度精确查询，因此我们选择将最近一周的消息日志存储在es。统计分析要求我们有足够多的数据，因此我们在将数据存储在es中的同时也存储在hbase中一份。最终再定期将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，甚至于如何选择一个最优的数据存储方案，还需要我们根据场景需要具体分析和设计。
作者：张松然
来源：51cto