真实案例，手把手教你构建用户画像

admin • 2021-12-15 21:10 • 云计算

导读：本文通过一个贯穿本书的实践案例来将大家更好地带入实际开发画像、应用画像标签的场景中。本文主要介绍案例背景及相关的元数据，以及开发标签中可以设计的表结构样式。

在本案例的开发工作中，基于Spark计算引擎，主要涉及的语言包括HiveQL、Python、Scala、Shell等。

作者：赵宏田

来源：大数据DT（ID：hzdashuju）

01 案例背景介绍

某图书电商网站拥有超过千万的网购用户群体，所售各品类图书100余万种。用户在平台上可进行浏览、搜索、收藏、下单、购买等行为。商城的运营需要解决两个问题：

一方面在企业产品线逐渐扩张、信息资源过载的背景下，如何在兼顾自身商业目标的同时更好地满足消费者的需求，为用户带来更个性化的购物体验，通过内容的精准推荐，更好地提高用户的点击转化率；
另一方面在用户规模不断增长的背景下，运营方考虑建立用户流失预警机制，及时识别将要流失的用户群体，采取运营措施挽回用户。

商城自建立以来，数据仓库中积累着大量的业务数据、日志数据及埋点数据。如何充分挖掘沉淀在数据仓库中的数据的价值，有效支持用户画像的建设，成为当前的重要工作。

02 相关元数据

在本案例中，可以获取的数据按其类型分为：业务类数据和用户行为数据。其中业务类数据是指用户在平台上下单、购买、收藏物品、货物配送等与业务相关的数据；用户行为数据是指用户搜索某条信息、访问某个页面、点击某个按钮、提交某个表单等通过操作行为产生（在解析日志的埋点表中）的数据。

涉及数据仓库中的表主要包括用户信息表、商品订单表、图书信息表、图书类目表、App端日志表、Web端日志表、商品评论表等。下面就用户画像建模过程中会用到的一些数据表做详细介绍。

1. 用户信息表

用户信息表（见表1-2）存放有关用户的各种信息，如用户姓名、年龄、性别、电话号码、归属地等信息。

▼表1-2 用户信息表（dim.user_basic_info）

2. 商品订单表

商品订单表（见表1-3）存放商品订单的各类信息，包括订单编号、用户id、用户姓名、订单生成时间、订单状态等信息。

▼表1-3 商品订单表（dw.order_info_fact）

3. 埋点日志表

埋点日志表（见表1-4）存放用户访问App时点击相关控件的打点记录。通过在客户端做埋点，从日志数据中解析出来。

▼表1-4 埋点日志表（ods.page_event_log）

4. 访问日志表

访问日志表（见表1-5）存放用户访问App的相关信息及用户的LBS相关信息，通过在客户端埋点，从日志数据中解析出来。

▼表1-5 访问日志表（ods.page_view_log）

5. 商品评论表

商品评论表（见表1-6）存放用户对商品的评论信息。

▼表1-6 商品评论表（dw.book_comment）

6. 搜索日志表

搜索日志表（见表1-7）存放用户在App端搜索相关的日志数据。

▼表1-7 搜索日志表（dw.app_search_log）

7. 用户收藏表

用户收藏表（见表1-8）记录用户收藏图书的数据。

▼表1-8 用户收藏表（dw.book_collection_df）

8. 购物车信息表

购物车信息表（见表1-9）记录用户将图书加入购物车的数据。

▼表1-9 购物车信息表（dw.shopping_cart_df）

03 画像表结构设计

表结构设计也是画像开发过程中需要解决的一个重要问题。

表结构设计的重点是要考虑存储哪些信息、如何存储（数据分区）、如何应用（如何抽取标签）这3个方面的问题。

不同业务背景有不同的设计方式，这里提供两种设计思路：一是每日全量数据的表结构；二是每日增量数据的表结构。

Hive需要对输入进行全盘扫描来满足查询条件，通过使用分区可以优化查询。对于用户标签这种日加工数据，随着时间的推移，分区数量的变动也是均匀的。

每日全量数据，即该表的日期分区中记录着截止到当天的全量用户数据。例如，“select count(*) from userprofile where data='20180701'”这条语句查询的是userprofile表截止到2018年7月1日的全量用户数据。日全量数据的优势是方便查询，缺点是不便于探查更细粒度的用户行为。

每日增量数据，即该表的日期分区中记录着当日的用户行为数据。例如，同样是“select count(*) from userprofile where data='20180701'”，这条语句查询的是userprofile表在2018年7月1日记录的当日用户行为数据。

日增量数据可视为ODS层的用户行为画像，在应用时还需要基于该增量数据做进一步的建模加工。

下面详细介绍这两种表结构的设计方法。

1. 日全量数据

日全量数据表中，在每天对应的日期分区中插入截止到当天为止的全量数据，用户进行查询时，只需查询最近一天的数据即可获得最新全量数据。下面以一个具体的日全量表结构的例子来进行说明。

