HBase 中 RowKey 可以唯一标识一行记录，在 HBase 查询的时候有以下几种方式：

从字面意思来看，RowKey就是行键的意思，在增删改查的过程中充当了主键的作用。它可以是任意字符串，在 HBase 内部 RowKey保存为字节数组。

HBase 中的数据是按照 RowKey 的 ASCII字典顺序进行全局排序的，有伙伴可能对 ASCII字典序印象不够深刻，下面举例说明：

假如有5个Rowkey："012"，"0"，"123"，"234"， "3"，按ASCII字典排序后的结果为："0"，"012"，"123"，"234"，"3"。

因此我们设计Rowkey时，需要充分利用排序存储这个特性，将经常一起读取的行存储放到一起，要避免做全表扫描，因为效率特别低。

RowKey中数据是以 key-value 格式存储的，RowKey可以类比为MySQL里面的key值，因此在HBase的一张表里面，RowKey不应该重复。而且一个RowKey只能对应一条数据，用RowKey去get表里面的数据时，返回的应该是唯一一条对应的数据记录，不应该返回多条。

另外，因为 RowKey 是按照字典顺序排序存储的，所以可以将经常读取的数据存储到一块，将最近可能会被访问的数据放到一块。不过这样做虽然方便了 scan 等范围查询数据，也可能会导致热点问题。

RowKey是一个二进制码流，可以是任意字符串，最大长度 64kb，实际应用中一般为 10-100bytes，以byte[] 形式保存，一般设计成定长。

建议越短越好，不要超过 16 个字节，原因如下：在 HBase 的底层存储 HFile 中，RowKey 是 Key-Value 结构中的一个域。假设 RowKey 长度 100B，那么 1000 万条数据中，光 RowKey 就占用掉 100*1000w=10 亿个字节 将近 1G 空间，这样会极大影响HFile 的存储效率。

过长会导致 RowKey 在 memStore 中占据的内存空间过大，而实际数据占据的空间很小，只写了少量数据就因为RowKey占据太多空间而flush。因此建议越短越好，不要超过100个字节。

RowKey 是按照字典顺序排序存储的，因此，设计 RowKey 的时候，要充分利用这个排序的特点，将经常读取的数据存储到一块，将最近可能会被访问的数据放到一块。

一个常见的数据处理问题是快速获取数据的最近版本，使用反转的时间戳作为RowKey 的一部分对这个问题十分有用，可以用Long.Max_Value-timestamp 追加到key 的末尾。

例如 [key][reverse_timestamp],[key]的最新值可以通过 scan [key]获得[key]的第一条记录，因为 HBase 中 RowKey 是有序的，第一条记录是最后录入的数据。

散列原则的作用是将数据打散，不要让连续的数据集中在一个region里面，降低热点问题出现的可能性。

以上面的数据为例，图中的数据就是以时间戳的方式来排序，这样排序如果要访问的数据集中在某一个时间段上，这个时间段内连续的RowKey在一个region里面（因为 HBase 里面的数据按照字典排序，连续写入的时候就会让数据因为连续的 RowKey 会进入相同的 region 里面），对这一个region进行频繁的访问就造成了热点问题。因此应该按照散列原则，给时间戳RowKey的前面加上随机生成的散列字段，这样连续的时间戳数据也会因为随机的散列字段而进入不同的region，避免了热点问题。

当然图上并没有这么做，代码的上半部分数据是原始数据，而代码的下半部分选择将时间戳反转，这样每行RowKey的前几位也是各不相同的，不会被写入同一个region里面，同样避免了热点问题。

HBase中设计有MemStore和BlockCache，分别对应列族/Store级别的写入缓存，RegionServer 级别的读取缓存。如果 RowKey字段过长，内存的有效利用率就会降低，系统不能缓存更多的数据，这样会降低检索效率。

另外，我们目前使用的服务器操作系统都是 64 位系统，内存是按照 8B 对齐的，因此设计 RowKey时一般做成 8B的整数倍，如 16B 或者 24B，可以提高寻址效率。

