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

了解更多Greenplum技术干货，欢迎访问Greenplum中文社区网站

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

业务系统的场景图如下。

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

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

如何实现？

具体实现参照如下步骤：

实验硬件配置：

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/blog/blob/master/201801/20180127_01.md）

• zeromax007/gpdb-roaringbitmap（https://github.com/zeromax007/gpdb-roaringbitmap）