Alauda AI
  • 简体中文

    • 介绍

    Feast 是一个用于 machine learning 的开源 feature store。它帮助团队在 model Training、batch scoring 和 online inference 中使用相同的 feature 定义，从而减少 training-serving skew 以及重复的 feature engineering 工作。

    在 Alauda Build of Feast 中，Feast 通常通过 Feast Operator 部署在 Kubernetes 上。每个部署都由一个 FeatureStore 自定义资源（CR）管理。单个 FeatureStore CR 可以创建主要的 Feast 服务，例如 online feature server、offline feature server、registry server 和 UI。

    目录

    典型需求托管资源核心概念ProjectEntityData SourceFeature ViewFeature ServiceRegistryMaterializationPush SourcePermission典型工作流operator 职责进一步阅读

    典型需求

    当平台需要一种更一致的方式来完成以下任务时，通常会使用 Feast：

    • 在共享目录中管理 feature 定义
    • 在 Training、batch scoring 和 online inference 中使用相同的 feature 定义
    • 在一个位置控制 freshness、materialization 和访问策略

    Feast 通过共享 registry、online store 和 offline store，以及用于 registration、materialization、serving 和 access control 的标准工作流来提供这些能力。

    托管资源

    在由 Feast Operator 管理的 Kubernetes 部署中，FeatureStore 通常会创建或管理以下资源：

    • Offline store：存储历史 feature 数据，并支持 Training 数据集生成或回填。
    • Online store：存储最新的 feature 值，以便在 inference 期间进行低延迟在线读取。
    • Registry：存储 entity、feature view、feature service 和权限等元数据。
    • UI：提供 Web 界面，用于浏览 feature 元数据和服务状态。
    • 客户端配置：operator 还会创建一个包含客户端 feature_store.yaml 的 ConfigMap，以便客户端应用和任务能够连接到已部署的服务。

    核心概念

    在开始使用 Feast 时，以下概念最为重要：

    Project

    Feast project 是一个隔离的逻辑工作区。feature 定义、权限和 registry 对象都按 project 进行组织。在 Alauda Build of Feast 中，project 名称通过 FeatureStore CR 中的 spec.feastProject 进行设置。

    Entity

    Entity 是用于检索 feature 的业务键，例如 user_id、driver_id 或 merchant_id。

    Data Source

    Data source 用于描述原始 feature 数据的来源。示例包括文件、data warehouse 或 push source。

    Feature View

    feature view 定义以下内容：

    • feature 属于哪个 entity
    • 源数据来自哪里
    • 哪些字段作为 feature 暴露
    • 这些 feature 是否应在线提供

    在实践中，feature view 通常是用户注册和 materialize 的主要对象。

    Feature Service

    feature service 会将一个或多个 feature 组合为某个 model 或 application 版本可复用的一组 feature。这有助于在 Training 和 serving 之间保持 feature 选择一致。

    Registry

    registry 存储的是 Feast 元数据，而不是 feature 值。它是已注册对象的事实来源，例如 entity、feature view、feature service 和权限。

    Materialization

    materialization 会将 feature 值从 offline source 复制到 online store，以便在 inference 时以低延迟获取。

    Push Source

    push source 允许应用或流式任务将新的 feature 值直接写入 Feast，写入目标可以是 online store、offline store，或者两者同时写入。

    Permission

    Permission 定义谁可以读取或修改 Feast 对象和数据。在 Alauda Build of Feast 中，常见的配置会结合使用：

    • Kubernetes Role 和 RoleBinding
    • 使用 RoleBasedPolicy 的 Feast Permission 对象

    这样可以向不同用户或工作负载授予只读和读写访问权限。

    典型工作流

    典型的 Feast 工作流如下：

    1. 安装 Feast Operator。
    2. 创建一个 FeatureStore CR 来部署 Feast 服务。
    3. 在 feature repository 中定义 entity、feature view、feature service 和权限。
    4. 运行 feast apply，将元数据注册到 registry 中。
    5. 将 feature 数据 materialize 或 push 到 online store。
    6. 从客户端应用、batch 作业或在线服务中读取 feature。

    operator 职责

    与手动部署 Feast 相比，Feast Operator 会管理 Feast 所需的 Kubernetes 资源。示例如下：

    • 创建并协调 Feast Deployments 和 Services
    • 初始化 feature repository，或从 Git 克隆一个 repository
    • 为 offline、online 和 registry 数据提供基于 PVC 的持久化
    • 创建 Feast authorization 使用的可选 Kubernetes Role 对象
    • 通过 CR status 和客户端 ConfigMap 发布连接信息

    进一步阅读

    在本文档集中：

    1. 安装 Feast
    2. 快速开始

    有关 Feast 的官方背景资料，请参阅：