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