基础推荐引擎的工程实现基础推荐引擎的工程实现基础推荐引擎的工程实现
推荐引擎模块
- 接收请求
- 处理请求
- 返回结果
制造结果集(离线模型训练得到的结果)
格式:
- UID:item_id,item_id,item_id
- ltem_id:item_id,item_id,item_id
日志格式
- cookie
- uid
- user agent
- ip
- video_id
- topic
- order_id
- log_type
日志种类
- 点击
- 播放
- 点赞
- 收藏
- 付费观看
- 站外分享
- 评论
Server.py
retargeting营销
对每一种日志，都可以做重定向，重定向就是对之前操作（买、看、点击）过的物品，再展现一次
- 电商重定向
- 电影重定向
- 文章重定向
编写重定向营销模块
- 点击重定向
- 播放重定向
- 点赞重定向
- 收藏重定向
- 付费观看重定向
- 站外分享重定向
- 评论重定向
处理日志
- 处理点击日志
- 处理播放日志
- 处理点赞日志
- 处理收藏日志
- 处理付费观看日志
- 处理站外分享日志
- 处理评论日志
处理点击日志
点击重定向
实际场景：
1.小明登录了major网站
2.前端瞬间向后端说明，小明来了，小明来了，我要继续推荐什么玩意给他
3.后端结合之前的点击日志，发送点击重定向推荐（之前小明所有点击过的商品）
流式处理
- 流式处理概念
- 流式处理逻辑实现
- 流式处理应用
打造你自己的流式处理系统打造你自己的流式处理系统打造你自己的流式处理系统
设计场景和梳理需求
- 例如说视频网站场景
- 例如说在线阅读小说的场景
制定流式处理规则
- 点击流式处理规则
- 收藏流式处理规则·
人工干预推荐结果
- 编辑推荐
流式处理（短期兴趣）的优势
- 低相应时延
- 动态效果丰富
- 用户体验效果好
- 转化率高
另一种就是离线处理（长期兴趣），两者结合就是整个推荐系统
流式处理的劣势
- 资源消耗严重
- 效果准确度有影响
- 效果起伏大、分析原因难
实现流式处理
- 内存更新方式
- 一致性哈希算法
- 更新缓存机制
内存更新方式
- map
- list
一致性哈希算法
一致性哈希算法在1997年由麻省理工学院提出的一种分布式哈希（DHT）实现算法，设计目标是为了解决因特网中的热点(Hot spot)问题，初衷和CARP十分类似。
一致性哈希修正了CARP使用的简单哈希算法带来的问题，使得分布式哈希（DHT）可以在P2P环境中真正得到应用。
在采用一致性哈希算法的分布式集群中将新的机器加入，其原理是通过使用与对象存储一样的Hash算法将机器也映射到环中（一般情况下对机器的hash计算是采用机器的IP或者机器唯一的别名作为输入值）
然后以顺时针的方向计算，将所有对象存储到离自己最近的机器中。
以上面的分布为例，如果NODE2出现故障被删除了，那么按照顺时针迁移的方法，object3将会被迁移到NODE3中，这样仅仅是object3的映射位置发生了变化，其它的对象没有任何的改动。
如下图:
如果往集群中添加一个新的节点NODE4，通过对应的哈希算法得到KEY4，并映射到环中，
如下图:
实现平衡
平衡性(Balance): 平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。
单调性(Monotonicity):单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去，而不会被映射到旧的缓冲集合中的其他缓冲区
分散性(Spread):在分布式环境中，终端有可能看不到所有的缓严，U定只所吧的缪共中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时，由于不同终端所见的缓冲范围有可能不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终新全1端映射到不同的缓冲区中。这种情况显然是应该避免的，因为它导致相同内容被不同缓冲中去，降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法应能够尽量避免不一致的情况发笙，也就是尽量降低分散性。
负载(Load):负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中，那么对于一个特定的缓冲区而言，也可能被不同的用户映射为不同的内容。与分散性一样，这种情况也是应当避免的，因此好的哈希算法应能够尽量降低缓冲的负荷。
应用流式处理
- 重定向
- 类别关联
- 同类目推荐
- 人工干预推荐结果
扫一扫
2219
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
