一. 目标

对于Feature Store的能力与边界，每家的定义略微不同，《Feature Stores - A Hierarchy of Needs》）这篇文章做了很好的总结，大体分为如下几个层次：

特征管理：特征抽取、处理、存储、元数据管理，以便于特征溯源、分享、复用
特征消费服务：为线上部署的模型，提供高吞吐、低延迟的特征获取能力
离线/在线特征一致性保证：避免Training-Serving Skew问题导致模型效果劣化
便利：易用、简单的交互和API
自治：特征回填、数据质量监控、联动模型效果评估等

二.能力

2.1 特征（Feature）创建

从各类原始数据，例如日志、记录、表，经过关联、统计、转化、聚集等操作得到的一系列值。

例如，对于电商领域，从用户行为日志，可以计算得到用户最近30天购买商品列表、最近1小时浏览商品列表、平均订单金额等特征。

特征是特征平台上最基础的概念。

2.2 特征注册中心（Feature Registry）

通常以UI控制台暴露给用户使用，平台上所有特征均在此展示，方便平台用户进行探索、共享、复用

2.3 特征离线存储&消费

离线存储&消费能力是为模型训练阶段服务的。

对于广告、个性化推荐等使用过去信息来预测未来信息的算法模型，特征是随时间变化的。例如用户最近1小时浏览商品列表，会随着时间变化而发生变化。

进行模型训练时，我们需要预先生成训练数据。以电商场景为例，将一系列被标记的行为关联其对应的特征，即可生成训练数据。

2.4 特征在线存储&消费

在线存储&消费能力是为模型部署阶段服务的。

算法模型部署成在线服务后，在进行推理（inference）时，需要快速取得特征，这要求我们将特征的最新的版本同步到高速缓存中，并提供便捷的查询API（例如按特征组查询），以便满足高并发、低延迟的特征在线消费要求。

三.特征平台构成与架构

除去控制台相关组件，特征平台核心的组件都是与数据相关的：

特征计算引擎：用于特征抽取、特征工程处理、训练数据生成等过程
特征存储：Google BigQuery、Hive等数据仓库用于特征离线存储，Redis、Cassandra等高速缓存用于特征在线存储

四.使用特征平台的利弊

4.1 好处:

强制隔离数据科学和数据工程以及 MLOps：ML 工作流往往很复杂，并且包含许多不同的步骤。特征平台自然地将数据工程与数据科学分离，因为它为数据工程工作流的输出提供了一个目的地，并为 ML 用例提供了一个自然的起点。同样，特征平台将模型训练与特征服务分开，这在数据科学和 MLOps 之间提供了天然屏障。这在 ML 工作流程周围强加了结构，从而提高了效率并避免了复杂的“流水线丛林”。
支持特征共享：通过支持特征重用和可发现性，特征平台可帮助组织更好地协作处理 ML 用例。领域专家可以在特征平台中快速注册特征，然后可以很容易地在跨团队的各种用例中使用。最终结果是强大的特征共享消除了重复的特征工程工作，并使每个人都更有效率。
防止数据泄漏和训练/服务偏差：数据泄露和训练/服务偏差是尝试将 ML 用例投入生产时最常见的两个障碍。正如我们之前所讨论的，特征平台为这两个问题提供了优雅的解决方案。
加速用例的采用：当特征平台是运营 ML 系统的一部分时，更新用例通常就像修改特征集一样简单。用户可以快速对用例进行原型设计和迭代，并迅速将最佳模型投入生产。如果没有特征平台，这将是不可能的。
使 ML 民主化：许多 ML 工具大胆声称有助于使 ML 工作流程民主化，但最终用户常常被困在编写代码或构建复杂的流水线，更不用说试图理解复杂的 ML 概念了。由于特征平台可以通过实体说出业务语言，这允许许多用户开始为 ML 用例做出贡献，无论是通过注册新特征以供使用，还是通过数据优先的 ML 运营平台显式构建模型。

4.2 缺陷

难以构建和维护：特征平台对于ML工作流来说非常棒，但它们的构建和维护可能非常具有挑战性。
需要专业知识才能使用：并非所有特征平台都是平等的。快速浏览一些文档可以发现这些系统非常复杂，您的组织需要时间来掌握这些系统。理想情况下，尝试选择一个易于使用且与现有数据堆栈配合良好的特征平台，因为它可以让您的团队更快地迭代并让更多的数据专业人员参与协作。
可能是“又一个”集成点因为这些系统需要复杂的集成，从而产生大量的技术债务。独立的特征平台可能很难有效地集成到您的 ML 工作流程中，并且无法完全实现真正的数据优先方法来操作 AI/ML 的潜力。

