|
思考如何设计推荐系统架构
一.先说业务和算法推荐如何交互
业务后端需要每天在用户打开app后拉取用户感兴趣的商品到页面，这个显然不能是实时计算出来的兴趣信息，肯定是直接读取的数据库。可以是先拿redis，不够拿取mysql数据库数据补充。
所以算法团队需要事先将需要的推荐数据放置到业务需要的数据库里面或者通过接口告知业务这些商品是推荐给某个用户的，让业务自己存储。
总之，算法团队就负责为平台用户推荐商品。
有几个问题？
1）平台可能有历史累积海量用户，都推荐？
显然是不可能的，也没必要，只需要给最近一个月内活跃的用户更新推荐即可，当然对于大公司而言，一个月内活跃用户也是海量数据。对于平台所有活跃用户统一推荐就是离线推荐的场景。
2）新用户刚来平台，如何推荐？
冷启动问题，简单粗暴的情况是推荐一些热度，新鲜度高的商品。当然针对新用户可以单独设计一套推荐逻辑(召回，排序)，尽可能多的利用它的已知信息来进行推荐。
3）新用户来了平台一会了，操作了一些东西，是否要针对这种情况进行更精确的推荐？算法团队又如何知道这种情况，要对这个用户更新推荐？
这个是非常需要的，假如新用户一开始是上面简单粗暴的情况，他进行了一些操作后需要及时更正/新他的推荐信息，否则用户体验不好，流失还是很严重的，当然这是对于发展期的公司和业务而言的，瓶颈期和稳定期要求急迫性没那么高了。
算法团队如何知道这个情况？
谁的事谁自己负责，算法团队自己搞定这件事，为自己的推荐效果负责。对于一个新上来的用户，业务后端是不知道推荐什么东西的，就只好请求你的接口告知或者通过一定的消息机制来告知你。这样的话，需要起一个服务来监控这件事，要记录哪些用户是新用户，然后根据新用户距离注册达到一定的时间或者行为操作达到一定的次数来触发更新推荐操作。这个就是所谓的实时推荐的场景。当然，在实际生产环境中，这样效率有点低，所以往往业务后端会知道新用户拉取哪些数据来进行暂时性推荐。
4）平台旧用户，很久不活跃，又来了，如何推荐？
这个实际上是新老用户结合的一个逻辑，但是由于资源没有更新，可以考虑按照新用户流程走，但是对于新用户流程里面的后续推荐，可以拉取到该用户的历史数据，加入这些特征数据，可以精进后续的推荐效果。
二.具体如何做？
1.离线推荐
频次为每天，离线推荐的需求是要求推荐精确，模型可以比较复杂。尽量覆盖到尽可能多的用户。
基本上要上spark来进行分布式计算
1.1 将平台(最近一个月活跃)用户的各种特征拉取到hive里面，将平台所有上架商品的各种特征汇总拉取到hive里面，这里面数据应该一直存在，后续是更新(添/删)操作。
1.2 对于用户进行聚类，一组组进行召回和排序，当然这个聚类可以比较简单，按照年龄，性别，类目偏好，地理位置等。
1.3 对于某一组用户，统一进行商品召回，比如协同过滤，内容标签，lbs(地理位置)，向量召回等。
1.4 对于组内各个用户，设计一个简单公式算法进行粗排，比如根据标签匹配+资源热度+资源新鲜度等综合排序，取topk进行精排
1.5 对于每个用户和topk中每个商品，按照精排模型要求进行向量化
1.6 调用模型进行预测，将推荐商品id排序数据批量告知业务或者入库
有几个问题？
1）将用户和商品数据拉到hive，具体怎么做？
这个基本上是用同步工具将当天计算需要的业务数据库，业务日志数据，可能有些数据是增量，有些数据是全量拉到一些临时的hive表，当然自己跑spark脚本代码里面利用读mysql的这些工具来进行拉取同步也行，但是这样往往效率比较低，而且相对容易出错，因为市面上的同步工具做的优化相对比较多。然后spark脚本任务来将这些拉取好临时数据和原有的hive数据做聚合，更新hive表里面的数据为最新数据。
2）用户聚类的逻辑是根据规则还是聚类模型来实现？
上面的聚类目的是为了加快计算，一组组用户做召回，而不是一个个用户做召回，这种情况下用规则相对简单一些，比如根据某个性别，某个年龄段，某个地区，某个类目偏好来锁定特定召回资源，说白了就是根据这些条件做商品过滤。
3）精排用到各种模型，比如常用的分类模型，lr，gbdt，深度学习模型，这个怎么和spark结合处理？
现在而言，主流的模型和深度学习，都有支持spark的分布式版本或者lr直接用spark mllib里面的即可，这个问题不值得担心。有个小问题是语言支持问题，不少是只支持java/scala的，不支持pyspark(python)版本。
当然到了预测阶段，M个用户和N个商品的模型预测，单机批量预测问题也不会太大，主要耗时肯定在hive数据到本机的io过程。
4）这种排序和LTR什么关系？LTR要不要用？
前文已经讲过，LTR和其他分类模型是一个道理，只是训练时候有差异，应用到预测是使用是一样的。
2.实时推荐
实时处理逻辑和离线推荐类似，但又不完全相同，因为它在一定程度上要注重效率，要在分钟级别有推荐生成。对于典型的新用户有一定活跃之后(按照成熟用户看待)，通过一定的机制来告知到实时推荐算法服务，该服务拉取用户最新的日志数据，业务数据等，再拉取看看用户有没有旧历史数据，最终也是为了拿到用户所有的特征数据，根据这个数据来做hive里面商品数据召回，然后进行粗排，精排等最后将得到推荐结果。因为全量上架商品数据比较多，为了提高效率同时可以为了利用离线的计算代码和思路，实时推荐算法服务是java/python服务 + 流式计算服务来做，告知机制用kafka来做，典型的就是kafka服务 + flink方式来实现，kafka来负责接收新用户需要更新画像的消息，flink上跑的java进程让kafka作为flink数据源，因为内部本身类似socket的监听阻塞式，会不断的来消息然后进行消费，无需起服务来做这件事，让java(脚本jar文件)里面让flink来执行分布式计算，这样直接在分布式商品hdfs(hive)文件所在的分布式集群来进行召回和预测，而且是分布式的，效率会相对比较高。
三.离线训练
1.模型的离线训练，取决于实际情况，能上分布式训练肯定上分布式，能上gpu肯定上gpu，真不行单机cpu跑呗，反正更新频次要求没那么高
2.离线训练的数据大多数情况下和后期训练的数据不能共用，比如会有一个用户不同阶段切分为不同用户的情况，用相对较久远的数据来训练，但二者的向量化处理的逻辑是一致的。
3.模型的滚动更新，这个取决于实际情况，手动周级、半月级更新训练还是自动训练模型上线替换等。
| 
转播
