YouTube的视频推荐算法

这篇是来自google 2007关于YouTube上视频推荐的文章。它的一个重大意义在于，让我们了解实际工程中，尤其是像YouTube这样的大型视频分享网站，推荐系统的架构是怎么样的，以及所遇到的问题。

文章指出YouTube上视频推荐面临着很多的挑战：

①由于用户可以自己上传视频，因此视频的数量大概和用户的数在一个数量及上（现实中，一般情况下物品数是要远远小于用户数的）

②用户上传的视频一般不会有高质量的元数据（即视频的描述）

③大部分视频都很短，因此就算用户看完了一个视频，我们也不能很有把握地说他喜欢这个视频——这与看网络电视不一样。④大部分视频的生命周期比较短，可能就只有几天。

文中，视频之间的关系被视为一张graph。节点V为视频，相似度大于某一threshold的节点之间有一条边E。边的权值即节点间的相似度。相似度通过CF的思路计算，这里被作者称为“association rule mining”或者“co-visitation”（其实“association rule mining”的叫法不准确）。 

有了这张graph后，就可以为每个视频X生成该视频所对应的candidate——即喜欢视频X的用户也可能会喜欢的其他视频。具体做法：将与物品直接或间接相连的物品作为candidate，考虑间接相连的物品是为了增加candidate的多样性。因为作者指出，只考虑直接连接得到的candidate过于相似，比如都是关于动物主题的。

为用户u推荐时，将用户看过的、喜欢过的视频作为一个种子集合（seed set）。所有seed的candidate合成final candidate，然后对其进行排序。排序时除了考虑video间的相似度，文章还考虑了视频本身的信息（观看次数，视频的评分，用户的评论，上传时间等等）。一个物品的最终评分由这些信息线性组合得到。最后，为了保证推荐的多样性，文章进一步对推荐的来源进行了限定：比如不能都是来自一个seed的推荐，不能都是来自一个video 上传者的推荐。或者可以使用pLSI等其他聚类手段物品聚类，并保证来自不同cluster的物品比例。

YouTube视频推荐系统在架构上分为3层：

①数据的采集。用户的评分记录和视频本身信息从YouTube的日志中抽取，然后以用户为单位存入Bigtable中。论文指出，当时他们有几百万的用户和几十亿的用户交互信息——TB级别的数据量。

②生成推荐。作者只说通过一系列的MapReduce walking through 用户/视频图，并未涉及细节。有兴趣的可以看这篇论文“Video Suggestion and Discovery for YouTube Taking Random Walks Through the View Graph”。

③推荐serving。生成的推荐也存于Bigtable中——GB级别的数据量，以供YouTube的web服务器取用。

最后，整个推荐的计算（上面的流程）一天进行数次。

----------------------------------------

回顾一下：由于Bigtable基于GFS，因此Bigtable中的数据按一个个tablet存储。每一行，每一列都是如此。由于，Bigtable对索引的支持不好，因此Bigtable适合做数据分析——涉及数据库中大部分数据的数据分析。
------------------------------------------

性能的测量：推荐是在Youtube首页进行的。google进行的A/B测试，即一部分流量作为基本对照组，另一部分流量则试验一些新的特性。然后根据一些指标来测量特性的效果。这里使用的指标是点击率CTR，long CTR，会话长度，距第一次long CRT的时间等等。文章指出，YouTube首页 60%的流量都来自推荐。

最后，值得指出的是实际的推荐算法要比这个更复杂。因为，这里并没有把视频的meta date和用户的看视频的序列考虑进去。

[1] The YouTube Video Recommendation System