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

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

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

1. 被索引的部分包含Row Key+Col Fam+Col Qual+Time Stamp
2. 因为HBase的Schema-Less和列式存储特性，列无需在表创建时定义好，能够动态加入。

   并且列名也存储在HFile中。用它来保存数据和用Cell value没有什么不同。

循序渐进实战

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

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

1. A用户关注哪些用户？
2. A用户是否关注B用户？
3. 谁关注了A用户？

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

 

最明显的问题有两个：

1. 当用户新增关注时，还须要进行查找当前已关注人。递增序号等逻辑。
2. 查找某个特定关注人效率一般。

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

宽表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()% 
     
      byte[] rowkey = Bytes.add(Bytes.toBytes(salt)\
+ Bytes.toBytes("|") + Bytes.toBytes(timestamp));
     

生成的Rowkey例如以下。查询处理变得略微复杂些，须要在应用端合并处理。

0|timestamp10|timestamp50|timestamp61|timestamp21|timestamp92|timestamp42|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'} 

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代表详细比較逻辑。常见的有字符串比較、正则匹配和二进制比較等。