Feast 0.18 发布解析：Snowflake 离线存储一等公民支持与数据质量监控的引入

Feast 0.18 发布解析：Snowflake 离线存储一等公民支持与数据质量监控的引入

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

Feast 0.18 是该版本周期里一次分量很重的发布：它将 Snowflake 离线存储从社区插件提升为一等公民，引入了实验性的 Saved Datasets（训练数据集持久化）与数据质量监控能力，并完成了 Python 在线服务端的 alpha 转正与多项性能优化。读完本文，你可以掌握 Feast 接入 Snowflake 作为离线存储的完整配置方式与关键参数、理解 Saved Datasets 的设计意图，以及 0.18 引入的数据质量监控如何演进为 Feast 原生的 Feature Quality Monitoring（DQM）体系。

0.18 发布概览

根据发布说明（docs/blog/feast-0-18-adds-snowflake-support-and-data-quality-monitoring.md，2022 年 2 月 14 日），Feast 0.18 的核心变更包括：

• Snowflake 离线存储：允许用户定义和使用存储在 Snowflake 中的特征；
• [实验性] Saved Datasets：允许将训练数据集持久化到离线存储中供后续复用；
• [实验性] 数据质量监控：允许用户校验训练数据，该初步集成后来被 Feast 原生的 Feature Quality Monitoring 系统取代；
• Python 特征服务端（Python feature server）从 alpha 状态转正；
• 性能改进：覆盖 on demand 特征视图、protobuf 序列化/反序列化以及 Python 特征服务端。

官方同时提示：实验性功能在收集反馈期间可能随时发生 API 变更。下面逐项展开，并结合当前仓库源码印证其落地形态。

Snowflake 离线存储成为一等公民

为什么是 0.18

在 Feast 0.18 之前，Feast 对 Google BigQuery 和 AWS Redshift 提供一等公民级别的离线存储支持，而 Snowflake、Azure、Postgres、Hive 等则以插件形式存在。0.18 将 Snowflake 提升为内置离线存储，意味着用户无需依赖外部插件即可直接使用定义在 Snowflake 中的特征表，并且该离线存储可以配合 AWS、GCP、Azure 三种 Provider 使用。

配置方式

在当前仓库中，Snowflake 离线存储的类型标识为snowflake.offline，feature_store.yaml配置示例如下（摘自 docs/reference/offline-stores/snowflake.md）：

project: my_feature_repo registry: data/registry.db provider: local offline_store: type: snowflake.offline account: snowflake_deployment.us-east-1 user: user_login password: user_password role: SYSADMIN warehouse: COMPUTE_WH database: FEAST schema: PUBLIC

启用该存储需要先安装对应依赖：pip install 'feast[snowflake]'；若使用基于文件（file-based）的 registry，还需叠加云厂商 extra，即pip install 'feast[snowflake, CLOUD]'（CLOUD为aws、gcp、azure之一）。仓库还内置了初始化模板，feast init -t snowflake生成的 feature_store.yaml 会同时给出离线存储、批计算引擎（snowflake.engine）与 Snowflake 在线存储三段的完整占位配置，可作为接入起点。

配置参数的源码级解读

从源码结构看，SnowflakeOfflineStoreConfig 定义了上述 YAML 中各字段的解析逻辑，关键参数包括：

除直接写死在 YAML 中的凭据外，源码中还实现了connection_ref级别的连接覆盖机制：SDK 在建立连接时 会检查数据源上声明的connection_ref，若提供则以account、user、password、database、warehouse、role、schema、authenticator、private_key等字段覆盖离线存储的全局配置。可以推断，这一机制主要用于多数据源分属不同 Snowflake 账号/角色的场景，避免为每张表重复配置全局连接信息。

定义数据源：SnowflakeSource

Feast 从 Snowflake 拉取特征时通过SnowflakeSource描述表或查询（docs/reference/data-sources/snowflake.md）。按表引用：

from feast import SnowflakeSource my_snowflake_source = SnowflakeSource( database="FEAST", schema="PUBLIC", table="FEATURE_TABLE", )

按查询：

my_snowflake_source = SnowflakeSource( query=""" SELECT timestamp_column AS "ts", "created", "f1", "f2" FROM `FEAST.PUBLIC.FEATURE_TABLE` """, )

从 SnowflakeSource 的构造函数 可以看到其核心约束：table与query二者必须且只能指定其一；timestamp_field是点位时间连接（point-in-time join）使用的事件时间戳字段；created_timestamp_column用于对重复行做去重（保留最新创建时间戳的行）；field_mapping则用于数据源列名到特征表列名的映射。文档同时提醒注意 Snowflake 对标识符引号的处理规则（大小写敏感、带引号的标识符等）。

功能矩阵与已知限制

根据 Snowflake 离线存储的功能矩阵，该存储完整支持点位时间正确的get_historical_features、pull_latest_from_table_or_query、pull_all_from_table_or_query（取回 Saved Dataset）、offline_write_batch（持久化 dataframe）与write_logged_features（写入服务日志特征）；其SnowflakeRetrievalJob支持导出为 dataframe / Arrow 表 / Arrow batches / SQL / 数据湖（S3、GCS 等）/ 数据仓库 / Spark dataframe，并支持将结果持久化到离线存储与执行前预览查询计划，其中「本地执行 Python on-demand 变换」为支持、「远端执行 Python on-demand 变换」暂不支持。

文档同时明确了一个实际开发中容易踩坑的限制：在 Snowflake 数据源的 SQL 查询字符串中应避免使用单引号。例如WHERE other_column = 'value'会失败，需要改用 Snowflake 的美元引号（dollar-quoted）字符串写法，如$$value$$。

