Hbase

1、物联数据Hbase查询优化：

1.1 业务场景：

hbase用于保存设备采集的数据，一个租户一个表，查询也是直接自从hbase中取数据

1.2 存在与待解决的问题：

查询场景为，查询某设备多测点某时间范围数据

• 1、物联数据查询慢，数据占用磁盘高
• 2、数据高并发写容易阻塞

1.3 查询慢问题定位

• 1）Rowkey设计缺陷，时间戳+设备ID，同时未进行预分区，读写容易产生在一个region中，数据热点问题，
• 2）查询时设置了多个fillter，全表查询
• 3）未进行预分区后，大量写入一定数据后，容易出现自动分区的场景

1.4 解决方法：

（1）重新设计hbase表：

• 1）rowkey为：分区号+设备id+时间戳，分区号为hash(设备id)%9，同一设备数据有序
• 2）预分区键为，｛0|，9|｝，hbase中rowkey按照字典排序，| 阿斯卡码最大
• 3）建表时，采用压缩机制，设置数据过期时间TTL
• 4）设置在有些情况下过滤掉不需要的hfile,节省IO，BLOOMFILTER = ‘ROW’

(2) 查询时，指定列族，start/endRow，尽量通过rowkey查询过滤数据，减少filllter的使用

(3) 将scan缓存从100增大到500或者1000，用以减少RPC次数

1.5 写阻塞：

• 1）预分区，减少热点
• 2）提高region分区大小，默认的region大小为10G，就是说当存储的数据达到10G的时候，就会触发region分区操作。 regions过多会导致集群不堪重负、regionserver 频繁FullGC的情况，进而影响集群的稳定性甚至上层的应用服务
• 3）物联场景，写多读少，RegionServer中，负责flush操作的是MemStoreFlusher线程。该线程定期检查写操作内存，当写操作占用内存总量达到阈值，MemStoreFlusher将启动flush操作，按照从大到小的顺序，flush若干相对较大的memstore，直到所占用内存小于阈值。默认：0.4该配置与“hfile.block.cache.size”的和不能超过0.8，

2、hbase 数据查询restful接口

Spring boot 版本 2.5.1
hbase-client 1.3.0

2.1 spring 结构

• controller的概念，在mvc中就已经存在，一般指控制部分。对view层提交的请求设置对应的servelet进行特定处理。
• entity层，是实体类层，一般与所连接的数据库中每个表对应。需要注意同时应该生成getter setter方法和构造方法。
• mapper层，中定义的是对数据库的操作，一般表现为接口形式
• service层，应用服务层，在其中创建mapper对象来进行进一步的包装。
  
  
  

2.2 restful接口，用http协议，json格式数据

1）用URI表示1种资源，只用名词表示资源，不要动作；
2）用http动作表示对资源的操作： get 查询； post insert put 更新； delete 删除
3）用http状态码表示结果

2.3 代码结构

util+controller

@RequestMapping(value = "/scanData",method = RequestMethod.POST)
public R findDataBytags( @RequestBody String json)  {
JSONObject object = JSONObject.parseObject(json);
String startTime = object.getString("startTime");// "2020-10-01 00:00:00";
Map<String, Object> dataMap = findByid()
return R.ok().put("data",dataMap);
}

Scan scan = new Scan();//若没有指定startRow以及stopRow，则全表扫描
scan.setStartRow .setStopRow 
scan.setReversed(true);
scan.addColumn("fdata".getBytes(), cloumnlist.get(i).getBytes());
scanner = table.getScanner(scan);
 Get g = new Get(Bytes.toBytes(rk));
 Result result = table.get(g);
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15