本章以山寨版Twitter为例介绍HBase Schema设计模式。广义的HBase Schema设计不只包括创建表时指定项，还应该综合考虑Column families/Column qualifier/Cell value/Versions/Rowkey等相关内容。
灵活的Schema&简单的存储视图
Schema设计和数据存储及访问模式关系密切，先回顾下HBase数据模型，有几个要点：
- 被索引的部分包括Row Key+Col Fam+Col Qual+Time Stamp
- 由于HBase的Schema-Less和列式存储特性，列无需在表创建时定义好，可以动态添加。而且列名也存储在HFile中，用它来保存数据和用Cell value没有什么不同。
循序渐进实战
Schema设计的首要切入点是为待解决的问题建模。下文从逐步完善Twitter用户关系表的过程中总结相关设计原则。
用户关系表follows要回答的问题包括：
- A用户关注哪些用户？
- A用户是否关注B用户？
- 谁关注了A用户？
最初版设计如下，以用户为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>生成的Rowkey如下，查询处理变得稍微复杂些，需要在应用端合并处理。
byte[] rowkey = Bytes.add(Bytes.toBytes(salt)\ + Bytes.toBytes("|") + Bytes.toBytes(timestamp));
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',5. TTL：用于自动清理过期数据
{NAME=> 'colfam1', BLOOMFILTER => 'ROWCOL'}
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代表具体比较逻辑，常见的有字符串比较、正则匹配和二进制比较等。