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);