Feast 0.10 发布回顾用 pip 安装与声明式 feature_store.yaml 重新定义特征仓库工作流【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feastFeast 0.102021 年 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 对此的回应可以概括为三点所有基础设施都是可选的——没有 Spark、Kubernetes 和 API 也能跑特征存储核心软件被抽成一个 Python 框架——团队通过声明式定义特征并据此在本地或云端声明式地供应provision一个特征存储入门者只需要管理一个 Git 仓库并运行 Feast CLI 或 SDK引入一等公民的本地模式——不再依赖 Docker 容器而是直接通过 pip 安装用户可以在 notebook 中从零启动一个最小特征存储基于样例数据快速开发并用与生产相同框架测试。公告同时提到 0.10 开始加入对托管服务的一等支持内置 GCP 支持其他 provider 随后跟进平台团队可以借助 serverless 技术扩展到生产负载也仍然可以把完整系统部署到 Kubernetes 上。这一从 notebook 起步、向平台扩展的思路正是当前仓库sdk/python/feast/目录组织方式providers、offline/online store、stream processor 均可插拔的历史源头。第一步创建特征仓库Feature Repository0.10 的安装方式简化为一行pip install feast然后基于 GCP 模板脚手架出一个特征仓库feast init driver_features -t gcp生成的特征仓库结构是driver_features/ └── feature_store.yaml └── driver_features.pyfeature_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三个字段各自的角色字段作用project唯一标识一个特征存储同一 registry 下多个项目由此区分registry特征定义的事实来源source of truth。0.10 的 GCP 场景下通常是 GCS 上的对象存储 registryprovider指定特征存储运行的环境。gcpprovider 会自动配置 GCP 侧基础设施对照当前仓库中 gcp 模板的实际 feature_store.yaml可以看到该机制的演化形态registry默认指向本地文件data/registry.db注释说明 GCP 上最小配置应为 GCS bucketprovider: 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(namedriver, join_keys[driver_id]) # 数据源构建训练数据集或物化时会被查询 driver_stats_source BigQuerySource( namedriver_hourly_stats_source, tablefeast-oss.demo_data.driver_hourly_stats_2, # 事件时间戳用于 point-in-time join也保证只返回 TTL 内的特征 timestamp_fieldevent_timestamp, created_timestamp_columncreated, ) # 特征视图按特征在离线/在线库中的存储方式分组 driver_stats_fv FeatureView( namedriver_hourly_stats, entities[driver], ttltimedelta(weeks52 * 10), # 示例用超长 TTL schema[ Field(nameconv_rate, dtypeFloat32), Field(nameacc_rate, dtypeFloat32), Field(nameavg_daily_trips, dtypeInt64), ], sourcedriver_stats_source, tags{team: driver_performance}, versionlatest, )几个值得注意的细节timestamp_field是 point-in-time join 的基础created_timestamp_column用于离线侧去重——这两个字段正是公告第三步用时间属性重建某一时刻特征视图的落点ttl决定特征值相对查询时刻的最大可接受年龄同时用于在线库的键驱逐并限制历史特征查询时的回溯扫描量模板在此基础上还展示了 0.10 之后加入的RequestSourceon_demand_feature_view按需在线计算特征、FeatureService把特征按模型版本分组以及PushSource向在线库推送新鲜特征——这些都是公告Whats next里解锁新运维 ML 用例方向的实际产物。第二步feast apply——声明式供应基础设施在仓库根目录执行feast applyfeast apply会把特征定义注册进 registryGCP 场景下是 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可通过vN读取、--skip-source-validation、--no-progress等说明 0.10 确立的apply 注册元数据 供应基础设施不搬数据的语义边界被完整保留。一个关键事实公告原文apply 阶段不移动任何数据——只是把特征定义元数据存入 registry并配置好基础设施。数据真正流动发生在第三步训练数据集构建与第四步物化中。第三步构建训练数据集get_historical_features公告给出的训练管线代码# Connect to the feature registry fs FeatureStore( RepoConfig( registrygs://driver-fs/, projectdriver_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_dfdriver_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-incrementalFeast 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.pyfeast 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_datedatetime.now())与 CLI 命令一一对应。公告第六步的建议——调度一个 Feast 物化作业并在 CI 中随特征定义变化更新基础设施——即把feast apply放 CI、把feast materialize-incremental放进定时调度这套运维模式至今仍是标准做法。第五步低延迟读取在线特征get_online_features在线库被物化填充后模型服务侧即可低延迟读取特征做预测。公告给出的代码# Connect to the feature store fs feast.FeatureStore( RepoConfig(registrygs://driver-fs/, projectdriver_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 确立的四大设计全部保留为骨架并持续扩展Git 仓库即特征仓库feature_store.yaml Python 特征定义模板机制templates 目录从一个 gcp 模板扩展为覆盖各云与多种在线/离线库的模板族声明式 apply幂等注册元数据并供应基础设施不搬数据天然适配 CI物化命令族增量/全量物化 --views/--version等参数支撑离线库 → 在线库的持续数据流动point-in-time 正确的训练数据构建以timestamp_field为基础的时间对齐 join是 Feast 防止特征泄漏的核心能力。0.10 公告Whats next中的展望更多数据源、流式、云 provider以及社区贡献新存储/计算层在今天的仓库结构中都有清晰映射sdk/python/feast/infra/下的离线库、在线库与计算引擎目录protos/feast/中的 registry/serving 协议以及 Kubernetes operatorinfra/feast-operator与 Helm chartsinfra/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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Feast 0.10 发布回顾：用 pip 安装与声明式 feature_store.yaml 重新定义特征仓库工作流
Feast 0.10 发布回顾用 pip 安装与声明式 feature_store.yaml 重新定义特征仓库工作流【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feastFeast 0.102021 年 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 对此的回应可以概括为三点所有基础设施都是可选的——没有 Spark、Kubernetes 和 API 也能跑特征存储核心软件被抽成一个 Python 框架——团队通过声明式定义特征并据此在本地或云端声明式地供应provision一个特征存储入门者只需要管理一个 Git 仓库并运行 Feast CLI 或 SDK引入一等公民的本地模式——不再依赖 Docker 容器而是直接通过 pip 安装用户可以在 notebook 中从零启动一个最小特征存储基于样例数据快速开发并用与生产相同框架测试。公告同时提到 0.10 开始加入对托管服务的一等支持内置 GCP 支持其他 provider 随后跟进平台团队可以借助 serverless 技术扩展到生产负载也仍然可以把完整系统部署到 Kubernetes 上。这一从 notebook 起步、向平台扩展的思路正是当前仓库sdk/python/feast/目录组织方式providers、offline/online store、stream processor 均可插拔的历史源头。第一步创建特征仓库Feature Repository0.10 的安装方式简化为一行pip install feast然后基于 GCP 模板脚手架出一个特征仓库feast init driver_features -t gcp生成的特征仓库结构是driver_features/ └── feature_store.yaml └── driver_features.pyfeature_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三个字段各自的角色字段作用project唯一标识一个特征存储同一 registry 下多个项目由此区分registry特征定义的事实来源source of truth。0.10 的 GCP 场景下通常是 GCS 上的对象存储 registryprovider指定特征存储运行的环境。gcpprovider 会自动配置 GCP 侧基础设施对照当前仓库中 gcp 模板的实际 feature_store.yaml可以看到该机制的演化形态registry默认指向本地文件data/registry.db注释说明 GCP 上最小配置应为 GCS bucketprovider: 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(namedriver, join_keys[driver_id]) # 数据源构建训练数据集或物化时会被查询 driver_stats_source BigQuerySource( namedriver_hourly_stats_source, tablefeast-oss.demo_data.driver_hourly_stats_2, # 事件时间戳用于 point-in-time join也保证只返回 TTL 内的特征 timestamp_fieldevent_timestamp, created_timestamp_columncreated, ) # 特征视图按特征在离线/在线库中的存储方式分组 driver_stats_fv FeatureView( namedriver_hourly_stats, entities[driver], ttltimedelta(weeks52 * 10), # 示例用超长 TTL schema[ Field(nameconv_rate, dtypeFloat32), Field(nameacc_rate, dtypeFloat32), Field(nameavg_daily_trips, dtypeInt64), ], sourcedriver_stats_source, tags{team: driver_performance}, versionlatest, )几个值得注意的细节timestamp_field是 point-in-time join 的基础created_timestamp_column用于离线侧去重——这两个字段正是公告第三步用时间属性重建某一时刻特征视图的落点ttl决定特征值相对查询时刻的最大可接受年龄同时用于在线库的键驱逐并限制历史特征查询时的回溯扫描量模板在此基础上还展示了 0.10 之后加入的RequestSourceon_demand_feature_view按需在线计算特征、FeatureService把特征按模型版本分组以及PushSource向在线库推送新鲜特征——这些都是公告Whats next里解锁新运维 ML 用例方向的实际产物。第二步feast apply——声明式供应基础设施在仓库根目录执行feast applyfeast apply会把特征定义注册进 registryGCP 场景下是 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可通过vN读取、--skip-source-validation、--no-progress等说明 0.10 确立的apply 注册元数据 供应基础设施不搬数据的语义边界被完整保留。一个关键事实公告原文apply 阶段不移动任何数据——只是把特征定义元数据存入 registry并配置好基础设施。数据真正流动发生在第三步训练数据集构建与第四步物化中。第三步构建训练数据集get_historical_features公告给出的训练管线代码# Connect to the feature registry fs FeatureStore( RepoConfig( registrygs://driver-fs/, projectdriver_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_dfdriver_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-incrementalFeast 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.pyfeast 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_datedatetime.now())与 CLI 命令一一对应。公告第六步的建议——调度一个 Feast 物化作业并在 CI 中随特征定义变化更新基础设施——即把feast apply放 CI、把feast materialize-incremental放进定时调度这套运维模式至今仍是标准做法。第五步低延迟读取在线特征get_online_features在线库被物化填充后模型服务侧即可低延迟读取特征做预测。公告给出的代码# Connect to the feature store fs feast.FeatureStore( RepoConfig(registrygs://driver-fs/, projectdriver_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 确立的四大设计全部保留为骨架并持续扩展Git 仓库即特征仓库feature_store.yaml Python 特征定义模板机制templates 目录从一个 gcp 模板扩展为覆盖各云与多种在线/离线库的模板族声明式 apply幂等注册元数据并供应基础设施不搬数据天然适配 CI物化命令族增量/全量物化 --views/--version等参数支撑离线库 → 在线库的持续数据流动point-in-time 正确的训练数据构建以timestamp_field为基础的时间对齐 join是 Feast 防止特征泄漏的核心能力。0.10 公告Whats next中的展望更多数据源、流式、云 provider以及社区贡献新存储/计算层在今天的仓库结构中都有清晰映射sdk/python/feast/infra/下的离线库、在线库与计算引擎目录protos/feast/中的 registry/serving 协议以及 Kubernetes operatorinfra/feast-operator与 Helm chartsinfra/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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考