讲讲对推荐系统特征工程的理解

从事推荐广告业务也有满一年整了，讲讲对特征工程的理解。

一、数据的来源会分为在线（实时）和离线之分

为什么会有两条线。有些场景的实时数据流比较难处理。比如说电商系统中，一笔订单在发生几天之后会产生推开，这种场景的实时数据是比较难处理，需要通过离线数据进行修正。还有比如说，点击对卖家进行收费，这会产生同行之间的恶性竞争，比如说卖家会故意点击对手卖家的商品产生不必要的广告费用。系统需要对这种行为进行监控，这种监控逻辑实时和离线都会存在，但有一些逻辑需要离线情况来计算。离线数据进行计算来达到最终数据一致性的标准。也有说法是根据更新的时效性，分位实时特征和离线特征两类，实时特征是秒级更新，离线特征多是天级任务或小时级任务更新。

二、特征的本质

特征数据作为整个推荐、广告系统的基础数据。原始特征数据包含请求上下文、用户特征和广告特征等几个部分。特征在预估环节上作为基础输入数据使用。特征数据来自于大数据团队维护的redis等表格。

同时特征也需要定期更新维护，特征的更新数据源来自于用户产生（客户端埋点上报或者复制请求的样本流落下的原始特征经过加工完成）。比如说某个用户特征最近一周安装过的app，那么这个数据就来自于观察用户一周的埋点上报或者样本流经过统计加工得来的数据。

三、预估流和样本流的分离

样本流的数据主要是特征工程的一部分，因为他是产生特征原始的主要来源，同时它与在线预估流量做了分离，不影响线上服务。这个样本snapshot数据落地的功能，主要是把预估请求的时刻用到的所有特征信息作为快照，落地到存储中。一般来说这种服务会通过kafka中介，将snapshot数据写入到kafka中，大数据根据埋点信息来进行join拼接特征。

四、特征工程的缓存机制

缓存机制是针对不同的特征类型，有不同的缓存策略和时长，保证请求不会大量的穿透到redis等存储介质中。对于广告item特征，除启动时会加载定时产出的全量广告id列表初始化缓存，还会消费kafka 感知广告特征的变化，来触发缓存的失效和重建。

五、样本流和在线请求之间的时间延迟

为了降低样本流和在线请求之间的时间延迟，降低特征穿越和一致性的问题，需要做一些架构设计

做了离在线集群合并，链路的时间差从秒级被缩短到了毫秒级。

离线和在线特征，都是存储在redis数据库中，占用的存储资源较大。考虑SSD存储。