用户画像 模型设计与存储

RS01.干货请收好 | 终于有人把用户画像的流程、方法讲明白了

RS02.代码实战 | 用户画像

RS03.案例实践 | 美团外卖的用户画像实践

0x00 前言

今天主要分享用户画像的数据模型设计与存储。

现在的用户画像，动不动就是几千几万个标签，标签一多就出现了一些需要克服的难题，比如下面两个：

1. 如何解决频繁新增和删除标签的场景

2. 如何解决不同标签更新时间和频率不同的问题

0x01 数据模型设计

从个人角度来讲，在大数据领域接触比较多的的存储引擎有这几个：Hive（Hdfs）、Hbase、ES。这也会是我们在选择存储系统中几个主要的备选方案。

优缺点就不再分析了。我们切入正题：数据模型该怎么设计？

一、横表

以Hive为例，我们最常用的就是横表，也就是一个 key，跟上它的所有标签。比如下面是一个简单的横表。

用户ID	性别	年龄	学历	职业	月薪	月消费能力
001	男	28	本科	程序员	10k-20k	1k-2k
002	女	23	大专	销售	不详	100-200

那么用横表有什么问题吗？有的，其实也就是前言里面提到的：

1. 由于用户的标签会非常多，而且随着用户画像的深入，会有很多细分领域的标签，这就意味着标签的数量会随时增加，而且可能会很频繁。

2. 不同的标签计算频率不同，比如说学历一周计算一次都是可以接收的，但是APP登录活跃情况却可能需要每天都要计算。

3. 计算完成时间不同，如果是以横表的形式存储，那么最终需要把各个小表的计算结果合并，此时如果出现了一部分结果早上3点计算完成，一部分要早上10点才能计算完成，那么横表最终的生成时间就要很晚。

4. 大量空缺的标签会导致存储稀疏，有一些标签会有很多的缺失，这在用户画像中很常见。

嗯，上述的问题，主要是当标签数量开始快速增多的时候会遇到的问题。标签量少的时候其实是不用担心这些的。

那么这些问题该怎么解决呢？这就是下面要聊得竖表。

二、竖表

竖表长下面这个样子：

用户ID	标签名	标签值
001	sex	男
001	salary_month	10k-20k
002	sex	女
002	age	23

这里就不再列举全部内容了，大概介绍一下，竖表其实就是将标签都拆开，一个用户有多少标签，那么在这里面就会有几条数据。

竖表能比较好地解决上面宽表的问题。但是它也会带来了新的问题，比如说多标签组合的查询需求：“我们想看年龄在23-30之间，月薪在10-20k之间，喜欢听古典音乐的女性”，这种多标签查询条件组合情况在竖表中就不太容易支持。

三、横表+竖表

如前面所分析，竖表和横表各有所长和所短，那么能不能两者结合呢？

这其实也要考虑横表和竖表的特性，整体来讲就是竖表对计算层支持的好，横表对查询层支持的好。那么设计的化就可以这样：

0x02 如何存储？

关于存储，我们以前文说的第三种方案为例。

标签的计算我们可以使用Hive、Spark这些计算引擎，这个没什么问题，然后就是这些标签的单独存储可以以Hive为主来存储。

那么在导入标签竖表的时候可以考虑两种存储引擎：Hive（Hdfs）和Hbase，其实笔者更倾向于Hbase，因为如果存在Hbase里的话会更方便查询。顺便再打上一个时间标签，用起来就更方便了。

最后，标签宽表的话可以考虑ES。另外需要注意的就是，从竖表往宽表到数据的时候需要做一层数据的加工，而且考虑到数据稀疏的情况的话，需要在宽表存储这里做一些优化。

0xFF 总结

用户画像最重要的是形成体系。从技术的角度，用户画像能与推荐系统形成联通闭环，最好不过了。下面是之前的分享，可以集中一起看下，希望更能帮到你！

拓展阅读

你可能还喜欢

点击下方图片即可阅读

有ACP意向的同学可以私聊我

领取新版考试大纲和样题以及报名优惠码和在线题库

尽我所能帮到大家

非诚勿扰，谢谢！

欢迎加入 技术交流群。戳：快来加入数据交流群吧

推荐阅读

觉得内容不错的话 请分享到朋友圈哦~
▼ 福利时刻 ▼ 

01. 后台回复「经典」,即可领取大数据数仓经典书籍。

02. 后台回复「中台」,即可领取大厂中台架构高清ppt。

03. 后台回复「加群」,或添加小助微信ID：iom1128  拉您入群（备注方向：大数据|数仓|分析|Flink|资源|python|爬虫）或领取资料。

Q: 关于数据仓库，你还想了解什么？

欢迎留言区与大家分享

觉得不错，请把这篇文章分享给你的朋友哦

入群请联系小助手：iom1128『紫霞仙子』

更多精彩，请戳"阅读原文"到"数仓之路"查看

 

       ！关注不迷路~ 各种干货、资源定期分享！