推荐系统的体系结构
整个推荐系统的结构如图：
Snip20161201_6.png
看起来还是挺简单的。分布式流计算主要负责了五块：
- 点击曝光等上报数据处理
- 新视频标签化
- 短期兴趣模型计算
- 用户推荐
- 候选集计算，如最新，最热(任意时间段)
存储采用的有：
- Codis （用户推荐列表）
- HBase （用户画像和视频画像）
- Parquet(HDFS) (归档数据)
- ElasticSearch (HBase的副本)
下面这张图则是对流式计算那块的一个细化：
Snip20161201_7.png
用户上报采用的技术方案：
- Nginx
- Flume （收集Nginx日志）
- Kafka （接收Flume的上报）
对于第三方内容(全网)，我们自己开发了一个采集系统。
个性化推荐示
Snip20161201_10.png
所有候选集都是实时更新的。
这里我们说下参数配置服务器的概念。
假设我有三个算法A,B,C ,他们分别由三个流式程序完成，各个程序是互相独立的，最后都会算出各自的结果集。因为不同候选集和算法算出的内容数据量和频度都会有差异，假设A算出的结果集过大，B算出的结果集很小，但是质量很好，这个时候他们在发送到用户推荐队列的时候，需要将自己的情况提交给参数配置服务器，并且由参数服务器决定最后能够发送到队列的量。参数服务器也可以控制对应频度。比如A算法距离上次推荐结果才10s就有新的要推荐了，参数服务器可以拒绝他的内容写入到用户推荐队列。
上面是一种多算法流程的控制。其实还有一种，就是我希望A,B的结果让一个新的算法K来决定混合的规则，因为所有算法都是StreamingPro中的一个可配置模块，这个时候A,B,K 会被放到一个Spark Streaming应用中。K可以周期性调用A,B进行计算，并且混合结果，最后通过参数服配置服务器的授权写入到用户推荐队列。
一些感悟
我14，15年做的一次推荐系统，那个时候还没有流式计算的理念，而且也不能复用一些已有的技术体系，导致系统过于复杂，产品化也会比较困难。而且推荐的效果也只能隔日看到，导致效果改良的周期非常长。当时整个开发周期超过了一个多月。然而现在基于StreamingPro,两三人没人么天只能投入两三小时，仅仅用了两个礼拜就开发出来了。后续就是对用户画像和视频画像的进一步深入探索，核心是构建出标签体系，然后将这些标签打到用户和视频身上。我们组合了LDA,贝叶斯等多种算法，获得不少有益的经验。
原文链接：http://www.jianshu.com/p/83af9502acb6
著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。