|
说明下包括上面的top30邻居和用户top500的最大推荐列表都是工程优化,截断节约些存储；具体读者可以根据自己业务需要进行设置；
然后大概说下各个表的含义：a1表是用户已消费过的物品，a2表是用户每个邻居喜好的物品;那么也就是说从邻居喜好的物品中过滤掉已经消费的
物品整体根据共现相似度进行排序。
思考
但思路很简单、实际作者开发中总会遇到各种各样的问题，下面就捡几个主要的和大家一起讨论下：
-
1.join引起的数据倾斜问题：tb_neighbour表很大，往往热点物品会占据80%的曝光和消费记录，如何解决？
-
2.增量更新问题：上面的框架，tb_behavior表每次都是全量计算，是否能改造成增量更新邻居表和推荐结果，并减少计算时间呢？
join引起的数据倾斜问题
先思考问题1，既然我们目的是求相似邻居，物品join只是为了关联上一组用户对，那自然的想法是可以根据feed做近似采样、相似度精度也几乎无损失。
下面我试着实现下这种思路：
里用了hive的with as语法，读者可自行查阅，篇幅有限，就不展开了；feed_rn就是随机采样了50000条，实际操作时读者可以先统计下item的分布、大概找到一个阈值；
比如取top10的item的出现次数作为阈值；那计算相似度时分子最多减小10，分母不变。这对大多数情况精度应该足够了，而且因为避免了数据倾斜，大大降低了计算时间。
增量更新问题
问题2是一个工程问题，lambda架构能使初始结果效果不错，可直接上线灰度了；在此基础上再加小时或者天增量；kappa架构相对就比较繁琐、需要一开始就设计增量流程。
精度方面也需要一定的累积；不过如何选择，读者可以根据自己的数据量和熟悉程度自行选择；作者这里仅以kappa架构说明。
重新review上面sql，我们发现我们仅需要记录下cnt12,cnt1,cnt2,iids1这些计算关键即可，其中iids2是用户邻居喜好的物品数组；数值类型可累加更新、
数组类型合并起来比较麻烦，一种解决方案是注册UDF；这里采取另一种这种的方案：把iids1合并成字符串，过滤的时候再分割为字符串数组。
（编辑：常州站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
