Spark+ES+ClickHouse 构建DMP用户画像 最新

本文主要是介绍Spark+ES+ClickHouse 构建DMP用户画像 最新，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

DMP用户画像介绍

DMP即 Data-Management Platform，数据管理平台，单从名称上来看，这个定义还是非常宽泛的，所以国内很多企业或者个人会将DMP的核心功能理解错。

结合我的理解，DMP其实是一个全面的数据收集，加工，整合的平台，吸收各种数据源的数据，以用户为基本单位，清洗，整理形成结构化的数据表，并进行用户标签的计算，以期能够精准的描述各种用户。

纯碎的DMP平台是指小型的、定制能力极强、中立性好的DMP技术服务商。美国DMP市场是极度细分的，中国市场是高整合的，往往DMP的需求是和DSP、SSP紧密联系在一起的，目前还很难有纯粹的DMP平台。

Spark+ES+ClickHouse实战用户画像签体系构建

第一步是标签系统，标签系统是用来为满足某些特征的人群做标记用的，一个人身上可以有很多标签，我们就是根据这些标签来描绘这个人或人群的用户画像，为业务提供更精准的人群。

搭建标签体系需要从分类开始，标签又可以分为很多种类型，可以分的很细，这里我们只从业务角度出发，简单的分一下类，满足基本的核心需求。

用户标签：这些信息是用户最基本的信息，例如，性别、年龄、地区、学历、注册时间、是否结婚等等。

行为标签：用户的一些可统计的基本行为，例如，7日活跃次数、30日购买次数、90日浏览次数、180日关注次数、90日消费金额等等。

偏好标签：时间偏好、商品偏好、品类偏好、店铺偏好等等，通过统计用户行为后按照规则进行判断分类。

预测标签：通过用户行为数据，运用协同过滤算法、回归算法等等对用户进行行为预测。如果公司业务数据量级不大，这类标签会用的比较少，带来的效果也不一定有明显提升。

TF：

这里我们用 N（P，T）表示一个标签T被用于标签用户P的次数。

TF（P，T）表示这个标记次数在用户P所有标签标记次数中所占的比例。

TF（P，T）= N（P，T）/Σ N（P，Ti）

N（P，T）：打在某用户身上某个标签的个数

Σ N（P，Ti）：该用户身上全部标签的个数

Ti 该用户全部标签个数

IDF：

IDF（P，T）：表示标签T在全部标签中的稀缺程度

如果一个标签出现的几率很小，同时被用户标记某个用户，这就使得该用户与该标签T之间的关系更加紧密。

IDF（P，T）=Σ Σ N（Pi，Ti）/ΣN（Pi，T）

Σ Σ N（Pi，Ti）：全部用户的全部标签之和

ΣN（Pi，T） ：所有打T标签的用户之和

7）计算方式

举例子：

用户“斑马”，对于标签“语文”的标签权重计算：假设我们之前定义 冷却系数α=0.16。

行为表：




用户“斑马”对标签“语文”的权重：

语文=2*0.1+2*0.2+3*0.6+1*0.5+1*0.9=3.8

语文=3.8 *exp（-α*1）+1*0.1+1*0.2+2*0.6+1*0.5+0=5.067718

2010-08-23：语文= 5.067718*exp（-α*1）= 4.318424

Spark+ES+ClickHouse实战用户画像群体用户画像构建

-- 本地查询代理

CREATE TABLE ch_agent_user

agentname String

ENGINE = MergeTree()

PARTITION BY agentname

ORDER BY (agentname)

SETTINGS index_granularity = 8192;

-- 分布式代理表

CREATE TABLE ch_agent_dist_user AS ch_agent_user

ENGINE = Distributed('cluster_test', 'test', 'ch_agent_user', cityHash64(agentname))

-- 查询用户数

SELECT sum(user_number) AS user_number

FROM ch_agent_dist_user

RIGHT JOIN

WITH

(

SELECT groupBitmapState(userid) AS users0

FROM ch_label_string

WHERE labelname = 'T'

) AS users0

SELECT

'agent' AS agentname,

bitmapCardinality(users0) AS user_number

) USING (agentname) settings enable_scalar_subquery_optimization = 0;

ch_agent_user 表本身不存储数据，当与 with 语句进行 right join 关联查询时，由于是右关联查询，查询结果以 with 语句的结果集为准。

各个节点的查询结果返回给查询节点，查询节点进行汇总计算。参数 enable_scalar_subquery_optimization = 0 表示 with 语句的查询结果不做优化，每个节点都需要执行。

默认情况，在 ClickHouse 中 with 语句的结果作为标量进行缓存，会将查询节点的标量分发到其他服务器，当发现已经存在标量时，就不会在本地节点执行 with 语句。

我们期望 with 语句在每个节点都执行，所以将这个参数设置为 0。

用户画像

用户画像对性能要求比较高，查询平均响应时间不能大于 5 秒。用户在界面上任意圈选人群，然后实时对圈选后的人群进行画像分析。

用户画像技术进行了三次架构重构：

1）V1：大宽表模式

最早的方案是创建一张 userid 为主键的画像表，表的其他字段为画像的特征字段，将圈选的人群与画像表进行 in 操作，然后 group by 操作。

这种设计带来两个比较严重的问题：

当增加或者删除特征字段时，画像表的表结构需要修改；
当圈选的人群数量比较大时，涉及到大记录集的 group by 运算，性能差。
2）V2：Bitmap 模式

将一个特征值下的 userid 集合做为 Bitmap 对象存储到一条记录中，一条记录的内容如下：

用户圈选的人群 Bitmap 对象与画像表的 Bitmap 对象进行与（AND）操作，返回圈选人群的画像信息。

通过这样设计，基本上满足了性能要求，平均时间小于 5 秒，但是一些大的人群包，画像的性能还是差，在 10 秒左右。

画像表的记录数据量不大，但画像表的 Bitmap 字段在计算时需要从磁盘上反序列化出来。有的 Bitmap 对象占用几百兆的空间，导致了性能的下降。

3）V3：Join 表引擎模式

ClickHouse 的 Join 表引擎可以将数据常驻到内存。当插入数据时，数据先写入内存，然后刷到磁盘文件，系统重启时，自动把数据加载回内存。Join 表引擎可以说是常驻内存的带持久化功能的表。

我们把画像表的数据保存到 Join 表引擎，画像表的 Bitmap 字段就常驻内存了，当圈选的人群 Bitmap 对象进行与（AND）操作时，两个内存中已经加载的 Bitmap 对象之间的计算就非常快。

通过这次优化平均查询时间优化到 1 到 2 秒，千万级人群画像分析不超过 5 秒。

作者 \/ 307570512

这篇关于Spark+ES+ClickHouse 构建DMP用户画像 最新的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！