1号店架构师王富平：一号店用户画像系统实践

你的名字 2022-02-19 10:41 171阅读 0赞

转载：https://blog.csdn.net/qiansg123/article/details/80121794

我先引用梵高的一句话：“我想强调的是，同一个人有多样的自画像。与其追求照相般的相似性，不如深入地发掘相似处”。下图是是当时梵高比较得意时的画像，戴了礼帽，穿了西服，但那时耳朵已经割掉了。我觉得作为一个好的架构师，要有艺术家的精神。时至今日架构发生了很多变化，新语言在不断出现，我觉得没必要把思维停留在某一个方面。

![图片描述][20160205143049886]

### 用户画像的定义 ###

用户画像定义使用标签来量化用户特性属性，达到描述用户的目的。用户画像的难点就是数据源，因为你拿要拿到足够多足够全的数据很不容易，所以要与业务结合，比如说这个人在30天内购买了你的商品，这就是一个标签，但是如果你不参与开发这个系统，你不会想到有这个标签。然后是动态更新，一个人是不断变化的，就像梵高一样，他不同时期的自画像也是不一样的。

### 假设现有用户画像有姓名、地域两个属性，你将如何使用？ ###

最简单的分析不同性别的群体特征，做特定营销。分析广州、北京、客户的群体特征，分析90后、80后的群体特征。其实这里面有共同点，就是说分类和聚类。京东也好、淘宝也好、一号店也好，我不可能真的每一个用户生成一套推荐方案，我们都是把人分成了一万个类，或者一千个类，我们把你划分到某一个类别里面，在那个类别里面做一个推荐。而且群体特征往往更能反映你的个人喜好，就是说其实人与人之间是有共同点的，也是有异同点的。

## 分类—聚类 ##

### 迈出个性化的第一步，用户画像的应用开始 ###

1号店建立用户画像的初中是来自于《千人千面》项目，简而言之：分析不同群体特征，针对群体进行推荐调整，典型的群体有小区、学校公司等。下图是2015年9月份转化率的数据。我们覆盖面也比较大，目前差不多355家公司，591个行业，覆盖293个城市的4.26万个小区。

![图片描述][20160205143402983]

1号店从零开始打造了自己的用户画像系统，包含了用户标签画像、用户偏好画像。经历了全量版画像、Storm版实时画像、电商用户标签画像等演进和完善的过程。在两年的时间里，遇到了性能瓶颈、数据质量评估、用户标签的膨胀、画像在精准化营销等应用场景的摸索，一步步成长，在推荐系统发挥了巨大作用。

### 用户标签画像 ###

我们的用户标签包含基本特征、社会身份、顾客用户生命周期、类目偏好等等。比如说你怎么判断一个人是不是对女装感兴趣，假设我们有一个类目就是女装，那很好办，如果你购买都是女装，那会认为你这个人对女装比较感兴趣。如下图所示。

![图片描述][20160205143509247]

### 挑战 ###

我们期间遇到了两方面的挑战：

1.  亿级画像系统实践和应用
2.  记录和存储亿级用户的画像，支持和扩展不断增加的维度和偏好，毫秒级的更新，支撑个公司性化推荐、广告投放和精细化营销等产品

### 怎么做到的 ###

1.  用户画像算法模型不断优化
2.  引入Storm等实时技术
3.  主题推荐标签、用户命名实体等新增标签补充进画像
4.  HBase的离线和在线分离、Hbase的KV读和Solr的批量读分离、region热点监控和切分
5.  数据流不断优化
6.  数据存储改进

### 第一版画像现状 ###

偏好系统包括类目偏好和导购属性偏好两个部分，第一版的偏好系统接口调用数每天达千万次，主要服务于推荐栏位和EMD，但改变的偏好系统存在性能低下，偏好得分分布不合理等问题：

1.  运行一次全量的数据更新太慢
2.  用户的偏好得分数据分布不合理，得分呈多波峰分布，且在6.0、8.0区间的得分数目几乎为0
3.  用户强偏好和弱偏好的阈值界限未有明显规定
4.  用户未产生新的行为，兴趣偏好分值将不会发生变化（未按时间进行衰减）

### 新版画像系统流程 ###

![图片描述][20160205143637763]

这个很简单，就是大家都能想到的离线和在线，离线要基于用户的行为，产品的信息进行打分，要得到一个个人的偏好，前端提供一个接，基本上是这样子。

### 画像模型优化1 ###

