简介：  淘宝用户增长团队使用 Hologres 的 RoaringBitmap 画像方案，成功让 3-5min 的画像分析提升到 10s 左右，显著提升人群分析的效率，为业务决策提供快速的依据。本文将会分享Hologres RoaringBitmap 方案在画像分析的应用实践。

作者：艾贺(致问) 阿里集团技术开发

业务介绍

淘宝用户增长团队所在的用户运营平台技术团队是一支懂用户，技术驱动的年轻队伍，团队立足体系化打造业界领先的用户增长基础设施，以媒体外投平台、ABTest平台、用户运营平台为代表的基础设施赋能用户增长，日均处理数据量千亿规模、调用QPS千万级。

在用户规模达到一定量级的情况下，单一的运营策略对于用户的效果愈发有限，人群分析的能力，因此显得尤为重要，它能帮助我们发现潜在用户、找寻运营时机，为策略调整提供数据支持。技术平台在过去一直采用MaxCompute进行画像分析，中途尝试过直接通过Hologres加速查询，但由于数据量级太大，在画像分析的效率上仍然存在一定的问题。为了解决Hologres的加速查询效率问题，我们团队调研了Hologres的RoaringBitmap画像方案，并在技术平台落地，成功让3-5min的画像分析提升到10s左右，显著提升人群分析的效率，为业务决策提供快速的依据。通过本文我将会分享RoaringBitmap方案在技术平台画像分析的应用实践。

Bitmap原理解释

1、Bitmap数据结构

Bitmap 是一种通过位（bit）来存储和操作数据的数据结构，具备高度的空间效率和计算效率。它在人群画像分析中，例如跟踪大型网站用户行为时，能够极大地节省存储空间，并提高处理速度。

原理描述：

• 用一个bit位来标记某个元素对应的Value，而Key即是该元素。
• 如果一个数存在，则将这个数对应bit设置为1，否则置为0。

如下图：有一堆用户id，其中用户id为3、4的用户是勇士球迷； 如果用Bitmap表示的话，那么key是勇士球迷； value是Bit数组。那么最后用户id用Bitmap存储如下：

Bitmap的详细原理如下图：

• 默认情况下每个用户都有自己对应的一个特征，比如user0对于特征0，user1对应特征1，等等；这种是常规的存储方式，如果这样存储，计算特征的时候一般要进行关联查询。
• 我们需要把对应关系转换为Bitmap形式，Key为特征，特征背后对应的是一个Bit数组，如果用户拥有这个特征，那么对应的数组位Bit置为1。 这样只要给一个特征，就可以知道有多少用户拥有这个特征，而不需要遍历所有数据。
• 当多个特征都通过Bitmap存储的时候，多个特征进行计算只需要通过位运算就可以，而不需要再关联查询，所以极大的提升了数据处理效率。

从以上原理图可以看出，Bitmap可以将数据转化为数组位存储，不仅可以节约存储空间，也可以进一步提高查询效率。

2、RoaringBitmap

虽然Bitmap已经让数据的存储空间有了N倍的缩减，但Bitmap的问题在于，不管业务中实际有多少个元素，它必须包含元素的最大值个bit空间，如果元素的取值范围是0-10亿，那么就要有10个bit空间，如果元素的取值比较稀疏，例如10亿个值中只有极少数据满足需求，那么这样的稀糊数据会造成严重的空间浪费，且也会占用大量的内存计算，所以我们一般还需要对Bitmap进行压缩处理。

RoaringBitmap就是一种高效的Bitmap压缩算法，适合计算超高基维的数据，常用于去重、标签筛选、时间序列等计算中。Roaring Bitmap算法是将32位的INT类型数据划分为216个数据块（Chunk），每一个数据块对应整数的高16位，并使用一个容器（Container）来存放一个数值的低16位。RoaringBitmap将这些容器保存在一个动态数组中，作为一级索引。

在 RoaringBitmap 中，容器（Container）是用于存储整数的数据结构，主要有三种类型：数组容器（Array Container）、位图容器（Bitmap Container）和运行长度编码容器（Run Container）。下面引用至RoaringBitmap的官方介绍，详情可以参考官网：https://roaringbitmap.org/

