基于 MaxCompute + Hologres 的人群圈选和数据服务实践

最新推荐文章于 2024-07-01 09:39:51 发布

阿里云技术

最新推荐文章于 2024-07-01 09:39:51 发布

阅读量433

点赞数

文章标签：运营

本文链接：https://blog.csdn.net/weixin_43970890/article/details/120434754

版权

本文介绍了基于MaxCompute + Hologres的人群圈选系统，强调了服务引擎的核心诉求，包括毫秒级洞察、灵活筛选能力和高吞吐更新能力。Hologres作为一站式实时数仓，提供了预计算模式、高性能查询和实时更新的能力，适用于大规模数据的交互式分析。文章详细阐述了Hologres如何通过位图索引、向量化执行引擎等技术实现高性能，并探讨了适合的场景和数据结构模式，如宽表、窄表和预计算模式。

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

人群圈选系统基本逻辑架构

人群圈选并不是一个新业务，几乎所有的互联网公司都在做，因为这是一个基本营销场景，选定的人群要发代金券，要导入流量，要做针对性促销，要选择合适的人群，那怎么做这件事情呢？实际上要通过人群的行为特征，采购特性，关注特征，兴趣特性，甚至是教育程度等等，把人群划分成不同的组。通过划分人群组，在有限的营销预算里面，将资源投放给转化率或点击率最高的人群。

基本的业务架构逻辑如下图，自下而上。首先是标签加工引擎，主要以离线加工为主。在标签加工引擎内，会对用户历史的采购行为、访问行为、关注行为等等做很多标签，可以统计出来，哪些人对哪些商品关注过多少次，点击过多少次，留意过多少次等等，会有很多统计性的属性在里面。这些标签会导入到在线画像服务引擎内，服务引擎是给运营人员，广告主进行交互式的查询，因为要根据用户行为特征，筛选出最关注的用户群体。这个用户群体可能是30天内关注某些商品但是没有买的群体，或者是相关的上下游产品，通过行为特征筛选出来。筛选过程是一个高度交互过程，因为一个人的行为特征是非常复杂的。所以需要频繁的选择某个条件，去掉某个条件，条件和条件之间可能会做合并、去重的操作等等。直到把人群大小限定到预算可支持的范围内，比如我们要投递给1万个人广告，那要通过各种限定条件把这1万个人找出来。找出来还不能做直接投递，还需要对人群做更细粒度的分析，通过历史数据行为分析这1万个人是不是想要的目标人群。之后会把目标群体以投递包的形式，导出给投递系统。这是一个基本业务逻辑。

那这个业务需求的背后技术要求是什么呢？

典型人群业务版块的核心是洞察分析，洞察分析一般的场景是，要支撑几万个不同的广告主，他们会在平台上自由选择更感兴趣的人群，每个广告主对人群的诉求是不一样的，某些人关注的购买力，有些关注的是收藏行为。每天数万广告主发出数百万次的查询请求，构建数万次各种人群包，各个系统的计算复杂度是要求非常高的。这里的核心诉求包含几个点，毫秒级洞察，因为所有的查询希望是交互式的，需要在界面上每一次互动，每一次下拉菜单，每一次选择，每一次条件组合，都希望看到一个互动结果，整个人群是变大还是变小，目标人群是不是跟期望的相似。这一点对性能要求是非常大的。同时提醒大家，数据一定要脱敏处理，保护好用户的个人隐私，所有的分析都是建立在合规数据基础之上的分析。

人群圈选系统服务引擎核心诉求

规模数据上的交互式分析性能

数万广告主提交数百万次的数据查询，需要毫秒级的响应，查的快是必须的。这个快加了一个限定词，是规模数据。百万级不算规模，行为日志是非常大的，希望是百亿级别以上，依旧有一个很好的交互式分析能力，能够在秒级响应。

灵活筛选能力

用户的筛选行为多种多样，等值比较、数值大小范围比较、时间范围比较等。各种各样的筛选条件能够灵活组合，表达这些筛选结果就体现出来计算引擎的能力。

高吞吐更新能力

用户标签并不是静态的，当前一切实时化，一切在线化，所有的行为数据变化，都希望能够实时触发，实时反馈下一时刻的系统决策。比如最新收藏夹里放了什么商品，这种行为能不能成为在线画像的一部分。所以对高实时的吞吐能力要求会很高。

从计算层面来讲，可以分成下图几种计算模式。

标签过滤分为等值过滤，可以用Equal/In/Between，这些过滤可以在百亿级别上进行操作。操作之后的结果集，要做很多的交差并集，举个常见例子，一个用户既关注了竞品品牌也关注了本公司商品，却没有买，这里面其实有并的关系，有差的关系，有交的关系。所以这些人群关系之间要组合，有很高的交差并集计算。最后还有很强的精确去重的需求，因为最终要把计算结果，变成一个唯一定位用户的ID，这个ID会用来做广告的投递。那这些需求，在引擎层面上就是数据读取效率怎么样，如果用行存读取是不是会出现IO放大的问题，数据按行去存，真正过滤是按照某一列过滤，但是IO读取，会把整行读取，会出现IO放大问题。列存还会有索引问题、过滤效果问题。计算算子上表连接时是Hash JOIN方式还是用Nest Loop JOIN方式。精确去重的效果如何。这些都是对计算引擎效率上有很高的要求。所以本质上是要解决高效数据存储与过滤、关系运算内存/CPU消耗、精确去重内存/CPU消耗问题。

这里就有很多不同的解决优化思路，是用更多的内存还是CPU。行业内大致的思路有两种。

一种是通过预结算思路，有Kylin/Druid这样的技术。这些技术可以在一些预定义的维度上，进行一次提前的预加工。预加工后，数据集会在本质上进行减少。比如要找一个用户群体，关注了第一个商品却没有关注第二个商品。每一个结果集都可以用bitmap数组来表达，数组之间做交差并集效率是非常高的。预计算技术实际上是把精确去重和交差并集上计算是有很大好处的。但缺陷也比较明显，最大的缺陷就是不灵活，同时完整SQL表达能力也比较弱。另一种是属于MPP分布式数据库技术，一些通过列存、分布式、索引方式提供更好的查询性能。

所以真正落地一套人群筛选方案时，一般不是只选择一个方案。因为不管是预计算方案还是MPP方案都有一些本质的缺陷。