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