Rowkey设计部分

Rowkey 设计

1. 热点

HBase中的行按照Rowkey的字典顺序进行存储。这种设计，允许你将一些相关的行或者经常一起读的行存储在一起，优化了scan方法。然而糟糕的rowkey设计是产生热点问题的主要来源。当大量的客户端跟其中的一个节点或者少量节点进行通信的时候，热点现象就会产生。这种通信包括读，写或者其他的操作，将压垮负责该region的机器，引起性能下降和region不可用的情况。也将对其他的regions产生不利的影响，因为其他的regions可能托管在相同的region server上（该regionserver已经不能再进行相关的请求负载啦）。重要的是要设计数据访问模式，这样集群才能被充分均匀使用。

为了阻止热点写问题，设计你的rowkey使得行能够真正的存放在相同的regions上，但是从全局考虑，数据是写入到集群中的多个regions中，而不是每次写入到一个region。下面有一些常见的技术来避免热点问题，并对这些技术的优缺点进行了分析。

分散（Salting）

分散(salting)在该场景下与密码学没有什么关系，但是与增加随机数据到一个rowkey的开始有关。在这种情况下，分散是指添加一个随机指定的前缀给rowkey使得它排序不同于原来的排序结果。前缀数量与你想要分散数据的regions个数想对应。如果你有一些“热点”rowkey不停的在其他均匀分布的行之间不停的出现，那么分散将可能会有用。考虑下面的例子，该例子可以展示分散能够在多个regionserver上平均写负载，而且阐述了一些写方面的负面影响。

Example 16. 散射 salting Example

假设你有以下的rowkey列表，你的数据表被分裂使得一个region对应字母表中的一个字母。前缀‘a'是一个region，前缀‘b'是另一个region。在该表中，所有的行以‘f'开头，都存储在f开头的那个region中。这个例子的rowkey如下所示:

foo0001
foo0002
foo0003
foo0004

现在，假设你想分散这些row到四个不同的region中。你决定使用四个不同的salts:a，b，c，d。在这个场景中，每个前缀字母将会存储在不同的region中。当使用了salts后，将会有以下的rowkeys替代。以后你可以写入四个不同的regions了。理论上你有四倍于所有写都进入相同region的吞吐量。

a-foo0003
b-foo0001
c-foo0004
d-foo0002

然后，如果你增加另一行，它将会随机的指定到四个可能的salt values中，在靠近现有的一行处结束(it will randomly be assigned one of the four possible salt values and end up near one of the existing rows.)

a-foo0003
b-foo0001
c-foo0003
c-foo0004
d-foo0002

由于该指定是随机指定的，在检索这些行的时候你需要做更多的工作。在这种方式下，散射（salting)尝试增加写的吞吐量，但是在读的时候有巨大的消耗。

哈希(Hashing）

与自由指定不同，你可以使用单向的hash使得一个给予的行总是与“salted”拥有相同的前缀，在该方式下，负载将会直接分散到Regionservers中，但是在读的时候允许可预见性。用一个确定性的hash将允许客户来重新构造完全的rowkey，并且使用一个Get操作来检索正常的行。

例子17. 哈希（Hashing） Example

给上面salting例子一样的情况，你可以使用单向hash从而使得foo0003总是预测性的接受a的前缀。然后，在检索行的时候，你已经知道了该key值。你也可以优化一些东西使得确定的keys对总是在相同的region上面。例如：

反转Key

第三个常见的阻止热点写的技巧是反转一个固定宽度或者数字的rowkey，这样的话，经常改变的那个部分将会是第一个。这将会有效的随机化rowkeys,但是牺牲了row的排序特点。

可以查看Phoenix工程上的https://communities.intel.com/community/itpeernetwork/datastack/blog/2013/11/10/discussion-on-designing-hbase-tables,和article on Salted Tables, 避免热点写的更多信息与相关讨论在HBASE-11682。

Client

HBase客户端查找那些服务于感兴趣的row范围内的regionservers，它通过查找hbase:meta表实现。在定位了需要的region后，客户端与regionserver建立连接响应读写请求，而不是通过去查找master节点。消息被缓存在客户端，使得后续的请求不会经过查找过程。一个region是否需要重新指定由master的负载均衡或者regionserver是否死亡决定，客户端将会去查询目录表来决定用户region的新的位置。

参考网址：http://hbase.apache.org/book.html#rowkey.design

http://hbase.apache.org/book.html#architecture.client