• 数组容器（Array Container）  ：这种容器使用一个数组来存储整数，适用于稀疏数据的情况，即数据之间的间隔较大。例如，如果一个容器内的整数数量小于4096，就使用数组容器来存储，因为在这种情况下，使用数组容器比使用位图容器更节省空间。
• 位图容器（Bitmap Container）  ：位图容器使用一个长度为65536的位数组（bit array）来存储数据，适用于稠密数据的情况，即数据之间的间隔较小。例如，如果一个容器内的整数数量大于4096，就使用位图容器来存储，因为在这种情况下，使用位图容器比使用数组容器更节省空间。
• 运行长度编码容器（Run Container）  ：运行长度编码（Run-length Encoding，RLE）是一种简单的数据压缩算法，适用于连续重复数据的情况。在 Roaring Bitmap 中，如果一系列连续的整数都存在于位图中，那么可以使用一个运行长度编码容器来存储这些连续的整数的起始值和长度，从而节省空间。

RoaringBitmap 根据实际的数据情况，动态地选择最适合的容器类型，从而实现了既高效的数据存储，又快速的数据查询。在做位图计算（AND、OR、XOR）时，RoaringBitmap提供了相应的算法来高效地实现在多个容器之间的运算，使得RoaringBitmap无论在存储和计算性能上都表现优秀。详细的实现原理图如下：

在实际的使用中一般使用RoaringBitmap来，并且官方也提供了对应的Java库地址，可以直接拿来使用。

技术平台基于RoaringBitmap的画像分析使用实践

技术用户画像分析是对一个或多个指定用户群，通过可视化的方式，可以多维、立体的展示用户群的画像信息，让运营更好的理解人群，实现人群细分及对个性化运营策略的制定提供能力支撑；在进行数据分析时，更加便捷的获得人群的特征信息，从而更好的进行定量的分析。

业务画像分析流程：

1、默认情况下平台有业务的所有标签在MaxCompute中存储，同时也会存储一份Bitmap的标签索引数据，再标签数据更新时构建。

2、业务可以使用标签和其他用户相关的数据圈选人群，人群圈选完成后，也会对其构建一份Bitmap索引数据。

3、圈选完人群后，就会进行画像分析，如果标签和人群都有Bitmap索引数据，就会通过Bitmap进行分析

1、方案对比

技术平台早期画像分析主要依赖于MaxCompute执行SQL，但这种方式耗时较长，对于需要实时洞察分析的业务场景，分析需要更加快速看到结果，高延迟无法满足业务需求。之前尝试通过将数据导入Hologres进行加速，然而由于数据量庞大，Hologres的执行耗时仍然超过3分钟。

在前期，根据业务需求我们也在技术上做了一些调研。从技术方案角度看，一些可以实现的画像分析的方案和其缺点：

方案名称	缺点
MaxCompute进行查询	MaxCompute的任务执行耗时较长，并且是异步的，无法满足实时查询的需求。
Hologres JSONB	Hologres有JSONB列存方案，可以通过列式存储优化查询效率，但是因为业务还是有join，仍然是N^2的关联查询，大数据量的情况下查询效率相比Bitmap仍然有一定的不足。
ClickHouse	成本较高，在阿里集团内的应用场景较少，实践少。

而Hologres原生支持RoaringBitmap数据结构，特别适合大数据量级下的交并差运算，并且在画像分析的场景天然适合，因此我们最后选择了RoaringBitmap方案。虽然RoaringBitmap会带来额外的处理和优化步骤、索引构建过程，这可能会带来一定的初期成本上升。然而，在我们的场景中，数据更新不是那么频繁，数据量级也在可控范围内，因此这一成本上升在可接受范围。而且使用RoaringBitmap带来的效率提升非常明显，最终还是选择使用这一方案进行标签和人群加速。

2、核心流程

• 平台人员：  筛选可加速的标签，然后配置在平台上，平台每天在标签数据更新完成后构建对应的标签Bitmap索引

• 小二同学：

• • 在圈人的时候，可以考虑勾选人群开启分析加速、或者核心空间会圈完之后会自动构建人群的Bitmap索引。
  • 在进行人群洞察分析的时候，点击画像分析，弹出可分析的标签，可进行加速的标签会标记