转转用户画像系统建设与实践_转转产品客户画像ppt-CSDN博客

在这里插入图片描述

1. 背景

转转作为二手电商交易领域的领军者，随着这几年的高速发展，用户数和业务量都急剧增长，为了更好的服务用户，并持续增长，产品运营的战略战术也会随之发生变化。在创业早期产品一般以粗放式运营为主，力求快速获取用户、推广产品，领跑赛道。业界也曾流传着这样的段子，产品有三宝：弹窗、浮层、加引导；运营有三宝：短信、push、加红包。然而到了中后期公司都会面临的三大问题是降本提效、持续增长、用户体验，所以基于数据的精细化运营成了大家的必然选择：

如何更有针对性的 push 用户避免被打扰？
如何更有针对性的发放红包避免被薅羊毛？
如何更低成本更好体验召回用户避免流失？
…

可以看到整个产品运营层面对于如何获取特定属性用户集的需求非常强烈，他们关心的几个核心点是：

可以按属性（或行为）筛选
还可以导出其他属性
可以做集合运算
还能上传自定义用户集参与运算

从开发和维护的角度看，也有几个比较关心的点：

如何方便地扩展属性
采用什么计算引擎低成本易维护？
如何方便快捷的将用户需求转化为计算任务？

2. 整体架构

针对上面的需求，我们的架构如下：

在这里插入图片描述
可以看到，我们选用的计算引擎是Hive，这个主要是为了满足开发和维护人员关心的两个点：

直接在页面上添加SQL模板就可以方便地添加属性
用SQL表达用户的逻辑还是比较方便的，把需求转化为SQL的过程比较容易实现

这样所有的逻辑通过SQL表达就可以了，非常简单方便。所以整个系统的重点就变成了SQL的设计和生成。SQL生成的过程如下：

在这里插入图片描述

3. 核心模块与逻辑

3.1 SQL模板

属性的抽取是通过SQL模板的方式来表达的。这里有两种类型的模板：

属性筛选模板，用于筛选特定属性的用户集，比如筛选男性，比如按年龄段筛选等；
属性输出模板，筛选得到目标用户集之后，输出的时候除了用户ID，还可以携带一些用户属性，比如购买商品数，发布商品数，当然，性别，年龄等属性也可以输出。

用户上传的用户集是一个属性筛选模板，用户集上传之后会放到某个hive表的一个分区下，我们用SQL取出这些用户即可。

SQL模板的例子如下：

在这里插入图片描述
SQL模板必须输出3个字段，分别是xxid，tag，p，都是string类型。xxid就是用户ID；tag是这个用户集的ID，用于集合运算，这里用占位符先占着，创建标签的时候会用相应的ID替换掉；p是输出参数，属性输出模板可以把属性放到这个字段中，属性筛选模板暂时用不到。${stat_date_s} 是公共变量，值是昨天的日期。${reg_start_date_omg_}、${reg_end_date_omg_}和${platform_array}是参数占位符，这个SQL模板有三个参数可以在页面上设置，是注册日期的开始日期、结束日期和注册平台，创建标签的时候会用用户填写的值替换这三个占位符。这个模板在页面上的展示情况如下：

在这里插入图片描述
参数除了可以是日期，还可以直接让用户输入值，比如输入一个数字n，筛选出至少卖出n件商品的用户；还可以是一个多选列表，比如我们可以筛选品类、城市等，这个列表的数据可以来自于json，也可以来自于一张数据库的表，我们把常用的品类、城市等列表作为内置列表放到系统中，使用的时候更方便。参数示例如下：

在这里插入图片描述
有些参数是选填的，比如"注册平台"不选的时候，我们希望得到的是2018-12-19这天全平台的注册用户。但是“注册平台”的参数值替换为空字符串或者null都不能实现我们的需求。如果这个参数没有值，这段SQL去掉就行了。这是一种方案，但是还需要配置参数和SQL片段的关系，这样会碎片化SQL模板，我们并不想对SQL模板有太多的入侵。所以，我们就用UDF重写了条件判断，如果参数值为null，则这个条件就为true。GInOrNot就是我们做in或not in判断的UDF，此外，我们还有一些其他特殊判断的UDF。开始日期和结束日期也是选填项，SQL模板里也是先判断了是不是null，是null就返回true，否则就会做真正的判断。当然也可以通过配置参数作为必填项来约束用户填写参数，同时页面上也会有红*提示。

