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模型`矩阵分解`的方式也可以得到用户的稠密向量，两者`表达的用户向量含义`是不同的，一个是有浓重的

　　物品属性特征的，一个是有协同特征的向量。但是都可以作为用户的向量表示方式。

上一篇

Hadoop集群安装系列------单机安装 (根据官方文档编写)

下一篇

java底层hashmap扩容怎么实现？