dmp只导数据不导结构_bitmap用户分群方法在贝壳DMP的实践和应用

最新推荐文章于 2023-06-25 03:01:30 发布

weixin_39738416

最新推荐文章于 2023-06-25 03:01:30 发布

阅读量356

点赞数

文章标签： dmp只导数据不导结构

本文链接：https://blog.csdn.net/weixin_39738416/article/details/111605871

版权

本文介绍了贝壳DMP平台如何利用bitmap实现用户分群，以提高数据处理速度和准确性。通过将用户标签转化为bitmap结构，进行交、并、补运算，实现了秒级别的人群包数量预估和分钟级别的运算。文章详细阐述了bitmap数据结构、用户ID生成、标签逻辑转换、Hive到ClickHouse的数据迁移以及bitmap SQL的生成过程。

摘要由CSDN通过智能技术生成

1. 背景介绍

DMP数据管理平台是实现用户精细化运营和和全生命周期运营的的基础平台之一。贝壳找房从2018年5月开始建设自己的DMP平台，提供了用户分群、消息推送、人群洞察等能力。关于贝壳DMP架构的介绍可参考文章：DMP平台在贝壳的实践和应用。

目前，贝壳DMP数据覆盖了贝壳和链家的数亿用户，用户偏好和行为数据量达到数十亿，拥有上千维画像标签。在海量用户画像数据基础上实现用户分群，同时满足业务方越来越复杂的标签组合需求，提高人群包构建速度同时保证数据准确性，为此，我们对DMP平台进行了持续的迭代优化。

本文主要介绍bitmap(位图)用户分群方法在贝壳DMP中的具体实践和应用。该方案上线后，贝壳DMP平台支持了秒级别的人群包数量预估，分钟级别的复杂人群包逻辑运算。

2. 用户分群方式介绍和对比

用户分群是在人群画像的基础上实现的。DMP平台上包含已经加工处理好的用户画像标签，运营等同学通过在前端选择一些标签，设定这些标签之间的逻辑关系，通过引擎层的计算，最终得到符合这些标签条件的用户的集合。

在Hive数据层，用户画像是以关系型数据表的形式进行存储的，即构建了用户-标签的映射关系。考虑到Hive查询速度等方面的限制，我们最终选择了ClickHouse(下文简称CH)作为DMP平台底层的存储和计算引擎。在Hive数据表产出之后，通过启动Spark任务将Hive中的画像数据导入到ClickHouse中。

在上一版本的实现中，CH中存储的是与Hive类似的关系型数据表。通过将人群包的标签组合逻辑转化成CH SQL，将标签取值条件转化成SQL的WHERE条件部分，过滤查找符合标签条件的用户，进行得到符合条件的目标用户集合。但是这种方式一般要涉及到全表数据的扫描和过滤，且画像数据一般存储在多张表中，当选择的标签分布在不同的表中时，还会涉及到中间结果之间的JOIN，限制了人群包数据的产出速度。

如果从另一个角度思考，使用标签进行用户分群，其本质还是集合之间的交、并、补运算。如果能够将符合每个标签取值的用户群提都提前构建出来，即构建好标签-用户的映射关系，在得到人群包的标签组合后直接选取对应的集合，通过集合之间的交/并/补运算即可得到最终的目标人群。bitmap是用于存储标签-用户的映射关系的比较理想的数据结构之一。ClickHouse目前也已经比较稳定的支持了bitmap数据结构，为基于bitmap的用户分群实现提供了基础。

3. Bitmap用户分群方案思路

我们以开源数据库ClickHouse的bitmap数据结构为基础，将符合某个标签的某个取值的所有用户ID(INT类型)存储在一个bitmap结构中，构建出每个标签的每个取值所对应的bitmap。

对于多个标签的逻辑组合，使用bitmapAnd、bitmapOr、bitmapXor函数进行bitmap之间的交、并、补运算(另外还有bitmapToArray、bitmapCardinality函数可用于bitmap的转换和基数计算)，最终得到符合该标签组合的所有用户ID集合，即圈选出了所有符合这些画像标签的用户。

基于bitmap的用户分群方案完整流程如下图所示：

整个方案主要包含以下几个技术问题：

如何针对亿级用户构建全局连续唯一数字ID标识join_id？
如何设计bitmap生成规则使其适用于DMP上所有的画像标签？
如何将Hive表中的关系型数据以bitmap的形式保存到ClickHouse表中？
如何将标签之间的与/或/非逻辑转化成bitmap之间的交/并/补运算并生成bitmap SQL？

下面将逐一分析并解决这些问题。

3.1 亿级用户构建全局连续唯一数字ID

DMP系统中，用户都是使用STRING类型的cust_join_key(不同数据表中用来关联用户的关联键)来进行标识的，不能在bitmap中直接使用，需要用INT类型的用户ID来标识所有的用户。同时原hive表中也是不包含INT类型的用户ID这个字段的，所以需要提前准备好bitmap分群方案所需的bitmap_hive表。

如何为DMP平台上用STRING类型的cust_join_key标识的亿级用户生成全局唯一的数字ID呢？hive提供了基础的row_number() over()函数，但是在操作亿级别行的数据时，会造成数据倾斜，受限于Hadoop集群单机节点的内存限制，无法成功运行。为此我们创新性的提出了一种针对亿级行大数据量的全局唯一连续数字ID生成方法。其核心思想如下：

具体解释为：

将全部亿级数据按照一定的规则分成多个子数据集(假设共有M个子数据集，每个子数据集各有Ni行数据，M >= 1，Ni >= 1，1<= i <= M)，确保每个子数据集的数据可以在Hadoop集群的单个节点上使用行号生成函数ROW_NUMBER() OVER (PARTITION BY col_1 ORDER BY col_2 ASC/DESC)生成行号。每个子数据集中的行号都是从1开始，最大的行号为Ni。
对于第1个子数据集(M = 1)的数据，其最终行号是1&