共计 1083 个字符，预计需要花费 3 分钟才能阅读完成。
在大数据处理和应用场景中经常需要 从亿级甚至十亿级会员中搜索出符合特定标签的会员。很多企业都会使用 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…）。
如何实现？
具体实现参照如下步骤：
实验硬件配置：
- Master 1 台,
- Segment Host 2 台, 3 Segments 每台 Host
- CPU: 2.40GHz 32 cores
- Memory:128G
- 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…）