同样，列族、列名的命名在保证可读的情况下也应尽量短。value 永远和它的 key 一起传输的。当具体的值在系统间传输时，它的 RowKey，列名，时间戳也会一起传输（因此实际上列族命名几乎都用一个字母，比如'c'或'f'）。如果你的 RowKey和列名和值相比较很大，那么你将会遇到一些有趣的问题。HFile中的索引最终占据了 HBase分配的大量内存。

我查看了很多博客，很多博客都只说了连续的RowKey在同一个region里面就会导致热点问题，其实这样是没有说完的。因为如果只是RowKey连续，那么RegionServer会自动划分过大的region，这样每个region里面的数据量也是差不多的，不会因为这样就导致热点问题。

导致热点问题的原因是，Clinet访问查询数据时，可能会集中访问某一段连续RowKey的数据，而因为HBase中是按照字典序升序来排列数据的，这样连续将数据写入表中时，连续RowKey的数据就会被划分在同一个region里面，而针对这一段连续RowKey所在的region进行频繁大量的访问，导致region所在的节点机器承受了超出自身处理极限的访问量，从而导致效率低下甚至故障。而其他节点存储的数据因为没有被访问，所以一个节点拼死的忙，其他节点围观看戏，这就造成了热点问题。

另外还有一种情况，那就是设置的预分区不合理，同样会导致热点问题，预分区不合理同样可能导致设置的其中一个region里面的数据被大量访问。

对于热点问题，应该做的是，对RowKey进行合理的设计，让一段连续的RowKey进入不同的region当中，这样就避免了访问集中在同一个region上。

给RowKey分配一个随机前缀以使得它和之前的RowKey的开头不同。分配的前缀种类数量应该和你想使用数据分散到不同的region的数量一致。加盐之后的RowKey就会根据随机生成的前缀分散到各个region上，从而避免热点问题。

针对RowKey进行hash运算，运算得出的结果，再拼接到原先RowKey的前面，这样连续RowKey计算得到的hash值不相同，将hash值与RowKey拼接后的新RowKey较大概率不会连续，这样就会被送入不同的region里面

但是上面也说了，这只是较大概率不会连续，但是连续的RowKey计算出来的hash值的前缀依旧可能相同。比如一段连续的RowKey，r1，r2，r3，这三者经过hash运算后的结果为aaa，aab，aac，这样虽然hash结果不同，但是hash值的前缀相同，按照字典序排序时依旧是连续的数据。

使用hash的好处是，同一个RowKey的hash值是固定的，因此查询时只要计算一下hash值，依旧可以按照RowKey查询数据。而加盐就是给每一个RowKey随机加上一个前缀，这就导致同一个RowKey，多次加盐的结果也是不同的，因此没办法再用RowKey去get到某一条数据（当然非要用RowKey去查也可以，用子串过滤器，把原来的RowKey作为子串去匹配加盐后的RowKey）。

使用hash的坏处是，虽然可以继续使用get查询，但是因为计算到的hash值依旧可能连续，导致热点问题没有被解决。而加盐可以保证解决热点问题，即连续RowKey的数据一定被划分到不同的region里面。

第三种防止热点的方法时反转固定长度或者数字格式的RowKey。这样可以使得RowKey中经常改变的部分放在前面。这样可以有效的随机RowKey，但是牺牲了RowKey的有序性。

就比如时间戳，大量连续的时间戳只有最后两三位会改变，前面几位基本不会改变，此时就可以将最后两三位提到最前面，将重复的时间戳部分放到后面，避免了连续。

时间戳反转这里的反转应该打上引号，因为这里不是将123变成321这样的反转，而是用大数减去小数，用差值作为新的RowKey。

此时需求是，让最新的记录排在最前面，也就是按照时间戳逆序排序，最新也即最大的时间戳排在最上面方法就是设定一个大数，比如设置一个9999999999的时间戳，然后用这个时间戳去减去上面rowkey里面的时间戳，结果为：

这样再排序的时候，按照字典序排列，最后一条RowKey，8,361,379,451_uid就会被放在第一位，实现了最新的一条记录放在最前面的需求。