此外，虽然特征平台对于可操作的 ML 平台至关重要，但拥有特征平台并不一定意味着您也拥有可操作的 ML 平台（这是必要条件，而非充分条件）。

五.产品选型

5.1 Feast

5.1.1 介绍

Feast是一个由Gojek开发的特征商店和特征服务平台，它提供了一组功能来管理和共享特征，包括特征注册、版本控制、特征微服务和特征预测等。Feast还支持自动特征衍生和特征联合，这使得其非常适合在大规模数据和高并发场景中进行特征工程和模型推理。

文档链接

5.1.2 架构

Feast对自身的定位是：特征管理服务、特征消费服务的提供者。

5.1.3 核心概念

Feast 中的顶级命名空间是一个project。用户在项目中定义一个或多个特征视图。每个特征视图包含一个或多个与特定实体相关的特征。特征视图必须始终有一个数据源，在生成训练数据集和将特征值具体化到在线商店时会用到它。

数据源

数据源是指原始底层数据（例如 BigQuery 中的表）。

Feast 使用时间序列数据模型来表示数据。此数据模型用于解释数据源中的特征数据，以便构建训练数据集或将特征具体化到在线商店中。

下面是一个具有单个实体 ( driver) 和两个特征 ( trips_today, 和rating) 的示例数据源。

实体

作为Feature View的数据主体，是特征存储、消费、复用的关键。

Entity可能由Data Source表中的单个或多个字段来确定（即数据库表中的单主键/联合主键）。

特征视图

Feature View是封装某一特定实体（Entity）的一组特征（Feature）的对象。

作为Feature Store的核心概念，以下能力均围绕Feature View建设起来：

训练数据生成：一个训练数据集可能使用来自多个Feature View的特征，在生成数据集时，会通过Feature View的Data Source取到这些特征的值
特征在线存储同步：特征以Feature View为单位，被同步到在线存储中
特征在线消费：特征以Feature View为主体，在消费时被定位和查询

5.1.4使用流程

部署阶段

生成特征：通过SQL、Spark、Pandas等各种方式生成特征时序表备用
创建Feature Repository：实际是编写一系列Python脚本，在其中调用SDK定义Data Source（关联步骤1中的时序表）、Feature、Feature View等对象
部署Feature Repository：实例化步骤2中的各对象

使用阶段

特征更新：通过SQL、Spark、Pandas等各种方式，持续增量更新特征时序表（即持续更新Data Source）
生成训练数据集：通过Dataframe对象提供训练样本列表，调用SDK的get_historical_features方法，从各Feature View中取得特征，并进行Point-in-time Correct Join，供模型训练使用
同步特征至在线存储：通过CLI，将各特征的最新版本同步到在线存储
在线消费特征：调用SDK的get_online_features方法，通过Feature View配合特征名批量取回特征，供在线推理使用

5.1.5 优点

支持批和流的特征，功能较为完善（官网Roadmap），生态也较为完善，社区较为活跃，版本发布也较快，Github上近4K Star。设计简单，轻量级，使用Python 开发对算法人员更友好；
不参与原始特征计算

Feast不参与特征日序表的生成过程，而只负责基于现有的特征日序表提供管理、消费能力。

这使得Feast本身很容易与现有的数据流程集成，无论原有数据架构是通过Backfill Data还是Feature Snapshot形式生成特征时序表，只要其符合Feast对特征数据源的要求，就可以通过Feast来管理
专注为算法模型提供特征消费服务

对于训练数据生成、线上/线下推理的特征消费场景做了完整覆盖，前者通过将point-in-time correct join流程固化成代码，确保训练数据可以被正确的生成，简化了算法工程师的工作；而后者通过online store同步能力和特征消费SDK，简化了数据工程师的工作。
简洁至上的模块设计

Feast充分地运用了GCP BigQuery、AWS Redshift等云数据库的能力，将piont-in-time correct join运算完全下推，使得Feast本体运行几乎不需要消耗计算资源。

在特征在线消费阶段，Feast封装具体从online store取数的逻辑，对使用者只暴露业务层级（Feature、Feature View）的概念。这一过程通过特征消费SDK实现，模型中只需调用SDK即可实现特征消费，一方面，避免了特征消费服务的部署、维护的工作量，另一方面，也避免了性能瓶颈点的出现。

5.1.6缺点：

但是有些插件是非官方贡献的，稳定性与兼容性需测试；
训练数据生成性能问题，使用point-in-time correct join方式生成训练集的方法，当面对庞大的特征版本数量时，会遭遇严重的计算效率和存储成本问题。
online store中特征的时效性问题

  online store同步需要通过CLI触发：

  这一过程使得整个流程的时效性极大下降，特征总是需要先写入offline store，并批量地被同步到online store。

  因此，online store中特征的时效性取决于：

  由于同步作业是全量更新，频繁更新会对offline store、online store都造成IO压力，因此时效性很难降低到分钟/秒级。
