引言 | 是微信小程序官方推出的面向小程序服务商的数据分析平台。其中，画像洞察是一个非常重要的功能模块。微信开发工程师钟文博将为您讲述 画像体系的模块是如何设计的。介绍完基础的标签模块后，我们将重点讲述用户分组模块的设计。希望相关的技术实现思路能对您有所启发。

目录

1 背景

1.1 画像系统简介

1.2 画像系统设计目标

2. 肖像系统概述

3 基础标签模块

3.1 功能描述

3.2 技术实现

4用户分组模块

4.1 功能描述

4.2 实时人群估计

4.3 人群创造

4.4 人群追踪应用

5 结论

01

背景

1.1 头像系统简介

We 是小程序官方针对小程序服务商推出的数据分析平台，其中画像洞察是重要的功能模块，该功能将为用户提供基础的画像标签分析能力，并提供定制化的用户分组功能，从而满足更多个性化的分析需求，支撑更多的画像应用场景。

在此之前，原有的小程序画像分析只有基础画像，相当于只能对固定时间段内的小程序市场进行基础属性分析，无法针对特定群体或者自定义群体进行分析应用。我们希望平台能够提供全面的画像分析能力，除了最基础的画像属性之外，还为用户提供更丰富的标签、更灵活的用户分组应用能力。因此，小程序画像分析计划对相关能力进行优化。

1.2 画像系统设计目标

总体来说，平台支持灵活的标注及人群创建方式，用户可以根据自己的想法选择想要的人群，并根据不同时段手动或自动选择人群套餐，此外还支持人群追踪与分析，多场景应用等。

02

肖像系统概述

从产品形态来看，系统分为两个模块进行讲解——基础标签模块和用户分组模块。

03

基础标签模块

3.1 功能描述

该模块主要满足用户画像的基础分析需求，预计可以满足大部分中长尾用户画像的深度使用需求。主要提供针对小程序大市场的基础标签分析，以及针对特定群体（如活跃：1天活跃、7天活跃、30天活跃、180天活跃）的特定标签分析。如下图所示：

3.2 技术实现 3.2.1 数据计算

从上述函数描述可以看出该函数的特点是官方定义的数据范围可控，并且支持针对特定人群进行特定的标签分析。

利用离线T+1的hive任务来计算特定人群的特定标签分析数据，流程如下。

分别计算特定标签的官方统计量、特定人群的统计量、特定人群的跨特定标签的数据。

3.2.2 数据存储 不同的存储对比是有差异的，经过上面的分析，需要存储的是预先计算的结果数据，再加上业务特点是按照小程序来存储多个数据主题的统计信息，所以第一直觉是 适合分布式OLTP存储。团队也对比了不同的数据库，在选型过程中，对比的重点包括数据的写入和读取性能。

从上图与//的对比可以看出，它更符合这个业务需求，更有优势，因此我们分析了平台几乎所有的预计算结果数据，最终选定它作为离线预计算结果数据的存储，其关键点如下：

目前整个平台的预计算数据已经达到数十亿条数据，数据表超过百张，实际存储量数百TB，整体功能比较全面，开发者只需要补充开发数据生命周期管理工具和删除方法即可，注意事项相同。

如果采用KV引擎进行存储，需要根据KV的特点合理设计存储键，在查询端将键组装、拼接，发送请求进行查询。整个流程的开发逻辑会相对复杂，需要更加注重键的设计。若要实现一个只有汇总数据的趋势图，存储键需要设计成类似格式：{日期}#{小程序}#{指标类型}。

04

用户分组模块

4.1 功能描述

此模块主要提供自定义用户分组能力。用户分组根据用户属性、行为特征对用户群体进行分类，方便用户观察、分析和应用。自定义用户分组可以满足中上层客户的个性化需求。例如客户想看上次6月18日参与某活动的用户群体，并与市场对比其活跃交易趋势；或者客户想验证对比某些群体对优惠券的敏感度，圈子……上述类似的应用会非常多。

