企业官网建设流程全解析

Feast 0.10 发布回顾：用 pip 安装与声明式 feature_store.yaml 重新定义特征仓库工作流

【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feast

Feast 0.10（2021 年 4 月 15 日发布）是 Feast 走向"轻量级特征存储"的关键里程碑：它把 Spark、Kubernetes、自管基础设施全部变为可选项，首次提供通过 pip 安装的本地模式，并让"建特征仓库 → 声明式 apply → 构建训练数据集 → 物化到在线库 → 低延迟读取"这条完整链路可以在 notebook 和 CI 中跑通。本文以该发布公告为主线，结合当前仓库中保留至今的特征仓库模板（如 gcp 模板）与 CLI 源码（cli.py），还原 0.10 的核心工作流，并说明这些设计在当前代码库中的实现形态。

发布背景：为什么 0.10 要让基础设施"全部可选"

0.10 发布公告指出的核心痛点是：

"Feature stores are big infrastructure!"

传统认知中，特征存储需要计算层、离线库、在线库，并且要直接对接生产系统，因此被当作平台来建设。基础设施为中心的模式导致很多 ML 团队无力自建特征存储，只能写一堆临时脚本，或等待工程团队排期。

Feast 0.10 对此的回应可以概括为三点：

1. 所有基础设施都是可选的——没有 Spark、Kubernetes 和 API 也能跑特征存储；
2. 核心软件被抽成一个 Python 框架——团队通过声明式定义特征，并据此在本地或云端声明式地"供应"（provision）一个特征存储；入门者只需要管理一个 Git 仓库，并运行 Feast CLI 或 SDK；
3. 引入一等公民的本地模式——不再依赖 Docker 容器，而是直接通过 pip 安装，用户可以在 notebook 中从零启动一个最小特征存储，基于样例数据快速开发，并用与生产相同框架测试。

公告同时提到 0.10 开始加入对托管服务的一等支持：内置 GCP 支持，其他 provider 随后跟进；平台团队可以借助 serverless 技术扩展到生产负载，也仍然可以把完整系统部署到 Kubernetes 上。这一"从 notebook 起步、向平台扩展"的思路，正是当前仓库sdk/python/feast/目录组织方式（providers、offline/online store、stream processor 均可插拔）的历史源头。

第一步：创建特征仓库（Feature Repository）

0.10 的安装方式简化为一行：

pip install feast

然后基于 GCP 模板脚手架出一个特征仓库：

feast init driver_features -t gcp

生成的特征仓库结构是：

driver_features/ └── feature_store.yaml └── driver_features.py

• feature_store.yaml：承载搭建特征存储所需的基础设施配置；
• Python 特征定义文件（如driver_features.py）：包含实体与特征视图定义，共同描述一组可用于训练或服务的特征。

在 CLI 实现层面，feast init命令至今保留在 cli.py 中：init_command接收项目目录、--minimal（生成空项目）与--template/-t模板参数后调用init_repo生成仓库。需要注意当前仓库中--template的可选值已扩展为 local、gcp、aws、snowflake、spark、postgres、hbase、cassandra、hazelcast、couchbase、milvus、ray、ray_rag、rag、pytorch_nlp（见 cli.py），这与公告末尾"欢迎社区贡献更多 provider 与数据源"的展望一致——模板机制就是 0.10 开启的扩展点。

feature_store.yaml 的三个核心字段

0.10 公告中给出的 GCP 配置示例是：

project: driver_features registry: gs://driver-fs/ provider: gcp

三个字段各自的角色：

对照当前仓库中 gcp 模板的实际 feature_store.yaml，可以看到该机制的演化形态：registry默认指向本地文件（data/registry.db，注释说明 GCP 上最小配置应为 GCS bucket），provider: gcp下不配置online_store时默认使用 Datastore（公告中 0.10 的 GCP 在线库即 Firestore/Datastore），也提供了 sqlite、bigtable、redis 等可替换的online_store配置注释块。也就是说，0.10 提出的"provider + 声明式配置"骨架没有变，只是在线库选项从单一对 Datastore 扩展为可插拔的 online store 体系。

特征定义的 Python 形态

公告说 GCP 模板"包含一个实体和一个特征视图"。以当前仓库 gcp 模板的 feature_definitions.py 为例，核心定义与 0.10 时期一脉相承，并叠加了后来的增量能力：

