关于用户画像系统，我们分享过很多相关的内容，包括《相似人群的扩展look-alike》、《用户关键特征的提取》、《用户画像系统的应用》等。今天分享一个基础功能的实现：人群包大小的实时计算。
01、项目背景
首先聊聊，人群包的实时计算，到底是咋回事。
之前的《画像应用》中讲过，画像系统的一个重要应用，是通过标签的组合，进行人群圈选，从而获得人群包，进行精准人群触达。而业务人员为了获得一个“满意”的人群包，往往需要进行多次的圈选逻辑调整。如下图：
而人群包的圈选生成，往往是离线的技术过程，如果等人群包圈好了才看到人数大小，用户再进行逻辑调整，无疑效率是极低的。
根据圈选条件，实时反馈人群包的大小，这就是人群包的实时计算。
对了，聪明的小伙伴一定发现了，如果圈选的逻辑很松了，圈出来的人仍然很少咋办？对，那就要用相似人群扩展功能了。具体参考以前的文章《相似人群扩展》，不再赘述。
02、技术实现过程
关于实时计算人群包大小的技术实现过程我们简单分享一下，还是蛮有意思的。
（1）整体架构
首先看一下整体的技术架构：
大家可以看一下上图中两个技术方案的差别。左边是旧版计算方案，计算效率很低，右边是新版计算方案，计算效率基本是秒级返回。
（2）数据的处理加工
看看我们怎么把hive中的明细数据加工成标签数据。下面是原始的数据存储结构：
我们期望的标签数据为：
关键的差别在哪呢？
对，原始的数据存储是按照userID为主键存储的，每条记录是该用户的详细数据情况；而加工转换以后的数据表，是按照标签为主键的，且只有三列：日期、标签、人群包。
为啥要进行这样的转换呢？
因为原始按照用户为主键的存储，数据量是巨大的。一方面用户量比较大，另一方面存储的字段量也大，对存储的挑战是比较大的。而转化之后的表格，按照标签为主键存储，记录数量大大减少。
（3）人群数量的计算
hive中的明细数据加工成标签数据，其存储还是在hive中，不适用于同步接口的使用场景。所以需要将hive中的数据导入到在线olap引擎中，我们选择了gp。
hive → gp 中间需要经过oss转储（为了优化速率），所以最终数据的流向为：hive → oss → gp。
gp中最终的表设计为（只截取部分核心字段）：
需要注意的是gp中的tag_audience是bitmap格式存储，为了解决存储以及使用位运算快速做标签的交并差，所以gp中存储的实际数据为：
【1101】代表第1、3、4个用户（从右往左看）都有这个标签，第2个用户没有。【1010】代表第2、4个用户有这个标签，第1、3个用户没有。
实际人群包是一个 2^32 位的bitmap（最大为512M），即一个bitmap可以存储 2^32 = 4294967296 的用户集合。
所以计算不同标签的交并差，就成了计算不同人群包的位运算，这个计算速度是很快的。
以上就完成了人群包实时计算的技术过程。
03、产品化示例
其实关于产品化，可简单可复杂。各给一个案例吧。
（1）京东
以下是京东人数计算的产品化过程：
前序的人群圈选过程是维持现状的。在圈选完之后，提供【人群计算】的按钮，支持用户进行人数的查看。
如果人群量不符合预期，可以继续调整圈选逻辑。
（2）达摩盘
以下是达摩盘的截图：
达摩盘确实是非常成熟的产品了，这里在选择标签的时候，会直接呈现覆盖人数，并给出可触达人数的预估，这个体验是非常好了。
关于画像系统中，实时计算人群包的人数，就分享到这，欢迎继续关注。
