推荐系统架构

前言

本文主要介绍推荐系统的基本架构。

推荐系统架构

目录

• 宏观的推荐系统架
• 细化的推荐系统架构
  • 外围架构图
  • 日志存储系统
  • 推荐系统

宏观的推荐系统架

 我们从宏观上可以感受到的推荐系统架构如下：通过数据分析得到用户画像，然后通过推荐系统给用户推荐数据。从此图中，我们也可以窥知一个完整的推荐系统至少应该有如下的子系统：用户画像子系统，内容子系统，存储子系统，推荐引擎子系统等。

推荐系统外围架构

外围架构图

 我们需要知道推荐系统是如何和网站的其他系统联系起来的。一般来说，每个网站都会有一个UI系统，UI系统负责给用户展示网页并和用户交互。网站会通过日志系统将用户在UI上的各种各样的行为记录到用户行为日志中。日志可能存储在内存缓存里，也可能存储在数据库中，也可能存储在文件系统中。而推荐系统通过分析用户的行为日志，给用户生成推荐列表，最终展示到网站的界面上。

日志存储系统

 在一个推荐系统中，需要对用户的行为数据进行存储分析，得到用户画像，进而为用户推荐符合个人口味的结果。毫无疑问，用户的行为数据量是巨大的。我们需要根据实际的情况采用不用的存储方式来进行存储。才能产生的，而有些行为是所有用户都可以产生的。从规模上看，浏览网页、搜索记录的规模都很大，因为这种行为所有用户都能产生，而且平均每个用户都会产生很多这些行为。购买、收藏行为规模中等，因为只有注册用户才能产生这种行为，但购买行为又是电商网站的主要行为，所以它们相对于评论来说规模更大，但相对于网页浏览行为来说规模要小得多，最后剩下的行为是注册用户里的一小部分人才有的，所以规模不会很大。从实时存取的角度上看，购买、收藏、评论、评分、分享等行为都是需要实时存取的，因为只要用户有了这些行为，界面上就需要体现出来，比如用户购买了商品后，用户的个人购买列表中就应立即显示用户购买的商品。而有些行为，比如浏览网页的行为和搜索行为并不需要实时存取。

 按照前面数据的规模和是否需要实时存取，不同的行为数据将被存储在不同的媒介中。一般来说，需要实时存取的数据存储在数据库和缓存中，而大规模的非实时地存取数据存储在分布式文件系统（如HDFS）中。数据能否实时存取在推荐系统中非常重要，因为推荐系统的实时性主要依赖于能否实时拿到用户的新行为。只有快速拿到大量用户的新行为，推荐系统才能够实时地适应用户当前的需求，给用户进行实时推荐。

推荐系统

 在先前的文章已经介绍过了，推荐系统是一个联系用户和物品的一个系统。而根据一般的规律，推荐系统联系用户和物品一般有三种方式。如下图：

 

 根据上面的抽象，可以设计一种基于特征的推荐系统架构。当用户到来之后，推荐系统需要为用户生成特征，然后对每个特征找到和特征相关的物品，从而最终生成用户的推荐列表。因而，推荐系统的核心任务就被拆解成两部分，一个是如何为给定用户生成特征，另一个是如何根据特征找到物品。

 如果我们为每一类的特征都准备一种推荐引擎，那么推荐系统需要由多个推荐引擎组成，每个推荐引擎负责一类特征和一种任务，而推荐系统的任务只是将推荐引擎的结果按照一定权重或者优先级合并、排序然后返回。

 那么来看一下推荐引擎的架构