本文共 8168 字，大约阅读时间需要 27 分钟。
推荐系统是基于用户行为、兴趣等特征，为用户推荐感兴趣的信息和产品的系统，旨在解决信息过载和用户需求不明确的问题。推荐系统可以根据不同的目标用户划分为基于大众行为的推荐引擎和个性化推荐引擎，也可以根据数据之间的相关性划分为基于人口统计学的推荐和基于内容的推荐。
通常，我们在讨论推荐系统时更关注个性化推荐系统，因为它实现了更智能的信息发现过程。协同过滤算法是目前应用最成功也是最普遍的算法之一，主要分为基于用户的协同过滤和基于物品的协同过滤。
在实际推荐系统中，通常会根据不同的场景采用不同的策略或多策略组合以达到最佳效果。本文主要通过应用ALS和基于内容的推荐算法来构建推荐系统，涉及大量数据和代码，后续将在GitHub上提供详细说明。
首先，我们来看看推荐系统的概况图。
接下来，我们将详细阐述推荐算法的应用和推荐过程。
1.1 数据准备
通过院校信息的结构化数据school.txt和school_loca.txt，将这两个结构化文件加载到Hive表中。
(1) school.txt数据样例：
院校id 名称 地址 类型 住宿方式 学费 备用金 运营归属 授权平台 审核状态1,诺丹姆吉本斯主教中学(Notre Dame-Bishop Gibbons School),纽约州-斯克内克塔迪,混校,寄宿家庭,283047,13289,UC独家代理,校代网/微信,审核通过2,毕晓普马金高中(Bishop Maginn High School),纽约州-奥尔巴尼,混校,寄宿家庭,277488,13028,UC独家代理,校代网/微信,审核通过
(2) school_loca.txt数据样例：
地址id 地址名称1,加利福尼亚州-洛杉矶2,纽约州-里弗黑德3,新泽西州-莱克伍德市4,安大略省-鲍曼维尔市
(3) 对院校信息进行量化处理
SQL语句示例：select sd.schoolid, sd.name schoolname, sd.location, sl.locationid, (casewhen sd.type="混校" then "0"when sd.type="男校" then "1"when sd.type="女校" then "2"end) as school_type, (casewhen sd.zhusu="寄宿家庭" then "0"when sd.zhusu="学校宿舍" then "1"when sd.zhusu="男生学校宿舍/女生寄宿家庭" then "2"when sd.zhusu="学校宿舍/寄宿家庭" then "3"when sd.zhusu="学校宿舍-寄宿家庭" then "3"end) as zs, sd.fee, sd.byjfrom school2_detail sdjoin school2_location slon sd.location = sl.name;
提取出唯一描述一所院校的“特征因子”：学校地址id（locationid）、学校类型（school_type）、住宿方式（zs）、学费（fee）、备用金（byj），并将这些"特征因子"进行量化（除了locationid、fee、byj按照实际值进行量化，school_type、zs量化标准参考上述SQL语句）。
1.2 数据归一化处理
奇异样本数据数据指相对于其他输入样本特别大或特别小的样本矢量。这些数据可能会增加训练时间并导致无法收敛，因此在存在奇异样本数据的情况下，进行归一化处理是有必要的。
院校"特征因子"具有不同的量纲，为了消除指标之间的量纲影响，需要进行数据标准化处理，以解决数据指标之间的可比性。原始数据经过数据标准化处理后，各指标处于同一数量级，适合进行综合对比评价。
本数据处理采取归一化方式：最大—最小标准化。
最大—最小标准化是对原始数据进行线性变换，设MIN(A)和MAX(A)分别是属性A的最小值和最大值，将A的一个原始值x通过最大—最小标准化映射到区间[0, 1]的值x’，那么公式如下：x’ = (x - MIN(A)) / (MAX(A) - MIN(A))。
在院校信息中，school_type、zs往往取值较小，而fee、byj取值较大，量纲对数据分析时会产生一定影响，需要进行归一化处理：
归一化前：1 诺丹姆吉本斯主教中学(Notre Dame-Bishop Gibbons School) 71 0 0 283047.0 13289.0归一化后：1 诺丹姆吉本斯主教中学(Notre Dame-Bishop Gibbons School) 0.693069306930693 0.0 0.0 0.4018890324907577 0.4000060201071579
归一化处理SQL语句示例：create table school2_detail_number asselect sd.schoolid, sd.name schoolname, sl.locationid, (casewhen sd.type="混校" then "0"when sd.type="男校" then "1"when sd.type="女校" then "2"end) as school_type, (casewhen sd.zhusu="寄宿家庭" then "0"when sd.zhusu="学校宿舍" then "1"when sd.zhusu="男生学校宿舍/女生寄宿家庭" then "2"when sd.zhusu="学校宿舍/寄宿家庭" then "3"when sd.zhusu="学校宿舍-寄宿家庭" then "3"end) as zs, sd.fee, sd.byjfrom school2_detail sdjoin school2_location slon sd.location = sl.name;
最终归一化结果表：schoolid int ##院校idschoolname string ##院校名称locationid int ##院校地址idschool_type string ##院校类型zs string ##住宿方式fee double ##学费byj double ##备用金gyh_lid double ##归一化后的locationidgyh_school_type double ##归一化后的学校类型gyh_zs double ##归一化后的住宿方式gyh_fee double ##归一化后的学费gyh_byj double ##归一化后的备用金
接下来，我们将详细阐述基于内容的推荐。
2.1 基于内容推荐概述
基于内容的推荐（CB）主要是根据用户过去喜欢的物品（item），为用户推荐和他过去喜欢的物品相似的物品，关键在于item相似度的度量。CB的过程一般包括以下三步：
优点：易于实现，不需要用户数据因此不存在稀疏性和冷启动问题；基于物品本身特征推荐，因此不存在过度推荐热门的问题。缺点：抽取的特征既要保证准确性又要具有一定的实际意义，否则很难保证推荐结果的相关性。
2.2 相似度算法描述
欧几里得距离衡量空间各个点之间的绝对距离，跟各个点所在位置的坐标直接相关。欧氏距离能够体现个体数值特征的绝对差异，所以更多的用于需要从维度的数值大小中体现差异的分析，如使用用户行为指标分析用户价值的相似度或差异。值域范围[0,正无穷大]
皮尔逊相关系数强调的是空间中各点之间的线性相关关系。值域范围[-1,1]。0代表无相关性，负值代表负相关，正值代表正相关
余弦相似度衡量空间向量的夹角，主要体现在方向上的差异，而不是位置。比如A、B两点：保持A点位置不变，B点朝原方向远离坐标轴原点，则二者之间的余弦距离是保持不变的（因为夹角没有变化），但A、B两点的距离明显发生变化。余弦距离更多的是从方向上区分差异，而对绝对的数值不敏感，更多的用于使用用户对内容评分来区分兴趣的相似度和差异，同时修正了用户间可能存在的度量标准不统一的问题（因为余弦距离对绝对数值不敏感）。值域范围[-1,1]
2.3 数据准备和处理
同“基于Spark KMeans对院校进行聚类”中的数据准备
2.4 具体实现逻辑
待处理数据示例：
院校id 院校名称 院校地址 院校地址id 学校类型 住宿方式 学费 备用金1,诺丹姆吉本斯主教中学(Notre Dame-Bishop Gibbons School),纽约州-斯克内克塔迪,71,0,0,283047.0,13289.022,毕晓普马金高中(Bishop Maginn High School),纽约州-奥尔巴尼,25,0,0,277488.0,13028.043,萨拉托加中央天主中学(Saratoga Central Catholic School),纽约州-萨拉托加斯普林斯,72,0,0,285705.0,13289.054,天主教中央中学(Catholic Central High School),纽约州-特洛伊,66,0,0,283047.0,13289.0
实现思路：根据上述获得院校详细数据，提取出特征因子，计算各个院校之间的相似度并根据相似度倒序排序，并计算每个院校与它相似的院校取TopN存储到Redis中【注意：去掉基准院校】。
接下来，我们将详细阐述基于Spark ALS实现离线推荐。
3.1 Spark基于模型协同过滤推荐算法ALS
Spark没有像mahout那样，严格区分基于物品的协同过滤推荐（ItemCF）和基于用户的协同过滤推荐（UserCF）。只有基于模型的协同过滤推荐算法ALS（model-based CF）。
ALS通过数量相对少的未被观察到的隐藏因子，来解释大量用户和物品之间潜在联系。ALS基于矩阵分解通过降维的方法来补全用户-物品矩阵，对矩阵中没有出现的值进行估计。
ALS基本假设：任何一个评分矩阵均可近似分解成两个低维的用户特征矩阵和物品特征矩阵。矩阵分解过程可理解成将用户和物品均抽象的映射到相同的低维潜在特征空间中。
3.2 具体实现逻辑
3.2.1 预处理日志数据获得用户对院校的“综合分数”
通过处理采集到的日志数据，得到school_als.txt，示例如下：
用户id，操作类型（浏览/收藏等），院校id1,浏览,141,浏览,261,浏览,11,收藏,12,浏览,152,浏览,82,浏览,122,浏览,10
根据用户id和院校id分组获得各个用户对院校的操作类型的次数，从而计算最终对应院校的分值（score）【注意：这里暂且将各个操作类型的基础权重设为1，浏览一次权重加0.15、收藏一次权重加0.55，评论一次权重加0.3。后续具体根据业务来定具体的权重】。最终得到的数据示例如下：
用户id，院校id，分数，唯一标示id（方便后边切分数据训练ALS模型）((1,16,1.15),16)((1,3,1.15),87)((1,26,2.3),88)((1,34,1.15),154)
3.2.2 训练Spark ALS模型，进行推荐
1）“历史”综合评分数据：将上一步处理得到的数据，转换成ALS的Rating格式数据，并将唯一标示id模于10（用于切分数据）
2）院校数据（school.txt）处理成（院校id -> 院校名称）并转成map
3）单一用户“实时”综合评分数据：用户在页面实时的行为数据并处理成“用户id，院校id，综合分数”的格式
将“综合评分数据”切分成3个部分，60%用于训练（加上单一用户“实时”综合评分数据），20%用于校验，20%用于测试
spark ALS训练API主要有这几个参数：
ratings：用户评分数据RDD[Rating]rank：隐因子个数，越大计算量越大，一般越精确iterations：迭代次数lambda：控制正则化过程，值越高正则化程度越高
计算不同参数下，根据训练集获得的模型计算校验集的RMSE（均方根误差）RMSE最小的即为最佳模型。
将用户“实时”浏览的院校去掉，其他院校作为“候选”推荐院校，根据训练的最优模型取TopN进行推荐。
接下来，我们将从业务角度分析ALS和CB的结合应用。
4.1 针对用户是否产生实时行为数据的不同处理
注意：由于本推荐系统中基于CB的推荐，是基于院校相似度的推荐（不依赖于用户偏好度数据），只要用户产生浏览/收藏等行为，就能基于浏览/收藏等的院校计算相似院校，所以不考虑新用户“冷启动”问题。
4.1.1 用户产生实时行为数据（浏览/收藏/评论等，设置不同权重）
ALS正常处理
CB参考下方"基于CB的离线和实时推荐结果落地分析"
4.1.2 用户没有产生实时行为数据
ALS老用户：直接根据用户历史数据，按照ALS的正常处理逻辑进行处理
新用户：可以推荐一些热门院校、需要推广的院校等
CB参考下方"基于CB的离线和实时推荐结果落地分析"
4.2 推荐结果"落地"分析
注意：
原始加载的院校数据是最基层、完整的数据（包括下线院校），所以推荐院校集要过滤掉已下线院校再进行推荐【也可以在加载院校数据时通过SQL语句过滤已下线院校，通过离线计算获得的推荐院校集也就不包含已下线院校；实时的推荐结果也会利用离线的推荐结果集所以获得推荐院校也不包含已下线院校。但是如果在离线结果已形成（当天或之前）或实时计算时下线院校更新而没有及时更新相应的推荐数据会有一定延迟误差】
取TopN存储到Redis中，但实际推荐院校的时候只取TopN中的前几个院校数据作为推荐，为了方便进行院校做CRUD处理时，Redis中推荐数据的更新
离线推荐结果和在线推荐结果进行汇总做最终推荐时，要过滤掉用户已浏览的院校[根据业务具体需求看是否过滤掉近期已经推荐过的院校]
最终推荐院校集数量可能不满足需要推荐的院校数量，可以设置默认推荐集（如热点院校）进行补全
4.2.1 离线结果"落地"分析
利用相似度算法，分别计算每一所院校与其他院校的相似度（并根据相似度倒序排序）
==> 如果没有新增院校或已有院校属性（"特征因子"）不改变，只需计算一次。计算量：200+所院校，计算4W+次。
将每个院校相似度计算结果，取TopN进行存储（Redis/HBase等）
==> 如存储到Redis中：以前缀"recom:offlineCB:"和"基准院校id"拼接成的字符串为key，以与基准院校”相似院校id:相似度”为value（"recom:offlineCB:"+baseSchoolId,"sid1:sims1,sid2:sims2,…"）
由于ALS需要训练模型，如果每来一个用户，产生了浏览/收藏等行为，ALS模型就要实时重新训练一次，会有一定的延迟；当用户比较多时产生的数据量也比较大，延迟性会进一步加大。因此，采取根据前一天及之前的历史数据，每天训练一次ALS模型，取TopN结果进行存储（Redis/HBase等）
==> 如存储到Redis中：以前缀"recom:offlineALS:"和"用户id"拼接成的字符串为key，以"推荐给该用户的院校id"为value（"recom:offlineALS:"+uId,"sid1,sid2,sid3,…"）
注意：设置Redis的key前缀是为了区别不同推荐模型
4.2.2 实时结果"落地"分析
用户浏览官网，Spark-Streaming从Kafka消费数据进行处理，先将数据处理成标准化数据：“用户id，操作类型，院校id”，再处理成“用户id，院校id,score”格式。
根据院校id从Redis中获取该院校基于CB的相似度推荐列表，自定义一个类CusItem.scala（属性：院校id，weight），以“score*相似度”作为最终权重weight并根据weight进行倒序排序，取TopN进行推荐（存储到Redis：以"recom:realCB:+userId"为key，以推荐院校id列表[拼接成字符串]为value）
老用户直接通过用户id获取Redis中ALS离线推荐结果（存储到Redis中：以"recom:realALS:+userId"为key，以推荐院校id列表[拼接成字符串]为value）
4.3 基于院校"流行度"对实时和离线推荐结果的补充
主要是对热门院校（比如点击率高的、申请率高的）、需要推广的院校等进行推荐。可以根据PV、UV、日均PV或分享率等数据分析出热门院校。能够解决新用户冷启动问题，同时根据不同的用户特点推荐不同的院校
4.4 院校信息发生改变具体分析
当有“新增/删除（包括院校下线）院校”或“已有院校属性发生改变”时，后台录入对院校信息进行处理的同时，异步发送一条消息（如通过ActiveMQ，将院校id和对应的操作类型[add、delete、update]）给“调整”计算院校相似度的程序，进行相应的处理。【注意：如果更新院校的属性不是“特征因子”，就不要发送信息了】
4.4.1 新增院校
step1：以新增院校为基准，计算其他院校与该院校的相似度数据，并按照相似度数据进行倒序排序，取TopN存储到Redis【去掉基准院校】
step2：以其他院校为基准，分别计算新增院校与其他院校的相似度，用该相似度与其他院校相似度数据中TopN院校最后一个院校的相似度数据比较，如果前者比后者小，不作任何操作；如果前者比后者大，根据TopN院校和新增院校的相似度数据进行倒序排序，去除相似度最小的，然后更新Redis中相应的数据
4.4.2 删除院校（包括院校下线）
step1：删除Redis中对应删除院校的CB相似度数据
step2：两种情况：1）“删除院校”不在其他院校的TopN列表中，不更新Redis中其他院校的相似度数据2）“删除院校”在其他院校的TopN列表中，移除该院校[TopN列表移除完的情况：实际业务场景可能性比较小，可不考虑]
4.4.3 已有院校属性发生改变
改变属性不是"特征因子"不作任何处理[让业务方那边先判断一下改变的属性是不是“特征因子”，如果不是就不要发消息了]特殊情况：改变属性是“上线状态”，如果由下线改为上线，则调用‘新增院校’的处理方法
改变属性是"特征因子"step1：更新自己redis中相似度数据step2：更新其他院校（1）计算该院校与其他院校的相似度数据，将该值与其他院校相似度数据中TopN院校最后一个院校的相似度数据进行比较：如果前者比后者大则TopN排序更新redis数据；如果前者比后者小，则重新计算其他院校所有的相似度数据倒序取TopN（2）计算该院校与其他院校的相似度数据，将该值与其他院校相似度数据中TopN院校最后一个院校的相似度数据进行比较：如果前者比后者大，进行TopN相似度数据和改变院校相似度数据倒序排序，并移除最后一个；如果前者比后者小,不作处理。
对于上述的算法模型实现逻辑以及具体的数据处理、推荐处理等除了算法建模本身的考量，还要结合实际业务做相应调整，包括推荐算法的种类、训练模型、数据的标准化，业务的场景等。本文更多是抛砖引玉，希望在大家做推荐系统的过程中给出一个参考思路。
关联文章：
转载地址：http://ksvkz.baihongyu.com/