推荐系统-埋点

 

        现在几乎所有的电商平台都或多或少的上了推荐系统，常用的推荐系统有。热门推荐、最近浏览、猜你喜欢、看了还看、买了还买、绑定销售，等等，这么多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:负责消息的校验，合法性检查，解析，打包，发送任务。