[实验性] Saved Datasets：训练数据集的持久化复用

Feast 0.18 允许将get_historical_features生成的训练数据集持久化到离线存储中，供后续直接复用（pull_all_from_table_or_query）。官方给出的两类典型用途：

1. 生成校验用的参考数据集（reference dataset）——这是当时数据质量监控能力的前置依赖（见下一节）；
2. 缓存高成本点位时间连接的结果——一次 point-in-time join 计算开销可观，持久化后可避免重复计算。

这一点在 Snowflake 侧有直接对应：上文功能矩阵中persist results in the offline store与pull_all_from_table_or_query (retrieve a saved dataset)均为 yes，说明 Saved Datasets 的存取在 Snowflake 离线存储上是完整闭环的。

[实验性] 数据质量监控及其向 DQM 的演进

0.18 的初步形态

多位用户长期希望 Feast 提供校验训练/服务数据、监控训练-服务偏差（training-serving skew）的手段。Feast 0.18 给出了第一个里程碑：用户可以声明此前生成的训练数据集（即以 Saved Dataset 形式持久化的数据集）作为校验参考，用参考数据集来校验新生成的训练数据是否发生显著漂移。

博客同时明确：这一基于 Saved Datasets 的初步集成后来已被 Feast 原生的 Feature Quality Monitoring 系统取代（参见 docs/how-to-guides/feature-monitoring.md），后者提供内置指标计算、漂移检测、服务日志监控与 UI 仪表盘。

当前仓库中的演进形态：DQM 系统

当前仓库中该能力已发展为成熟的 DQM（Data Quality Monitoring）体系，见 docs/reference/dqm.md：系统会为每个已注册特征计算、存储并提供统计指标（分布、空值率、分位数、直方图等），覆盖批数据与服务日志两条链路，目标是解决数据一致性、上游管道 bug 污染在线存储、训练/服务偏差三类问题。其工作流与 0.18 时期的 Saved Dataset 方案形成对照：

1. feast apply注册特征视图；若配置auto_baseline: true，基线指标自动计算（取代了 0.18 时期手动声明参考数据集的做法）；
2. 定期执行feast monitor run计算指标，自动模式下会探测源数据最新事件时间戳，并按日、周、双周、月、季度五个时间窗口计算；
3. 通过 REST API（GET /monitoring/metrics/features?project=...&feature_view_name=...&granularity=...）或 Feast UI 读取指标。

相关命令示例：

# 自动模式（生产推荐） feast monitor run # 指定特征视图 feast monitor run --feature-view driver_stats # 显式时间范围与粒度 feast monitor run \ --feature-view driver_stats \ --start-date 2025-01-01 \ --end-date 2025-01-07 \ --granularity weekly # 手动设置基线 feast monitor run \ --feature-view driver_stats \ --start-date 2025-01-01 \ --end-date 2025-03-31 \ --granularity daily \ --set-baseline # 基于特征服务日志计算指标 feast monitor run --source-type log

配置上只需在feature_store.yaml中开启：

data_quality_monitoring: auto_baseline: true

值得注意的是，DQM 与离线存储原生集成、不要求额外基础设施；而 0.18 源码中 Snowflake 离线存储模块（snowflake.py）已导入feast.monitoring.monitoring_utils的相关工具，可以推断 Snowflake 离线存储同样接入了监控指标计算链路。

其他改进：Python 特征服务端转正与性能优化

0.18 中 Python 特征服务端（Python feature server）从 alpha 状态转正，标志着在线服务链路的稳定性承诺正式落地。性能方面，官方列举了三处显著改进：

• Python 特征服务端：切换到更高效的服务接口，吞吐得到改善；
• On demand 特征视图：优化 protobuf 序列化/反序列化逻辑带来加速；
• Datastore 实现：通过批量操作（batching）降低操作开销。

官方博客当时指向了附带的基准测试文章，说明这些优化均有量化数据支撑；本文不在此转述具体数字，读者可参考仓库中 go 服务端的基准测试相关博客 了解后续演进中 Go 服务端的性能背景。

发布后的路线图：0.18 时期的 What's Next

博客结尾披露了当时的后续计划，回顾这些条目对理解 Feast 的演进脉络很有价值：

• feast plan命令的首个里程碑（注册前的变更预览）；
• 数据质量监控的后续里程碑——即上文所述的 DQM 体系；
• 在线服务逻辑向 Golang 收敛——仓库中 go/internal/feast 目录下的 registry、onlineserving、server 等模块正是这一方向长期推进的产物；
• 社区活跃工作包括：Snowflake 作为在线存储的支持（当前仓库中已存在 sdk/python/feast/infra/online_stores/snowflake.py）以及将 Azure 插件合并进主仓库。

小结

Feast 0.18 的三条主线在今天的代码库中都能找到清晰的落地痕迹：Snowflake 一等公民支持沉淀为snowflake.offline类型的完整配置与SnowflakeSource数据源（含connection_ref级连接覆盖与数据卸载能力）；Saved Datasets 与数据质量监控则从实验性方案演进为覆盖批数据与服务日志的 DQM 指标体系；而 Go 服务端的在线服务收敛也已成为仓库的主要架构之一。对于以 Snowflake 为数仓核心的团队，feast init -t snowflake生成的模板加上述配置参数即可快速起步；对于需要保障训练数据质量的团队，则应直接使用当前的 DQM 体系而非 0.18 时期的 Saved Dataset 校验方案。

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