“标签画像”或者说“用户画像”体系建设是各大互联网公司在发展过程中绕不开的话题，在阿里内部以及各大网络论坛上也有诸多分享和讨论。但大多立足数据算法或产品形态，解决方案方面并不多（尤其是工程研发实际构建角度）。本文初衷是想站在工程研发的角度，以阿里本地生活标签画像系统的开发经验为基础，分享一下构建标签画像体系的实践经验。本文将按总分的结构进行展开：首先对标签画像的基本概念做简单的说明；其次会从业务需求的角度出发，阐述如何构建一个可用的最小标签画像系统单元；而后会以这个最小单元为基础，对部分重点模块进行扩展介绍；最后会进行总结，并对文中未涉及的发展方向简要说明。希望对大家有所帮助。
便于后续文章开展，以下结合经验，介绍了一些标签画像系统中的常见概念，仅供参考。
标签（tag）通俗意义上讲是对某一类群体或对象的某项特征进行的抽象分类和概括。从数据角度来说，是对数据集的某一特征进行的抽象描述，可以作为一个维度，也可以作为一个属性。标签值一般都是可分类、可穷举的，比如用户性别。而对一些数值类的标签，既可以保持原有值，也可以做进一步的抽象：比如客单价，可以根据数值进一步抽象成高客单价、低客单价。
画像（profile）是对特定人或对象的描述信息的集合。一个用户的画像可以描述成“25岁，男性，在互联网公司上班，喜欢喝可乐 等”。人群画像分析则是对特定人群进行的画像分析描述，比如：“荷兰成年男性”这个人群，“身高”这个标签，“80%高于一米八”标签值特征描述。以个性化推荐场景为例，画像是基于数据刻画用户需求的模型，数据标签化则是构建这个模型的方法。
群组（group）是特定人和对象的集合。在标签画像系统中，可以通过标签组合筛选出群组，也可以直接人工定义一个群体作为群组。群组是差异化营销活动的对象和常见手段。
本节通过实际的营销场景，从后端研发角度，遵循构建最小可运行系统的原则，阐述从0到1实现一个标签画像系统的基本技术架构和中间件选型。
以“发优惠券”这个业务运营场景举例，涉及标签画像的运营过程大体可分为四步：首先运营人员要了解目标人群数量申请预算（预估），其次圈出满足条件的人群（圈人），然后对目标人群进行发券（投放），最后用户在核销的时候进行最终确认（判定）。
不管是预估还是圈选，其实我们最初的材料都是一张张用户属性表，而用户的每一个属性字段都可以作为一个“标签”。标签有多种分类方式，从复杂程度可以分为原子标签、复合标签，从时效性上又可以分为实时标签、离线标签等。
第一小节已经做了基本的业务需求分析，此处我们再明确一下：
3.4.1 预估接口
预估接口的主要难点在于复杂SQL的运行响应时间（10S内）。举例来说，如果我们圈上海、20岁以上用户，当两个基础属性正好在一张表，SQL如下：SELECT count(distinct user_id)FROM table_1WHERE 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文件和用于“判定”的群组查询接口的技术实现流程和选型。接下来，将会对一些重点模块的设计进行详细说明。
一个标签画像系统每天可能面临数以万计的群组圈选任务，因而需要一个相对独立的圈选模块控制每天任务的执行调度。圈选引擎主要由圈选任务池、任务调度、任务执行、依赖检测四个子模块构成。任务池负责维护所有任务的运行状态（init、ready、running、success/failure）；任务调度模块居中调度，负责对圈选任务送检依赖、派发执行、失败重试，并控制整个引擎调度速率；任务执行模块将直接与数据中间件（ODPS/ADB/Lindorm/OSS）进行交互，包括提交圈选SQL、监测圈选状态、推送圈选结果 等；依赖检测模块负责检验圈选任务的前置依赖，根据群组类型不同会有不同的差异，下一小节单独说明。
以上，列出了常见的六种群组依赖方式，概括一下可分为四种：首先是最常见的标签底表依赖；其次是有些用户已经自定义圈出了一个群组（文件/ODPS表），那么对对应的人群底表有依赖；然后是外部群组依赖，这里的外部也可以扩展理解为“其他”，就是本体系之外的系统通过某种方式生成群组来进行系统对接，需要定制化检测依赖；最后就是以上几种方式的组合，群组与群组之间、标签与群组之间可以进行二次交并差，因而会有父群组依赖。
上图回顾了从群组创建到生成可消费数据的过程。群组在创建完成后，平台将会根据群组的生效时间生成日滚任务并执行调度。但是在通用圈选引擎计算完成之后，增加了一个ID映射的模块：狭义的ID映射可直接理解为ID类型转换。以在常见的电商环境为例，可运营实体包含了消费者、商户、商品。但在实际圈选时，圈的主体未必是要运营的主体。比如运营想圈出所有卖“小龙虾”这个商品的商户，加入“小龙虾节”活动。那么运营在圈的时候可能圈的是所有包含“小龙虾”关键字的商品，系统要做的就是提供一个通用能力把包含这些商品的商户也圈出来。这就是ID映射的基本功能和应用场景。 广义的ID映射是指在这一环节，系统所能提供支持的衍生处理能力。还是刚才的例子，运营在圈出所有卖小龙虾的商户后，还想知道这些商户在哪个城市，注册的联系方式是什么。那么系统就要在商户列表中再查询添加城市和联系方式两个字段，方便进一步使用。
以上，以阿里本地生活标签画像系统的开发经验为基础，分享了一些基本的标签画像系统工程实现方案，挑选了部分核心模块做了细化分享。而当系统消费达到一定体量时，还有诸多可扩展的点：系统架构方面，包括生产侧的标签生产管理、消费侧的租户化以及整个生产消费过程中监控运维体系 等；系统应用扩展方面，则包括群组洞察分析、场景化运营策略以及运营投放过程中的效果回收/诊断/推荐 等。后续有机会再进行分享。文中的的一些技术架构和选型，都是结合自身业务发展需求所做的选择，遇到类似场景可参考。