# 实体：可以理解为获取特征用的主键 driver = Entity(name="driver", join_keys=["driver_id"]) # 数据源：构建训练数据集或物化时会被查询 driver_stats_source = BigQuerySource( name="driver_hourly_stats_source", table="feast-oss.demo_data.driver_hourly_stats_2", # 事件时间戳用于 point-in-time join，也保证只返回 TTL 内的特征 timestamp_field="event_timestamp", created_timestamp_column="created", ) # 特征视图：按特征在离线/在线库中的存储方式分组 driver_stats_fv = FeatureView( name="driver_hourly_stats", entities=[driver], ttl=timedelta(weeks=52 * 10), # 示例用超长 TTL schema=[ Field(name="conv_rate", dtype=Float32), Field(name="acc_rate", dtype=Float32), Field(name="avg_daily_trips", dtype=Int64), ], source=driver_stats_source, tags={"team": "driver_performance"}, version="latest", )

几个值得注意的细节：

• timestamp_field是 point-in-time join 的基础，created_timestamp_column用于离线侧去重——这两个字段正是公告第三步"用时间属性重建某一时刻特征视图"的落点；
• ttl决定特征值相对查询时刻的最大可接受年龄，同时用于在线库的键驱逐，并限制历史特征查询时的回溯扫描量；
• 模板在此基础上还展示了 0.10 之后加入的RequestSource+@on_demand_feature_view（按需在线计算特征）、FeatureService（把特征按模型版本分组）以及PushSource（向在线库推送新鲜特征）——这些都是公告"What's next"里"解锁新运维 ML 用例"方向的实际产物。

第二步：feast apply——声明式供应基础设施

在仓库根目录执行：

feast apply

feast apply会把特征定义注册进 registry（GCP 场景下是 GCS 上的对象存储 registry），并为特征读写准备好基础设施（GCP 场景即 Firestore/Datastore）。公告强调两点：apply 是幂等的，并且设计为在 CI 中于特征定义变更时执行——这正是"基础设施即代码"的思路。

从源码结构看，当前的feast apply命令（cli.py 中的apply_total_command）仍遵循同一骨架：先load_repo_config读取feature_store.yaml，再执行apply_total(repo_config, repo, ...)。它新增了 0.10 之后的参数，如--no-promote（保存新版本但不提升为 active，可通过@v<N>读取）、--skip-source-validation、--no-progress等，说明 0.10 确立的"apply = 注册元数据 + 供应基础设施，不搬数据"的语义边界被完整保留。

一个关键事实（公告原文）：apply 阶段不移动任何数据——只是把特征定义元数据存入 registry，并配置好基础设施。数据真正流动发生在第三步（训练数据集构建）与第四步（物化）中。

第三步：构建训练数据集（get_historical_features）

公告给出的训练管线代码：

# Connect to the feature registry fs = FeatureStore( RepoConfig( registry="gs://driver-fs/", project="driver_features" ) ) # Load our driver events table. This dataframe will be enriched with features from BigQuery driver_events = pd.read_csv("driver_events.csv") # Build a training dataset from features in BigQuery training_df = fs.get_historical_features( feature_refs=[ "driver_hourly_stats:conv_rate", "driver_hourly_stats:acc_rate" ], entity_df=driver_events ).to_df() # Train a model, and ship it into production model = ml.fit(training_data)

这段代码的技术核心是point-in-time correct join：用户提供的driver_events数据框会与 BigQuery 中的driver_stats表按时间属性做正确的时间点对齐——Feast 利用特征表的事件时间戳，从任意多张特征表/视图中重建出"某一时刻的特征视图"，从而避免训练数据泄漏（feature leakage）。这是公告开篇对 Feast 定位的三件事之一（防止泄漏地构建训练数据集）。

当前仓库中FeatureStore的构造方式已演化：feature_store.py 中FeatureStore.__init__接受repo_path、config（即 0.10 时代的RepoConfig）、fs_yaml_file等参数，且支持直接FeatureStore(repo_path=".")从目录中的feature_store.yaml读取配置——这对应 0.10 主打的"pip 安装 + 本地仓库"体验。同时，get_historical_features的参数名从feature_refs演化为features（当前 gcp 模板 test_workflow.py 中使用features=[...]），且entity_df现在既支持 pandas DataFrame，也支持 SQL 字符串（模板中fetch_historical_features_entity_sql直接传entity_sql），用于"时间窗口内所有实体"的场景——0.10 公告未覆盖但同属训练数据集构建能力。

