特征训练、预测一致性管理工具：开源项目Feast

在机器学习的流程大体可以分成模型训练和模型服务两个阶段。无论是训练和服务阶段，其实都需要进行特征工程相关的工作，这块的技术挑战就是如何保证训练和预测过程中使用的特征是一致的。这个问题困扰了很多机器学习从业者，比较典型的场景就是推荐场景。在推荐业务中往往要用离线数据做特征工程然后输入到算法中训练生成推荐模型，在实际业务侧也需要按照同样的特征样本拼接方式生成预测样本，输入给模型做实时预测并拿到推荐结果。

今天要介绍的Feast其实是一个特征管理工具，他通过一套封装好的sdk保证了Model Serving和Model Training两个场景下的特征一致性问题。

Feast架构介绍

看下Feast的架构图，他可以接受Spark、Hive等数仓体系生成的Batch类数据，也可以将Log Service产出的数据通过Kafka构建成Streaming Feature与Batch数据结合构建特征。在Feast篮框内看到，针对Offline和Online的Feature提供了不同的方案，Offline Feature可以通过Feast SDK形成Training Features进行训练，在Online Feature可以通过部署Feast Serving构建出来用于Inference。而且训练和预测的特征是严格一致性保证的。接下来通过一个例子介绍下Feast是如何使用的。

Feast使用方式

1.特征表注册

Feast中将特征构建的主key定义为Entity，Entity往往是多个表关联的索引。可以用以下方法注册：

driver_id = Entity(name="driver_id", description="Driver identifier", value_type=ValueType.INT64)

有了主key后，就可以注册多张表的关联关系。Feature Table可能由离线和在线的多种源构成，需要在里面描述清楚每种特征是如何构建出来的。

最终特征的拼接逻辑会生成yaml文件。

2.离在线特征区分

离在线的特征的构建是不同的，离线通常是聚合统计类特征，比如算比例之类的，在Feast里这种特征处理方式叫做driver statistics，如下图：

在线特征更多的是单纯的计算出现次数，如某件行为发生的次数，可以通过flink实时统计出来，叫做driver trips。

driver statistics和driver trips通常在注册数据表来源的时候要体现。

定义好这些内容之后就可以具体的生产特征了。离线特征可以存储在S3、本地等环境里。实时特征可以处理好并存储到Redis里供实时调用。

3.时间窗定义

既然特征工程分离线处理的特征和在线处理的特征，那么离在线任务肯定会涉及到时间窗口一致性问题。比如一个表3个特征是离线的，2个特征是实时的，如果离线特征的生产时间窗总是比实时特征慢，会造成特征拼接不准确的问题。为了解决这个问题Feast提供了一个time-stamp功能。

系统会为每个Entity记录一个time-stamp，客户在使用的过程中可以根据time-stamp确定某个Feature Table是否可用。

Feast总结

经过整体的特征生成、特征表注册、离线和在线配置就可以构建以上的特征生成系统，可以通过time-stamp功能去选择要调用的Feature Table。