ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

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

2026/9/16 11:49:59 拓冰建站 浏览量
Feast 0.18 发布解析:Snowflake 离线存储一等公民支持与数据质量监控的引入 Feast 0.18 发布解析Snowflake 离线存储一等公民支持与数据质量监控的引入【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feastFeast 0.18 是该版本周期里一次分量很重的发布它将 Snowflake 离线存储从社区插件提升为一等公民引入了实验性的 Saved Datasets训练数据集持久化与数据质量监控能力并完成了 Python 在线服务端的 alpha 转正与多项性能优化。读完本文你可以掌握 Feast 接入 Snowflake 作为离线存储的完整配置方式与关键参数、理解 Saved Datasets 的设计意图以及 0.18 引入的数据质量监控如何演进为 Feast 原生的 Feature Quality MonitoringDQM体系。0.18 发布概览根据发布说明docs/blog/feast-0-18-adds-snowflake-support-and-data-quality-monitoring.md2022 年 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.offlinefeature_store.yaml配置示例如下摘自 docs/reference/offline-stores/snowflake.mdproject: 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 中各字段的解析逻辑关键参数包括参数说明type固定为snowflake.offline用于选择离线存储实现accountSnowflake 部署标识符去掉.snowflakecomputing.com域名后缀user/password用户名与密码role使用的 Snowflake 角色名warehouse计算仓库warehouse名称database/schema数据库与 schemaschema 缺省为PUBLICauthenticator认证器名称支持更细粒度的认证方式private_key/private_key_content/private_key_passphrase密钥文件路径、密钥字节内容及其口令用于密钥认证config_path默认读取~/.snowsql/config允许复用已有的 snowsql 配置connection_name指向~/.snowflake/connections.toml中的连接名storage_integration_nameSnowflake 存储集成名用于数据卸载offloadblob_export_location数据卸载的目标位置S3、GCS 或 Azure Storagemax_file_size卸载文件的大小上限字节默认 1677721616 MBconvert_timestamp_columns导出时将 timestamp 列转换为 Parquet 支持的格式除直接写死在 YAML 中的凭据外源码中还实现了connection_ref级别的连接覆盖机制SDK 在建立连接时 会检查数据源上声明的connection_ref若提供则以account、user、password、database、warehouse、role、schema、authenticator、private_key等字段覆盖离线存储的全局配置。可以推断这一机制主要用于多数据源分属不同 Snowflake 账号/角色的场景避免为每张表重复配置全局连接信息。定义数据源SnowflakeSourceFeast 从 Snowflake 拉取特征时通过SnowflakeSource描述表或查询docs/reference/data-sources/snowflake.md。按表引用from feast import SnowflakeSource my_snowflake_source SnowflakeSource( databaseFEAST, schemaPUBLIC, tableFEATURE_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。官方给出的两类典型用途生成校验用的参考数据集reference dataset——这是当时数据质量监控能力的前置依赖见下一节缓存高成本点位时间连接的结果——一次 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 系统当前仓库中该能力已发展为成熟的 DQMData Quality Monitoring体系见 docs/reference/dqm.md系统会为每个已注册特征计算、存储并提供统计指标分布、空值率、分位数、直方图等覆盖批数据与服务日志两条链路目标是解决数据一致性、上游管道 bug 污染在线存储、训练/服务偏差三类问题。其工作流与 0.18 时期的 Saved Dataset 方案形成对照feast apply注册特征视图若配置auto_baseline: true基线指标自动计算取代了 0.18 时期手动声明参考数据集的做法定期执行feast monitor run计算指标自动模式下会探测源数据最新事件时间戳并按日、周、双周、月、季度五个时间窗口计算通过 REST APIGET /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 时期的 Whats 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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考