HBase如何设计rowkey，如何在负载均衡和读写性能之间做出平衡

由于在开始建表时，表只会有一个region，并随着region增大而拆分成更多的region，这些region才能分布在多个regionserver上从而使负载均分。对于写负载很大的业务，如果一开始所有负载都在一个regionserver上，则该regionserver会承受不了而导致数据丢失。因此，有必要在一开始就将HBase的负载均摊到每个regionserver。要将负载均摊，可用的方法就是建表时将表分区，将这些分区均匀地放到每个regionserver上，然后客户端在进行写操作的时候，将这些写操作均匀分布到各个分区上.

 

Rowkey设计的3个原则

1 rowkey 长度原则

rowkey 是一个二进制码流，可以是任意字符串，最大长度 64kb，实际应

用中一般为 10-100bytes，以 byte[]形式保存，一般设计成定长。建议越短越好，不要超过 16 个字节, 原因如下：

数据的持久化文件 HFile 中是按照 KeyValue 存储的，如果 rowkey 过长会

极大影响 HFile 的存储效率MemStore 将缓存部分数据到内存，如果 rowkey 字段过长，内存的有效利用率就会降低，系统不能缓存更多的数据，这样会降低检索效率

2 rowkey 散列原则

如果 rowkey 按照时间戳的方式递增，不要将时间放在二进制码的前面，建议将

rowkey 的高位作为散列字段，由程序随机生成，低位放时间字段，这样将提高数据均衡分布在每个 RegionServer，以实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息，所有的数据都会集中在一个 RegionServer 上，这一方面不能发挥整个集群的并发处理能力，另一方面势必造成此台RegionServer资源严重消耗（比如IO耗尽、handler耗尽等），落在该台RegionServer上的其他业务会因此受到很大的波及。可见，读请求不均衡不仅会造成本身业务性能很差，还会严重影响其他业务。当然，写请求不均衡也会造成类似的问题，可见负载不均衡是HBase的大忌。

3 rowkey 唯一原则

必须在设计上保证其唯一性，rowkey 是按照字典顺序排序存储的，因此，设计

rowkey 的时候，要充分利用这个排序的特点，将经常读取的数据存储到一块，将最近可能会被访问的数据放到一块。

 

 

问题扩展

HBase流量限制和表负载均衡

为什么要做流量限制，无限制全量跑不是更好吗？举个例子，比如今天的双十一日，数据流量是非常大的。如果不限制用户和表的流量，某些重要的核心业务，需要在资源有限的情况下优先保证正常运行。如果非核心业务在此期间其QPS一直降不下来，严重消耗系统资源，影响核心业务的正常运作。

针对上述问题，可以采取以下方案来解决：

资源限制：针对用户、命名空间及表的请求大小和QPS进行限制。

资源隔离：将不同表中的数据通过物理隔离，均衡到不同的RegionServer上。