浅谈推荐系统中的样本拼接

样本拼接要做什么？

　　样本拼接原理上其实非常简单，就是将推荐在线服务给的特征快照先暂存起来，等待道具曝光后根据收集到用户对此道具的一系列交互行为（点赞、收藏、转发等）给原本只有特征的推荐记录拼接上标签。

Key-Value is All You Need

　　有开发经验的朋友大概一眼就看出了：所谓的拼接，本质上就是KV的增查改。这里连主动删除都不是必须的，将超出时间窗口的数据统一淘汰掉就可以。这个KV操作的难点在于数据量很大，准确来说是特征的数据量很大。不过和标签不同，特征在整个拼接过程中只需要增查，并不涉及修改，于是可以通过将其从KV核心DB分离来改善性能。另外，推荐系统中道具的总数量远远少于用户，而且除了库存之类的易变特征外，大部分道具特征更新频率很低，每天打一个包就可以。由于每条推荐记录都包含多个道具，插入稳定道具特征很可能会带来大量的冗余数据，从后台导入道具特征包是更合理的选择。道具特征包在拼接窗口内会存在多个版本，是否真的能够减少总存储空间还要看具体业务场景。

　　要获得理想的性能，KV单元需要使用本地SSD作为存储介质，那意味着每个单元的承载能力是比较有限的。不过这里的推荐系统本来就是同时服务很多用户的，可以根据根据用户ID分流任务到多个KV单元处理。在拼接同时原始数据也要备份到HDFS，在KV单元出现异常时方便利用备份数据进行重建。

真的这么简单吗？

　　理想情况下，收集到的用户的行为应该是存在清晰脉络的，而实际上这过于奢侈。且看如下案例：

　　用户浏览了A道具，很喜欢，因为比较贵就先点了收藏；接下来他又浏览了B道具，觉得不错，不过和A道具比还是差那么一点意思；再后面他看C道具的图片毫无吸引力，直接跳过；最后他浏览了D道具，感觉还是B道具好，倒回去下单了B道具；又过了一天，他用过B道具后有点后悔，从搜藏里捞出A道具并下了单。

　　假定采集的标签分别是浏览和下单，那么从上帝视角可以知道这次推荐对应的真实样本应该是A11、B11、C00、D10。可是数据科学家并没有上帝视角，此时只能名侦探附体，使用一定的策略去尽可能还原真相了。策略和具体业务场景紧密相关，超出了本文“浅谈”的定位，就不再继续展开了。