前言

在互联网发展的早期,内容比较匮乏,不论在资讯,电商,还是广告行业。那个阶段诞生了搜索引擎。解决了信息查找的问题。随着互联网迅速发展起来,互联网上面的内容几何式增长。用户获取信息的途径不再困难。怎么样在海量的信息中找到用户感兴趣的内容,就是我们现在要解决的问题了。推荐系统就应运而生了。从最早的千篇一律。然后到物以类聚,人以群分的推荐。到现在的千人千面,实时推荐。本文主要介绍了电商推荐系统的一些基础架构和基础概念。本文主要介绍的推荐系统的系统工程。其他依赖模块都简略概括

总架构图

推荐系统是基于大数据系统之上的。需要使用到用户的行为数据,训练模型。

推荐系统总架构图

应用入口

目前电商中,基本每个场景都有推荐系统的功能。比如：首页,商品详情页,分类,搜索,活动,购物车等等。
虽然每个场景都有推荐模块,但是各个场景又是不一样的。

首页场景的推荐比较综合,新品推荐,爆款推荐,品牌推荐等等。
商品详情页推荐,偏向于以商品推荐商品。推荐相似商品,相关商品,看了又看等等
分类场景,向用户推荐偏好的分类,品牌等等
搜索场景,向用户推荐搜索词,在搜索的基础上做推荐
购物车场景,也是基于商品推商品。

目前电商平台一般都有APP,PC,H5,微信小程序等多种接入方式,不同的接入方式在推荐内容上面也会有一些差别。

推荐系统

本文介绍的推荐系统是一个分布式推荐系统。支持各种类型的推荐业务。系统主要由七个子系统构成。
接入层,调度层,abtest,召回层,粗排层,精排层以及规则层。不同的推荐业务。
根据业务需求,选择走其中的N层。
本系统对外提供HTTP接口。方便各类前端业务接入。系统内部使用基于tcp长连接的内部协议。提高性能。

接入层

接入层是整个分布式推荐系统的入口网关,是整个推荐系统的对外门户,也是整个系统最坚实的后盾,主要工作简介：

安全校验,屏蔽非法请求
容灾,当下游内部系统超时或者处理失败。返回容灾结果
限流,按照场景,调用方,业务进行限流。
协议转换,将外部HTTP请求转成内部协议,以及将内部返回的响应转换成HTTP协议

接入层是整个系统种要求稳定性最高的系统。自身绝对不允许有问题。就算下游系统全部挂掉。也依然需要提供对外的容灾服务。一般情况下,对于核心场景。都会去准备一些核心的容灾数据,如果下游请求失败。走核心的容灾数据返回。非核心场景会利用之前的成功请求来容灾。

调度层

调度层负责协调内部各子系统的运行。当系统流量突增时(双十一)并对下游系统进行保护。其主要工作简介：

请求ABTEST系统,获取当前流量需要执行的路径。如果ABTEST挂掉了,需要对ABTEST进行容灾
请求召回层,根据ABTEST返回的参数,选择对应的具体召回层子域进行请求,获取推荐的候选集。
请求粗排层,将上一步的结果,根据ABTEST返回的参数,选择对应的具体粗排层子域进行请求,将推荐的候选集快速排序,取出TopN。
请求精排层,将上一步的结果,根据ABTEST返回的参数,选择对应的具体精排层子域进行请求,将推荐的候选集进行精细排序。
请求规则层,将上一步的结果,根据ABTEST返回的参数,选择对应的具体规则层子域进行请求,将推荐的候选集进行规则处理。

其中针对召回层做了更精细的保护逻辑。如果一个场景需要走召回层。那么这个场景的输入一般都是一些简单的条件,比如用户信息,商品信息,品牌信息。需要通过这些信息,取召回相应业务的商品列表。如果这一步失败的话。那就意味着,整个请求失败。所以针对召回层做了容灾处理。保证每个流量都尽可能有返回。

ABTEST

ABTEST是用来做AB实验的分流系统。同时也提供配置服务器的功能。为算法,业务场景提供丰富的实验功能,其主要工作简介：

提供稳定的实验分流。同一个设备(不是每个请求都有用户id),在实验周期内稳定的落到一个分支中
提供分层实验支持。在推荐系统中,一次请求需要经过召回层,粗排层,精排层,规则层中的一层或多层
提供人群分流。某些推荐场景可能需要区分新客和老客,男性和女性等,对精准的人群是做实验
提供实验对齐功能。在多个不同场景的实验中,有写场景需要确保同一个用户落到的分支对齐
提供实验洗牌功能。实验组按照某个周期洗牌按天,周,月等等。防止因为长时间不洗牌造成马太效应
提供条件分流功能。支持自定义条件参数进行分流。比如终端,省份等等。
提供配置服务功能。在不同的分支中提供不同的参数。支持自定义灵活配置。

ABTEST是推荐系统中的核心基础服务。为推荐效果的优化方向提供指导。摒弃拍脑袋决定,用数据说话。万物皆可ABT。算法迭代升级的过程中。一个新算法上线不知道是正向还是负向。需要用ABTEST,分出一个小分支作为实验组。和现有的基线版本对比。如果效果好(点击率,转化率,人均UV金额等等),就把实验组的流量放大。如果效果不好就需要减少流量或者关闭实验。ABTEST的作用就是保证每次优化迭代,都至少不能比当前差。

