推荐系统-埋点
来源:互联网 发布:美国癌症存活率 知乎 编辑:程序博客网 时间:2024/06/02 08:02
现在几乎所有的电商平台都或多或少的上了推荐系统,常用的推荐系统有。热门推荐、最近浏览、猜你喜欢、看了还看、买了还买、绑定销售,等等,这么多NB的系统都依赖一点,就是用户行为数据,这些用户行为数据都从那来的呢,那就是埋点系统了,埋点系统是一切推荐系统的生命源。
所谓埋点系统,按本人理解就是埋点引擎+存储系统,埋点引擎位于前端系统与后端存储系统之间,主要是接收前端的埋点数据,经协议转换以后存储到后端存储系统。
整个系统的架构如下所示:
1,用户行为搜索存储格式选择
数据存储格式一定要考虑到足够的可伸缩性,因为业务方的需要总是千奇百怪,一个NB的存储设计可以减少后续很多工作量,下面是我设计埋点系统存储的数据项,欢迎讨论。
Name
Des&R
msg_id
消息ID
realuserid
用户ID,登录后存在,
sysname
来源系统的名称
servicetype
具休来源页面
oper_type
行为类型
appid
移动应用会有APPID
location
移动应用会有APPID位置信息
accesstime
访问时间
ip
PC端IP地址
itemid
商品ID
anomoususerid
用户ID,没有登录存匿名,登录以后存实际用户ID
descinfo
描述信息,日志类型是评分时,此处写评分
sessioninfo
会话IDs,随机生成的10位数字,每位单独生成
2,存储系统选择
当时选择HBASE主要是考虑到两点因素,一是它的可伸缩性,一是它较高的实时性,当然也有很多其它的选择,比如mongodb也不行,只是我没有用过,不熟。
3,埋点引擎
埋点引擎是本系统的核心所在,主要负责解析前端发来的http消息,解析以后通过thrift协议丢给thriftserver,thriftserver再放到HBASE。
这个设计上来讲还是比较简单,主要是要考虑到高并发,短连接的情况,下面是单机的一个设计。
采用了比较典型的多线程设计模型。
Monitor是主线程,负责接收前端的埋点消息,通过某种调度算法放到对应的队列,给客户端应答埋点成功消息。
Scheduler:调度模块,Monitor调用,不是单独线程。
QX:消息队列,采用无锁队列设计,可以理解为一个先进先出的缓存机制,Monitor负责生产消息,Worker负责消费消息。
Worker:负责消息的校验,合法性检查,解析,打包,发送任务。
- 推荐系统-埋点
- 《推荐系统学习》之推荐系统那点事
- 每天学点推荐系统(一)
- 推荐系统的十个关键点
- 推荐系统的那点事
- 推荐系统的那点事
- 推荐系统的那点事
- 推荐系统的那点事
- [推荐] Linux系统新手学习的11点建议
- 《程序员》杂志:成功开发推荐系统的十个关键点
- 智能推荐系统开发中的十个关键注意点
- 智能推荐系统开发中的十个关键注意点
- 智能推荐系统开发中的十个关键注意点
- 智能推荐系统开发中的十个关键注意点
- 智能推荐系统开发中的十个关键注意点
- 智能推荐系统开发中的十个关键注意点
- 智能推荐系统开发中的十个关键注意点
- 智能推荐系统开发中的十个关键注意点
- 【编程习题★★★☆☆】计算岛屿的数量
- 极课 good
- 装饰者模式
- 判断当前一个物料被其他人锁定
- Android如何实现左边侧滑界面SlidingMenu
- 推荐系统-埋点
- IM收藏
- TextView/EditText字体阴影 ,自动换行,焦点获取,输入法回车键前往,自定义光标
- ios开发Keyboard Type及其截图
- Scala集合笔记
- CocoaPods详解之使用篇
- 分类器评价指标
- 多线程第五篇 经典线程同步之信号量Semaphore
- python time模块详解