读书笔记-HBase in Action-第二部分Advanced concepts-(1)HBase table design


本章以山寨版Twitter为例介绍HBase Schema设计模式。广义的HBase Schema设计不只包括创建表时指定项，还应该综合考虑Column families/Column qualifier/Cell value/Versions/Rowkey等相关内容。

灵活的Schema&简单的存储视图

Schema设计和数据存储及访问模式关系密切，先回顾下HBase数据模型，有几个要点：


循序渐进实战

Schema设计的首要切入点是为待解决的问题建模。下文从逐步完善Twitter用户关系表的过程中总结相关设计原则。

用户关系表follows要回答的问题包括：

最初版设计如下，以用户为rowkey，follows列族中包含多个列，每个列名为序号，存储的值为关注用户。

 

最明显的问题有两个：

改进如下，将关注人直接作为列名：


宽表VS窄表

之前的设计为宽表模式，一行记录包含了用户所有关注人。如果使用窄表，Schema如下：

      

 窄表设计最大的优点是能通过rowkey查找高效回答之前的问题2：A用户是否关注用户B。而问题1：A用户关注哪些用户，则变成了扫描操作，但从HBase底层列式存储看，I/O读取数据量是一样的（get操作内部实现为针对单行的scan操作）。代码片段如下：

Scan s = new Scan();s.addFamily(Bytes.toBytes("f")); 
s.setStartRow(Bytes.toBytes("A"));
s.setStopRow(Bytes.toBytes("A"+ 1));
ResultScanner results = followsTable.getScanner(s);

窄表带来的最大问题是，HBase只有单行操作才是原子性的。假设用户新关注了多个用户，在宽表中能通过一次Put原子操作完成，而在窄表操作中则需要多次操作。

注：回答问题3，谁关注了A用户，可以再建一张被关注用户表，rowkey为followed+follower。由应用端维护两张表数据一致性。

Rowkey设计

使用Hash rowkey有助于数据在regionserver之间均匀分布，一般可以使用MD5获取定长key。


比较棘手的一个场景是在时间序列数据中，使用时间戳作为rowkey，那么你始终在表底部插入数据，由于rowkey的有序性存储，表的最后一个region成为热点。而应用又需要根据时间范围进行扫描查询，所以不能简单将时间戳Hash，这时可以考虑“Salting”方法：

int salt = new Integer(new Long(timestamp).hashCode()).shortValue()% <number of region servers>
byte[] rowkey = Bytes.add(Bytes.toBytes(salt)\
+ Bytes.toBytes("|") + Bytes.toBytes(timestamp));
生成的Rowkey如下，查询处理变得稍微复杂些，需要在应用端合并处理。

0|timestamp1
0|timestamp5
0|timestamp6
1|timestamp2
1|timestamp9
2|timestamp4
2|timestamp8

反规范化

上节中，Rowkey包含了被关注人ID，CQ中存储被关注人名称，而不用再join用户表查询，已经是某种程度的反规范化。

 

由于HBase列的动态性，可以用单个HBase表使用嵌套列来表达数据库中一对多关系（类似于MongoDB文档模型）。

继续以twitter为例，假设已经有follows和twits表，那么用户登录后，通过follows读取关注人信息，然后从twits表中根据第一步读取的用户ID读取关注人的twits，最后合并取最新结果展现在用户首页。可以考虑增加一张冗余表用来存储用户首页上展示的twits，Rowkey为登录用户+倒序时间戳，存储所关注人的最新twits。该表提供了更好的读取性能，还能解决一个常见问题：某大V帐号被海量用户关注，如果不使用冗余表，他的twits数据所在的regionserver将成为热点，可能导致性能瓶颈。


该表的数据生成可以通过coprocessor实现（下章介绍，类似于数据库的触发器），数据保留由TTL实现（Time To Live，下节介绍）

Column family配置

HBase提供了一些配置参数，在创建表时可以按需定制。

1.       HFile block size：和HDFS block size不同，默认大小是64KB。Block索引存储了每个block的起始key，所以block size大小会影响索引大小。如果你的应用偏重于随机查找，可以选择小一点的block size；如果侧重于顺序扫描，那么可以使用较大的block size。

hbase(main):002:0> create'mytable', {NAME => 'colfam1', BLOCKSIZE => '65536'}

2.       Block cache：顺序扫描场景下block cache不是那么重要，可以禁用cache，将内存空间留给其他表或者列族。

hbase(main):002:0> create'mytable',
{NAME => 'colfam1', BLOCKCACHE => 'false’}

3.       Aggressive caching：为某些列族设置更高的block cache优先级，HBase会更积极地将其保留在LRU cache中。

hbase(main):002:0> create'mytable', {NAME => 'colfam1', IN_MEMORY => 'true'}

4.       Bloom filters：block索引中只存储了block的起始key，默认block size为64KB，如果表中每行数据都偏小，那么一个block中记录行数过多，可能会出现辛苦查找半天，发现所查找数据不存在的情况。通过Bloom filter引入negative test能快速判断数据是否存在

hbase(main):007:0>create 'mytable',
{NAME=> 'colfam1', BLOOMFILTER => 'ROWCOL'}
5.       TTL：用于自动清理过期数据 

hbase(main):002:0>create 'mytable', {NAME => 'colfam1', TTL => '18000'}

6.       Compression：Google发布的Snappy格式是个好选择。

hbase(main):002:0>create 'mytable',
{NAME => 'colfam1', COMPRESSION => 'SNAPPY'}<span style="font-family: Arial, Helvetica, sans-serif;"> </span>

7.       Cell versioning：默认为3.

base(main):002:0>create 'mytable', {NAME => 'colfam1', VERSIONS => 1}

Filter过滤器

Filter作用在RegionServer上，数据依然会从磁盘加载到RegionServer，所以Filter一般减少的是网络I/O，而不是硬盘I/O（有一些Filter能减少硬盘数据读取，比如ColumnPrefixFilter）。

HBase提供了Filter接口，用户实现接口可以自定义过滤功能。其中的过滤方法回调顺序如下：


HBase还预置了一些filter。典型的如RowFilter

public RowFilter(CompareOprowCompareOp, WritableByteArrayComparable rowComparator)

其中CompareOp代表比较操作符枚举类，比如相等、大于和小于等。Comparator代表具体比较逻辑，常见的有字符串比较、正则匹配和二进制比较等。

相关内容