OLAP技术应用——位运算原理及应用

背景

位图（bitmap）是一种基于bit位数组的数据结构，在大数据场景下对于存储和计算效率均有奇效。

假如将10亿连续的用户ID存在int数组，需要10亿个32位int，占用存储3.72G左右，如果改用bit数组存储，每一个bit位表示一个用户ID，只需要10亿个bit，120M左右存储就够。

下图为表示用户是否登入属性的一个bitmap数据结构，存储的是0和1，其中1表示登入过，0表示没登入，数组的下标位置表示用户ID，例如下图用户ID为1、2、5的用户登入过系统，那么统计当天登入的UV用户数只需要计算1的个数即可。

如果要计算次日留存，7日、30日留存，可以对每一天登入用户状态存入bitmap结构，计算次日留存就是计算day1和day2的bitmap结构对应位的与运算（day1表示第一天，计算7日，30日原理类似），这样就把留存计算从传统数据库中的left join转化为bit位运算，在存储和计算效率上都有本质的提升。

利用bitmap位运算特性，可以实现与、或、非和异或计算，计算结果也是bitmap，通过统计1的个数就可以知道结果集个数。对于应用场景中的基数统计都可以考虑使用bitmap处理。

业界实践

美图的Naix

用户行为例如新增、活跃、留存、升级、回访，本质上都是计算用户行为的个数，使用bitmap来表示不同行为可以快速计算结果，美图在这方面做了大量实践。

但是对于海量数据场景，单机bitmap计算仍会成为性能瓶颈，因此需要并行bitmap计算方案。

美图自研的Naix就是分布式bitmap服务，能实现分布式bitmap计算，主要原理是把bitmap按位拆分，存储在不同节点上的KV数据库（例如redis、PalDB），分节点计算完后进行merge汇总。

• 方案优点
  这种方案解决bitmap扩展性问题，可以支持数百TB级别数据，对于大数据量的计算更快。

• 不足

  • 索引的分片倒入、分节点计算、合并最终结果都需要自研服务来控制，对服务实现性能要求较高，实现成本高。
  • 不支持SQL，不同维度的计算依赖API接口，通用性不足，学习成本较高。

快手的BitBase

快手使用bitmap主要解决千亿级日志任意维度7-90日留存计算问题，对于这个需求，使用传统数据库行存维度信息表，利用SQL进行计算的性能难以达到要求，在性能测试中使用clickhouse的时间也在秒级到分钟级。

快手也开发并行bitmap方案，自研整个bitmap数据切分、压缩、存储和查询计算过程，跟美图不同的是讲构建的bitmap index数据存储在hbase。

• 优点
  实现大规模并行bitmap计算，性能达到2-3秒级别，满足实时交互OLAP分析

• 不足
  不足类似美图的方案，如实现成本、不支持SQL计算、复杂index元数据管理，此外也都有设备ID问题，因为bitmap只支持整型数字，其他标识需要转化为数字。

总结

bitmap因为其位运算的特质，非常适合多维分析计算基数场景，但是对于大数据场景需要将bitmap进行按位切分存储到不同节点来实现并行计算，这涉及bitmap在存储和计算方面大量整合工作，而且原始方案只能用API实现，还不支持SQL，有一定学习成本。

但bitmap方案已经验证在此类场景下的优秀效果，但是仍需进一步改进来降低bitmap服务的存储、计算和使用成本。

参考：

bitmap原理

美图分布式Bitmap实践：Naix

快手 HBase 在千亿级用户特征数据分析中的应用与实践

查看公众号可了解更多：水木之椿