短视频服务推荐Feed流
短视频服务推荐feed流背景
我们主app是面向海外的一个短视频APP，大致可以理解为抖音(TikTok)和快手的海外版本，并且与这两个app的海外版本为竞品关系。
主feed的任务是将媒资池中视频、新视频等，根据用户的使用习惯、喜好，视频的实时热度、得分，推荐给用户。
于此同时，app中还有一个主Tab是关注流，其中关注流也是有推荐逻辑的，但是两者不太一样。之后我会另起一篇文章介绍。
推荐feed主要架构
推荐feed流主要分为两大块：离线数据计算，实时数据计算。
离线计算：
- 根据打点日志，计算用户行为，得出用户的离线画像
- 根据打点日志，计算视频的离线特征，包括用户的点击展现数据(CTR)，视频的互动数据(ATR)
- 从媒资库获取视频基础信息，获取到近期或全量视频，生成各个视频索引文件(索引拉链)
实时计算：
- 根据MQ实时消息，计算视频的实时特征，包括实时ctr，atr，各项互动数据等
- 根据MQ实时消息，计算用户的实时特征，获取用户的偏好信息，对某一品类/作者的喜好等反馈
- 根据实时用户信息，从索引文件中获取视频列表，实时计算视频分数，推荐给用户
离线部分主要交给了gump任务平台去完成这类的计算任务，gump下主要为hadoop。
实时部分分为了两个服务，一个是engine，负责获取各类特征，并完成计算将最终结果返还给调用方；一个是feature服务，负责计算视频特征，用户特征，提供给engine使用。
注：离线平台完成计算之后，会生成一张hive表，两个实时服务engine和feature是将生成完成的hive表拷贝到服务机器上，进行解析然后存入对应的缓存、内存。
engine服务主要架构
engine的主要任务是获取到不同的视频索引(包含视频的离线特征)，视频的实时特征，用户特征等，安装既定的公式/算法得出视频的排序列表，再根据服务的机制，筛选出定长的视频列表返回给服务调用方。
主要这几个部分：
上下文信息填充/ab-test准备，召回，过滤，特征合并，排序，选择/机制，填充
1. 上下文信息填充/ab-test准备
推荐上游调用推荐API，此时会传入用户请求的基本信息，如版本号，设备id，网络情况，请求方式等等，推荐服务将各种信息填入上下文，并且根据已配置好的ab测试配置，讲请求分类填入请求上下文。
2. 召回
召回是根据获取各个视频拉链，为后续的过滤排序阶段提供基础的视频池。
召回的视频拉链主要分为三类：概括为获取用户画像，根据用户画像召回视频拉链；根据视频离线特征召回基础底池视频拉链；召回特殊拉链。
目前线上运行的engine服务存在的主要索引有：High-quality索引，Uploader索引(根据视频创作者建立的索引)，Tag索引(根据视频品类建立的索引)，I2I索引(根据视频的内容偏好相似度建立的索引，协同过滤计算得出)，Explore索引，Start索引(主要为新用户建立的索引拉链)，New索引(保障新进入媒资库的视频，能够具有一定的展现机会，来判断这个视频是否为优质视频)
3. 过滤
很多视频尽管已经进入了视频的离线索引，但是也会根据时间不同、规则不同、用户不同，不能进入推荐列表，所以需要进行过滤，在过滤之前还加上了截断来保障视频过滤更加高效，但可能导致尾部视频一直无法出现到推荐feed中。
目前线上运行的主要过滤规则有：黑名单视频过滤(相较离线更加迅速，过滤更加直接)、黑名单Tag过滤，特殊分支过滤(不同策略导致某些已上线分支不能进推荐列表)、音乐类别过滤、图集过滤、用户已播放视频过滤、用户已展现视频过滤、上传者过滤(用户在feed流不能浏览到自己上传的视频)、新视频保量过滤(某些已得到了充分展现的视频将会被过滤掉并且从new分支移除)、相似视频过滤
4. 实时特征获取
根据已经过滤完成的索引列表中视频，从feature服务(接口或者存储耦合)获取视频实时特征，并填充进索引列表，上下文特征。因为在召回阶段已经获取了一部分用户特征了，所以此处只用获取视频侧的特征。
5. 视频排序
根据获取得到的视频特征，按照既定的公式排序，主要参考的特征有视频实时ctr，视频播放完成率，视频实时互动分，用户特征分数。
视频的排序目前是按各个分支独立排序。
6. 视频选择
由于是视频的各个分支独立排序，所以出视频的视频，需要按照给定的槽位分配到各个分支，然后按照各个分支的排序完成后的视频列表从高到低依次选择槽位数的视频。
其中需要注意的是：分支之间需要判重，品类数量控制，特殊视频的数量控制(特殊视频可能出现在各个分支)。
同时也需要进行槽位控制，不同的用户的分支槽位可能是存在差别大，比如新用户、冷起用户 画像索引会非常少甚至没有，那么相应的冷起索引就需要更多的槽位。
7. 填充
在视频选择完成之后，就基本上获取得到了推荐所需的视频列表。但是仍然存在可能是某个分支的视频数量少于了给定的槽位的视频数量。此时就需要将底池视频补齐。并且在完成推荐之后，还有诸多的视频信息、推荐信息、推荐策略、推荐获取到的实时特征等填充进推荐列表，并且完成发送MQ消息，打印Debug信息等操作。
feature服务主要架构
feature服务主要分为两个部分：feature-online, feature-offline
离线部分主要完成将离线任务平台gump得到的计算结果，根据一定的规则导入到feature特征库(redis)。
实时部分主要获取实时MQ消息，计算用户特征/用户画像，视频特征等，提供给engine相应接口。