1. 提交SQL到offline store，获取最新的特征版本值
2. 拉取SQL结果集到执行CLI的机器
3. 将结果集更新到online store
4. offline store的更新频率
5. 同步作业的调度频率
Registry通过CLI交互，未提供界面
Registry无权限管理和审计能力

5.2 Tecton

官方文档

Tecton是Feast的商业化版本，在Feast的基础上，补充了很多能力，其中一些正解决了Feast的一些问题，另一些则完善了平台的能力：

易用性：统一的Web-UI
权限管控：SSO&ACLs
审计：DevOps Integration
特征时效性：Raw Stream Data Ingestion（流式数据接入）、Transformation during Data Ingestion（数据接入时处理）
数据处理监控：Transformation Monitoring
上下文特征计算：Realtime（Context）Feature Transformation

5.2.1 补充能力（与feast对比）

Tecton自带了特征计算能力

  Feast不负责特征生产，极大的降低了其架构复杂度，但也因此遗留了两个缺陷：

  Tecton自带了特征计算能力，彻底解决了实效性问题，并提供了一定程度上的自治能力。

  通过Tecton的Feature View语法，不但可以将预计算好的特征导入到平台；也可以从原始数据出发，计算出需要的特征并导入平台存储。

  其本质上是Tecton根据Feature View定义，创建Spark作业作为数据Pipeline，进行定时或流式的ETL和Aggregation操作。数据源可以是数据库、文件、消息队列，而计算结果——即特征的目的地则是平台的offline store和online store。
1. 平台用户缺失自治能力：只能消费已有的特征，无法根据需求方便地创建特征
2. 平台不管理特征计算，导致online store中特征的实效性受限
流批一体化处理与特征回填

Tecton借助Databricks（Spark）最新的流批一体化API，以流式数据源作为Single Source of Truth，自动化的完成特征回填操作

这一方案直接规避了数据不同源、处理逻辑有差异等问题，很可靠地解决了特征回填的问题，同时它又是自动完成的，极大地降低了用户的使用负担。
1. 最新的特征，通过流处理，消费流式数据源进行计算
2. 同时，流式数据落盘保存
3. 需回填的特征，通过批处理，消费落盘的数据，尽量复用流处理的处理逻辑，完成特征计算
监控能力

在特征计算过程，Tection提供了数据领域与业务领域的监控指标，例如Spark作业是否如期调度、Spark作业是否正常完成、特征的新鲜度（freshness）等。

5.2.2 总结

Tecton在Feast的基础上补充了诸如特征计算、WEB UI、ACLs、监控能力，解决了特征时效性、特征回填等难点问题，使其作为特征平台的能力更加完整，达到了商用要求
Tecton活用了Spark流批一体化的API，构建了声明式的特征计算、特征回填等能力，提供了极佳的架构设计参考

5.3 OpenMLDB

国内的第四范式在2019年开源的， OpenMLDB 是一个开源机器学习数据库，产品定位：线上线下一致的生产级特征计算平台。官方文档

OpenMLDB 的主要使用场景为作为机器学习的实时特征平台。其基本使用流程如下图所示：

可以看到，OpenMLDB 会覆盖机器学习的特征计算环节，从离线开发到线上实时请求服务的完整流程。

5.3.1 四大核心特性

线上线下一致性：离线和实时特征计算引擎使用统一的执行计划生成器，线上线下计算一致性得到了天然的保证。
毫秒级超低延迟的实时 SQL 引擎：线上实时 SQL 引擎基于完全自研的高性能时序数据库，对于实时特征计算可以达到毫秒级别的延迟，性能远超流行商业内存数据库（可参考 VLDB 2021 上的论文），充分满足高并发、低延迟的实时计算性能需求。
基于 SQL 定义特征：基于 SQL 进行特征定义和管理，并且针对特征计算，对标准 SQL 进行了增强，引入了诸如 LAST JOIN 和 WINDOW UNION 等定制化语法和功能扩充。
生产级特性：为大规模企业应用而设计，整合诸多生产级特性，包括分布式存储和计算、灾备恢复、高可用、可无缝扩缩容、可平滑升级、可监控、异构内存架构支持等。

有中文文档，这点对国内的用户较为友好。

5.3.2 缺点：

数据来源主要支持Hive、Kafka等有点单薄；

使用SQL对特征工程的支持有点单薄

5.4 Feathr

Feathr 定位为：企业级高性能特征平台，由LinkedIn 领英在2022年 4 月份开源，于2022年 9 月份捐献给 LF Data & AI 社区。官方文档

5.4.1 优点：

1. 已捐献给社区，由社区维护预期发展会更好；