在功能设计上，平台需要做到数据丰富、规则灵活、查询快捷，需要支持丰富的人群选择数据，以及预置标签、人群标签、平台行为、自定义上报行为等，支持灵活的标签和人群创建方式，让客户可以按照自己的想法选择想要的人群，根据不同时段手动或自动选择人群套餐，并支持人群追踪与分析，以及人群在多场景下的应用能力。

4.2 实时人群估计

实时人群估算是根据用户客户定义的规则，计算出当前规则下有多少用户命中了该规则，产品交互通常如下：

4.2.1 数据处理

为了满足客户按照自己的想法圈定目标人群的需求，平台支持多种数据源，整体画像数据量巨大，其中预置标签画像在离线HDFS上垂直表存储量高达近万亿/日，平台行为数十亿/日，维度细化，定制化报表行为数十亿/日。

如何设计一个既能节省存储又能加速查询的系统是需要考虑的重点问题之一，总体思路是对预置的标签画像进行压缩存储，对平台行为详情进行预聚合，对维度枚举值进行ID自增编码，将字符串转化为整数以节省存储空间。同时在产品层面增加启用按钮，启用后可导入近期数据，从而控制存储消耗。具体细节如下。

构建用户画像的核心工作是对用户进行标签化。标签是人为指定的高度提炼的特征标识，比如性别、年龄、地域、兴趣，或者是一组用户行为的集合，这些标签集合抽象出了用户信息的整体画面。每一个标签描述了用户的一个维度，各个标签的维度相互关联，构成了对用户的整体描述。目前用户属性和人群标签都是平台提供的，并由平台每天统一更新。平台目前还不支持用户自定义标签，所以这里我们主要讲解一下平台标签是如何计算、处理和管理的。

比如有源标签，该标签每个标签值的编码如下：

对特定人群进行编码。基础组是必需的过滤条件，用于限制用户范围：

标签数据离线存储在垂直表中，表结构如下图所示。标签可以并行独立构建，互不影响。采用垂直表结构设计的好处是不需要专门为纵向开发一张大而宽的表，任务异常延迟不会影响其他标签的产出。但是大而宽的纵向表需要等到所有纵向标签完成后才能开始生成宽表数据，会增加数据延迟的风险。在增加或删除标签时，需要修改表结构。因此在线存储引擎是否支持与离线垂直表模式相匹配的存储结构成为重要的考量。

对于使用大宽表的存储，如 和 ，所有需要在线使用的图片标签都必须在离线计算阶段处理完毕后才能入库，对于 和 这样的图片，可以采用与竖式表对应的表结构，数据可以立即投递到线上集群，从而降低因一个标签的延迟而导致整体延迟的风险。

代码语言：

复制

CREATE TABLE table_xxx(     ds BIGINT COMMENT '数据日期',     label_name STRING COMMENT '标签名称',     label_id BIGINT COMMENT '标签id',     appid STRING COMMENT '小程序appid',     useruin BIGINT COMMENT 'useruin',     tag_name STRING COMMENT 'tag名称',     tag_id BIGINT COMMENT 'tag id',     tag_value BIGINT COMMENT 'tag权重值' ) PARTITION BY LIST( ds ) SUBPARTITION BY LIST( label_name )(     SUBPARTITION sp_xxx VALUES IN ( 'xxx' ),     SUBPARTITION sp_xxxx VALUES IN ( 'xxxx' ) )

‍

如果把标签理解为用户群体，那么所有与某个标签的某个值匹配的用户ID（UInt类型）就构成了一个群体，存储标签与用户的映射关系是一个比较理想的数据结构，最终需要的就是构造出各个标签对应的值，比如性别这个标签群体就对应着男性用户群体、女性用户群体。

性别标签：男->男性用户组包，女性->女性用户组包。