第四步：物化特征到在线库（materialize-incremental）

模型训练完成后，在线特征库还是空的。公告给出的做法是从命令行运行materialize-incremental：

Feast provides materialization commands that load features from an offline store into an online store. The default GCP provider exports features from BigQuery and writes them directly into Firestore using an in-memory process. Teams running at scale may want to leverage cloud-based ingestion by using a different provider configuration.

即：0.10 的 GCP provider 默认用进程内（in-memory）方式从 BigQuery 导出数据并直接写入 Firestore；规模化团队可通过更换 provider 配置改为云端 ingest。

对照当前 CLI 实现，物化命令族保留了下来并细化为两个命令（cli.py）：

• feast materialize START_TS END_TS：非增量物化，从离线库读取[START_TS, END_TS]区间内全部数据写入在线库；支持--views/-v指定视图子集、--disable-event-timestamp（源数据无事件时间时用当前时间物化全部数据）；
• feast materialize-incremental END_TS：增量物化，从"上次 ingest 的位置"读到END_TS写入在线库；不带--views时物化所有已注册 Feature View。

两个命令的时间参数均为 ISO 8601 格式，例如'2021-07-16T19:20:01'。当前 gcp 模板的 test_workflow.py 展示了 SDK 等价调用：store.materialize_incremental(end_date=datetime.now())，与 CLI 命令一一对应。公告第六步的建议——"调度一个 Feast 物化作业，并在 CI 中随特征定义变化更新基础设施"——即把feast apply放 CI、把feast materialize-incremental放进定时调度，这套运维模式至今仍是标准做法。

第五步：低延迟读取在线特征（get_online_features）

在线库被物化填充后，模型服务侧即可低延迟读取特征做预测。公告给出的代码：

# Connect to the feature store fs = feast.FeatureStore( RepoConfig(registry="gs://driver-fs/", project="driver_features") ) # Query Firestore for online feature values online_features = fs.get_online_features( feature_refs=[ "driver_hourly_stats:conv_rate", "driver_hourly_stats:acc_rate" ], entity_rows=[{"driver_id": 1001}, {"driver_id": 1002}], ).to_dict() # Make a prediction model.predict(online_features)

要点：

• entity_rows是以实体 join key 为键的字典列表（driver_id来自第一步定义的 Entity）；
• 特征引用格式为feature_view_name:feature_name；
• 返回结果.to_dict()后直接作为模型输入，保证训练/服务两侧看到一致的取值路径。

当前仓库中get_online_features的签名同样演化过：特征引用参数改为features，且可以直接传入第一步定义的FeatureService对象（模板 test_workflow.py 中store.get_feature_service("driver_activity_v1")后整体传入），这是 0.10 之后引入的"按模型版本取特征"机制，与公告"ensures your models in production have a consistent view of feature data"的目标直接呼应。

总结：0.10 留下的架构遗产

把 0.10 的工作流完整走一遍是六步：pip install feast→feast init -t gcp→feast apply→get_historical_features→feast materialize-incremental→get_online_features，最后由 CI 与调度作业闭环。对照当前仓库可以确认，0.10 确立的四大设计全部保留为骨架并持续扩展：

1. Git 仓库即特征仓库：feature_store.yaml+ Python 特征定义，模板机制（templates 目录）从一个 gcp 模板扩展为覆盖各云与多种在线/离线库的模板族；
2. 声明式 apply：幂等注册元数据并供应基础设施，不搬数据，天然适配 CI；
3. 物化命令族：增量/全量物化 +--views/--version等参数，支撑"离线库 → 在线库"的持续数据流动；
4. point-in-time 正确的训练数据构建：以timestamp_field为基础的时间对齐 join，是 Feast 防止特征泄漏的核心能力。

0.10 公告"What's next"中的展望（更多数据源、流式、云 provider，以及社区贡献新存储/计算层）在今天的仓库结构中都有清晰映射：sdk/python/feast/infra/下的离线库、在线库与计算引擎目录，protos/feast/中的 registry/serving 协议，以及 Kubernetes operator（infra/feast-operator）与 Helm charts（infra/charts/feast）。对希望复现 0.10 体验的读者，直接参考 sdk/python/feast/templates/gcp/feature_repo/test_workflow.py 即可在当前版本上跑通 apply → 历史特征 → 增量物化 → 在线特征的完整闭环。

【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feast