B站推荐模型数据流的一致性架构

01 背景

推荐系统的模型，通过学习用户历史行为来达到个性化精准推荐的目的，因此模型训练依赖的样本数据，需要包括用户特征、服务端推荐的视频特征，以及用户在推荐视频上是否有一系列的消费行为。

推荐模型数据流，即为推荐模型提供带特征和优化目标的训练样本，包括两个模块，一是Label Join模块，负责用户行为的采集。二是feature extract模块，从原始日志中抽取特征，并基于用户行为计算模型优化的目标label。

在B站早期的推荐模型数据流架构中，如下图所示，采样两阶段特征补齐设计。Label Join模块除了完成用户行为的采集，还需要查询实时特征，补齐训练样本依赖的部分原始特征数据，一般是秒级更新的实时特征，存储在Redis中。而Feature Extract模块在计算样本之前，补齐另外一部分原始特征数据，一般是批量更新的特征数据，存储在KFC中（B站自研的KV系统）

02 问题分析

上述的推荐模型数据流架构，存在“不一致”问题，包括“数据不一致”和“计算不一致”

2.1 数据不一致

在这种自反馈系统中，推理输入的特征版本和训练输入的特征版本，如果有差异的话，会影响模型的准确性。数据不一致有3个原因：

• 访问时间差异。推理服务和Label Join/Feature Extract模块访问同一个特征的时间是不一样的。特别是秒级更新的实时特征，这种数据差异会被放的更大

• 新稿件问题。在线推理服务有稿件服务可获取新稿件的特征。而离线没有这个服务，所以离线缺少新稿件的特征，导致新稿件的推荐不准确

• 特征穿越问题。LabelJoin有N分钟的固定时间窗，所以Feature Extract在查询批量特征的时候，可能批量特征版本已经更新，查到的是最新版本特征，从而导致特征穿越。一般需要有经验的算法工程师，在离线批量特征更新上加上时间延迟，规避穿越问题。但这种规避可能会进一步加剧数据不一致

2.2 计算不一致

这里“计算”指的是从原始数据，生成特征的过程。特征可以用于在线推理和离线训练。特征计算有