关于算法模型做了一些优化，第一个优化就是得分，通过操作得分使它的偏好更有区分性，历史行为应有衰减。你这个得分假设永远是叠加的，这也是有问题的，因为你一个月之前或者一年之前所有的行为，如果现在还影响着你的得分，会有不准确性，所以会有一个历史的衰减得分。偏好得分分布应与用户对类目的权重分布一致，关键是对数据的处理，还有怎么样去调整你的模型。

偏好画像的得分应满足三个条件：

*  用户在此类目或导购属性上的操作越多，得分越高
 *  用户对类目或导购属性的喜好程度不同，可以通过偏好得分区间体现
 *  用户的历史行为应有衰减

对于类目偏好，需先将用户对类目偏好离散化提高某些场景性能，最简单的行为可划分为两档【喜欢|一般】。

参数调整原则：

*  衰减系数的设置满足两个月衰减一半

（结合用户在不同类目下的购买周期，见下页）

*  各类行为权重之间的比例设置等同于用户各种行为数目的比例
 *  偏好得分分布应与用户对类目的权重分布一致

### 画像模型优化2 ###

然后有一个购买周期的问题，就是说不同的东西会有一个购买周期的，比如说牙膏多久前买的，牛奶多久前买的，这些东西的周期性是比较强的。后面会有一个实时推荐，根据用户的行为进行算分，根据各个类目的偏好进行一个实时推荐。

主题标签，比如说吃货，比如说爱吃零食的女性，算是吃货范围。还有数码极客，就是通过主题划分人。具体的方法我就不多讲，就是通过你购买的东西进行分类。下图是用户不同类目的购买周期。

![图片描述][20160205143923694]

### 主题推荐标签 ###

主题和标签的映射关系如下：

![图片描述][20160205144008890]

使用标签表中的关键词列表，结合商品的评论、标题数据给商品打标签。

商品打标签公式为：

![图片描述][20160205144043680]

用户打标签公式为：

![图片描述][20160205144119774]

### HBase的离线和在线分离 ###

讲一下HBase，我们拿了很多开源的东西。我想问一下CAP大家都了解吧，一个数据库你只能获取两个特性。这边我们采用了离线和在线的方式，把可用性提上去。如下图所示。

![图片描述][20160205144157578]

### Solr解决批处理选人 ###

我们还有一个选人机制，就是用户画像的另一个场景，既然你有用户的各种信息了，那么对于其他业务，比如说广告业务，比如说促销业务他们提供了一个需求，就是选人，是基于Solr做的一个选人中心。如下图所示。

![图片描述][20160205144236885]

### 调优相关表，提高读写性能 ###

根据画像表每一台机器的热点，迁移或者切分。

![图片描述][20160205144311448]

### 数据流优化 ###

guid和userid的对应关系中，滤掉公用电脑和黄牛账户（全国有20万左右人从事刷单产业链）。为了进一步提高离线部分的计算速度，牺牲算法精确性，用户的行为权重计算亦可以增量计算

设Wh为用户对某个类目的历史行为权重，Wc为用户最新一天的行为权重，则总的行为权重

Wt = λWh + Wc, 0<λ<1

如果采用上述方法，则不必遍历用户的所有的行为数据，每次更新时，只需遍历一天的数据即可。

### 优化数据存储 ###

用户行为和行为统计表HBase替换为Hive，最后的画像表保留为HBase；

考虑到类目偏好使用比较频繁，而导购属性偏好数据量远大于类目偏好，解耦来将两者分开存储；

类目偏好离线数据结构-Hive

![图片描述][20160205144412719]

### 全量数据过滤 ###

全量数据过滤，就是类目偏好离线的全量数据进行过滤之后，导入在线部分，主要优化就是刚才讲的模型优化。过滤原则:

*  每个用户的偏好类目数量小于一个固定值
 *  用户偏好得分大于下限，该下限可假设用户当天在某个类目只有一个加车行为，然后带入模型反推出来

导购属性偏好离线的全量数据进行过滤之后，导入在线部分。过滤原则:

*  属性偏好大于一个固定的下限
 *  属性值的数量小于一个上限
 *  属性值偏好大于一个固定下限

### 主要优化和改进点 ###

主要优化和改进如下图所示。

![图片描述][20160205144516595]

*  长期兴趣和短期偏好解耦
 *  类目和属性不同画像偏好解耦

### 尝试与未来 ###

