分享协同过滤思想简介什么是协同过滤？( 五 ) _协同过滤

文章插图
图8：标的物的topK相似列表利用Map数据结构来存储
有了标的物之间的相似度Map，为用户计算推荐的过程可以基于用户行为RDD，在每个Partition中，针对每个用户u计算u与每个标的物之间的偏好度(利用第二节2基于标的物的协同过滤中的公式)，再取topN就得到该用户的推荐结果了。由于用户行为采用了RDD来表示，所以整个计算过程可以分布式进行，每个Partition分布在一台服务器上进行计算。具体的计算逻辑可以用下面的代码片段来实现。

文章插图
图9：为每个用户计算topN推荐
讲到这里，基于Spark平台离线实现协同过滤算法的工程方案就讲完了。该实现方案强依赖于Spark的数据结构及分布式计算函数，可能在不同的计算平台上(比如Flink、Tensorflow等)具体的实现方式会不一样，但是基本思路和原理是一样的，有兴趣并且平时使用这些平台的读者可以在这些计算平台上独自实现一下，算是对自己的一个挑战。
四、近实时协同过滤算法的工程实现上面第三节中的协同过滤工程实现方案适合做离线批量计算，比较适合标的物增长较缓慢的场景及产品(比如电商、视频、音乐等)，对于新闻、短视频这类增量非常大并且时效性强的产品(如今日头条、快手等)是不太合适的。那么我们是否可以设计出一套适合这类标的物快速增长的产品及场景下的协同过滤算法呢？实际上是可以的，下面我们来简单说一下怎么近实时实现简单的协同过滤算法。
我们的近实时协同过滤算法基于Kafka、HBase和Spark Streaming等分布式技术来实现，核心思想跟第三节中的类似，只不过我们这里是实时更新的，具体的算法流程及涉及到的数据结构见下面图10 。下面我们对实现原理做简单介绍，整个推荐过程一共分为4步。

文章插图
图10：近实时基于标的物的协同过滤算法流程及相关数据结构

获取用户在一个时间窗口内的行为

首先Spark Streaming程序从kafka读取一个时间窗口(Window)(一般一个时间窗口几秒钟，时间越短实时性越好，但是对计算能力要求也越高)内的用户行为数据，我们对同一个用户U的行为做聚合，得到上面图中间部分的用户行为列表(用户在该时间窗口中有k次行为记录) 。
顺便说一下，因为是实时计算，所以用户行为数据会实时传输到Kafka中，供后续的Spark Streaming程序读取。

基于用户在时间窗口W内的行为及用户行为记录表更新标的物关联表CR

基于(1)中获取的用户行为记录，在这一步，我们需要更新标的物关联表CR，这里涉及到两类更新。首先，用户U在时间窗口W内的所有k次行为

文章插图
，我们对标的物两两组合(自身和自身做笛卡尔积)并将得分相乘更新到CR中，比如

文章插图
组合，它们的得分

文章插图
相乘

文章插图
更新到CR表中rowkey为

文章插图
的行中。

文章插图
的得分score更新为score+

文章插图
) 。其次，对于用户U在时间窗口W中的行为还要与用户行为表UAction中的行为两两组合(做笛卡尔积)采用前面介绍的一样的策略更新到CR表中，这里为了防止组合过多，我们可以只选择时间在一定范围内(比如2天内)的标的物对组合，从而减少计算量。
这里说一下，如果用户操作的某个标的物已经在行为表UAction中(这种情况一般是用户对同一个标的物做了多次操作，昨天看了这短视频，今天刷到了又看了一遍)，我们需要将这两次相同的行为合并起来，具体上我们可以将这两次行为中得分高的赋值给行为表中该标的物的得分，同时将操作时间更新为最新操作该标的物的时间。同时将时间窗口W中该操作行为剔除掉，不参上面提到的时间窗口W中的操作行为跟UAction表中同样的操作行为的笛卡尔积计算。