📚 课程目录第4章 Feast 深度解析

4、Feast 深度解析：架构设计、核心组件与部署模式

Feast 是我个人在实时特征工程里用得最多的开源方案。说实话，它不算最轻量的，但胜在概念清晰、社区活跃。今天咱们就把它拆开来看——架构怎么搭、核心组件怎么用、部署有哪些坑。

4.1 整体架构：离线与实时的桥梁

Feast 的核心思路，是把离线批量计算好的特征，和实时流式计算产生的特征，统一暴露给线上推理服务。说白了，它就是个特征中间层。

一句话总结：Feast 不存原始数据，只存特征元数据和 Serving 逻辑。真正的特征值存在你指定的 Online Store 或 Offline Store 里。

你看这个图，左边是离线存储，右边是在线存储，中间是注册中心。SDK 和 API 层负责把特征喂给模型推理服务。我习惯把 Feast 比作「特征路由器」——它不生产特征，只是特征的搬运工。

4.2 核心组件详解

4.2.1 Feature Store

Feature Store 是 Feast 里的顶层概念。它代表一个完整的特征仓库实例，包含所有配置、存储后端和元数据。一个团队通常只维护一个 Feature Store，但可以包含多个项目（Project）。

我的经验：别把 Feature Store 和「特征存储」搞混。Feature Store 是逻辑概念，真正的特征值存在你指定的数据库里。我在项目中见过有人以为 Feast 自带存储，结果把 Redis 集群忘配了——上线直接 OOM。

4.2.2 Feature View

Feature View 是特征定义的逻辑分组。它把一组相关的特征（比如用户画像特征、交易统计特征）打包在一起，并指定数据源、时间戳列、TTL 等属性。

# 定义一个用户画像 Feature View
user_profile_fv = FeatureView(
    name="user_profile",
    entities=["user_id"],
    ttl=timedelta(days=7),
    batch_source=BigQuerySource(
        table_ref="project.dataset.user_features",
        timestamp_field="event_timestamp"
    ),
    features=[
        Feature(name="age", dtype=ValueType.INT64),
        Feature(name="city", dtype=ValueType.STRING),
        Feature(name="membership_level", dtype=ValueType.INT32),
    ]
)

这里要注意 TTL 参数。TTL 决定了特征在 Online Store 里存活多久。我踩过一个坑：把 TTL 设成 30 天，结果 Redis 内存爆了。后来改成 7 天，配合定时刷新，内存稳定多了。

4.2.3 Feature Service

Feature Service 是面向线上推理的接口。它把多个 Feature View 组合成一个 Serving 单元。模型推理时，只需要指定 Feature Service 名称，Feast 会自动拉取所有需要的特征。

# 定义一个线上推理用的 Feature Service
fraud_detection_service = FeatureService(
    name="fraud_online",
    features=[
        user_profile_fv,
        transaction_stats_fv,
        device_fingerprint_fv
    ]
)

# 线上调用
online_features = feast_client.get_online_features(
    feature_service="fraud_online",
    entity_rows=[{"user_id": "12345", "transaction_id": "abcde"}]
)

⚠️ 注意：Feature Service 不是简单的 Feature View 列表。它会自动处理实体映射、时间对齐和特征合并。但这也意味着——如果两个 Feature View 的实体键不一致，Feast 会报错。我建议在定义 Feature Service 前，先用 feast apply 验证一下。

4.3 部署模式对比

Feast 支持三种部署模式。我按实际场景排了个优先级，你根据团队规模选就行。

部署模式	适用场景	优点	缺点
本地/单机模式	开发测试、小团队原型	部署简单，一条命令启动	不支持高可用，数据量有限
Kubernetes 模式	生产环境、中大规模	弹性伸缩、健康检查、滚动更新	运维成本高，需要 K8s 经验
Serverless 模式	云原生、按需付费	零运维，自动扩缩容	冷启动延迟，依赖云厂商

4.3.1 本地模式

说白了就是 feast serve 一条命令。适合你在笔记本上调试 Feature View 定义。我刚开始学 Feast 时就用这个模式，跑通后再上 K8s。

# 启动本地 Feast Server
feast apply
feast serve --port 6566

4.3.2 Kubernetes 模式

这是生产中最常用的模式。Feast 提供 Helm Chart，一键部署到 K8s 集群。我建议至少配 2 个副本，加上 HPA 自动扩缩容。

# 使用 Helm 部署 Feast
helm repo add feast https://feast-helm-charts.storage.googleapis.com
helm install feast feast/feast \
  --set global.registry.path="gs://my-bucket/feast-registry" \
  --set onlineStore.type="redis" \
  --set onlineStore.connection_string="redis://redis-service:6379"

避坑指南：我曾经把 Registry 存在本地磁盘，结果 Pod 重启后元数据全丢了。后来改成 GCS 或 S3 存储 Registry，再也没出过问题。记住——Registry 必须用持久化存储。

4.3.3 Serverless 模式

如果你用 AWS 或 GCP，可以考虑 Serverless 模式。Feast 可以部署在 AWS Lambda 或 Cloud Run 上，按请求计费。适合流量波动大的场景。

不过要注意冷启动问题。我有个客户用 Lambda 部署 Feast，平时流量低还好，一到促销活动就频繁冷启动，特征获取延迟从 5ms 飙到 200ms。后来加了预留并发才解决。

4.4 部署最佳实践

Registry 必须持久化：存到 S3/GCS/MinIO，别放本地磁盘。
Online Store 选型：Redis 适合低延迟（<5ms），DynamoDB 适合高吞吐。我一般用 Redis Cluster，分片 16 个节点。
监控与告警：至少监控 Online Store 的 QPS、延迟、内存使用率。Feast 暴露 Prometheus 指标，直接接入 Grafana。
版本管理：每次 feast apply 前，先 feast plan 看看变更。我习惯把 Registry 的版本号打在 Docker 镜像标签里。

一句话总结部署：本地开发用单机，生产环境上 K8s，流量波动大就 Serverless。Registry 放对象存储，Online Store 用 Redis 或 DynamoDB。监控到位，版本可控。

嗯，Feast 的核心内容差不多就这些。你可能会觉得组件有点多，但用熟了就会发现——Feature View 管定义，Feature Service 管服务，Feature Store 管全局。各司其职，挺清晰的。