巧用RoaringBitMap处理海量数据内存diff问题

原创

已于 2022-07-19 11:01:35 修改 · 1.6k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#hbase #java #大数据

于 2022-07-19 11:01:13 首次发布

针对大数据量商品集的处理，原Java Set结构因内存占用过高导致服务宕机。引入RoaingBitmap数据结构，通过位数组存储数据，降低内存占用并支持高效运算。在标签刷新场景中，使用RoaingBitmap进行差集运算，减少内存消耗，提升刷新速度和写入效率。对比测试表明，RoaingBitmap在内存占用和CPU耗时上优于其他Bitmap实现，平均提升刷新速度52.42%，写入量级降低86.98%。

背景

目前，在商品圈选投场景，每个标签id都会根据规则/指标绑定一定数据量的商品集，在圈选规则条件变动或者定时任务触发时会进行商品集的刷新，新增符合规则的商品，删除不符合规则的商品。

但是由于商品集下的spu数量大部分都在数十万，多的能达到上百万，如果直接将刷新前后各十万甚至百万的spu全量放到内存中互相做diff，再对diff得到的差集做增删，当同一时间刷新的标签数量过多时，内存就很容易溢出，造成整个服务宕机。

同时目前底层存储商品集的数据库为Hbase，因此在标签侧对于商品集的刷新场景目前都是采取全增全删的策略，即把刷新后的商品集先全量保存一次(利用Hbase 保存的幂等性，同一个rowkey的数据重复保存会进行覆盖，而不用在保存前做额外的数据是否存在的判断)，并更新数据的modity_time=now()，然后再从Hbase中分批scan遍历商品集，找到modity_time<now的再进行删除，以此完成一次标签的刷新任务。

往往一个商品集在刷新前后真正变化的spu量并不大，通过取数分析得知变化的不会超过商品集数量的10%。而我们目前采用的这种全增全删的策略，每次刷新后都会有大量已有数据的重复插入，不仅延长了刷新的速度，也增加底层储存的压力，同时由于选投平台里有标签的指标，标签的变动需要推送变化的spu给选投平台进行重新圈品，同时spu es 中也存有标签的数据用于后台展示，所以当前全增全删的策略，尤其是大量已有数据的重复插入，都会同步到选投平台和spu es侧，对他们造成大量的性能浪费和处理成本，改造迫在眉睫。