平台行为数据指官方上报的行为数据，如访问、分享等行为数据，用户无需进行任何点对点操作，团队主要对平台行为进行预聚合，计算同维度下的PV数据，减少了后续数据存储和计算量。

同时，维度枚举值会用一个自增ID进行编码，目的是为了减少存储占用，提高写入和读取性能；从效果来看，该团队对可枚举类型的字典ID编码可以节省原有字符类型60%的在线存储空间，同时在同等数据量条件下带来2倍的查询速度提升。

定制化上报数据是指用户自己上报数据，上报的内容包括公共参数和定制化内容，定制化内容的格式为key-，在OLAP引擎中，团队会将定制化内容转换成4.2.2 数据写入存储首先说一下在线OLAP存储的选择，标签和行为明细数据的存储引擎选择对于画像系统来说至关重要，不同的存储引擎决定了不同的系统设计方式。业务团队通过调研发现，业界构建画像系统的存储方案有很多种，团队对常用的画像OLAP引擎进行了对比，如下图所示：

基于以上研究，团队采用了作为画像数据存储引擎的解决方案。在，该解决方案支持多种操作功能，可以非常灵活方便的进行重复检测和基数统计操作，如下图所示。

使用（RBM）来压缩稀疏位图可以减少内存占用，提高效率。该方案的核心思想是将32位无符号整数按照高16位分成桶，也就是最多可能有216个桶，称为 ，在存储数据时，先找到数据的高16位（如果找不到就新建一个），再将低16位放入中间。也就是说，一个RBM就是很多个数据的集合，具体可以参考高效位图压缩的原理与应用。

接下来说一下数据导入在线存储。确定使用哪个存储引擎存储在线数据之后，团队需要将离线集群中的数据导入在线存储。对于标签数据，通常的做法是将原始明细 ID 数据直接导入表中，然后通过创建物化视图构建 RBM 结构以供使用。但是业务明细数据非常庞大，每天近万亿，这种导入方式给集群带来了很大的资源开销。团队使用这套离线计算框架来处理大规模数据，最终将预处理工作全部交给框架，这种方式大大减少了数据写入量，也减轻了集群的处理压力。

具体步骤为：首先会根据id对任务进行分片，然后在每个分片中为每个tag生成一个tag值，保证自定义的序列化方式和RBM兼容。然后写入线上tag表，表中业务团队定义一个物化列字段进行实际存储，写入过程中通过函数将序列化后的字符串转化为（, ）数据结构。

具体表结构如下：

代码语言：

复制

CREATE TABLE xxxxx_table_local on CLUSTER xxx (     `ds` UInt32,     `appid` String,     `label_group_id` UInt64,           `label_id` UInt64,           `bucket_num` UInt32,     `base64rbm` String,          `rbm` AggregateFunction(groupBitmap, UInt32) MATERIALIZED base64Decode(base64rbm) ) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/xxx_table_local', '{replica}') PARTITION BY toYYYYMMDD(toDateTime(ds)) ORDER BY (appid, label_group_id, label_id) TTL toDate(ds) + toIntervalDay(5) SETTINGS index_granularity = 16

另外一个值得关注的问题是存储占用，标签类型的数据是存到type里的，平台行为是存到里的，这样大大降低了存储占用。 4.2.3 数据查询 数据查询方式：如何保证大APP查询，复杂规则下的查询速度如何？在导入过程中，团队会将预置的、平台行为、自定义上报行为按照相同的规则导入到集群中，这样可以保证一个用户在同一台​​机器上查询时，只会进行本地表查询，避免分布式表查询。

为了保证查询性能，团队始终保证所有查询都在本地表完成，如上文所述，数据入库时会按照同一个用户ID的哈希分桶规则，存放到对应的机器节点中。数字编码，经过测试数字编码比字符模式查询性能提升2倍以上。将标签对应的人群转化为方法进行处理，用户的不同规则最终会转化为针尖对嘴的交并差补运算。

