推荐系统提供web服务的2种方式( 三 )


 
该架构既可以支持T+1推荐模式和实时推荐模式,对于T+1型推荐产品形态,每天为用户生成一次推荐结果,生成推荐结果时直接替换昨天的推荐结果就可以了 。而对于实时推荐,情况会复杂一些,实时推荐可能会调整用户的推荐结果(而不是完全替换),对用户推荐结果进行增删形成新的推荐结果,这时可行的方法有两个:一是从推荐结果存储数据库中读出该用户的推荐结果,按照实时推荐算法逻辑对推荐结果进行修改,再将推荐结果存进去替换掉,另外一种做法是,增加一个中间的镜像存储(可以采用HBase等,现在业界很多推荐算法都基于Hadoop/Spark平台实现,用大数据生态系的HBase是比较好的选择),所有的算法逻辑修改只对镜像存储进行操作,操作完成后,将镜像存储中修改后的推荐结果同步到最终的推荐库中,这跟T+1更新就保持一致了,只不过现在是实时推荐,同一个用户可能一天会更新多次推荐结果 。作者公司的短视频实时推荐更新就是采用后面的这种方案,感兴趣的读者可以参考《基于标签的实时短视频推荐系统》这篇文章第三节1中的介绍 。
 
四、实时装配型web服务本节我们来讲解实时装配型web服务的实现原理与架构(参考下面图6) 。这种方式事先不计算用户的推荐结果,当有用户请求时,web接口服务器从特征数据库(一般也是存放在Redis、HBase这种非关系型数据库中)中将该用户需要的特征取出来,并将特征灌入推荐模型,获得该用户的推荐结果,跟事先计算型一样,还需要加载推荐标的物的metadata信息,拼接成完整的推荐结果,并返回给前端展示给用户 。

推荐系统提供web服务的2种方式

文章插图
 
图6:实时装配型web服务架构(web接口服务加载推荐模型)
 
该web服务架构需要将推荐模型加载到web接口服务中,可以实时基于用户特征获得推荐结果,这就要求推荐模型可以在极短的时间(毫秒级)内获得推荐结果,计算一定要快,否则会影响用户体验 。当然另外一种可行的方案是,将推荐模型做成独立的web模型服务,web接口服务通过HTTP或者RPC访问模型服务获得推荐结果 。具体架构如下面图7,这种方式的好处是推荐模型服务跟web服务解耦,可以分别独立升级模型服务和推荐接口服务,互相之间不会影响,只要保证它们之间数据交互的协议不变就可以了 。
推荐系统提供web服务的2种方式

文章插图
 
图7:通过推荐模型服务来获取推荐结果的实时装配型web服务架构
 
实时装配型架构在实际提供推荐服务时就与具体的推荐范式是T+1推荐还是实时推荐没有关系了,因为在任何时候web接口服务都是临时调用推荐模型为用户生成推荐结果,只不过T+1推荐的模型可以一天训练一次,而实时推荐的模型是实时训练的(用户的每一次操作行为都会产生日志,通过实时日志处理,生成实时特征,灌入实时模型训练流程中,最终完成对模型的实时训练,让实时模型得到更新) 。
 
业界流行的TensorFlow Serving就是一种实时装配型服务架构,它提供web服务的架构模式类似上面图6的形式,下面对其进行简单介绍,让读者更好地理解这种模式 。读者可以查看参考资料1、2、3对TensorFlow Serving进行更深入的了解 。
 
TensorFlow Serving是一个灵活的、高性能的机器学习模型在线服务框架,设计用于生产系统,可以与训练好的TensorFlow模型高效整合,将训练好的模型部署到线上,使用gRPC作为接口接受外部调用 。TensorFlow Serving支持模型热更新与自动模型版本管理 。
 
下图为TensorFlow Serving整个框架图 。Client端会不断给Manager发送请求,Manager会根据版本管理策略管理模型更新,并将最新的模型计算结果返回给Client端 。
推荐系统提供web服务的2种方式

文章插图
 
图8:TensorFlow Serving架构,图片来源于TensorFlow Serving官方文档
 
FaceBook开源的FAISS(见参考资料4)框架也是业界用的比较多的一款用于实时装配型web服务的框架 。FAISS包含几种相似性搜索方法,它假设用户或者标的物被表示为向量并由整数标识(用户和标的物用整数来唯一标识,即用户id和标的物id),可以在海量向量库中搜索出按照某种相似性计算的最相似的向量列表 。FAISS提供了向量之间计算L2(欧几里德)距离或点积距离的方法,与查询向量最相似的向量是那些与查询向量具有最小L2距离或最大点积的向量 。FAISS具备在极短的时间(毫秒级)内计算某个向量最相似的一组向量的能力 。它还支持cosine余弦相似性查询,因为cosine余弦只不过是向量内积的归一化 。


推荐阅读