2. Feathr UI 来进行特征的探索和发现；

3. 企业级的特性，例如基于角色的访问权限控制（RBAC）；

5.4.2 缺点：

1. 功能尚不完善，Roadmap还有许多未实现；

2. 开源时间不久，用户较少；

5.5 FeatHub

FeatHub 是一个流批统一的特征存储，可简化机器学习应用程序的特征开发、部署、监控和共享。由阿里巴巴开发，官方文档

5.5.1 架构概述

FeatHub的架构及关键组件如下图所示。

使用 FeatHub 定义、计算和提供特征的工作流程如下图所示。

5.5.2 支持的计算引擎

Apache Flink 1.16
Aapche Spark 3.3

六.其他产品

以下是一些具备特征工程能力的项目：

Google Feature Store：Google Feature Store是一个特征管理平台，旨在为机器学习和数据科学团队提供特征存储和特征服务支持。它是Google Cloud的一部分，适用于Google Cloud用户。
Mlflow：Mlflow 是一个开源的机器学习平台，提供了实验追踪、模型管理和部署的功能。它包括一个特征化工具，可将原始数据转换为特征并处理特征的离散化、缩放和编码等。
TFX Tensorflow Extended :TFX 是一个非常流行的机器学习平台，包括特征管理、特征选择和模型部署工具。TFX中包含多种特征处理组件，可帮助将原始数据转换为特征集以供训练和部署使用。
Hopsworks: Hopsworks 是一个开源的数据平台，包括特征实时删除、特征存储和可视化特征仪表板等功能。它是一个完整的数据生态系统，可以进行大规模的数据处理和机器学习任务。
Featuretools:Featuretools是一个Python库，它自动化创建特征的过程，可以处理时间序列和关系数据，而不需要任何额外的算法知识或特征工程知识。
Kaleido：Kaleido是一款基于分布式存储架构和分布式计算框架的特征工程平台，可以最大限度地从原始数据中提取特征以供算法和模型使用。数据科学家的工作中，有80%的时间都在获取、清洗和特征处理，Kaleido通过分布式存储架构和分布式计算框架，快速完成这80%的工作量，将数据转换为能更好的表示业务逻辑的特征，从而提高机器学习的性能。

.......

七.对比

特征功能	Feast	Feathr	OpenMLDB	FeatHub	Tecton	Mlflow	Hopsworks	Featuretools
特征存储和服务	支持	不支持	支持	支持	支持	不支持	支持	不支持
特征提取	不支持	支持	支持	不支持	支持	支持	支持	支持
特征选择	支持	支持	不支持	支持	支持	支持	支持	支持
特征变换	不支持	支持	支持	不支持	支持	支持	支持	支持
特征生成	支持	支持	支持	不支持	支持	不支持	支持	支持
数据源类型	SQL、Kafka、Kinesis	MySQL、Hive、Vertica、HBase	MySQL、Kafka、Hbase、Minio	MySQL、Hive、Redshift、BigQuery	MySQL、PostgreSQL、Redshift	文件、MySQL、PostgreSQL	HDFS、Hive、Kafka、JDBC	Pandas、Dask
开源	是	否	是	是	否	是	是	是
支持的语言	Python	Scala, Java	C++	Python	Python	Python, R	Python, Scala	Python
可扩展性	支持	支持	支持	支持	支持	支持	支持	支持
可视化	支持	不支持	不支持	支持	支持	支持	支持	支持
流处理	支持	支持	支持	支持	支持	支持	支持	不支持
批处理	支持	支持	支持	支持	支持	支持	支持	支持
实时流	支持	支持	支持	支持	支持	支持	支持	支持
特征监控	支持	不支持	支持	不支持	支持	支持	支持	不支持
特征版本控制	支持	不支持	不支持	支持	支持	支持	支持	不支持
官方文档	完善	部分	部分	部分	完善	完善	完善	完善
社区支持	活跃	有	有	有	有	活跃	活跃	活跃

八.案例

外卖排序系统特征生产框架

Feature Stores - A Hierarchy of Needs

Feature Stores for ML

使用特征存储简化机器学习开发

九.结论

目前主流的开源特征平台中Feast因为开源时间较早，文档齐全等原因被使用或者二次开发的次数较多，产品也相对成熟，从开源产品选择来说落地更加容易

MLflow虽然是一个开源的机器学习平台，但是在机器学习相关开源社区使用比较广泛，而且也具备一定的特征工程能力，可以作为备选方案

OpenMLDB（第四范式）的使用场景相对较少，但因为有对应商业化产品，如果使用场景符合，可以作为选择

Kaleido（天云科技）的客户较多，功能相对OpenMLDB更多一点，也可以作为商业产品选择之一

主流特征工程平台（一）