画像系统人群服务数据存储架构的演进与创新| 京东云技术团队
一、画像系统命中接口相关简介
什么是画像系统
标签画像系统是一种数据管理和分析工具,它通过整合和分析用户的行为数据、交易数据、社交数据等多维度信息,构建出用户的详细画像,帮助咱们运营人员更好地理解目标用户群体,从而实现精准营销和精细化运营。
提供了那些能力:标签注册,标签沉淀,标签取值;群体圈选;群体服务(群体命中,群体下载和订阅等)核心能力
怎么实现精准营销和精细化运营
命中接口:它作为连接用户数据和营销活动的桥梁,确保了营销信息能够准确地传递给最合适的用户群体。
业务场景
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-16lTqLWByne164z1w.png)
在支付、消金、财富等核心业务中发挥着至关重要的作用,影响着用户拉新、交易转化、促活等关键环节。
命中接口实现逻辑
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-16wmZWXN4kY9JOQA9..jpg)
挑战
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-1616HLjOw8HNuTolNr..jpg)
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-16RWDWVPQG16tMz6QP..jpg)
二、画像系统1.0和2.0版本的命中接口
存储方式(物理机内存)
将人群数据从OSS拉取并存储在物理机(32C256G)中,由于群体数量过多,256G不足以将所有的群体的OSS文件都保存下来,所以采用分片的逻辑,每个分片只存储群体OSS文件的四分之一。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-16xURmG16RA7uprNWu..jpg)
方案优缺点
优点:
1、性能达标:基于内存取值,减少中间件依赖,单机压测到30000TPS,TP999最高40ms;
2、存储成本较低:在当时,和直接使用缓存相比,成本较低;
3、缓解了CK的压力:从OSS拉取文件,减少了CK查询次数。
缺点:
1、初始化群体非常慢:由于数据是存在机器内存中,每次启动机器总要全量加载所有群体,但随着业务发展,群体数量的增加重启也会越来越慢;
2、扩容成本高:虽然分组内可以水平扩容,但是固定分组后,单机器的内存有限,一旦达到上限需要扩容分组时,必须成倍的扩容,导致扩容分组困难;
3、排查问题效率低:由于是自研的依赖于机器内存的存储方案,整体结构复杂,在运维的能力方面偏弱,运维的相关工具少。
三、画像系统3.0版本的命中接口
背景
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-16K1P9tzZpGyc6R8b.png)
存储方式(物理机内存)
依旧将人群数据存储在物理机中,但使用了拆分前置的操作,并且将原先的物理机四份片改为了八分片。先将群体的OSS文件拆分成8分,然后物理机对应的分片只需要去拉取自己分片对应的文件即可。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-16JBRxlfBCtbuuOd33..jpg)
数据分层方案(缓存)
为什么需要使用缓存做数据分层
存储方式
因为set集合的特征,元素小于512个会自动压缩,所以我们使用set集合来存用户的offset的。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-16jpqaHOIJ7LPOyxE..jpg)
四、画像系统4.0版本的命中接口
背景
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-16M9tqSXf1a16TR16ez.png)
由于在3.0的时候,offset的编码已经超过了2的32次方。我们使用的ck版本加工群体位图的时候不支持大于2的32次方位图计算,升级版本不兼容。对ck计算层架构升级:小于32位的offset计算到现有的bitmap中,大于32位的offset计算时,所有offset - 2^32,计算到高32位bitmap。基于这点想到了如果低成本使用R2M。也可以通过开发达到RoaringBitmap的压缩效果。
为什么要压缩
我们知道创建Bitmap的时候,长度必须是最大的offset的长度。再结合我们的场景,我们现在的pin数量已经超过了数十亿,但是每个人群不可能都是数十亿之多,所以我们位图存储的数据不是连续的,而是稀疏的。
假设我们现在只有64个用户,然后有一个人群包,只有1个offset,63。
按照正常我们需要创建一个64位的Bitmap
1 | 2 | 3 | …… | 63 | 64 |
0 | 0 | 0 | …… | 1 | 0 |
这时候我们就把数组拆分成2组,1到32的用户存储到第1组,把33到64的用户存储到第二组。此时我们发现第一组的数组里全是0,那第一组是不是可以不创建?这样我们就用一个32位大小的数组存储了64位的数据。
接下来更进一步,把64位的数组拆成每16个一组,那么我们只需要创建最后一个分组的数组,也就是16位的数组来达到进一步压缩的目的。
49 | 50 | 51 | …… | 63 | 64 |
0 | 0 | 0 | …… | 1 | 0 |
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-1633wMUKsLlWMGfy60..jpg)
压缩流程
根据我们的业务场景,每个位图大小是65536压缩效果最好。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-16lES0k4tUwIC416lS..jpg)
存储方式(缓存)
部署多个R2M集群(或分组),将群体bitmap进行拆分,并根据一定的路由策略存储到不同的集群上,通过不同的集群提供查询能力,如下图
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-16dJHZdN4Fmu1BYbk..jpg)
在新方案中,增加了一整套的群体推送服务,包括数据的新增,更新,删除,检测,重试等全部可视化到页面,大大增强了群体加载的可监测性及有效性,而在之前的方案中,非常缺少这些有效的运维手段。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-23-16-50Bo23tdKTUvqZ98N23.png)
流程对比
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-16ctsz116roneVCSSI..jpg)
采用集中缓存替换自研分布式存储优缺点对比
自研分布式存储 | R2M存储(新方案) | |
劣势 | 优势 | |
稳定性 | ·突然新增的大量人群信息新增或变更,堆内存变化比较剧烈,容易达到服务器上限 ·恢复周期长:服务器出现宕机后,恢复周期较长 ·单分片比较大,单台命中存储服务的流量占比比较大,出现故障时,影响比较大 | ·R2M具有自动扩容的能力,当达到了一定的使用比例,分片会自动扩容 ·分片出现宕机,会主从切换,瞬间恢复,并且支持异地机房备份 ·单分片比较小,影响范围更小 |
维护成本 | ·启动慢:单台存储服务启动比较慢,启动最长达到30分钟 ·上线难:总共有103台服务器,65个分组(8个预发分组,57个生产分组),分组管理比较复杂,配置文件比较难以管理,启动要注意的事项比较多 ·扩容难:由于各分组是有状态的,并且要求均是特殊的物理机,扩容相对复杂 | ·没有这个节点了,不存在启动慢,上线难问题 ·扩容简单:自动扩容或者提扩容工单即可 ·缓存集群由运维团队在维护,他们有专业的团队和工具维护 |
硬件成本 | ·总共103台物理机服务器,其中预发服务器 8台,命中服务器48台,下载服务器8台,其他39台(待下线)--32C192G服务器 | ·R2M是科技集群,碎片会更小有的管理和使用,可以更有效的使用缓存空间 ·不存在预发的服务器一直在在浪费 ·40亿集群大概500M,如果是13000个平均是10个亿的人群,大概是1.5T,主从结构大概就是3T,换算成成192G的物理,大概就是15台物理机,如果保持水位是60%的话,大概物理机是25台物理机 |
其他 | ·只在初始化时拉取一次OSS文件即可,减少带宽占用 |
性能对比
接口整体TP999耗时从40ms下降到10ms以内
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-28-17-49sYBzhHCWmtdgzs6.png)
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-28-17-46efFmjZXyvb6eMmp.png)
五、命中接口的后续探索
一、逆向存储
背景
我们对一些耗时长的请求进行分析时发现,有些业务方传的群体编码,一次可能传几十个,这种情况我们可能需要判定几十次,然后把结果返回给用户,性能肯定比一次只传一个群体会差。所以我们想使用用户的pin当作key,然后value是用户所在的群体数据。这样不管用户一次传多少个群体,我们只用取一次缓存就可以。
存储方式
key:用户的pin的offset为key
value:用户所在的所有群体集合(以位图的方式存储)
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-16B6B1BbNbhdiHDrA..jpg)
优势
二、规则判定
背景
发现有些用户在创建群体的时候,只用到了标签,然后对这些标签做逻辑与或非的操作。
举个例子:如果用户选择了两个标签(标签1:男性,标签2:三十岁以上,而且是且的关系)创建了一个人群,现在想判断一个pin是否在这个群体里面,我们可以怎么操作?我们只需要先判定用户是否是男性,然后判断用户是否三十岁以上,然后在内存中做逻辑且的操作就可以了。
优势
六、相关技术附录
CDP系统中目前存在大量由pin集合组成的标签和群体,截止当前共有标签4000+,有效群体17000+。而且大量的群体都是pin数量都是千万级别以上,甚至有的群体pin数量达到了40亿+。如此大量的pin集合,对我们存储结构提出较高的要求。
这里拿群体举例,如果某群体包含1000W个pin,通过文本文件存储,大概需要150M,40亿的群体就达到了惊人的150*40*10=60000M,大约60G,而我们的群体数量已经达到了17000+,再加上标签数据,所需要的存储空间将不可接受。
并且,数据的存储只是其中一个方面,后续针对标签和群体的组合计算,创建出更细粒度的pin包也是一个挑战。
面对以上问题,CDP采用了Bitmap的思路来解决,不但解决了存储空间问题,而且Bitmap本身的交并差运算,能够很好的支持用户对不同标签和群体的组合计算,详细方案如下。
一、bitmap简介
它的基本思想是用bit位来唯一标记某个数值,这样可以用它来记录一个数值没有重复的数据元组。并且每一条数据只使用一个bit来标识,能够大大的节省存储空间。
比如,如果想存储一个数值数组[2,4,6,8]。
Java中如果用byte类型来存储,不考虑其他开销,需要4个字节的空间,一个字节8位,也就是4*8=32bit。
倘若使用更大的数据类型,存储空间也会相应增大,如使用Integer(4字节),则需要4*4*8=128bit。
而如果采用bitmap的思想,只需要构建一个8bit空间,也就是一个字节的空间来存储,如下图。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-161VQelQcX41rv8zq..jpg)
二、pin池编码
通过上文的例子,可以看到,使用Bitmap思想来存储,实际上每一个数据是一个bit,而且不能重复,这一点用户pin是符合的,没有重复的pin。
由于bitmap里只能存0或者1来标识当前位是否有值,而用户pin确是一个字符串,这就需要将数十亿的用户pin进行唯一性编码,这个编码也就是我们常说的offset偏移量。
每一个pin对应一个唯一的offset,目前已到46亿+,也就是说当前最大的偏移量是45亿+,这部分由数据同学帮我们加工一张pin池表,其中包含了pin和offset的对应关系。这样,新注册的pin,只要顺序增加offset值即可。
下边是一个简单示意图,假设我有8个pin,pin1~pin8,对应的offset编号为1~8。
我要建一个只包含双数pin的标签或群体,则我只需要将offset为2,4,6,8的位设为1即可。
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-16lWRMzUHj0RbWDGU..jpg)
三、ClickHouse简介
有了位图之后,存在哪里,以及怎么进行位图之间的交并差的运算。基于这些问题,我们使用了ClickHouse(以下简称CK),一个由俄罗斯Yandex在2016年年开源的⾼性能分析型SQL数据库,是一个用于联机分析处理(OLAP)的列式数据库管理系统(columnar DBMS)。
它具有以下特点:
1、完备的数据库管理功能,包括DML(数据操作语言)、DDL(数据定义语言)、权限控制、数据备份与恢复、分布式计算和管理。
2、列式存储与数据压缩: 数据按列存储,在按列聚合的场景下,可有效减少查询时所需扫描的数据量。同时,按列存储数据对数据压缩有天然的友好性(列数据的同类性),降低网络传输和磁盘 IO 的压力。
3、关系模型与SQL: ClickHouse使用关系模型描述数据并提供了传统数据库的概念(数据库、表、视图和函数等)。与此同时,使用标准SQL作为查询语言,使得它更容易理解和学习,并轻松与第三方系统集成。
4、数据分片与分布式查询: 将数据横向切分,分布到集群内各个服务器节点进行存储。与此同时,可将数据的查询计算下推至各个节点并行执行,提高查询速度。
更多特性可查看官方文档:https://clickhouse.com/docs/zh/introduction/distinctive-features
还可以查看同事的这篇文章:如何使用Clickhouse搭建数十亿级用户画像平台看这一篇就够了
除了上文CK的特性之外,它还具有分析数据高性能,开发流程简便,开源社区活跃度高,并且支持压缩位图等优势。
四、群体加工链路
基于上面对bitmap以及clickhouse的介绍,我们采用的是ClickHouse+Bitmap实现标签群体组合计算和群体的存储
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-16ulSFce3344Z4wYqE..jpg)
上图可以看到除了CK中的数据外,我们在OSS对象存储中也放了一份群体数据。
五、RoaringBitmap压缩
我们最终使用的是RoaringBitmap,一种高效的压缩位图实现,简称RBM。于2016年由S. Chambi、D. Lemire、O. Kaser等人在论文《Better bitmap performance with Roaring bitmaps》 《Consistently faster and smaller compressed bitmaps with Roaring》中提出。
基本实现思路如下:
以整型int(32位)为例,将数据分成高16位和低16位两部分,低16位不变,作为数据位Container,高16位作为桶的编号Container,可以理解为高位的Container中,存放了很多个低位Container。
比如,我要存放65538这个值,则高位为65538>>>16=1,低位为65538-65536*1=2,即存储在1号桶的2号位置,存储位置如下图:
![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2024-04-01-16-1616BQlFvveLFUSVpN..jpg)
我们当前使用的RoaringBitmap版本为0.8.13,Container包含了三种实现:ArrayContainer(数组容器),
作者:京东科技 王京星
来源:京东云开发者社区