我们曾经想做实时画像，实时的达到导到实时里面，但是现在我们并不是做实时画像，我们做的是实时推荐，为什么不做呢？因为这些算法不太好算，比如说算一个衰减周期，你要根据30天的编号算一个你当前类目的变化，你要拿30天的数据，这样的算法压力就很重。未来想做就是使用HBase镜像双集群，Apache Lgnite+HBase。

我们也做了一些有趣的东西，就是一些排行榜，对某些大学做一些排行榜的排名，实际上根据大学的特定群体我们已经做了推荐，这个东西其实还蛮好玩的。

### 一些启示 ###

1.  提炼出该案例（或项目）的哲理、方法论。
2.  算法准确度、数据规模、更新速度相互制衡，提高某些指标，必须牺牲其他指标。
3.  一个系统遇到性能瓶颈的时候，跳出系统本身，了解业务，根据业务解耦，以满足不同场景。
4.  数据流各个环节都可能出错，自动化检查各个节点的中间数据，考虑降级和延迟环境。
5.  系统的演进是个长期的过程，系统的分分合合和业务量有关，防止过度架构浪费资源。
6.  不同版本开发的时候，适度换些开发者，融入新的思路，避免思维定式。
7.  标签体系的管理规范比技术本身更重要，否则大部分标签会沉睡，后面基本用不到。
8.  数据驱动，通过观察和研究数据，对数据有一定的敏感度，产生新的用户画像数据。

--------------------

本文是1号店架构师王富平日前在「七牛云主办的架构师实践日——瞩目电商」的演讲内容整理。PPT、速记和现场演讲视频等参见[“七牛架构师实践日”官网][Link 1]。

--------------------

七牛架构师实践日是由七牛云发起的线下技术沙龙活动，联合业内资深技术大牛以及各大巨头公司和创业品牌的优秀架构师，致力于为业内开发者、架构师和决策者提供最前沿、最有深度的技术交流平台，帮助大家知悉技术动态，学习经验成果。
    
       
        
       
        
         1

### 架构技术实践系列文章（部分）： ###

*  唯品会官华：实现电商平台从业务到架构的治理体系
 *  沈剑：58同城数据库架构最佳实践
 *  荔枝FM架构师刘耀华：异地多活IDC机房架构
 *  UPYUN的云CDN技术架构演进之路
 *  初页CTO丁乐：分布式以后还能敏捷吗？
 *  陈科：河狸家运维系统监控系统的实现方案
 *  途牛谭俊青：多数据中心状态同步&两地三中心的理论
 *  云运维的启示与架构设计
 *  魅族多机房部署方案
 *  艺龙十万级服务器监控系统开发的架构和心得
 *  [京东商品详情页应对“双11”大流量的技术实践][11]
 *  [架构师于小波：魅族实时消息推送架构][Link 2]

（责编/钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件qianshg@csdn.net，交流探讨可加微信qshuguang2008，备注姓名+公司+职位）

「CSDN 高级架构师群」，内有诸多知名互联网公司的大牛架构师，欢迎架构师加微信qshuguang2008入群，备注姓名+公司+职位。

[20160205143049886]: /images/20220219/40ae75a667234df1a1d124e009a2c521.png
[20160205143402983]: /images/20220219/1f514ce591f14901b3bc6cb109d81c6c.png
[20160205143509247]: /images/20220219/f8bd77322f6c4c918df172ed8a9d09b4.png
[20160205143637763]: /images/20220219/2749e0f57e104ac29c2e0128e7cb2e17.png
[20160205143923694]: /images/20220219/ec28b338e83543519f462c1624fe6c70.png
[20160205144008890]: /images/20220219/63a81275dbb849ecb519943d51c00d37.png
[20160205144043680]: /images/20220219/294f44657b52476c8d1a10d6e1bb0d00.png
[20160205144119774]: /images/20220219/8d3864d9754d4ce48cab16545cb8d6e3.png
[20160205144157578]: /images/20220219/1e32d6655a9947dda8712d5aceffd157.png
[20160205144236885]: /images/20220219/3edbc0e41d354c2fa6187bd7ef7bb257.png
[20160205144311448]: /images/20220219/91df308810ff4b118efd411c630b030f.png
[20160205144412719]: /images/20220219/ea1830793917455c9a4103cd63216150.png
[20160205144516595]: /images/20220219/fddea51d8e384fb79840efc40a0b79e9.png
[Link 1]: http://hd.qiniu.com/arch
[11]: http://www.csdn.net/article/2015-12-28/2826570
[Link 2]: http://www.csdn.net/article/2015-12-22/2826542