对于平台行为，若用户使用模糊匹配，会先查询维度ID映射表，将用户可见维度转化为维度编码ID，再根据编码ID和规则构造查询SQL，使用规则选择器组合不同的查询语句，再使用规则组合器组合不同的子查询，最终判断用户是否命中众筹规则。

基于rpc开发服务接口：利用rpc框架开发查询服务接口。

数据服务上面一层是团队的数据中间件，统一做了流控、异步调用、调用监控、参数安全校验等工作。特别是对于用户量很大的APP，查询多条规则耗时较长，因此业务团队配置了细粒度的流控，保证查询请求的有序性和服务的稳定可用性。

查询表现数据：不同DAU层级的小程序查询表现。

从性能数据来看，对于用户量很大的APP，规则多的时候还是需要几十秒的时间，等待这么长时间并不是一个好的体验，所以针对这些用户量很大的APP，业务团队采用的策略是抽样，通过抽样，可以大大提高速度，而且预估的准确率误差也不大，在可以接受的范围内。

4.3 人群创建4.3.1 实时人群创建

实时众包创建与上面介绍的实时众包规模估算类似，不同之处在于，在众包创建结束时，需要将所选众包的用户详情写入存储，然后将众包规模返回给用户。执行表并将生成的众包写入同一台机器，以保持分桶规则一致。

4.3.2 常规人群创建

客户创建的常规众包需要每天计算，如何才能持续跟踪分析趋势，又不给集群带来太大的计算压力？团队利用离线超大规模计算的力量，将所有众包计算任务在凌晨启动，减轻了线上集群的计算压力。所有小程序客户创建的常规众包计算都集中在凌晨的一个任务中，这样一次读取数据，就能计算所有众包，最大程度地节省计算资源。详细设计如下：

首先，团队会按照小程序粒度、选择的时间范围，筛选全部数据（标签属性数据+行为数据），保留有效数据；

其次进行数据预聚合，按照小程序用户粒度聚合用户在一定时间段内的行为数据、标签属性图像数据，最终的数据只会有一行数据；那么众包计算其实就是看这个用户在一定时间范围内产生的行为、标签属性特征是否符合客户定义的众包规则；

最后在用户层面数据聚合之后，进行复杂的规则匹配，核心是获取用户一段时间内的行为和人群标签属性，判断用户定义的哪些人群套餐规则满足，如果满足则该用户属于该人群套餐的用户。

4.4 人群追踪应用 4.4.1 人群追踪分析

根据用户规则选定众包后，将对众包进行统一的常见指标（如活跃度、交易等）跟踪，整个流程由离线任务处理，实时生成的众包包将从在线存储中导出，以及离线批量生成的众包包进行汇总，关联对应指标表，导出到在线OLTP存储进行在线查询分析。其中，在线众包包的导出将在凌晨空闲时间进行，通过将众包RBM转换为用户详情ID进行导出。

具体方法为：((e(rbm)))。

4.4.2 人口基数分析

人群基础分析分析自定义用户群体的基础标签，如该群体的省份、城市、交易等标签分布；人群行为分析分析该群体的不同事件行为等。

4.4.3 实验人群定位

在AB实验中，用户按照规则选取特定的一群人作为实验组（比如想验证某个区域内满足某些条件的人是否更有可能参与活动），并将相应指标与对照组进行比较，以验证假设。

05‍

总结

本文回顾了微信画像分析体系各个模块的设计思路。在基础模块中，业务团队根据功能特点选择了腾讯云作为在线数据的存储引擎，并用它来存储所有预计算的数据。为了实现灵活的人群创建、分析和应用，业务团队利用画像数据的存储引擎，并根据存储的特​​点开发上层服务，以达到最优性能。

未来，小程序微信画像分析系统还会在产品能力方面不断丰富功能和体验，同时拓展更多的应用场景。以上就是微信画像分析系统模块设计与实现思路的全部内容，感兴趣的读者欢迎在评论区留言交流。