图片来自 Pexels

【51CTO.com原创稿件】随着苏宁业务的高速发展，大数据平台对海量的业务数据分析越来越具有挑战，尤其是在精确去重、复杂 JOIN 场景下，如用户画像、UV、新老买家、留存、流失用户等。

苏宁大数据平台目前 OLAP 分析的总体架构是将时序化的数据采用 Druid+ClickHouse、非时序化采用 PostGreSQL、固化场景采用 Hbase+phoenix、明细数据采用 Elasticsearch 分析。

基于 Druid 我们有 HyperLogLog 非精确去重算法，具有非常优异的空间复杂度 O(m log2log2N)，空间的占用随着基数的增长变化不大，但统计存在一定的偏差。

基于其他引擎我们常用的精确去重算法一般是 GROUP BY 后 count distinct 操作，GROUP BY 会带来大量的 shuffle 操作，占用大量的磁盘和 IO，其性能较为低下。

下面将为大家揭开苏宁如何整合 RoaringBitmap 进行高效精确去重架构方案的神秘面纱。

RoaringBitmap 在苏宁的应用实践

为何选择 RoaringBitmap

首先简单为大家介绍下 RoaringBitmap，32 位的 RoaringBitmap 的是由高 16 位的 Key 和低 16 位的 Value 组成，Key 和 Value 通过下标一一对应。

Key 数组保持有序存储在 roaring_array_t 中，方便二分查找。低 16 位的 Value 存储在 Container 中，Container 共有三种。

RoaringBitmap 对创建何种 Container 有自己的优化策略，在默认创建或元素个数小于 4096 的时候创建的是 Array Container。

它是动态扩容的数组，适合存放稀疏数据，超过最大容量 4096 时，会自动转换为 Bitmap Container。

当元素超过 4096 时 Array Container 的大小占用是会线性增长，但是 Bitmap Container 的内存空间并不会增长，始终还是占用 8 K。