一、业务背景
xxx银行的手机银行将埋点日志实时采集到，传回服务器并存入hbase集群的原始表，现在需要检查原始表日志信息完整性，字段是否缺失，是否有异常数据。结果用于反馈给前端开发，检查日志抓取是否有问题。
二、数据类型及数据
原始日志包含：
打开日志 、查看数据
hbase字段，含有13个字段，其一为vehaviour字段，为json,不同日志类型字段数以后在不同。
hbase数据量及region数目：
含13个必填字段，其一字段为hehavious字段，为字段，不同日志类型数量不同。
hbase数据量及region数目：
目前17个hbase节点，单日数据量为700GB，TTL为3天，major_compaction触发间隔为7天，保守估计要存储7T数据（10g天）
1.2 业务查询类型一范围查询
查询十分钟内所有日志
三、现状及诉求
当前rowkey设计
（一个随机数0-9）|时间精确到天（如20210111）|uuid
例如：2|20210111|uuid
1、每天的数据量为700G，保守估计要存储7T数据，数据量很大，所以rowkey高位使用一位随机数0-9细分还是不够，很容易出现时间相近的数据依然存在同一region的情况，数据检索的时候，负载会集中在个别regionserver上，造成热点问题，查询效率太低。
2、时间戳精确到天不能满足查询十分钟范围的数据。
四、诉求
需要重新设计rowkey,优化查询方案
五、优化方案
5.1row设计
预分区
估计要存储7t数据（10天），按每个Region 5G计算，需要1400个region，每个regionserver建议管理200-20活跃region，目前有17个hbase节点，分1400个region完全够用，在建表时就预分region,例如
1、xxxx-1001
2、1001-1002
3、1002-1003
4、2399-xxxxx
那么插入数据就可以使用1001-2399四位随机数作为rowkey的高位，尽可能的把数据均匀在每个region中，以实现负载均衡率。
rowkey的中间时间字段，需要精细到分秒，设计yyyyMMddHHmmss
rowkey的尾部uuid
使用32位uuid，用于区别同一时该的大量数据
综上：重新设计后rowkey 规则
(四位随机数1001-2399) -yyyyMMddHHmmss-uuid
查询设计
扫描数据时，使用基于spark on hbase调用scan进行扫描，底层会根据region数进行并发查询，提升效率。
