哪些做图形推理的网站360搜索引擎下载
Hbase中Rowkey的设计方法
过去对于Rowkey设计方法缺乏理解，最近结合多篇博主的文章，进行了学习。有不少心得体会。总结下来供后续学习和回顾。
一、设计Rowkey的三个原则
1.长度原则：长度不能太长，小于100个字节。可以偏端一些，短一些可以方便存储。最好是8的倍数。因而建议16字节为好。
太长的话有两点影响：1.降低HFile的存储效率，需要话更多的空间存储不包含实际数据的Rowkey。2.会使MemStore的缓存效率下降，缓存大小固定，Rowkey越长，能缓存的数据个数越少。
2.唯一原则
一个Rowkey只唯一标识一组数据，若出现两条数据的数据部分一样但Rowkey不一样，那么就不是同一条数据。
3.散列原则
设计的Rowkey应该是分布于各个Hbase节点上的，这样主要是为了防止出现热点，造成单个RegionServer服务器压力过大。
二、写优化与读优化
Rowkey在数据进行读写时及其重要。在写入时，当Rowkey足够分散，能均匀的写入不同的HRegionServer时，写入效率就会提升。在读取时，当Rowkey设计的足够好，就可以避免对所有数据进行扫描。甚至于仅需要扫描某个Region中的一部分数据即可。为了使写入和查询的效率进一步提高，可以对Rowkey进行一些设计。
1.写优化
写优化主要有三种技术层面的操作：hash值，加盐，和反转
- hash值
优点：一般使用MD5生成的hash值足够散列，能均匀分布。且hash值能讲部分变长字符串转化为定长字符串。
缺点：单纯的使用hash值容易使数据散乱的分布，当查找的时候会进行全表扫描，遍历所有region
- 加盐
所谓加盐就是指在一部分有实际含义的数据中添加一部分无实际含义的数据。
例如：将Rowkey直接设置为时间戳的话有可能造成大量的数据堆积在同一个region中。此时在时间戳之前添加一个随机的hash值就会使数据均匀分布且查找数据时可以按时间戳进行查找。
有如下三个时间戳timestamp1、timestamp2、timestamp3，若将时间戳作为Rowkey，可能三条数据都被存储在一个Region上。若对其分别进行加盐操作，在时间戳之前加上一个分区号，此时三个时间戳变为字符串 0timestamp1、1timestamp2、2timestamp3。此时首位变成了不同的数，也更容易分散到不同的Region中
优点：确保Rowkey在包含实际意义的情况下也能够均匀分布在Region中。
缺点：读取时依然需要遍历所有region
- 反转
反转操作一般可以用于时间戳，此时反转后的时间戳作为Rowkey的一部分时，既能使Rowkey分散于各个Region，又方便捕获数据的最新版本。
2.读优化
相比于写优化，读优化是一个复杂的议题。原因在于，写优化通常只需要确保Rowkey不会影响数据在Region中的分布。而读优化则依据场景的不同设计不同的Rowkey去缩小扫表范围。
在上一小节对写优化方法的总结中，反转操作是读优化中常用的，主要是为了方便获取最新数据。
下面举两个应用场景下的读优化：
1.目标：在Hbase中存储用户订单状态
Rowkey：反转订单id+反转时间戳
通过反转订单id能避免所有数据存储在同一个Region中的情况，通过反转时间可以便于获取最新订单。
rowkey可以表示为：reverse(userId) + (Long.MAX_VALUE - timestamp)
注意：此处时间戳反转使用(Long.MAX_VALUE - timestamp)。主要是为了方便查询。如果要查询某段时间的操作记录，则使用如下方法：
startRow是[userId反转] [Long.MAX_VALUE - 结束时间]
stopRow是[userId反转] [Long.MAX_VALUE - 起始时间]
2.目标：存储最近10分钟的热点数据
Rowkey：两位随机数Salt + eventId + Date + kafka的offset
其中两位随机数用于使数据写入时均匀分布在不同的Region中，后两个eventId和Date则由查询语句的查询条件所决定。如果查询之前总是能获取到eventId和某一个数据字段，则将两个字段放入Rowkey中。
kafka的offset则是为了确保获取最新的数据。