CREATE TABLE `dw.userprofile_attritube_all `(
    `userid` string COMMENT 'userid', 
    `labelweight` string COMMENT '标签权重',)
COMMENT 'userid 用户画像数据'
PARTITIONED BY ( `data_date` string COMMENT '数据日期', `theme` string COMMENT '二级主题', `labelid` string COMMENT '标签id')

这里userid表示用户id，labelweight表示标签权重，theme表示标签归属的二级主题，labelid表示一个标签id。通过“日期 +标签归属的二级主题+标签id”的方式进行分区，设置三个分区字段更便于开发和查询数据。

该表结构下的标签权重仅考虑统计类型标签的权重，如：历史购买金额标签对应的权重为金额数量，用户近30日访问天数为对应的天数，该权重值的计算未考虑较为复杂的用户行为次数、行为类型、行为距今时间等复杂情况。

通过表名末尾追加“_all”的规范化命名形式，可直观看出这是一张日全量表。

例如，对于主题类型为“会员”的标签，插入“20190101”日的全量数据，可通过语句：insert overwrite table dw. userprofile_userlabel_all partition(data_date= '20190101', theme= 'member', labelid='ATTRITUBE_U_05_001')来实现。

查询截止到“20190101”日的被打上会员标签的用户量，可通过语句：select count(distinct userid) from dw.userprofile_userlabel_all where data_date='20190101'来实现。

2. 日增量数据

日增量数据表，即在每天的日期分区中插入当天业务运行产生的数据，用户进行查询时通过限制查询的日期范围，就可以找出在特定时间范围内被打上特定标签的用户。下面以一个具体的日增量表结构的例子来说明。

CREATE TABLE dw.userprofile_act_feature_append (  
  labelid STRING COMMENT '标签id',   
  cookieid STRING COMMENT '用户id',   
  act_cnt int COMMENT '行为次数',
  tag_type_id int COMMENT '标签类型编码'，
  act_type_id int COMMENT '行为类型编码') 
comment '用户画像-用户行为标签表'
PARTITIONED BY (data_date STRING COMMENT '数据日期')

这里，labelid表示标签名称；cookieid表示用户id；act_cnt表示用户当日行为次数，如用户当日浏览某三级品类商品3次，则打上次数为3；tag_type_id为标签类型,如母婴、3C、数码等不同类型；act_type_id表示行为类型，如浏览、搜索、收藏、下单等行为。分区方式为按日期分区，插入当日数据。

通过表名末尾追加“_append”的规范化命名形式，可直观看出这是一张日增量表。

例如，某用户在“20180701”日浏览某3C电子商品4次（act_cnt），即给该用户（userid）打上商品对应的三级品类标签（tagid），标签类型（tag_type_id）为3C电子商品，行为类型（act_type_id）为浏览。

这里可以通过对标签类型和行为类型两个字段配置维度表的方式，对数据进行管理。例如对于行为类型（act_type_id）字段，可以设定1为购买行为、2为浏览行为、3为收藏行为等，在行为标签表中以数值定义用户行为类型，在维度表中维护每个数值对应的具体含义。

该日增量数据表可视为ODS层用户行为标签明细。在查询过程中，例如对于某用户id为001的用户，查询其在“20180701”日到“20180707”日被打上的标签，可通过命令：select * from dw.userprofile_act_feature_append where userid = '001' and data_date>='20180701' and data_date<= '20180707'查询。

该日增量的表结构记录了用户每天的行为带来的标签，但未计算打在用户身上标签的权重，计算权重时还需做进一步建模加工。

3. 关于宽表设计

用户画像表结构如何设计，没有一定要遵循的固定的格式，符合业务需要、能满足应用即可。下面通过两个宽表设计的案例，提供另一种解决方案的思路。

用户属性宽表设计（见表1-10），主要记录用户基本属性信息。

▼表1-10 用户属性宽表设计

用户日活跃宽表设计（见表1-11），主要记录用户每天访问的信息。

▼表1-11 用户日活跃宽表设计

关于作者：赵宏田，资深大数据技术专家，先后在中国地质大学（武汉）和武汉大学获得工学和经济学双学士学位。在大数据、数据分析和数据化运营领域有多年的实践经验，擅长Hadoop、Spark等大数据技术，以及业务数据分析、数据仓库开发、爬虫、用户画像系统搭建等。开源项目的贡献者，知乎专栏作者，撰写了大量专业文章，广受好评。著有畅销书《数据化运营：系统方法与实践案例》。

本文摘编自《用户画像：方法论与工程化解决方案》，经出版方授权发布。（ISBN：9787111635642）

《用户画像：方法论与工程化解决方案》

点击上图了解及购买

转载请联系微信：DoctorData

推荐语：这是一本从技术、产品和运营3个角度讲解如何从0到1构建用户画像系统的著作，同时它还为如何利用用户画像系统驱动企业的营收增长给出了解决方案。作者有多年的大数据研发和数据化运营经验，曾参与和负责多个亿级规模的用户画像系统的搭建，在用户画像系统的设计、开发和落地解决方案等方面有丰富的经验。