xxx银行日志信息检查业务场景

一、业务背景

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数进行并发查询，提升效率。