导语 | We 剖析是微信小程序官网推出的、面向小程序服务商的数据分析平台，其中画像洞察是一个十分重要的功能模块。微信开发工程师钟文波将形容 We 分析画像零碎各模块是如何设计，在介绍根底标签模块之后，重点解说用户分群模块设计。心愿相干的技术实现思路，可能对你有所启发。
目录
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 剖析是小程序官网推出的、面向小程序服务商的数据分析平台，其中画像洞察是一个重要的功能模块。该性能将为使用者提供根底的画像标签剖析能力，提供自定义的用户分群性能，从而满足更多个性化的剖析需要及撑持更多的画像利用场景。
在此之前，原有 MP 的画像剖析仅有根底画像，相当于只能剖析小程序大盘固定周期的根底属性，而无奈针对特定人群或自定义人群进行剖析及利用。平台头部的使用者均心愿平台提供欠缺的画像剖析能力。除最根底的画像属性之外，也为使用者提供更丰盛的标签及更灵便的用户分群利用能力。因而，We 剖析在相干能力上打算进行优化。
1.2 画像零碎设计指标
- 易用性：易用性次要指使用者在体验画像洞察性能的时候，不须要学习老本就能间接上手应用。使用者能够联合本身业务场景解决问题，做到开箱即用 0 门槛。
- 稳定性：稳定性指零碎稳固牢靠体验好。例如画像标签数据、人群包按时稳固产出，在交互应用过程中查问速度快，做到如丝般顺滑的手感。
- 齐备性：指数据丰盛、规定灵便、功能完善；反对丰盛的人群圈选数据，预置标签、人群标签、平台行为、自定义上报行为等。做到在不违反隐衷的状况下平台根本提供使用者想要的数据。
整体来看，平台反对灵便的标签及人群创立形式，使用者依照本人的想法任意圈选出想要的人群，按不同周期手动或主动选出人群包。此外也反对人群的跟踪剖析，人群在多场景的利用等。
02、画像零碎整体概述
零碎从 产品状态 的角度登程，在下文分成 2 个模块进行论述——别离是 根底标签模块及用户分群模块。
- 多源数据：数据源包含用户属性、人群标签、平台行为数据、自定义上报数据。
- 画像加工：次要是对用户属性、人群标签、平台行为，进行相应的 ETL（Extract Transform Load，提取转换加载）及预计算。
- 人群计算：依据使用者定义的用户分群规定，从多源数据中计算出对应的人群。
- 画像导入：画像及人群数据在 TWD 加工好后，从 TWD 分布式 HDFS 集群导入到线上的 TDSQL、ClickHouse 存储；其中，预计算的数据导入到线上 TDSQL 存储，用户行为等明细数据导入到线上 ClickHouse 集群中。
- 画像服务：提供在线的画像服务接口。其中标签治理应用通用配置零碎，数据服务采纳 RPC 框架开发，在上一层是平台的数据中间件。此处也对立做了流量管制、异步调用、调用监控、及参数平安校验。
- 画像利用：提供根底标签剖析及针对特定人群的标签剖析，另外还提供人群圈选跟踪剖析及线上利用等。
03、根底标签模块
3.1 性能形容
该模块次要满足使用者对画像的根底剖析需要，预期能满足绝大部分中长尾使用者对画像的应用深度要求。次要提供的是 针对小程序大盘的根底标签剖析，及针对特定人群 （如沉闷：1 天沉闷、7 天沉闷、30 天沉闷、180 天沉闷） 的特定标签剖析。如下所示：
3.2 技术实现
3.2.1 数据计算
从上述性能的形容，能够看出性能的特点是官网定义数据范畴可控，反对的是针对特定人群的特定标签剖析。
针对特定人群的特定标签剖析数据是用离线 T + 1 的 hive 工作进行计算。流程如下。
别离计算官网特定标签的统计数据、特定人群的统计数据，以及计算特定人群穿插特定标签的数据。
3.2.2 数据存储
不同存储比照存在差别 。在上述剖析之后，须要存储的是预计算好的后果数据。此外，业务的特点是依照小程序进行多个数据主题统计的存储，所以第一直觉是适宜用分布式 OLTP 存储。团队也比照了不同的数据库， 在选型过程中，次要思考比照的点包含数据的写入、读取性能。
-
写入：包含是否能够反对疾速的建表等 DDL 操作。平台数据指标多，例如 We 剖析平台数据指标近千个。
不同的场景主题指标个别会别离进行计算，写入到不同的在线存储数据表中，所以这须要具备疾速 DDL 及高效出库数据的能力。
- 读取：包含查问性能、读取接口是否简略灵便、开发是否简略；以及相干运维配套设施是否欠缺，如监控告警、扩容、权限、辅助优化等。
从上图和 Datacube / FeatureKV / HBase 的比照能够发现 TDSQL 更合乎此业务诉求、更具备劣势。
因而 We 剖析平台根本所有的预计算后果数据，最终选用 TDSQL 来存储离线预计算后果数据，对于 TDSQL 的几个关键点如下：
- 存储容量：We 画像剖析零碎采纳的 TDSQL 服务中，以后反对最大 64 个分片，每个分片最大 3 T，单个实例最大能反对存储 192 T 的数据。
- 数据出库：通过数平 US 上的出库组件能够实现数据从 TDW 间接出库到 TDSQL，近 1 亿数据量能够在 40 min + 实现出库，出库组件的监控及日志欠缺。
- 查问性能：2 个分片，8 核 32 G 进行测试，查问某小程序一段时间数据，查问 QPS 5 W。
- 读取形式：通过 jdbc 连贯查问，拼接不同 sql 进行查问，查问形式简略灵便。
- 运维方面：实例申请、账号设置、监控告警、扩容和慢查问剖析等能力，都能够开发自助在云控制台实现。
- 开发效率：DDL 操作简略，数据开发从建表到出库根本没有学习老本，问题定位简略高效。
以后整个平台的预计算数据出库到 TDSQL 的数据达到十亿级别，数据表超百张，理论应用存储上百 T。TDSQL 整体性能较为全面，开发者仅须要补充开发数据生命周期管理工具，删除形式的留神点跟 MySQL 一样。
如果采纳 KV 类型的引擎进行存储，须要依据 KV 的个性正当设计存储 Key。在查问端对 Key 进行拼接组装，发送 BatchGet 申请进行查问。整个过程开发逻辑会绝对简约些，须要更加重视 Key 的设计。若要实现一个只有概要数据的趋势图，那么存储的 Key 须要设计成相似格局：{日期} # {小程序} # {指标类型}。
04、用户分群模块
4.1 性能形容
该模块次要提供自定义的用户分群能力。用户分群根据用户的属性及行为特色将用户群体进行分类，以便使用者对其进行察看剖析及利用。自定义的用户分群可能满足中头部客户的个性化剖析经营需要，例如客户想看上次 618 加入了某流动的用户人群，在接下来的沉闷交易趋势跟大盘的差别比照；或者客户想验证比照某些人群对优惠券的敏感水平、圈选人群后通过 AB 试验进行验证。上述相似的利用会十分多。
在功能设计上，平台须要做到数据丰盛、规定灵便、查问疾速，须要反对丰盛的人群圈选数据，并且预置标签、人群标签、平台行为、自定义上报行为等。反对灵便的标签及人群创立形式，让客户能依照本人的想法任意圈选出想要的人群，按不同周期手动或主动选出人群包，反对人群的跟踪剖析、人群在多场景的利用能力。
4.2 人群包实时预估
人群包实时预估是依据使用者客户定义的规定，计算出以后规定下有多少用户命中了该规定。产品交互通常如下所示：
4.2.1 数据加工
为了满足客户能随便依据本人的想法圈出想要的人群，平台反对丰盛的数据源。整体画像的数据量较大，其中预置的标签画像在离线 HDFS 上的竖表存储达近万亿 / 天，平台行为百亿级 / 天，且维度细，自定义上报行为百亿级 / 天。
怎么设计能 节俭存储同时减速查问 是重点思考的问题之一。大体的思路是：对预置标签画像转成 Bitmap 进行压缩存储，对平台行为明细进行预聚合及对维度枚举值进行 ID 自增编码，字符串转成数据整型节俭存储空间。同时在产品层面减少启用按钮，开明后导入近期数据，从而管制存储耗费，具体细节如下。
属性标签数据通常建设用户画像的外围工作就是给用户打标签，标签是人为规定的高度精炼的特色标识，如性别、年龄、地区、趣味，也能够是用户的一些行为汇合。这些标签汇合形象出一个用户的信息全貌，每个标签别离形容该用户的一个维度，各标签维度间互相分割，形成对用户的整体形容。以后的用户属性及人群标签是由平台方提供，由平台每天进行对立的加工解决生成官网标签。平台临时没有反对用户自定义的标签，因而这里次要阐明平台标签是如何计算加工治理。
- 第一，标签编码治理。
例如沉闷标签 10002，对标签的每个标签值进行编码如下：
对特定人群进行编码，基准人群是作为必选的过滤条件，用于限定用户的范畴：
- 第二，标签离线存储。
标签数据在离线的存储上，采纳竖表的存储形式。表构造如下所示，标签之间能够并行构建互相独立不影响。采纳竖表的结构设计，益处是不须要开发画像大宽表，即便工作出现异常延时也不会影响到其它标签的产出。而画像大宽表须要期待所有画像标签均实现后能力开始执行该宽表数据的生成，会导致数据的延时危险增大。当须要新增或删除标签时，须要批改表构造。因而，在线的存储引擎是否反对与离线竖表模式相匹配的存储构造，成为很重要的考量点。
采纳大宽表形式的存储如 Elasticsearch 和 Hermes 存储，期待全副须要线上用到的画像标签在离线计算环节加工实现能力开始入库。而像 ClickHouse、Doris 则能够采纳与竖表绝对应的表构造，标签加工实现就能够马上出库到线上集群，从而减小因为一个标签的延时而导致整体延时的危险。
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 类型）就形成了一个个的人群。Bitmap 是用于存储标签 - 用户的映射关系的、十分现实的数据结构，最终须要的是构建出每个标签的每个取值所对应的 Bitmap。例如性别这个标签组，背地对应的是男性用户群和女性用户群。
性别标签：男 -> 男性用户人群包，女 →女性用户人群包。
平台行为数据是指官网进行上报的行为数据，例如拜访、分享等行为数据，使用者不须要进行任何埋点等操作。团队次要是会对平台行为进行预聚合，计算同一维度下的 PV 数据，已缩小后续数据的存储及计算量。
同时会对维度枚举值进行 ID 自增编码，目标是缩小存储占用，写入以及读取性能；从成果来看，团队对可枚举类型进行字典 ID 编码比照本来字符类型能节俭 60% 的线上存储空间，同时雷同数据量条件下带来 2 倍查问速度晋升。
自定义上报数据是使用者本人埋点进行数据的上报，上报的内容包含公共参数及自定义内容，其中自定义内容是 key-value 的格局，在 OLAP 引擎中，团队会将客户自定义的内容转成 map 构造类型进行存储。
4.2.2 数据写入存储
-
在线 OLAP 存储选型：
首先讲下，在线 OLAP 存储选型。标签及行为明细数据的存储引擎选型对于画像零碎至关重要，不同的存储引擎决定了零碎不同的设计形式。业务团队调研理解到，行业内建设画像零碎时有多种不同的存储计划。团队对罕用的画像 OLAP 引擎做了比照，如下：
综合上述调研，团队采纳 ClickHouse 作为画像数据存储引擎。在 ClickHouse 中应用 RoaringBitmap 作为 Bitmap 的解决方案。该计划反对丰盛的 Bitmap 操作函数，能够非常灵便不便的判重和进行基数统计操作，如下所示。
采纳 RoaringBitmap（RBM） 对稠密位图进行压缩，能够缩小内存占用并提高效率。该计划的外围思路是，将 32 位无符号整数依照高 16 位分桶，即最多可能有 216=65536 个桶，称为 container。存储数据时，依照数据的高 16 位找到 container（找不到则会新建一个），再将低 16 位放入 container 中。也就是说，一个 RBM 就是很多 container 的汇合，具体参考高效压缩位图 RoaringBitmap 的原理与利用。
-
数据导入线上存储：
接下来讲讲，数据导入线上存储。在确定了采纳什么存储引擎存储线上数据后，团队须要将离线集群的数据导入到线上存储。其中对于标签数据通常的做法是将原始明细的 id 数据间接导入到 ClickHouse 表中，再通过创立物化视图的形式构建 RBM 构造进行应用。
然而，业务明细数据十分大，每天近万亿。这样的导入形式给 ClickHouse 集群带来了很大资源开销。而通常业务团队解决大规模数据都是用 Spark 这样的离线计算框架来实现解决。最初团队把预处理工作全副交给了 Spark 框架，这种形式大大的缩小了写入的数据量，同时也缩小了 ClickHosue 集群的解决压力。
具体步骤是 Spark 工作首先会依照 id 进行分片解决，而后对每个分片中标签的每个标签值生成一个 Bitmap，保障定制的序列化形式与 ClickHouse 中的 RBM 兼容。其中通过 Spark 解决后的 Bitmap 转成 string 类型，而后写入到线上的标签表中，在表中业务团队定义了一个物化列字段，用于理论存储 Bitmap。在写入过程中会将序列化后的 Bitmap 字符串通过 base64Decode 函数转成 ClickHouse 中的 AggregateFunction (groupBitmap, UInt32) 数据结构。
具体表构造如下：
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-
存储占用问题：
值得关注的还有存储占用问题。标签类型数据用 Bitmap 类型存储，平台行为采纳编码方式存储，存储占用大幅缩小。
4.2.3 数据查问
数据查问形式：人群圈选过程中，如何保障大的 APP 查问、在简单规定状况下的查问速度？团队在导入过程中对预置画像、平台行为、自定义上报行为，均按雷同分桶规定导入集群。这保障一个用户仅会在同一台机器，查问时始终进行本地表查问，防止进行分布式表查问。
对于查问性能的保障，团队始终保障所有查问均在 本地表 实现。下面曾经介绍到数据在入库时，均会依照雷同用户 ID 的 hash 分桶规定出库到相应的机器节点中。应用维度数字编码，测试数字编码后比照字符形式查问性能有 2 倍以上晋升。对标签对应的人群转成 Bitmap 形式解决，用户的不同规定到最初都会转成针 Bitmap 的交并差补集操作。
对于平台行为，如果在用户用含糊匹配的状况下，会先查问维度 ID 映射表，将用户可见维度转化成维度编码 ID，后通过编码 ID 及规定构建查问 SQL。整个查问的外围逻辑是依据圈选规定组合不同查问语句，而后将不同子查问通过规定组合器最终判断该用户是否命中人群规定。
基于 rpc 开发服务接口：查问的服务接口采纳 rpc 框架进行开发。
在数据服务的上一层是团队的数据中间件，对立做了流量管制、异步调用、调用监控及参数平安校验，特地是针对用户量较大的 app 在多规定查问时，耗时较大，因而业务团队配置了细粒度的流量管制，保障查问申请的有序及服务的稳固可用。
查问性能数据：不同 DAU 等级小程序查问性能。
从性能数据看，对用户量大的 app 来说，在规定十分多的状况下还是要大几十秒，期待这么长时间体验不佳。因而对于这部分用户量大的 app，业务团队采纳的策略是抽样。通过抽样，速度能失去十分大的晋升，并且预估的准确率误差不大，在可承受的范畴内。
4.3 人群创立
4.3.1 人群实时创立
人群包实时创立相似下面形容的人群大小实时预估，区别是在最初人群创立是须要将圈选的人群包用户明细写入到存储中，而后返回人群包的大小给到用户。同样是在本地表执行，生成的人群包写入到同一台机器中，放弃分桶规定的统一。
4.3.2 人群例行化创立
客户创立的例行化人群包，须要每天计算。如何继续跟踪剖析趋势，并且不会对集群造成过大的计算压力？团队的做法利用离线超大规模计算的能力，在凌晨启动所有人群计算工作，从而减小对线上 ClickHouse 集群的计算压力。所有小程序客户创立的例行化人群包计算集中到凌晨的一个工作中进行，做到读一次数据，计算实现所有人群包，最大限度节俭计算资源，具体的设计如下：
首先，团队会先将 全量的数据 （标签属性数据 + 行为数据） 依照小程序粒度及抉择的工夫范畴进行过滤，保留无效的数据；
其次，对数据进行预聚合解决，将用户在一段时间范畴的行为数据，标签属性镜像数据依照小程序的用户粒度进行聚合解决，最终的数据将会是对于每个小程序的一个用户仅会有一行数据；那么人群包计算，实际上就是看这个用户在某个工夫范畴内所产生的行为、标签属性特色是否满足客户定义的人群包规定；
最初，对数据按用户粒度聚合后进行简单的规定匹配，外围是拿到一个用户某段时间的行为及人群标签属性，判断这个用户满足了用户定义的哪几个人群包规定，满足则属于该人群包的用户。
4.4 人群跟踪利用
4.4.1 人群跟踪剖析
在依照用户规定圈选出人群后，对立对人群进行罕用指标（如沉闷、交易等指标）的跟踪。整个过程用离线工作进行解决，会从在线存储中导出实时生成的人群包，以及离线批量生成的定时人群包，汇总一起，后关联对应指标表，输入到线上 OLTP 存储进行在线的查问剖析。其中，导出在线人群包会在凌晨闲暇工夫进行，通过将人群 RBM 转成用户明细 ID。
具体方法为：arrayJoin(bitmapToArray(groupBitmapMergeState(rbm)))。
4.4.2 人群根底剖析
人群根底剖析对一个自定义的用户分群进行根底标签的剖析，如该人群的省份、城市、交易等标签散布。人群行为剖析，剖析该人群不同的事件行为等。
4.4.3 试验人群定向
在 AB 试验中的人群试验，使用者通过规定圈选出指定人群作为实验组（如想验证某地区的合乎某条件的人群是否更喜爱参加该流动），跟对照组做相应指标的比照，以便验证假如。
05、总结
本篇回顾了 We 画像剖析零碎各模块的设计思路。在根底模块中，业务团队依据性能个性，选用了腾讯云 TDSQL 作为在线数据的存储引擎，将所有预计算数据都应用 TDSQL 进行存储。在人群剖析模块中，为了实现灵便的人群创立、剖析及利用，业务团队应用 ClickHouse 作为画像数据的存储引擎，依据该存储的个性进行下层服务的开发，以达到最优的性能。
后续，小程序 We 画像剖析零碎在产品能力上会继续丰盛性能及体验，同时扩大更多的利用场景。以上是 We 画像剖析零碎模块设计与实现思路的全部内容，欢送感兴趣的读者在评论区交换。
-End-
原创作者|钟文波
技术责编|钟文波、谢慧志
你可能感兴趣的腾讯工程师作品
| ChatGPT 深度解析：GPT 家族进化史
| 腾讯工程师聊 ChatGPT 技术「文集」
| 微信全文搜寻耗时降 94%？咱们用了这种计划
| 10w 单元格滚动卡顿如何解决？腾讯文档的 7 个秘笈
技术盲盒：前端 | 后端 |AI 与算法| 运维 | 工程师文化
公众号后盾回复“小程序”，领本文作者举荐的更多材料