2021最新 阿里云PostgreSQL精选案例 - 实时精准营销、人群圈选

行业:

几乎所有行业, 如互联网、新零售、教育、游戏等.

应用场景:

根据目标群体的特征, 快速提取目标群体.
例如,

• 在电商行业中, 商家在搞运营活动前, 根据活动的目标群体的特征, 圈选出一批目标用户进行广告推送或活动条件的命中.
• 在游戏行业中, 运营经常会根据游戏玩家的某些特征圈选, 针对性的发放大礼包, 激活游戏活跃度.
• 在教育行业中, 根据学生不同的特征, 推送不同的有针对性的习题, 提升学生的弱项.
• 在搜索、门户、视频网站等业务中, 根据用户的关注热点, 近期行为的不同, 根据群体推送内容.

场景痛点:

业务特点:
1、数据量庞大, 运算量大
2、用户标签多, 字段多, 存储占用空间多
3、字段多, 可能超过数据库的字段数限制, 一般数据库最多支持1000多个字段.
4、使用数组替代多字段存储标签, 需要数据库支持倒排索引, 不是所有数据库都支持倒排索引
5、使用数组代替多字段存储标签, 加上倒排索引, 存储空间会暴增
6、圈选条件组合多样化, 没有固定索引可以优化, 每个字段一个索引, 存储空间暴增
7、性能要求高, 实时营销, 要求秒级响应
8、数据更新时效要求高, 用户画像要求近实时的更新, 如果不能准实时更新很可能圈选到的用户不精准(例如用户昨天在浏览手机. 昨晚已下单, 但是数据未更新, 那么作为手机卖家圈选时这个用户就会被选中, 但是实际上已经不是目标群体)

业务痛点:
在常见的产品如MySQL中, 无法在有限的资源下, 满足实时圈选目标群体的需求.

技术方案:

方案1

表结构:

KEY: 用户ID  
标签1:   
标签2:   
...  
标签N:  

索引:

每个标签字段一个索引  

搜索方法:

and , or , not 组合  
where 标签a and 标签b and ...  

缺陷:

• 用户标签多, 字段多, 存储占用空间多
• 字段多, 可能超过数据库的字段数限制, 一般数据库最多支持1000多个字段.
• 圈选条件组合多样化, 没有固定索引可以优化, 每个字段一个索引, 存储空间暴增
• 新增一个新多用户群体(标签)时, 需要更新大量数据
• 查询性能差

• 方案1也可以是多对多的结构, 每个标签一条记录, 解决字段数限制的问题.

  • 当然了, 字段数限制还可以通过拆表来解决, 但是查询的时候就可能需要跨表JOIN了.

方案2

表结构:

KEY：用户ID  
VALUES：标签数组  

索引:

标签数组字段: GIN倒排索引  

搜索方法:

与、或、非  
where VALUES @> array[标签s] -- 与  
where VALUES && array[标签s] -- 或  
where not VALUES @> array[标签s] -- 非  

缺陷:

• 使用数组替代多字段存储标签, 需要数据库支持倒排索引, 不是所有数据库都支持倒排索引
• 使用数组代替多字段存储标签, 加上倒排索引, 存储空间会暴增
• 新增一个新多用户群体(标签)时, 需要更新大量数据

方案3

表结构:

KEY：标签ID  
VALUES: 用户bitmap  

索引:

标签ID字段: Btree索引  

搜索方法:

聚合bitmap: 与、或、非  
and_agg(bitmaps) where KEY in (标签s) -- 与  
or_agg(bitmaps) where KEY in (标签s) -- 或  
except(bitmap1,bitmap2) -- 非  

缺陷:

• bitmap最大长度为1GB, 用户数超过长度需要使用offset, 方法如下:

  • offset0_bitmap, offset1gb_bitmap, ...
• 用户ID需要是数字(建议连续数值), 如果没有数值型UID, 需要治理, 建立映射表.

优势:

• 表存储占用空间小