「实战系列」GP+Roaringbitmap，亿级会员十万级标签毫秒级查询

在大数据处理和应用场景中经常需要从亿级甚至十亿级会员中搜索出符合特定标签的会员。很多企业都会使用 HBase 或者 Hive + Hadoop 的方式，这样的方式查询效率非常慢，在标签非常多的情况下计算，更是让人无法忍受。这里我们介绍一种 Greenplum + Roaringbitmap 的组合使用方案，亿级甚至十亿级会员_万级标签_的条件下查询毫秒级出结果。

业务系统的场景图如下。

数据从业务系统经过处理后流进 OLAP 分析平台，OLAP 平台的底层支持就是使用 Greenplum + Roaringbitmap。 Greenplum 是一个分布式大数据平台数据库，基于 MPP 架构的模式来达到快速分析效果的。 关于 Greenplum 的官方介绍：About the Greenplum Architecture（
http://gpdb.docs.pivotal.io/5..._guide/intro/arch_overview.html ）。

Roaringbitmap 是压缩的 bitmap 的一种实现，参考文档：
RoaringBitmap/RoaringBitmap（
https://github.com/RoaringBit... ）。

如何实现？

具体实现参照如下步骤：

实验硬件配置：

1. Master 1 台,
2. Segment Host 2 台, 3 Segments 每台Host
3. CPU: 2.40GHz 32 cores
4. Memory:128G
5. Disk: SATA 1T

用户表schema：

用户标签表schema:

2亿会员数据导入GP，耗时60s

GP分区影响： 分区后查询效率提升 5-10 倍。

创建用户标签表：

初始化标签：耗时分钟级别。

查询效率：

对会员表使用 count 查询，耗时 8 s ，使用 Roaringbitmap 查询，耗时 100 毫秒

占用空间：平均一个标签包含客户数500万， 占用空间12M ，10万标签总存储空间 10M * 12M = 120G

关于存储空间，将2亿会员全部设定为一个标签，查询该标签后，存储需要25M左右。

感谢阿里德哥，Talkingdata的Zeromax 提供的文档和源代码。

该实现是基于以上两位给出的方案和源代码修改而来，如果完全照搬digoal/blog这里提的方案，在聚合查询时，Greenplum会有一些问题。

关于作者

周长跃，目前就职于深见网络高级技术总监，之前在华为和腾讯工作很多年。

参考文档：

• digoal/blog（https://github.com/digoal/blo..._01.md）
• zeromax007/gpdb-roaringbitmap（https://github.com/zeromax007...）