粗排层

粗排层,是将召回层的返回或者请求中的海量商品。进行粗选。选出用户可能感兴趣的TopN商品,然后给精排层排序,其主要工作简介：

提供简单的过滤筛选功能。比如库存打压(无库存商品需要打压),商品去重(去掉一些重复的商品)等
提供按照运维规则粗选功能。根据运营需求,将一些主推商品前置,保证能进入到精排中等等
提供按照算法模型粗排功能。使用一些高性能的算法模型,对大量进行粗排

粗排层的作用从大量商品中,将用户可能感兴趣的商品前置。并且将其中一些不合适的商品打压掉。提供一些简单的运营需求的支持。为精排商品做截断。粗排层一般需要处理的商品列表在5000+。而精排层处理能力有限只能处理2500+左右的商品。因此需要粗排层做前置筛选。

精排层

精排层,对上游传下来的商品列表进行精排。使用的算法也是多种多样的有机器学习的也有深度学习的。比如LR,SVM,GBDT,CNN,DIN等等。其主要工作简介：

提供效果更好的算法排序模型(相对于粗排层)
针对不同场景,提供不同类型的算法模型排序
针对不同人群,提供不同类型的算法模型排序

精排层的作用是依靠各种机器学习和深度学习的算法模型。去精排商品。好卖热卖的商品。未必是每个人都喜欢的商品。把最合适的商品展示给用户,同时也能解决大量商品无法得到曝光和售卖的机会。

规则层

规则层,针对上游返回的商品列表进行一些规则调整。其主要工作简介：

执行商务的运营规则,比如固定(将指定的商品,品牌固定到指定位置)
执行打压规则,比如曝光打压(同一个商品对同一个用户曝光很多次,但是用户没有行为的需要打压)。库存打压(无库存的商品,或者库存低于一定程度的商品需要适度打压等)
执行用户已购商品的打压。针对不同的商品类型和购买周期打压。
执行打散功能。比如品牌打散,类目打散。然结果看起来比较自然
执行紧急的一些过滤置顶功能。比如快速下架某些品牌等

规则层主要作用就是解决一些精排层(机器学习和深度学习)不是很好解决或者解决不好的问题。让最终呈现给用户看的商品看起来更舒适(不会都是一个品牌或者一个分类,特定场景除外)。当一些紧急突发事故出现的时候。可以通过规则层来做一些调整解决。比如紧急下线某品牌。在某些情况下需要出来的商品没有出来。但是短时间内又找不到问题等等。

数据层

数据层,存放大数据系统处理后的各类供推荐使用的数据。推荐系统的各子系统需要对其进行读写。算法模型进行预估排序时,需要实时获取商品和用户的属性信息。接入层,调度层需要对召回层的返回进行剪枝缓存。以供容灾使用。大数据实时和离线处理的结果,会按照算法和推荐业务的需求存储在数据层。数据层是推荐系统的基石。没有数据无从推荐。怎么样做稳定,跨机房容灾,防止断电,断网就是数据层需要保证的。一般推荐系统的数据层使用最多的是nosql。

离线平台

离线平台负责日常处理的海量数据。将不同类型,不同格式的数据通过ETL入仓。落到hdfs,数据库,nosql,数据仓库。为大数据数据产品提供数据支持。相对实时平台来说。离线的任务处理的耗时比周期都比较长。时效性比较差一点。推荐算法平台训练模型,需要使用到离线平台的用户行为相关的数据

实时平台

实时平台通过Storm,Spark,Flink等实时处理平台,实时处理日志数据。推荐系统中需要使用的数据都是比较实时的。比如在做曝光打压中,就需要比较实时的知道。当前这个用户曝光和点击过的商品。模型训练也是一样。需要实时获取当前一段时间比如5分钟内的用户行为增量。然后去训练模型迭代。用户画像方面也需要实时的生成。比如一个新客购买了一个商品之后,就需要马上变成老客表示。下次推荐的时候就需要用老客的方式推荐或者展示老客的价格等等。数据越实时。推荐的效果相对来说会越好

机器学习平台

机器学习平台,包含了目前通用的一些机器学习和深度学习框架。算法同学通过在机器学习平台上,调整和优化算法模型和参数。算法模型依赖于离线平台和实时平台的数据。当模型实时生成出来之后。就会按照模型的使用场景,推送到推荐系统里面的对应的子系统中。动态加载。

运维平台

运维平台,为推荐系统提供发布,监控,运维支持。实时监控推荐场景流量。及时发现和解决问题。对线上各子域进行监控。对容量进行评估。对线上异常(流量,硬件,效果,容量)进行实时告警。针对ABTEST实验系统进行效果统计,提供不同实验的效果对比,让算法迭代升级更安全可控。同时还需要对离线和实时的数据进行监控。不仅仅是监控数据任务的执行成功与否,同时还需要对数据质量进行监控。