当前位置: 首页 / 技术干货 / 正文
用户画像、推荐系统、Flink实时数仓、准实时数仓中,遇到的棘手的问题都有什么?

2022-08-02

用户 问题 标签 向量 可以

用户画像、推荐系统、Flink实时数仓、准实时数仓中,遇到的棘手的问题都有什么?

 

用户画像

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模型`矩阵分解`的方式也可以得到用户的稠密向量,两者`表达的用户向量含义`是不同的,一个是有浓重的物品属性特征的,一个是有协同特征的向量。但是都可以作为用户的向量表示方式。

推荐系统

1. SparkML Pipline 训练模型通过PMML跨平台部署时字符串转向量的问题

由于我们通过Pipline训练出来的排序模型,模型的输入是之前存入HBase中向量(用户和物品)字符串,当我们使用`jpmml-sparkml` 这个类库去生成PMML模型,进行扩平台部署时,发现无法正常生成PMML。 原因是因为对于字符串转向量这种`transformer操作` jpmml没有支持,我们参照jpmml源码的实现方式,做了自定义transformer的实现。原理是先自定义一个Spark ML的transform,然后再扩展一个jpmml对应的converter即可。

2. 特征向量Load到HBase慢的问题

我们构建出来的用户特征向量和物品特征向量,最终是存储到HBase中的,最初是使用HBase API写入数据,但是太慢了,整个数据的写入要耗费5~6个小时,之后我们`使用了bulkLoad的方式`,直接通过使用Spark生成将数据`生成HFile文件`写入到HDFS,然后使用blukLoad直接生成好的HFile文件mv过去即可,15分钟完成。 更具体点,首先我们把我们将要写入hbase的rdd,按照设定的行键排序,之后将行键和值构造一个HFile的KeyValue结构,设定outputformat 为HFileOutputFormat2,将生成的hfile数据写入到hdfs,之后通过doBulkLoad方法将写到HDFS上hfile数据移动到hbase目录中。(这些项目的代码中都有)

3. 多路召回结果如何如何统一排序的问题

因为我们采用了多种召回算法,比如ItemCF,ALS, 基于热门,基于地域 等召回算法。 没有召回算发的结果集我们是无法直接排序的,因为各个召回算法表达的含义是不同的,最开始不知道该怎么做,因此就是各个召回算法设定一个人为比例去取。 之后学习了解到可以加`一个排序模型`做这个事情,原理就是用户向量和物品向量作为基础特征,用户是否点击物品作为标签,训练一个排序模型(LR),只有将各路召回策略输入排序模型重新排序即可。 # 注意如果你同时说1,3问题,注意顺序

数仓问题

1. Flink Watermark激增的问题

参考:http://coder.yihongyeyan.com/question/7, `里面有watermark 激增的场景说明`。从这上面的我举的例子,你应该知道这种情况发生的原因,是因为我们抽取事件事件直接减去延迟时间造成,解决方式就是我们再抽取watermark时,判断一下事件中的时间和上次watermark的时间,如果两者时间相差很大,我们就不更新watermark或者将watermark加上一个小值就可以了,一般选择不更新。

2. 实时作业和离线作业的资源竞争问题

因为我们统一用Yarn做资源调度,实时作业Flink(Spark Streaming)和离线作业会调度到同一个机器上,集群相对空闲时没什么问题,但是当集群负载较高时,尤其是晚上大批离线任务启动,就会造成我们实时作业的某些Container所在机器负载过高,同时我们实时作业中如果有重计算逻辑,Flink计算不过来,背压产生,Kafka消费延迟,数据积压。解决这个问题的方法是,YARN Label,给YARN管理的机器打上标签,离线和实时分开,提交作业时指定Lable。

3. 实时作业调度集中的问题

问题产生的背景是,当提交一个作业时(Flink,Spark),作业不大,YARN上申请10个Container,发现10个Container都调度到一个节点上,或者大部分调度到一个节点上,几个调度到另一个节点,资源分配倾斜。 这样造成如果我的作业是一个重计算的作业,10Container都在一个节点上,CPU load过高,计算延迟。 当时出现这个问题,比较苦恼,不知道什么原因,也没有search到解决方案,最后只能去看源码了(我们用的是Fair调度器),发现Container的分配策略是在一个NodeManger心跳中尽可能多的分配Container,这是为了提升调度的吞吐,但是源码中有参数可以控制,是否一个心跳允许分配多个Container,以及一次心跳最大分配多少个Container给当前的NodeManager.这个参数Yarn已经暴露给用户了`yarn.scheduler.fair.assignmultiple` 默认是true。`yarn.scheduler.fair.max.assign` 默认是-1,就是无限制。 解决的方式是`yarn.scheduler.fair.max.assign` 设置为一个较小的值,比如2.

 

好程序员公众号

  • · 剖析行业发展趋势
  • · 汇聚企业项目源码

好程序员开班动态

More+
  • HTML5大前端 <高端班>

    开班时间:2021-04-12(深圳)

    开班盛况

    开班时间:2021-05-17(北京)

    开班盛况
  • 大数据+人工智能 <高端班>

    开班时间:2021-03-22(杭州)

    开班盛况

    开班时间:2021-04-26(北京)

    开班盛况
  • JavaEE分布式开发 <高端班>

    开班时间:2021-05-10(北京)

    开班盛况

    开班时间:2021-02-22(北京)

    开班盛况
  • Python人工智能+数据分析 <高端班>

    开班时间:2021-07-12(北京)

    预约报名

    开班时间:2020-09-21(上海)

    开班盛况
  • 云计算开发 <高端班>

    开班时间:2021-07-12(北京)

    预约报名

    开班时间:2019-07-22(北京)

    开班盛况
IT培训IT培训
在线咨询
IT培训IT培训
试听
IT培训IT培训
入学教程
IT培训IT培训
立即报名
IT培训

Copyright 2011-2023 北京千锋互联科技有限公司 .All Right 京ICP备12003911号-5 京公网安备 11010802035720号