简介： 本文将按总分的结构进行展开：首先对标签画像的基本概念做简单的说明；其次会从业务需求的角度出发，阐述如何构建一个可用的最小标签画像系统单元；而后会以这个最小单元为基础，对部分重点模块进行扩展介绍；最后进行总结，并对文中未涉及的发展方向简要说明。

1 前言

“标签画像”或者说“用户画像”体系建设是各大互联网公司在发展过程中绕不开的话题，在阿里内网以及各大网络论坛上也有诸多分享和讨论。但大多立足数据算法或产品形态，解决方案方面并不多（尤其是工程研发实际构建角度）。本文初衷是想站在工程研发的角度，以阿里本地生活标签画像系统的开发经验为基础，分享一下构建标签画像体系的实践经验。

2 基本概念

便于后续文章开展，以下结合经验，介绍了一些标签画像系统中的常见概念，仅供参考。

标签

标签（tag）通俗意义上讲是对某一类群体或对象的某项特征进行的抽象分类和概括。从数据角度来说，是对数据集的某一特征进行的抽象描述，可以作为一个维度，也可以作为一个属性。 标签值一般都是可分类、可穷举的，比如用户性别。而对一些数值类的标签，既可以保持原有值，也可以做进一步的抽象：比如客单价，可以根据数值进一步抽象成高客单价、低客单价。

画像

画像（profile）是对特定人或对象的描述信息的集合。一个用户的画像可以描述成“25岁，男性，在互联网公司上班，喜欢喝可乐 等”。 人群画像分析则是对特定人群进行的画像分析描述，比如：“荷兰成年男性”这个人群，“身高”这个标签，“80%高于一米八”标签值特征描述。 以个性化推荐场景为例，画像是基于数据刻画用户需求的模型，数据标签化则是构建这个模型的方法。

群组（人群）

群组（group）是特定人和对象的集合。在标签画像系统中，可以通过标签组合筛选出群组，也可以直接人工定义一个群体作为群组。群组是差异化营销活动的对象和常见手段。

圈选

根据人或对象的特征标签，筛选出特定集合的过程。

3 构建最小标签画像系统

本节通过实际的营销场景，从后端研发角度，遵循构建最小可运行系统的原则，阐述从0到1实现一个标签画像系统的基本技术架构和中间件选型。

3.1 业务想要什么

以“发优惠券”这个业务运营场景举例，涉及标签画像的运营过程大体可分为四步：首先运营人员要了解目标人群数量申请预算（预估），其次圈出满足条件的人群（圈人），然后对目标人群进行发券（投放），最后用户在核销的时候进行最终确认（判定）。

3.2 我们有什么

不管是预估还是圈选，其实我们最初的材料都是一张张用户属性表，而用户的每一个属性字段都可以作为一个“标签”。标签有多种分类方式，从复杂程度可以分为原子标签、复合标签，从时效性上又可以分为实时标签、离线标签等。

3.3 技术要实现什么

第一小节已经做了基本的业务需求分析，此处我们再明确一下：

• 人群预估 —— 新建一个实时预估接口
• 人群圈选 —— 生成一张离线表（本文使用ODPS表）
• 人群投放 —— 生成一个人群文件（本文使用OSS存储文件）
• 人群判定 —— 新建一个判定接口

3.4 技术选型

3.4.1 预估接口

预估接口的主要难点在于复杂SQL的运行响应时间（10S内）。举例来说，如果我们圈上海、20岁以上用户，当两个基础属性正好在一张表，SQL如下：

SELECT count(distinct user_id)
FROM table_1
WHERE location = '上海'
        AND age > 20;

如果我们再加个筛选条件，比如“爱喝茶”，而“爱喝茶”作为行为属性在另一张表的话：

SELECT count(distinct user_id)
FROM 
    (SELECT table_1.user_id
    FROM table_1
    LEFT JOIN table_2
        ON (table_1.user_id = table_2.user_id)
    WHERE (table_1.location = '上海'
            AND table_1.age > 20
            AND table_2.is_like_tea = 1) ) AS `mt1`

可以看出，当有多标签圈选时不可避免的会有多次并表操作，且主表数据量过大（>1亿行）时，比较考验数据库性能（尤其join运算性能）。建议使用分析型数据库作为数据引擎，如阿里的ADB、Hologres或者ES，具体选用哪个可根据不同场景进行压测。

3.4.2 圈选引擎

这里的“圈选”包含生成人群表和对应文件的过程，“引擎”则指运行的计算平台。因而这一小节重点解决的是通过“群组生成规则”将“标签底表”进行计算输出的过程，基本方案如下：

注：本文使用阿里云的MaxCompute平台作为离线圈选引擎，配套使用的数仓底表（ODPS）、数据开发节点（DataStudio）、文件存储（OSS）均为同系列产品。

3.4.2 判定接口

群组判定接口直接面对业务方，QPS与用户数、营销活动数成正比，需要满足三个基本条件：大数据量（用户多&群组多），高QPS（用户多&营销场景多），低RT（ms级）。因而在数据库选型上，建议使用KV型存储。常见的选型可以是Redis或者Hbase，本文使用的阿里云的Lindorm。各中性能差异不再赘述，可按需选择。

3.5 完整方案

基于以上分析，我们基本厘清了标签“从哪里来”再到“到哪里去”的问题。我们对圈选引擎小节中的流程图稍加丰富，形成如下链路：

以上，分享了以标签数据源、群组圈选规则为原始数据，构建用于“预估”的查询接口、用于“圈人”的ODPS结果表、用于“投放”的OSS文件和用于“判定”的群组查询接口的技术实现流程和选型。 接下来，将会对一些重点模块的设计进行详细说明。

点击查看原文，获取更多福利！

https://developer.aliyun.com/article/1123328?utm_content=g_1000367441

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。