我们需要把每个属性作为一个SQL模板录入。之后，产品和运营就可以在页面上选择一些属性，设置参数，设置逻辑关系，就可以创建一个标签了。

3.2 集合运算

每个属性模板代表的都是一个用户集，这些用户集之间的运算就是集合运算。我们这里支持完整的集合运算：交、并、补，同时支持多级嵌套。为此，我们设计了一个简单的逻辑表达式，用来表示用户设置的逻辑。比如，我们想要的用户集（下图蓝色部分）是买过手机或看过手机的男性，并排除掉卖家。

在这里插入图片描述

那这个的逻辑表达式就是：

在这里插入图片描述
实际使用的时候表达式中不会有中文，会用集合ID来代替（就是前面说的tag字段）。为了方便解析，每个集合都用括号包裹了起来，逻辑表达式中每个节点只能有两个子节点，或者没有子节点。

我们需要收集到每个用户的所有tag，这里我们把这个标签用到的所有模板union all 到一起，然后group by xxid，收集到每个用户的所有tag。

我们用UDF实现了这个逻辑表达式的执行引擎。将用户的tag列表和逻辑表达式传入UDF，就可以判断用户是不是我们想要的用户了。执行引擎会先将逻辑表达式解析为一棵树（会缓存，避免重复解析），类似于抽象语法树，然后遍历这颗树，做解释执行。逻辑运算中有个优化就是短路运算，即做一部分运算之后就可以得到整个表达式的值，剩下部分不需要再计算。比如，“与运算”中有一个false，结果就是false，“或运算”中有一个true，结果就是true。解析得到的树如下：

在这里插入图片描述
逻辑表达式是前端根据用户的设置生成的。完整SQL如下所示：

在这里插入图片描述
以上就是生成的完整SQL。group_c就是做集合运算的UDF。param_c是用来抽取输出属性的UDF，这个输出tag4和tag5的属性。

3.3 相似标签合并计算

有了上面的方案，产品和运营就可以愉快地提取满足特定属性的用户集了。这些标签大多是一次性的需求，用完即丢，同时一些标签的定义并不严谨，也不通用。所以，我们接下来配置了一批定义清晰明确、长期稳定计算、通用性强的标签。这样用起来就方便多了。这些长期运行的标签越来越多，每天要运行的任务数也越来越多，对我们的计算资源产生了一些压力。主要是像一些标签要分城市，或者分品类等，一下就建一批标签，只有城市或品类不一样。不仅有城市、品类这样的维度，还有按频次来创建一组标签的。如下图：

在这里插入图片描述
针对这样的问题，我们把这样的标签分组，同一组的标签合并为一个任务去算。

还记得我们SQL模板中的p字段么？在属性筛选模板中，p字段并没有使用。但是这里，我们就把他给用上了。模板可以按什么字段批量创建标签，就把这个字段的值放到p字段中，如果有多个字段可以用来创建批量标签，就把多个值用分隔符拼接起来放到p字段中。之后，在外层SQL中拿到这个字段之后，转化为对应的标签的ID，然后将数据分别放到标签对应的分区中就可以了。

这些任务合并计算之后，任务数下降了一个数量级，计算资源再也没有压力了。

3.4 上下游接入

画像系统数据的入口就是模板里配置的SQL。可以通过SQL取的数据就可以进入画像系统。通常我们都是从数据仓库提取数据，特别是一些统计类的属性，比如发布商品数，最近30天卖出商品数等，都是先在数据仓库中聚合好结果，然后再从数据仓库提取数据。同时，也可以从事件模型中提取数据。当然，直接从明细层提取数据也没问题，但是可能会比较慢。

俗话说，没有机器学习的画像系统不是一个好产品。我们通过SQL的方式接入了机器学习的计算结果作为我们的数据源，补充规则式的标签不能覆盖的领域。和机器学习平台打通，就可以直接在页面上引入机器学习的结果，毕竟这类模板的SQL都是差不多的。

画像系统自上线以来，陆续接入了多个系统。在系统层面打通之后，就可以在其它的系统中使用画像系统产生的数据了，比如运营管理后台接入画像系统后，从之前的人肉推送变成了自助式精准推送，并能实时看到推送效果。