Hbase rowkey设计原则
HBase 中的 rowkey 设计需要遵循以下原则：
1 rowkey 唯一原则
若在 HBase 中向同一张表插入相同 rowkey 的记录，如没有设置版本数量，则此 rowkey 原先的数据会被覆盖，且 rowkey 是用来唯一标识一行记录的。所以，在 rowkey 的设计上务必要保证其唯一性。
2 rowkey 排序原则
rowkey 是按照 ASCII 字典排序（byte order）由低到高存储在表中的。设计 rowkey 时，要充分考虑排序存储这个特性，使用前缀将经常一起读取的行存储到一起。但量不能太大，若太大需要拆分到多个节点上。
注意：字典排序对 int 类型排序的结果是 1,10,100,11,12,13,14,15,16,17,18,19,2,20,21 ... 。因此要保持 int 的自然序，rowkey 必须用 0 作左填充。
3 rowkey 散列原则
我们设计的 rowkey 应能均匀地散列分布在各个 HBase 的 RegionServer 节点上。下面用常见的时间戳来举例说明这一原则。
若 rowkey 是按系统时间戳的方式递增，而时间戳又位于 rowkey 的第一部分，则会很容易造成热点现象，即所有的新数据会堆积在同一个 RegionServer 上，导致大量的 client 直接访问集群的一个或极少数个节点（访问可能是读、写或者其他操作）。
这种情况会直接导致热点 Region 所在的单个 RegionServer 机器超出自身负载能力，引起性能的下降甚至 Region 不可用。常见的是发生 jvm full gc 或者显示 region too busy 的异常情况。而且由于主机无法服务其他 Region 的请求，因此这种情况还会影响同一个 RegionServer 上的其他 Region。
散列原则的 rowkey 设计就是要使集群被充分、均衡地利用，避免热点现象的发生。散列设计的 rowkey 可以使得不同行在同一个 Region，同时在更多数据的情况下，数据可以被写入集群的多个 Region，而不是一个。
4 rowkey 长度原则
rowkey 为二进制形式，可以是任意字符串，最大长度为 64kb。而在实际应用中，一般为 10-100bytes，它以 byte[] 形式保存，一般设定为定长格式。
rowkey 的设计建议越短越好，最好不要超过 16 bytes，其原因有三点：
HBase 的持久化文件 HFile 是按照 Key-Value 存储的，rowkey 是 Key 中的一个域，如果 rowkey 过长（比如 rowkey 是 500 bytes，1000 万行数据，那单是 rowkey 的存储就要占用 500*1000万=50 亿 bytes，将近 5G 的容量），会极大地影响 HFile 的存储效率；
HBase 中的 MemStore 和 BlockCache，分别对应 Store 级别的写入缓存，和 RegionServer 级别的读取缓存。如果 rowkey 过长，内存的有效利用率就会降低，这样系统就无法缓存更多的数据，检索的效率就会受到影响；
目前我们使用的服务器操作系统都是 64 位系统，内存按照 8 字节对齐，因此 rowkey 一般设计成 8 字节的整数倍，这样就能利用操作系统的最佳特性，提高寻址效率。
