业务特性
信息流推荐，实时性要求高
例如图中的用户实时兴趣特征(受到用户兴趣迁移用户反馈等影响)，文章的实时点击率等
历史版本
常规的做法离线训练时将日志表、用户表、文章表等离线表 join 后产生样本，在线服务有专门的服务加速从数据表中获取内容的过程。
注：这种方式和我们目前在用的方式差不多，离线训练使用 hive 表关联，并将特征分组后存储到 redis 中，在线服务时直接从 redis 中获取特征，这种方式基本不涉及到用户或物料维度的实时特征信息
网易新闻历史版本的基本思路是： 线上服务实时生产特征，离线样本生成使用线上实时落盘的特征
流程：
- 在线服务阶段在精排之前，获取或计算用户侧、文章侧的各个维度原始属性并人工特征工程以得到结构化、规范化的特征数据，以此特征进行预测
- 完成精排后，将此刻预估时的特征数据落盘
- 离线训练阶段，使用落盘的特征数据，以用户 ID 和文章 ID 为 key，与曝光日志、点击日志、其他行为日志关联标签，形成带有标签的特征样本
利弊：
- 可以保证线上和训练的特征一致性，避免特征穿越问题。
- 灵活性差，且对存储有较高的要求
设计方案
优化灵活性
- 抽象出特征算子 比如bucket、cross、cosine，基于json文件做特征计算管理，线上和线下基于同样的特征算子包做计算
- 将特征区分为原始特征和特征，比如用户年龄 27 岁为物料，而年龄 3 号桶则为特征，日志落盘的是物料数据，在线和离线使用的是同一套特征算子所以可以保证一致性。
注： 我理解这边主要是落盘元数据，可以通过物料计算的特征数据都不需要落盘，这样一方面可以保证性能，一方面可以减少存储的需求。
基本流程如下图所示
算法同学主要的工作集中在特征工程和模型训练上，算法人员可以根据提供的基础工具和基础特征算子书写特征配置优化业务复用性
每个子业务都需要构架上述的服务, 为了解决业务复用问题，引入物料服务和物料缓存网关的概念
image.png
离线环节：各个业务依然是独自落原始物料，经过特征算子计算生成样本，没有改变；
在线环节：pCTR 服务不再直接和物料服务通信，而是借助物料缓存网关。物料缓存网关的核心功能则为缓存和路由，其根据特征名称路由到不同的物料服务来计算
注：我理解这边就是由业务场景构建属于业务自己的物料库，即对不同业务的物料信息做隔离，由物料缓存网关做路由
- 优化性能
为了灵活性，我们引入了特征算子包，在离线和线上做实时的计算。然而实时计算就意味着 RT 增加，随着进入 pCTR 排序服务的候选数目的扩大，RT 的压力越来越大（需要在线做特征计算，CPU 密集型操作,召回数量增加直接导致 RT 升高)
优化方向 这边可以学习下问题分析的思路- 算子库实现的性能优化
- pCTR 服务端的性能优化
- 特征平台侧的优化
降低 RT 的常见思路为用空间换时间，给定特征配置文件，同个用户的不同请求中，类似年龄性别等人口属性和用户的长期兴趣是固定的，没有必要每次都计算。将某些类型的特征提前计算好并存储到缓存中，线上请求直接拉取对应的特征即可
image.png
线上服务的获取：线上服务的获取只是会区分物料和特征。针对精排服务而言，其直接获取到特征粒度，物料缓存服务网关需要根据其对应的特征配置拉取具体的特征。而在落物料日志的过程中，则获取物料粒度，这样在性能优化的同时依旧保持了灵活性
样本生成逻辑
将样本生成的过程拆分为两个环节：join 环节、sample 环节。
join 环节的核心工作为融合信息，融合如物料信息、推荐点击信息、用户互动信息等等，同时我们将业务中常见的标签推理的方式封装为函数，外面直接设置相关的参数即可得到实际的标签，比如加上阅读时长、阅读完成度类似的限制。
sample 环节的工作为特征工程，除了基于配置的特征工程之外，我们将样本权重计算、样本过滤逻辑、样本采样逻辑也做了函数式的封装，并对外暴露参数使其可配置
样本生成逻辑是基于 flink 任务来完成的，flink 任务会定期读取数据表，获取需要计算的样本详情，生成新的样本
特征算子
一套基于特征配置的特征算子库，以解决现有特征工程方法中存在的特征工程策略可读性差、通用性差、特征调整迭代周期长、计算冗余度高等问题，能够在灵活性、高效性、复用性上有很好的表现能力。
对训练样本需要的特征进行汇总分析，并对依赖的原始数据进行梳理，整理出由原始数据到特征样本之间所有的变换、组合关系，我们称之为特征算子
特征配置设计
json格式，支持嵌套。例如{“feat”: “a = op(b)”, “param_A”: “val_A”, “paramB”: “val_B”}，表示使用op对原始数据b变换处理得到特征a，变换过程中需要两个参数
