如何构建标签画像工程体系及实现方案

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,恶意文件检测 1000次 1年
对象存储 OSS,内容安全 1000次 1年
简介: 本文将按总分的结构进行展开:首先对标签画像的基本概念做简单的说明;其次会从业务需求的角度出发,阐述如何构建一个可用的最小标签画像系统单元;而后会以这个最小单元为基础,对部分重点模块进行扩展介绍;最后进行总结,并对文中未涉及的发展方向简要说明。

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如下:

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

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

SELECTcount(distinct user_id)FROM(SELECT table_1.user_idFROM table_1
    LEFT JOIN table_2
ON(table_1.user_id= table_2.user_id)WHERE(table_1.location='上海'AND table_1.age>20AND 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文件和用于“判定”的群组查询接口的技术实现流程和选型。 接下来,将会对一些重点模块的设计进行详细说明。

4 核心模块设计

4.1 圈选调度

一个标签画像系统每天可能面临数以万计的群组圈选任务,因而需要一个相对独立的圈选模块控制每天任务的执行调度。

圈选引擎主要由圈选任务池、任务调度、任务执行、依赖检测四个子模块构成。任务池负责维护所有任务的运行状态(init、ready、running、success/failure);任务调度模块居中调度,负责对圈选任务送检依赖、派发执行、失败重试,并控制整个引擎调度速率;任务执行模块将直接与数据中间件(ODPS/ADB/Lindorm/OSS)进行交互,包括提交圈选SQL、监测圈选状态、推送圈选结果 等;依赖检测模块负责检验圈选任务的前置依赖,根据群组类型不同会有不同的差异,下一小节单独说明。

4.2 依赖检测

以上,列出了常见的六种群组依赖方式,概括一下可分为四种:首先是最常见的标签底表依赖;其次是有些用户已经自定义圈出了一个群组(文件/ODPS表),那么对对应的人群底表有依赖;然后是外部群组依赖,这里的外部也可以扩展理解为“其他”,就是本体系之外的系统通过某种方式生成群组来进行系统对接,需要定制化检测依赖;最后就是以上几种方式的组合,群组与群组之间、标签与群组之间可以进行二次交并差,因而会有父群组依赖。

4.3 ID映射

上图回顾了从群组创建到生成可消费数据的过程。群组在创建完成后,平台将会根据群组的生效时间生成日滚任务并执行调度。但是在通用圈选引擎计算完成之后,增加了一个ID映射的模块:狭义的ID映射可直接理解为ID类型转换。以在常见的电商环境为例,可运营实体包含了消费者、商户、商品。但在实际圈选时,圈的主体未必是要运营的主体。比如运营想圈出所有卖“小龙虾”这个商品的商户,加入“小龙虾节”活动。那么运营在圈的时候可能圈的是所有包含“小龙虾”关键字的商品,系统要做的就是提供一个通用能力把包含这些商品的商户也圈出来。这就是ID映射的基本功能和应用场景。

广义的ID映射是指在这一环节,系统所能提供支持的衍生处理能力。还是刚才的例子,运营在圈出所有卖小龙虾的商户后,还想知道这些商户在哪个城市,注册的联系方式是什么。那么系统就要在商户列表中再查询添加城市和联系方式两个字段,方便进一步使用。

5 总结

以上,以阿里本地生活标签画像系统的开发经验为基础,分享了一些基本的标签画像系统工程实现方案。受限于篇幅,仅挑选了部分核心模块做了细化分享。而当系统消费达到一定体量时,还有诸多可扩展的点:系统架构方面,包括生产侧的标签生产管理、消费侧的租户化以及整个生产消费过程中监控运维体系 等;系统应用扩展方面,则包括群组洞察分析、场景化运营策略以及运营投放过程中的效果回收/诊断/推荐 等。后续有机会再进行分享。

文中的的一些技术架构和选型,都是结合自身业务发展需求所做的选择,仅供参考。

相关实践学习
简单用户画像分析
本场景主要介绍基于海量日志数据进行简单用户画像分析为背景,如何通过使用DataWorks完成数据采集 、加工数据、配置数据质量监控和数据可视化展现等任务。
SaaS 模式云数据仓库必修课
本课程由便宜云服务器开发者社区和便宜云服务器大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由便宜云服务器资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:便宜云服务器大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
相关文章
|
10天前
|
搜索推荐 数据可视化 数据挖掘
构建精准的目标客户群用户画像构建
构建精准的目标客户群用户画像
30 6
|
6月前
|
数据采集 存储 搜索推荐
58标签体系建设实践
58标签体系建设实践
112 1
|
3月前
|
存储 搜索推荐 分布式数据库
用户画像标签系统体系解释
用户画像标签系统体系解释
60 1
|
4月前
|
机器学习/深度学习 自然语言处理 Cloud Native
探索在云原生环境中构建的大数据驱动的智能应用程序的成功案例,并分析它们的关键要素。
大数据索引: Google使用大数据索引来构建其搜索引擎,并实时处理全球各种语言的文本数据。 云原生基础设施: Google Cloud提供了强大的云原生基础设施,支持大规模数据存储和处理。 自然语言处理: Google使用自然语言处理技术来理解和索引文本数据,从而提供高质量的搜索结果。 实时搜索: Google的
118 0
|
5月前
|
数据采集 数据建模 BI
数据中台实战(05)-如何统一管理纷繁杂乱的数据指标?
数据中台实战(05)-如何统一管理纷繁杂乱的数据指标?
111 1
|
11月前
|
安全
便宜云服务器产品体系分为6大分类——安全——安全的6种模块——安全服务
便宜云服务器产品体系分为6大分类——安全——安全的6种模块——安全服务自制脑图
82 1
|
11月前
|
安全
便宜云服务器产品体系分为6大分类——安全——安全的6种模块——业务安全
便宜云服务器产品体系分为6大分类——安全——安全的6种模块——业务安全自制脑图
148 1
|
11月前
|
安全
便宜云服务器产品体系分为6大分类——安全——安全的6种模块
便宜云服务器产品体系分为6大分类——安全——安全的6种模块自制脑图
100 1
便宜云服务器产品体系分为6大分类——安全——安全的6种模块
|
运维 Kubernetes Java
一站式动态多环境建设案例
作为创业团队来讲,能够快速具备一站式解决服务治理问题,是一件非常酷的事。这整个方案的讨论实施过程中,研发团队对于 K8s、Nginx Ingress、MSE 都有较深入的理解。“像我们部门研发团队,没有专门的运维团队,每个开发人员都可以深入了解每个产品的来龙去脉,想想就很有意义。”
225 2
一站式动态多环境建设案例
|
数据采集 存储 监控
电商项目之数据治理流程分析|学习笔记
快速学习电商项目之数据治理流程分析
167 0
电商项目之数据治理流程分析|学习笔记

热门文章

最新文章


http://www.vxiaotou.com