一、Hbase 数据模型概述
HBase的数据模型也是由表组成，每一张表里也有数据行和列，但是在HBase数据库中的行和列又和关系型数据库的稍有不同。
表(Table): HBase会将数据组织成一张表，表名必须是能用在文件路径里的合法名字，因为HBase的表是映射成hdfs上面的文件，Hbase的表及表中的数据都是以二进制字节进行存储；
行(Row): 在表里面，每一行都是以一个行键（Row Key）来进行唯一标识的，行键并没有什么特定的数据类型，以二进制的字节来存储。
列族(Column Family): 列族是Hbase Schema定义的一部分，列不是，列族一旦确定后，就不能轻易修改，因为它会影响到HBase真实的物理存储结构，但是列族中的列标识(Column Qualifier)以及其对应的值可以动态增删。表中的每一行都有相同的列族，但是不需要每一行的列族里都有一致的列标识(Column Qualifier)和值，所以说是一种稀疏的表结构，这样可以一定程度上避免数据的冗余；
列标识(Column Qualifier): 列族中的数据通过列标识来进行映射，即为一个键值对,Column Qualifier就是Key，值是value；
单元(Cell): 每一个行键，列族和列标识共同组成一个单元，存储在单元里的数据称为单元数据；
时间戳(Timestamp): 默认下每一个单元中的数据插入时都会用时间戳来进行版本标识。读取单元数据时，如果时间戳没有被指定，则默认返回最新的数据，写入新的单元数据时，如果没有设置时间戳，默认使用当前时间。每一个列族的单元数据的版本数量都被HBase单独维护，默认情况下HBase保留3个版本数据。
Hbase一定程度上又可以看成一个多维度的Map模型去理解它的数据模型。即以行键(Row Key),列标识(column qualifier),时间戳(timestamp)标识的有序Map数据结构的数据库，具有稀疏，分布式，持久化，多维度等特点。正如下图，一个行键映射一个列族数组，列族数组中的每个列族又映射一个列标识数组，列标识数组中的每一个列标识(Column Qualifier)又映射到一个时间戳数组，里面是不同时间戳映射下不同版本的值，但是默认取最近时间的值，所以可以看成是列标识(Column Qualifier)和它所对应的值的映射。用户也可以通过HBase的API去同时获取到多个版本的单元数据的值。Row Key在HBase中也就相当于关系型数据库的主键，并且Row Key在创建表的时候就已经设置好，用户无法指定某个列作为Row Key。
HBase也可以看成是一个类似Redis那样的Key-Value数据库。如下图，当你要查询某一行的所有数据时，Row Key就相当于Key，而Value就是单元中的数据(列族，列族里的列和列中时间戳所对应的不同版本的值)；用户要查询指定行里某一条单元数据时，HBase会去读取一个数据块，里面除了有要查询的单元数据，可能同时也会获取到其它单元数据，因为这个数据块还包含着这个Row Key所对应的其它列族或其它的列信息，这些信息实际也代表着另一个单元数据，这也是HBase的API内部实际的工作原理。
HBase提供了丰富的API接口让用户去操作这些数据。主要的API接口有3个，Put，Get，Scan。Put和Get是操作指定行的数据的，所以需要提供行键来进行操作。Scan是操作一定范围内的数据，通过指定开始行键和结束行键来获取范围，如果没有指定开始行键和结束行键，则默认获取所有行数据。
在HBase表设计中最重要的就是定义Row-Key的结构，要定义Row-Key的结构时要紧密结合实际业务应用场景，对这张表出现什么样的读写场景。除此之外，在设计表的时候我们也应该要考虑HBase数据库的一些特性。
1. HBase中表的索引是通过Key来实现的
2. 在表中是通过Row Key的字典序来对一行行的数据来进行排序的，表中每一块区域的划分都是通过开始Row Key和结束Row Key来决定的。
3. 所有存储在HBase表中的数据都是二进制的字节，并没有数据类型。
4. 原子性只在行内保证，HBase表中并没有多行事务。
5. 列族(Column Family)在表创建之前就要定义好
6. 列族中的列标识(Column Qualifier)可以在表创建完以后动态插入数据时添加。
二、Hbase 表设计示例
业务场景描述
设计一张表，用来保存微博上用户互粉的信息。
读场景业务要求
1. 每个用户都关注了谁
2. 用户A有没有关注用户B
3. 谁关注了用户A
写场景业务要求
1. 用户关注了另一个用户
2. 用户取消关注某个用户
初始表结构设计方案
每一行代表着某个用户和所有他所关注的其它用户。这个用户ID作为Row Key，一个列族follows,而每一个列标识(Column Qualifier)就是这个用户所关注的其他用户在列族里的序号，单元数据就是这个用户所关注的其他用户的用户ID。在这种表结构的设计下，“每个用户都关注了谁”这个问题很好解决，但对于“用户A有没有关注用户B”这个问题在列很多的时候，需要遍历A用户所在Row的所有单元数据去找到用户B，这样的开销会十分大。并且当添加新的被关注用户时，因为不知道给这个新用户分配什么样的列族序号，需要遍历整个列族中的所有列找出最后一个列，并将最后一个列的序号+1给新的被关注用户作为列族内的序号，这样的开销也十分大。
改进列族序号方案
在初始方案的基础上，添加一个counter记录列族中所有列的总数量，当添加新的被关注用户时，这个新用户的序号就是counter+1。但是当要取消关注某个用户时，一样得遍历所有的列数据，而且最大的问题是在于HBase不支持事务处理，这种通过counter来添加被关注用户的操作逻辑得写在客户端中。
改进列表识方案
列标识(Column Qualifier)存储的时候是二进制的字节，可以存储任何数据，而且列标识还是动态增添的，基于这个特性我们再改进表的设计，如下图。这次以被关注的用户ID做为列标识(Column Qualifier)，然后单元数据可以是任意数字，比如全部统一成1。在这种表结构的设计下，添加新的被关注者，以及取消关注都会变得很简单。但是对于读场景中，谁关注了用户A这个问题，因为HBase数据库的索引只建立在Row Key上，这里不得不扫描全表去统计所有关注了用户A的用户数量。
综合优化方案
将Row Key设计成“followerID+followedID”的形式，比如：“Jame+Emma”，这里的Row Key值就代表着Jame关注了Emma(其实这里应该是“Jame的ID+Emma的ID”，只是为了解释方便而直接用名字)，同时包含了关注者和被关注者两个信息；还需要注意的一点就是列族的名字被设计成只有一个字母f，这样设计的好处就是减少了HBase对数据的I/O操作压力，同时减少了返回到客户端的数据字节，提高响应速度，因为每一个返回给客户端的KeyValue对象都会包含列族名字。同时将被关注人的用户名称也保存在了表中作为Column Qualifier，这样做的好处就是节省了去用户表查找用户名的资源。在这种表结构设计下，“用户A取消关注某个用户B”，“用户A有没有关注用户B？”的业务处理就会变得简单高效。
RowKey加密处理
在实际的生产环境中，还需要将Row Key使用MD5加密，一方面是使Row Key的长度都一致，能提高数据的存取性能。
设计要点总结
- Row Key是HBase表结构设计中很重要的一环，它设计的好坏直接影响程序和HBase交互的效率和数据存储的性能。
- Base的表结构比传统关系型数据库更灵活，你能存储任何二进制数据在表中，而且无关数据类型。
- 在相同的列族中所有数据都具有相同的操作模式
- 主要是通过Row Key来建立索引
- 以纵向扩张为主设计的表结构能快速简单的获取数据，但牺牲了一定的原子性，就比如上文中最后一种表结构；而以横向扩张为主设计的表结构，也就是列族中有很多列，比如上文中第一种表结构，能在行里面保持一定的原子性。
- HBase并不支持事务，所有尽量在一次API请求操作中获取到结果
- 对Row Key的Hash优化能获得固定长度的Row Key并使数据分布更加均匀一些，而不是集中在一台服务器上，但是也牺牲了一定的数据排序和读取性能。
- 可以利用列标识(Column Qualifier)来存储数据。
- 列标识(Column Qualifier)名字的长度和列族名字的长度都会影响I/O的读写性能和发送给客户端的数据量，所以它们的命名应该简洁。
参考资料
http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/9353-login1210_khurana.pdf
https://blog.csdn.net/ymh198816/article/details/51244911
来源：oschina
链接：https://my.oschina.net/u/3967174/blog/2250165