用户画像系统中遇到的比较难的问题是什么?
1. 我们在选择如何存储用户标签时,遇到了问题(标签查询速度慢,并且构建不够灵活,标签更新和删除比较麻烦),比如之前用HDFS或者ES存储,后来切换为ClikcHouse,并用BitMap存储,原因如下:
针对标签的表示形式,存储方式有很多,结构为`宽表,BitMap` 都可以,存储选择`HDFS,ES,ClickHouse 等` 也都可以,
需要衡量的有两点`1.标签构建的灵活性和构建速度 2.标签的查询效率 `
`HDFS [Presot,Impala]:` 标签的增加,删除,更新不友好, 一个小变动,要重写整个`Parquet`, 写放大问题。查询效率还可以,但是不够优秀。 支持查询并发较小。
`ES:`标签的构建的写入速度一般, 新增和修改标签需要对ES文档结构更新,ES的DSL语法不友好,有一定学习成本。
查询效率还算优秀,同时支持高并发。 ES资源占用高,需要较好的硬件配置。
`ClickHouse[BitMap]` 标签可以并行构建,查询效率优秀,标签的增加非常方便,标签的更新和删除可以实现,
但是并不高效,并发查询支持比Presto,Impala要好,但同样不支持高并发,能够满足大部分场景需求。
注意两点`1. BitMap存储的是用户ID 2. BitMap使用了RoaringBitMap, 解决BitMap空间占用问题,
不然1亿这一个数也要占用11.9M空间`
2. 如何构建用户的稠密向量的问题
如果我们直接将用户的标签转换为稀疏向量来存储,对于类别标签使用`one-hot`编码,但这样会出现维度爆炸的问题,
向量过于稀疏,向量之间的余弦相似度计算结果基本没有意义,根本无法实现用户相似度的计算。所以就开始思考如何将用户
表示为转换为稠密向量,经过调研发现,Word2Vec可以将词转换为稠密向量,同时借助Word2Vec思想,也可以将物品转换为
向量Item2Vec,比如将一个Session内,用户购买的物品或者点击的物品列表,看成是一句话,每个物品看成是一个单词,
就可以借助Word2Vec的思想将物品转换为稠密向量表示。(这里注意如果是文章,可以使用分词,然后抽取关键词,将词通过
Word2Vec转换为向量的方式) ,我们再将用户点击或者购买的物品列表中物品向量加和求平均,就可以得到用户的稠密向量。
后来发现通过ALS模型`矩阵分解`的方式也可以得到用户的稠密向量,两者`表达的用户向量含义`是不同的,一个是有浓重的
物品属性特征的,一个是有协同特征的向量。但是都可以作为用户的向量表示方式。
相关推荐HOT
redis数据类型有几种
消息队列(stream):一个特殊的数据结构,用于支持流式处理消息,并可以支持消费者分组、消费者位移等特性。每种数据类型都有对应的命令可以进行...详情>>
2023-03-16 10:19:36hadoop集群的最主要瓶颈
Hadoop集群的主要瓶颈取决于许多因素,例如集群的大小、硬件规格、网络架构、数据复杂性和处理任务等。以下是可能影响Hadoop集群性能的一些常见...详情>>
2023-03-14 10:22:17java底层hashmap扩容怎么实现?
Hashtable的synchronized是针对整张Hash表的,即每次锁住整张表让线程独占,ConcurrentHashMap允许多个修改操作并发进行,其关键在于使用了锁分...详情>>
2022-11-08 14:31:36用户画像系统中遇到的比较难的问题是什么?
如果我们直接将用户的标签转换为稀疏向量来存储,对于类别标签使用`one-hot`编码,但这样会出现维度爆炸的问题,向量过于稀疏,向量之间的余弦...详情>>
2022-11-07 15:25:17