HBase数据模型和表设计

术语

Table

• Hbase的table由多个行组成。

Row

• 一个行在Hbase中由一个或多个有值的列组成。Row按照字母进行排序，因此行键的设计非常重要。这种设计方式可以让有关系的行非常的近，通常行键的设计是网站的域名反转，比如(org.apache.www, org.apache.mail, org.apache.jira)，这样的话所有的Apache的域名就很接近。

Column Family（列簇或列族）

• 列簇在物理上包含了许多的列与列的值，每个列簇都有一些存储的属性可配置。例如是否使用缓存，压缩类型，存储版本数等。在表中，每一行都有相同的列簇，尽管有些列簇什么东西也没有存。

Column

• 列由列簇加上列的标识组成，一般是“列簇：列标识”，创建表的时候不用指定列名（列标识）

Column Qualifier

• 列簇的限定词，理解为列的唯一标识。但是列标识是可以改变的，因此每一行可能有不同的列标识

Cell

• Cell是由row，column family,column qualifier包含时间戳与值组成的，一般表达某个值的版本。

Timestamp

• 时间戳一般写在value的旁边，代表某个值的版本号，默认的时间戳是写入数据的那一刻，也可以在写入数据的时候指定不同的时间戳

标识设计要点

• 只要是数据库都存在，模式设计的问题，关系型中有模式设计的范式，Hbase作为列式存储数据库，其模式设计也非常重要。

hbase与关系型数据库对比

属性	hbase	RDBMS
数据类型	只有字符串	丰富的数据类型
数据操作	增删改查，不支持join	各种各样的函数与表连接
存储模式	基于列式存储	基于表结构和行式存储
数据保护	更新后仍然保留旧数据	数据替换
可伸缩性	轻易增加节点	需要中间层，牺牲性能

设计时考虑因素

• Hbase关键概念：表，rowkey，列簇，时间戳
  • 这个表应该有多少列簇
  • 列簇使用什么数据
  • 每个列簇有有多少列
  • 列名是什么，尽管列名不必在建表时定义，但读写数据是要知道的
  • 单元应该存放什么数据
  • 每个单元存储多少时间版本
  • 行键(rowKey)结构是什么，应该包含什么信息

设计要点

行键rowkey设计

• 说明
  • 行键是关键部分，直接关系到后续服务的访问性能。如果行键设计不合理，后续查询服务效率会成倍的递减。
• 细节
  • rowkey全局唯一，如果重复添加数据会覆盖。
  • 避免单调的递增行键，因为Hbase的行键是有序排列的，这样可能导致一段时间内大部分写入集中在某一个Region上进行操作，负载都在一台节点上。可以设计成： [metric_type][event_timestamp]，不同的metric_type可以将压力分散到不同的region上
  • 行键短到可读即可，因为查询短键比长键性能好些，所以设计时要权衡长度，最好不要超过16个字节。
  • 行键不能改变，唯一可以改变的方式是先删除后插入

列簇设计

• 说明
  • 列簇是一些列的集合，一个列簇的成员有相同的前缀，以冒号(:)作为分隔符。
• 细节
  • 当前Hbase不能很好处理2~3个以上的列簇，所以尽可能让列簇少一些，如果表有多个列簇，列簇A有100万行数据，列簇B有10亿行，那么列簇A会分散到很多的Region导致扫描列簇A的时候效率底下。
  • 列簇名的长度要尽量小，一个为了节省空间，另外加快效率，比如d表示data，v表示value

列簇属性

• HFile数据块，默认是64KB，数据库数据的大小影响数据块索引的大小。数据块大的话一次加载进内存的数据越多，扫描查询效果越好。但是数据块小的话，随机查询性能更好
• 数据块缓存，数据块缓存默认是打开的，如果一些比较少访问的数据可以选择关闭缓存
• 数据压缩，压缩会提高磁盘利用率，但是会增加CPU的负载，看情况进行控制

总结

• 了解hbase设计是影响hbase查询效率的关键因素，信息的排列方式，决定数据的聚集性，使用时根据实际场景设计，如数据多对一时，增加索引表，实现多种信息规则关联。如复杂计算过滤查询，可使用Elasticsearch作为hbase查询入口。
• 实践出真知，任何理论知识必须经历实际场景的考验，才能真正学会，融汇贯通。