行健设计
HBase有两种基本键结构：行健(row key)和列键(column key)。两者都可以存储有意义的信息，这些信息可以分为两类，一种是键本身存储的内容，另一种是键的排列顺序。
时间序列
当处理流式事件时，最常见的数据就是按照时间序列组织的数据。由于HBase的数据组织方式，数据可能会被存储到一定的范围内，比如一个有特定起始键和停止键的region中。由于region只能由一个服务器管理，所以所有的更新都会集中在一台服务器上，这回导致系统产生读写热点，并由于写入数据过分集中而导致整个系统性能下降。
为了解决这个问题，用户需要将数据分散到所有的region服务器上去，由很多方法可以实现
salting 方式
使用salting前缀来保证数据分散到所有的region服务器。
但是这样做会当用户要扫描一个连续的范围时，可能需要对每个region server发起请求，不过用户也可以通过多线程并行的方式读取数据。
字段交换/提升权重
用户可以将时间戳字段以开或添加其他字段作为前缀。
随机化
将行健使用散列函数分散到所有的region server
这种方式比较适合每次只读一行数据的应用。
时间顺序关系
上述数据会按照差生的时间顺序以独立行插入到HBase中，但是也可以将新的事件以发生时间为列进行插入。
因为列在HBase中是按照列族组织的，所有每个列族下的列可以作为一个服务索引单独进行排序。
事务
在HBase中，一般并没有事务这个概念，但是对于系统而言，比如更新数据表和对应的辅助决策索引表时，就需要事务来保证一致性。对于用户而言，因为范式化的数据模式能够被转化成单个表的存储，因此不需要分布式事务的支持，同时也不需要为保证一致性而产生额外的开销。
但是，如果用户还是需要一致性支持，可以选择下述解决方案。
事务型HBase
比如选择带索引的事务型HBase(Indexed Transactional HBase)。
ZooKeeper
ZooKeeper提供了一个能够被用于实现两阶段提交协议的锁方案。它使用一个特定的znode来代表事务，并且每个参与的客户端对应一个孩子znode。客户端可以使用自己的znode标志自己在事务中的那部分是成功还是失败。其他客户端可以监控同级的znode，并采取适当的行动。
