Alauda AI
  • 简体中文

    • Alauda Build of Feast

    Feast 是一个用于机器学习的开源 feature store。它帮助团队在模型训练、批量评分和在线推理中使用相同的 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 定义
    • 在训练、批量评分和在线推理中使用相同的 feature 定义
    • 在一个位置控制 freshness、materialization 和访问策略

    Feast 通过共享 registry、online 和 offline store，以及用于注册、materialization、服务和访问控制的标准工作流，提供这些能力。

    托管资源

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

    • Offline store：存储历史 feature 数据，并支持训练数据集生成或回填。
    • Online store：存储最新的 feature 值，以便在推理期间进行低延迟在线读取。
    • Registry：存储 entities、feature views、feature services 和权限等元数据。
    • UI：提供用于浏览 feature 元数据和服务状态的 Web 界面。
    • 客户端配置：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 组合成一个可复用集合，供某个模型或应用版本使用。这有助于在训练和服务之间保持 feature 选择的一致性。

    Registry

    registry 存储的是 Feast 元数据，而不是 feature 值。它是已注册对象的权威来源，例如 entities、feature views、feature services 和权限。

    Materialization

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

    Push Source

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

    Permission

    权限用于定义谁可以读取或修改 Feast 对象和数据。在 Alauda Build of Feast 中，常见配置结合了：

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

    这使得为不同用户或工作负载授予只读和读写访问权限成为可能。

    典型工作流

    典型的 Feast 工作流如下：

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

    Operator 职责

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

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

    延伸阅读

    在本文档集中：

    1. 安装 Feast
    2. 快速开始

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