文章目录
- 前言
- 特征样本构造工具概述
- 特征和样本的存放关系
- 特征和样本的获取
- 特征复用的实现
- 特征&样本获取
- 特征&样本生产的整体思路
下面开始介绍特征样本构造工具的实现，由于这一块内容比较多，应该会分多篇博客进行介绍。
特征样本构造工具概述
一般的，如果业务场景的流量本身比较小，直接简单使用sql拉取特征及进行简单处理，之后直接丢给模型进行训练即可。但规模大一些的app，本身的数据量级很大，使用sql显然不能满足需求。本文也是针对后者数据量级大的问题，思考解决方案。
通常情况下，数据都是存储在hive表中，需要是直接拉取数据到HDFS上。如果可以开发出一套数据处理逻辑，实现对特征的获取、拼接、编码映射等操作，得到模型需要的数据集，这样就可以直接拿来训练模型，同时，还可以增加对特征池内每个特征的维护，后续调研迭代的成本更低。
要实现上述的功能，需要考虑以下几个问题：
1.特征和样本间的存放关系如何设定
2.特征和样本的获取
3.特征的复用如何实现
后面针对这几个问题给出对应的解决方案
特征和样本的存放关系
通常情况下，特征的迭代频次要比样本的迭代频次多很多，即特征和样本的版本迭代不同步，因此可以人为规定某些规则将特征和样本分离，这样优化特征时不会影响到特征，更新样本时也不会改变特征，只需要保证特征和样本的一一对应关系即可。
其实在之前特征的介绍中，已经把特征按照一定的规则将特征进行了分类：user侧特征、item侧特征、context侧特征。这种分类和很多网络结构中field的概念保持一致，user和context侧特征，通常都可以根据user_id获得唯一准确的特征值；item侧特征，都可以根据item_id获得唯一准确的特征值。
如此，特征和样本就可以根据user_id和item_id进行关联，当然，还需要time，因为通常情况下，训练样本是合并了多天的行为数据产出的，需要time字段来进行区分。相当于，每个特征都可以存储成k-v格式，key是关联id，value为特征详情；样本数据只需要将样本和关联id、time字段做好一一对应关系。
特征和样本的获取
基于SparkSQL或hive sql获取原始日志数据，再编写spark任务实现特征和样本的生产。
对于特征，相似计算逻辑的特征的生产逻辑写在一个任务中，不同特征之间相互独立，根据配置文件实现配置化管理，spark任务解析配置文件完成特征生产。
对于样本，维护一套完整的样本池，提供不同的样本处理方式及采样方法，同样根据配置文件实现配置化管理。
特征复用的实现
上面有提到，如果特征能够实现复用，统一维护一套特征池，每个rank项目只完成对特征和样本的读取操作，而不需要各自产出特征，就可以极大降低时间成本，节省资源。
一般的，特征都是按照一定规则进行编码，最终产出编码后的sparse feature，实现特征复用，就需要在产出sparse feature前，将每个特征的编码数据保存下来，同时产出特征值与编码索引的映射关系。
特征&样本获取
原始特征在hive表中，获取特征分以下几种情况：
基础特征：直接通过hive sql或SparkSQL获取数据
复合特征：编写spark任务产出
样本：编写spark任务产出，提供多种采样方式和样本reweight方法
特征&样本生产的整体思路
1.特征和样本可以设计成低耦合，单独生产，然后通过关联字段连接在一起，这样相当于只需要生产一份特征数据，和一份样本数据（样本逻辑不变的情况下），根据需要进行拼接就可以
2.对特征进行优化时，只需要开发新增的特征；对样本优化时，只需要重新定义样本。保证特征或样本的复用性
3.线上特征和样本进行统一维护，使用方便
4.特征逻辑、样本逻辑封装，处理逻辑相同时直接使用，提高代码复用性
