拓冰网站定制 
Feast LabelView 设计解析ADR-0012 如何让可变标签成为一等公民【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feast本文基于 Feast 架构决策记录 ADR-0012状态Accepted深入讲解 LabelView 这一新原语的设计动机、Protobuf 协议、Python SDK 实现与全链路集成方式。读完本文你将理解 Feast 如何将“可变判断数据奖励信号、安全评分、人工标注”与“不可变观测特征”分离并掌握LabelView的定义、FeatureStore.push()写入、get_historical_features()联合读取、冲突策略ConflictPolicy与标注画像Annotation Profiles的完整实战用法。为什么需要 LabelView动机与问题Feast 传统上把所有数据都当作不可变、只追加append-only的特征数据来管理。这对观测型信号司机行程数、页面浏览量、嵌入向量工作得很好但对“数据是对实体的可变判断而非观测”的场景会产生四类问题标签不是特征。奖励标签、安全评分、人工标注是可变判断mutable judgments而非不可变观测。把它们混入普通FeatureView会把 append-only 与 overwrite 两种完全不同的数据生命周期混为一谈导致语义混乱、管道脆弱。多个标注者会相互矛盾。在 RLHF、安全监控、多标注者工作流中不同来源人工审核员、自动扫描器、奖励模型会独立地为同一实体写入标签。此前 Feast 没有机制追踪“哪个标注者写了什么”也无法在标注者意见冲突时进行裁决。安全系统需要反馈闭环。当 AI 安全层如 NeMo Guardrails拦截了一次有害交互时需要把负奖励数据实时写回特征存储作为再训练的反馈信号。这要求一条面向可变数据的推送式push-based实时写入路径——普通 FeatureView 并非为此设计。训练数据集需要“特征 标签”联合取回。ML 训练管道需要以 point-in-time 正确性取回特征及其对应标签。没有一等标签原语时团队只能在 Feast 之外做临时 join失去可复现性与治理。LabelView 的定位就是与 FeatureView、StreamFeatureView、OnDemandFeatureView 并列的 Feast 一等原语管理以实体为键的可变标签与标注数据通过FeatureStore.push()配合PushSource实时摄入支持可配置冲突裁决策略的多标注者工作流并无缝集成FeatureService、get_historical_features()、get_online_features()、版本化与权限系统。核心概念与职责分离ADR 定义了五个核心概念概念说明LabelView新的 Feast 一等原语BaseFeatureView的子类以实体为键管理可变标签。存放在独立的 registry 表 / proto 段中。ConflictPolicy枚举LAST_WRITE_WINS、LABELER_PRIORITY、MAJORITY_VOTE控制不同标注者的冲突标签如何裁决。离线存储读取时强制执行在线存储固定使用 LAST_WRITE_WINS。labeler_field指定的 schema 字段默认labeler标识每条标签由哪个来源写入实现多标注者溯源。reference_feature_view可选字段指向本标签视图所标注的那个FeatureView用于文档与血缘lineage说明。PushSource 集成标签通过FeatureStore.push()经PushSource摄入实时写入在线与离线两个存储。特征与标签的职责分离是理解整个设计的钥匙维度FeatureViewLabelView数据性质观测性的、不可变判断性的、可变写入模式批式或流式追加实时 push按 key 覆写或经batch_source批式导入写入方单一可信来源多个标注者物化方式feast materialize/ 增量实时走FeatureStore.push()设置batch_source时支持feast materialize冲突处理N/A单一写入方ConflictPolicyLAST_WRITE_WINS 等标注者追踪N/Alabeler_field标识来源版本化触发条件LabelView 从BaseFeatureView完整继承 Feast 特征视图版本化体系RFC-44只有 schema 级变更会触发自动版本快照仅元数据变更description、tags、owner、TTL会原地更新当前生效定义不产生新版本。类层次结构BaseFeatureView (abstract) ├── FeatureView │ ├── BatchFeatureView │ └── StreamFeatureView ├── OnDemandFeatureView └── LabelView ← 新增LabelView 从BaseFeatureView继承标准的能力name、features、projection、proto_class、版本化version、current_version_number与 schema 基础设施在其上叠加标签专属字段labeler_field、conflict_policy、reference_feature_view以及通过tags携带的标注画像元数据。Protobuf 协议LabelView.protoLabelView 的持久化模型定义在 protos/feast/core/LabelView.proto 中核心结构如下message LabelView { LabelViewSpec spec 1; LabelViewMeta meta 2; } enum ConflictResolutionPolicy { LAST_WRITE_WINS 0; LABELER_PRIORITY 1; MAJORITY_VOTE 2; } message LabelViewSpec { string name 1; string project 2; repeated string entities 3; repeated FeatureSpecV2 features 4; mapstring, string tags 5; google.protobuf.Duration ttl 6; DataSource source 7; bool online 8; string description 9; string owner 10; repeated FeatureSpecV2 entity_columns 11; string labeler_field 12; ConflictResolutionPolicy conflict_policy 13; // 早期设计中曾用于控制历史保留现已废弃 // 离线存储始终保留全部写入历史 bool retain_history 14 [deprecated true]; string reference_feature_view 15; } message LabelViewMeta { google.protobuf.Timestamp created_timestamp 1; google.protobuf.Timestamp last_updated_timestamp 2; }注意与 ADR 原文的一处细节差异ADR 设计稿中字段 14 为reserved而当前仓库的 LabelView.proto 实际保留了retain_history 14 [deprecated true]字段——注释明确其“为向后兼容线协议而保留SDK 忽略该字段”离线存储始终以 append 方式保留完整历史。Python SDK 实现LabelView 类实现位于 sdk/python/feast/labeling/label_view.py模块通过init.py 导出ConflictPolicy、LabelView与resolve_conflicts三个符号。构造函数签名为全关键字参数LabelView( name, # 唯一名称 sourceNone, # 通常为 PushSourceNone 时只能经 push() 写入 schemaNone, # Field 列表同时描述实体列与标签列 entitiesNone, # Entity 对象列表 ttltimedelta(days0), # 0 表示在线存储永不过期None 表示继承默认 TTL onlineTrue, # 是否物化到在线存储 description, tagsNone, owner, labeler_fieldlabeler, # 默认 labeler conflict_policyConflictPolicy.LAST_WRITE_WINS, reference_feature_viewNone, )从源码结构看构造函数有几个值得注意的实现细节见 label_view.py#L134-L194schema 自动拆分传入的schema中凡是与实体 join key 同名的字段自动归入entity_columns其余归入features标签列。schema 中缺失的 join key 会按实体类型或兜底String自动补齐为Field。类型一致性校验若 schema 中实体列的 dtype 与Entity.value_type推导出的类型不一致直接抛出ValueError。join key 唯一性两个实体共享同一 join key 会被拒绝A label view should not have entities that share a join key。投影标记self.projection.view_type labelView使 LabelView 在下游UI、查询路由中可被类型化识别。有效性校验ensure_valid()在基类校验之外额外要求entities非空。batch_sourcematerialize 与离线读取的桥batch_source 属性 是 LabelView 参与离线物化的关键property def batch_source(self) - Optional[DataSource]: from feast.data_source import PushSource if self.source is None: return None if isinstance(self.source, PushSource): return self.source.batch_source # 可能为 None纯 push 型 return self.source若source是PushSource返回其底层batch_source可为None即“纯 push”标签视图若source是普通DataSourceSnowflake 表、Parquet 文件、Spark 源等直接返回自身。stream_source属性则相反仅当 source 是PushSource时返回它否则返回None。这两个属性共同让 LabelView 复用离线/在线存储的全部现有代码路径。冲突策略与解析器ConflictPolicy枚举定义在 conflict_policy.py提供to_proto()/from_proto()与 proto 枚举的双向映射。其文档字符串明确限定执行范围离线存储读取pull_all_from_table_or_query、UI 端点、训练数据生成应用配置的策略在线存储无论策略如何一律 LAST_WRITE_WINS因为打标本质上是训练期问题。真正的解析逻辑在 conflict_resolver.py 的resolve_conflicts(df, join_key_columns, feature_name_columns, timestamp_field, labeler_field, conflict_policy, labeler_prioritiesNone)对包含完整历史的 DataFrame 做“每个实体 key 一行”的裁决策略实现行为LAST_WRITE_WINS按timestamp_field降序排序后对 join keydrop_duplicates(keepfirst)即保留每个实体的最新一行。LABELER_PRIORITY依据labeler_priorities从高到低排序的标注者列表计算优先级秩按优先级秩升序、时间戳降序排序取首行同一高优先级标注者写过多行时最新时间戳获胜不在优先级列表中的标注者排最低未提供labeler_priorities时回退为 LAST_WRITE_WINS。MAJORITY_VOTE按 join key 分组后对每个标签列取出现频率最高的值平票时由最新时间戳打破平局裁决行的labeler列被标记为majority_vote时间戳取组内最大值。这一实现印证了 ADR 的关键约束conflict_policy目前只在离线读取路径强制执行在线存储始终 last-write-wins。摄入路径FeatureStore.push()标签写入复用既有FeatureStore.push()API数据被路由到PushSource名称匹配的任意 FeatureView或 LabelView默认PushMode.ONLINE同时写入在线与离线两个存储——标签立即可用于服务稍后可用于训练数据集生成。ADR 指出FeatureStore内部的_fvs_for_push_source_or_raise()被扩展为在解析 PushSource 名称时遍历list_label_views()使既有 push 基础设施无需改动即可工作。import pandas as pd from feast import FeatureStore store FeatureStore(repo_pathfeature_repo/) labels_df pd.DataFrame({ interaction_id: [int-001, int-002], reward_label: [positive, negative], safety_score: [0.95, 0.12], labeler: [nemo_guardrails, nemo_guardrails], event_timestamp: pd.to_datetime([2025-01-15, 2025-01-15]), }) # 同时写入在线与离线存储 store.push(label_push_source, labels_df)语义上每次 push向离线存储追加保留全部历史并更新在线存储中该 key 的最新值——这正是冲突解析器能在离线侧看到多标注者分歧、而在线侧只拿到最新值的原因。取回路径get_historical_features() 与 FeatureServiceLabelView 通过与普通特征视图相同的代码路径参与历史取回registry 的get_any_feature_view()会与其他视图类型一起搜索 LabelView而batch_source属性为离线存储实现提供底层批源以兼容 point-in-time join。直接按特征名引用特征与标签混排一次取回training_df store.get_historical_features( entity_dfentity_df, features[ driver_hourly_stats:conv_rate, # 来自 FeatureView interaction_labels:reward_label, # 来自 LabelView interaction_labels:safety_score, # 来自 LabelView ], ).to_df()FeatureService 组合LabelView 可与普通 FeatureView 打包进一个FeatureService训练管道在一次调用中以 point-in-time 语义取回特征加标签from feast import FeatureService training_service FeatureService( nameinteraction_training_service, features[ interaction_history, # 普通 FeatureView interaction_labels, # LabelView ], ) training_df store.get_historical_features( entity_dfentity_df, featurestraining_service, ).to_df()批量回填batch_source 与 feast materialize这是 ADR 中已解决的关键设计决策LabelView 支持经batch_source的批量回填。背景金融机构等受监管行业存在大量早于实时打标管道建立的历史标签表。例如信用风险团队有一张 Snowflake/Spark 贷款违约结果表需要作为标签载入 Feast 供训练使用这类数据动辄数百万行、跨越数年放贷历史用push()循环不现实。且标签数据往往与被标注的特征数据存放在完全不同的源/表中因此 LabelView 需要自己独立的batch_source而不是借用所链接 FeatureView 的源。此类数据的标准形态是point-in-time 标签表loan_id | origination_date | as_of_date | vintage | delinquent --------|------------------|------------|----------|------------ 1 | 2026-01-01 | 2026-01-01 | 00 days | no 1 | 2026-01-01 | 2026-02-01 | 30 days | no 1 | 2026-01-01 | 2026-03-01 | 60 days | no 1 | 2026-01-01 | 2026-04-01 | 90 days | yes 2 | 2026-01-01 | 2026-01-01 | 00 days | no 2 | 2026-01-01 | 2026-02-01 | 30 days | no ...每行都是entity_key,as_of_date在某一时刻对标签的观测——恰好是feast materialize写入离线存储的形态。行为规则batch_source非空时普通DataSource直连或PushSource内嵌batch_sourcefeast materialize/feast materialize-incremental会把该 LabelView 纳入物化运行把历史标签行写入离线存储仅有PushSource而无底层batch_source的 LabelView被排除在 materialize 之外其标签只能经FeatureStore.push()到达。这一点在 feature_store.py 中得到印证materialize路径遇到纯 push 型 LabelView 会显式抛出cannot be materialized错误而teardown()路径feature_store.py#L1952会把 LabelView 一并纳入在线表清理。FeatureStore 集成点全览ADR 列出了 LabelView 集成所涉及的每个组件及改动组件改动LabelView.proto新增LabelViewSpec、LabelViewMeta与ConflictResolutionPolicy枚举RegistryServer.protoApplyFeatureViewRequestoneof 增加label_view分支Permission.protoPermissionSpec.Type枚举增加LABEL_VIEW 11Registry.proto增加repeated LabelView label_views字段base_registry.py新增抽象方法_get_label_view、_list_label_views、delete_label_viewapply_materialization类型标注registry.pyfile实现 label view CRUD、proto 构建器、删除、apply_materialization类型标注sql.py为 LabelView 增加_infer_fv_table/_infer_fv_classes、proto()构建器、类型标注remote.py增加 LabelView 的apply_feature_view分支、get/list/delete 方法snowflake.py增加LABEL_VIEWSDDL、_infer_fv_classes、delete_feature_view映射、proto()构建器registry_server.py增加 LabelView 的ApplyFeatureView与 proto 构建分支feature_store.py扩展apply()、push()、teardown()、get_historical_features()、_make_inferences()materialize 排除逻辑repo_operations.py从 repo 模块自动收集 LabelView 对象repo_contents.pyRepoContentsNamedTuple 增加label_views字段feature_service.pyfeatures列表接受 LabelViewfeast_object.pyFeastObject联合类型增加 LabelViewpermission.py_PERMISSION_TYPES映射增加LABEL_VIEWCLI新增feast label-views list与feast label-views describe命令provider.pyupdate_infra放宽为接受BaseFeatureView管理 LabelView 在线表在 feature_store.py 中可直接看到list_label_views()/get_label_view()两个 APIapply()通过isinstance(ob, LabelView)分流 LabelViewlvs_to_update注册时与 FeatureView 一并处理。注册表支持与权限四种 registry 后端全部支持 LabelView 的 apply / get / list / delete 与 proto 序列化Registry状态文件型 registry支持SQL registry支持远程 gRPC registry支持Snowflake registry支持远程 registry 通过ApplyFeatureViewRequestoneof 中专用的label_view分支完成 gRPC 传输。LabelView 同时是受权限保护的资源LABEL_VIEW类型已加入Permission.proto值 11与 Python 侧_PERMISSION_TYPES映射可套用标准 Feast RBAC 策略例如只允许安全团队写标签而不动特征from feast import Permission from feast.permissions.action import AuthzedAction from feast.labeling.label_view import LabelView label_write_permission Permission( namelabel_writers, types[LabelView], policymy_policy, actions[AuthzedAction.UPDATE], )CLI 与完整 API 面# 列出所有 label view feast label-views list # 查看某个 label view 的详情 feast label-views describe interaction_labelsPython SDK 完整用法定义 → 注册 → 写入 → 在线读 → 历史读 → 列表/获取 → 拆除from datetime import timedelta from feast import Entity, FeatureStore, Field, PushSource from feast.labeling import ConflictPolicy, LabelView from feast.types import Float32, String # 定义 interaction_labels LabelView( nameinteraction_labels, entities[interaction], ttltimedelta(days90), schema[ Field(nameinteraction_id, dtypeString), Field(namereward_label, dtypeString), Field(namesafety_score, dtypeFloat32), Field(namelabeler, dtypeString), ], sourcelabel_source, labeler_fieldlabeler, conflict_policyConflictPolicy.LAST_WRITE_WINS, reference_feature_viewinteraction_history, ) # 注册 store.apply([interaction, label_source, interaction_labels]) # 写入标签 store.push(label_push_source, labels_df) # 在线读取 store.get_online_features( features[interaction_labels:reward_label], entity_rows[{interaction_id: int-001}], ) # 历史读取训练用 store.get_historical_features( entity_dfentity_df, features[interaction_labels:reward_label], ) # 列表 / 获取 store.list_label_views() store.get_label_view(interaction_labels) # 拆除包含 label view 在线表 store.teardown()ConflictPolicy 枚举语义汇总策略行为状态LAST_WRITE_WINS最近写入的标签获胜默认离线 在线均强制LABELER_PRIORITY高优先级标注者覆盖低优先级仅离线读取强制MAJORITY_VOTE跨标注者出现频率最高的标签值获胜仅离线读取强制版本限定引用如interaction_labelsv2:reward_label对在线与历史取回均有效versionv1版本钉选同样支持。标注画像Annotation ProfilesLabelView 支持标注画像——描述 Feast UI 应“如何创建和编辑标签”的元数据。画像通过既有tags字典中的feast.io/命名空间声明无需任何 schema 或 proto 变更。设计动因不同打标任务需要截然不同的交互形态任务交互方式示例RAG 检索评估在文档中高亮文本片段标记检索 QA 的 chunk 相关性RLHF 奖励标注按实体填结构化表单评响应质量、标记安全问题批量修正在表格中编辑单元格修正自动标注器的错误主动学习标注模型选出的高价值样本先标注不确定预测与其做一个通用大表格不如让 UI 读取 tag 中的标注元数据并动态选择对应的标注组件。Tag 规范feast.io/labeling-method → 标注方法 (table | entity-form | document-span | active-learning) feast.io/field-role:field_name → 语义角色 (label | metadata | content | content_ref | span_start | span_end) feast.io/label-values:field_name → 允许的标签值逗号分隔 feast.io/label-widget:field_name → 控件类型 (enum | binary | text | number)这些 tag 由 LabelView.annotation_config 属性解析为结构化配置profile/field_roles/label_values/label_widgets并经/annotation-config/{name}REST 端点下发给 UI动态配置 Annotate 标签页。labeling_method属性在未设置 tag 时默认返回table。画像行为矩阵画像默认方法其他可用方法主动学习document-spanDocument SpanReview Edit隐藏无实体池entity-formEntity FormReview Edit、Active Learning可用active-learningActive LearningEntity Form、Review Edit主模式table默认Review EditActive Learning、Entity Form可用字段角色语义label—— 标注者主动填写的字段配合适控件enum 下拉、binary 开关、文本输入metadata—— 展示用上下文信息不是主要标注对象content/content_ref—— 片段标注的文本内容或文档引用span_start/span_end—— 文本 span 标注的字节偏移。示例配置Entity FormRLHF / 安全评审tags{ feast.io/labeling-method: entity-form, feast.io/field-role:response_quality: label, feast.io/field-role:is_safe: label, feast.io/field-role:reviewer_notes: metadata, feast.io/label-values:response_quality: excellent,good,acceptable,poor,harmful, feast.io/label-values:is_safe: 1,0, feast.io/label-widget:response_quality: enum, feast.io/label-widget:is_safe: binary, feast.io/label-widget:reviewer_notes: text, }Document SpanRAG 检索评估tags{ feast.io/labeling-method: document-span, feast.io/field-role:source_document: content_ref, feast.io/field-role:chunk_text: content, feast.io/field-role:chunk_start: span_start, feast.io/field-role:chunk_end: span_end, feast.io/field-role:relevance: label, feast.io/field-role:ground_truth: label, feast.io/label-values:relevance: relevant,irrelevant, feast.io/label-widget:relevance: binary, feast.io/label-widget:ground_truth: text, }Table批量评审 / 修正tags{ feast.io/labeling-method: table, feast.io/field-role:is_default: label, feast.io/label-values:is_default: 1,0, feast.io/label-widget:is_default: binary, }设计权衡为什么是独立原语而非扩展 FeatureView自然的质疑是今天 LabelView 的结构schema entities PushSource与一个由PushSource驱动的FeatureView几乎相同运行时代码路径push、在线读、历史 join也完全一致labeler_field与conflict_policy能否只是FeatureView上的可选字段ADR 给出了五条选择独立原语的理由语义分离比实现相似更重要。特征与标签的生命周期语义根本不同类型区分让用户与工具仅凭类型系统即可推断数据意图而不必检查可选字段来判断某个“特征视图”是否其实是标签存储。差异在数据性质不在计算时机。既有视图层次按计算何时/如何发生批、流、按需划分LabelView 的差异在数据代表什么可变判断 vs 不可变观测——这是正交轴不应重载在面向计算的层次上。类型边界利于强制执行。离线存储冲突解析器用isinstance(view, LabelView)决定批量读取时是否应用冲突裁决未来若在线存储也强制策略同一个类型检查即可干净地分支而不必在每个存储实现中散落if feature_view.conflict_policy is not None守卫。物化语义不同。纯 push 型 LabelView 没有批源可拉取须被feast materialize排除而直连DataSource的 LabelView 则完全像普通 FeatureView 一样参与物化。类型区分让物化路径能做正确判断isinstance(view, LabelView) and view.batch_source is None → skip而非在每个视图类型上散落skip_materializationTrue标志。Registry、权限、CLI 受益于类型级分离。feast label-views list比把标签混进feast feature-views list更清晰Permission区分LABEL_VIEW与FEATURE_VIEW支撑细粒度 RBAC如安全团队可写标签但不可改特征。前向兼容性LabelView 继承BaseFeatureView、使用与FeatureView相同的运行时路径与 proto 序列化模型。若社区将来决定标签应为带可选字段的FeatureView变体迁移路径平滑——设计遵循“以后合并两个类型比拆分一个类型更容易”的原则先以独立原语起步是风险更低的方向。迁移与向后兼容零破坏性变更。LabelView 完全 opt-in不影响任何既有 Feast 工作流、特征视图或配置只有用户显式定义 LabelView 时该原语才出现。无数据迁移。复用现有在线/离线存储基础设施除 registry 元数据外不需要新的存储后端或表 schema。Proto 向后兼容。新字段使用 proto3 默认值不含 LabelView 段的旧 registry proto 可正确反序列化为空的 label view 列表。物化行为不变。LabelView 默认被排除在物化路径之外不显式按名指定 LabelView 时feast materialize行为与从前完全一致。局限与未来工作局限当前行为未来方向冲突策略强制范围仅在离线存储读取训练数据、UI、批管道强制执行在线存储使用 LAST_WRITE_WINSSQL 能力后端可选在线强制历史保留离线存储保留完整写入历史append在线存储每实体仅最新值SQL 能力后端可选在线多行保留标注者优先级配置LABELER_PRIORITY经冲突解析器的labeler_priorities列表传入尚未持久化进 proto为LabelViewSpec增加labeler_priorities字段批量物化已实现直连DataSource的 LabelView 支持feast materialize纯 push 型仍只接受 pushN/A本版本已支持跨版本标签 join历史取回中跨版本 join 标签无特殊处理版本感知的标签 join保障训练可复现标签感知训练 API没有专门的get_training_dataset(features..., labels...)理解特征/标签区分的一等训练数据集 API自动切分 X/y开放问题冲突策略是否应延伸到在线存储当前仅离线读取强制训练优先设计。SQL 能力在线存储可原生实现 MAJORITY_VOTERedis 则需要应用层解析。多数打标场景只需要离线强制。历史是否需要可配置保留窗口离线存储当前无界保留历史。max_history_entries或history_ttl配置可在保障可审计性的同时约束存储。FeatureService 是否应区分特征与标签当前 FeatureService 对 LabelView 与 FeatureView 一视同仁。未来可为“标签”投影打标供下游框架使用如训练时自动切分 X/y。参考路径内容位置本 ADR 原文docs/adr/ADR-0012-label-view.md用户概念文档docs/getting-started/concepts/label-view.mdProto 定义protos/feast/core/LabelView.protoPython 模块sdk/python/feast/labeling/label_view.py、conflict_policy.py、conflict_resolver.pyFeatureStore 集成sdk/python/feast/feature_store.pyADR 索引docs/adr/README.md单位测试位于sdk/python/tests/unit/test_label_view.pyADR References 节所列。需要说明的适用前提本文所有行为描述以当前仓库代码为准其中冲突策略仅离线强制、在线始终 last-write-wins、纯 push 型 LabelView 不可 materialize 等均为当前实现的既定约束未来版本可能放宽。【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feast创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Feast LabelView 设计解析：ADR-0012 如何让可变标签成为一等公民
Feast LabelView 设计解析ADR-0012 如何让可变标签成为一等公民【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feast本文基于 Feast 架构决策记录 ADR-0012状态Accepted深入讲解 LabelView 这一新原语的设计动机、Protobuf 协议、Python SDK 实现与全链路集成方式。读完本文你将理解 Feast 如何将“可变判断数据奖励信号、安全评分、人工标注”与“不可变观测特征”分离并掌握LabelView的定义、FeatureStore.push()写入、get_historical_features()联合读取、冲突策略ConflictPolicy与标注画像Annotation Profiles的完整实战用法。为什么需要 LabelView动机与问题Feast 传统上把所有数据都当作不可变、只追加append-only的特征数据来管理。这对观测型信号司机行程数、页面浏览量、嵌入向量工作得很好但对“数据是对实体的可变判断而非观测”的场景会产生四类问题标签不是特征。奖励标签、安全评分、人工标注是可变判断mutable judgments而非不可变观测。把它们混入普通FeatureView会把 append-only 与 overwrite 两种完全不同的数据生命周期混为一谈导致语义混乱、管道脆弱。多个标注者会相互矛盾。在 RLHF、安全监控、多标注者工作流中不同来源人工审核员、自动扫描器、奖励模型会独立地为同一实体写入标签。此前 Feast 没有机制追踪“哪个标注者写了什么”也无法在标注者意见冲突时进行裁决。安全系统需要反馈闭环。当 AI 安全层如 NeMo Guardrails拦截了一次有害交互时需要把负奖励数据实时写回特征存储作为再训练的反馈信号。这要求一条面向可变数据的推送式push-based实时写入路径——普通 FeatureView 并非为此设计。训练数据集需要“特征 标签”联合取回。ML 训练管道需要以 point-in-time 正确性取回特征及其对应标签。没有一等标签原语时团队只能在 Feast 之外做临时 join失去可复现性与治理。LabelView 的定位就是与 FeatureView、StreamFeatureView、OnDemandFeatureView 并列的 Feast 一等原语管理以实体为键的可变标签与标注数据通过FeatureStore.push()配合PushSource实时摄入支持可配置冲突裁决策略的多标注者工作流并无缝集成FeatureService、get_historical_features()、get_online_features()、版本化与权限系统。核心概念与职责分离ADR 定义了五个核心概念概念说明LabelView新的 Feast 一等原语BaseFeatureView的子类以实体为键管理可变标签。存放在独立的 registry 表 / proto 段中。ConflictPolicy枚举LAST_WRITE_WINS、LABELER_PRIORITY、MAJORITY_VOTE控制不同标注者的冲突标签如何裁决。离线存储读取时强制执行在线存储固定使用 LAST_WRITE_WINS。labeler_field指定的 schema 字段默认labeler标识每条标签由哪个来源写入实现多标注者溯源。reference_feature_view可选字段指向本标签视图所标注的那个FeatureView用于文档与血缘lineage说明。PushSource 集成标签通过FeatureStore.push()经PushSource摄入实时写入在线与离线两个存储。特征与标签的职责分离是理解整个设计的钥匙维度FeatureViewLabelView数据性质观测性的、不可变判断性的、可变写入模式批式或流式追加实时 push按 key 覆写或经batch_source批式导入写入方单一可信来源多个标注者物化方式feast materialize/ 增量实时走FeatureStore.push()设置batch_source时支持feast materialize冲突处理N/A单一写入方ConflictPolicyLAST_WRITE_WINS 等标注者追踪N/Alabeler_field标识来源版本化触发条件LabelView 从BaseFeatureView完整继承 Feast 特征视图版本化体系RFC-44只有 schema 级变更会触发自动版本快照仅元数据变更description、tags、owner、TTL会原地更新当前生效定义不产生新版本。类层次结构BaseFeatureView (abstract) ├── FeatureView │ ├── BatchFeatureView │ └── StreamFeatureView ├── OnDemandFeatureView └── LabelView ← 新增LabelView 从BaseFeatureView继承标准的能力name、features、projection、proto_class、版本化version、current_version_number与 schema 基础设施在其上叠加标签专属字段labeler_field、conflict_policy、reference_feature_view以及通过tags携带的标注画像元数据。Protobuf 协议LabelView.protoLabelView 的持久化模型定义在 protos/feast/core/LabelView.proto 中核心结构如下message LabelView { LabelViewSpec spec 1; LabelViewMeta meta 2; } enum ConflictResolutionPolicy { LAST_WRITE_WINS 0; LABELER_PRIORITY 1; MAJORITY_VOTE 2; } message LabelViewSpec { string name 1; string project 2; repeated string entities 3; repeated FeatureSpecV2 features 4; mapstring, string tags 5; google.protobuf.Duration ttl 6; DataSource source 7; bool online 8; string description 9; string owner 10; repeated FeatureSpecV2 entity_columns 11; string labeler_field 12; ConflictResolutionPolicy conflict_policy 13; // 早期设计中曾用于控制历史保留现已废弃 // 离线存储始终保留全部写入历史 bool retain_history 14 [deprecated true]; string reference_feature_view 15; } message LabelViewMeta { google.protobuf.Timestamp created_timestamp 1; google.protobuf.Timestamp last_updated_timestamp 2; }注意与 ADR 原文的一处细节差异ADR 设计稿中字段 14 为reserved而当前仓库的 LabelView.proto 实际保留了retain_history 14 [deprecated true]字段——注释明确其“为向后兼容线协议而保留SDK 忽略该字段”离线存储始终以 append 方式保留完整历史。Python SDK 实现LabelView 类实现位于 sdk/python/feast/labeling/label_view.py模块通过init.py 导出ConflictPolicy、LabelView与resolve_conflicts三个符号。构造函数签名为全关键字参数LabelView( name, # 唯一名称 sourceNone, # 通常为 PushSourceNone 时只能经 push() 写入 schemaNone, # Field 列表同时描述实体列与标签列 entitiesNone, # Entity 对象列表 ttltimedelta(days0), # 0 表示在线存储永不过期None 表示继承默认 TTL onlineTrue, # 是否物化到在线存储 description, tagsNone, owner, labeler_fieldlabeler, # 默认 labeler conflict_policyConflictPolicy.LAST_WRITE_WINS, reference_feature_viewNone, )从源码结构看构造函数有几个值得注意的实现细节见 label_view.py#L134-L194schema 自动拆分传入的schema中凡是与实体 join key 同名的字段自动归入entity_columns其余归入features标签列。schema 中缺失的 join key 会按实体类型或兜底String自动补齐为Field。类型一致性校验若 schema 中实体列的 dtype 与Entity.value_type推导出的类型不一致直接抛出ValueError。join key 唯一性两个实体共享同一 join key 会被拒绝A label view should not have entities that share a join key。投影标记self.projection.view_type labelView使 LabelView 在下游UI、查询路由中可被类型化识别。有效性校验ensure_valid()在基类校验之外额外要求entities非空。batch_sourcematerialize 与离线读取的桥batch_source 属性 是 LabelView 参与离线物化的关键property def batch_source(self) - Optional[DataSource]: from feast.data_source import PushSource if self.source is None: return None if isinstance(self.source, PushSource): return self.source.batch_source # 可能为 None纯 push 型 return self.source若source是PushSource返回其底层batch_source可为None即“纯 push”标签视图若source是普通DataSourceSnowflake 表、Parquet 文件、Spark 源等直接返回自身。stream_source属性则相反仅当 source 是PushSource时返回它否则返回None。这两个属性共同让 LabelView 复用离线/在线存储的全部现有代码路径。冲突策略与解析器ConflictPolicy枚举定义在 conflict_policy.py提供to_proto()/from_proto()与 proto 枚举的双向映射。其文档字符串明确限定执行范围离线存储读取pull_all_from_table_or_query、UI 端点、训练数据生成应用配置的策略在线存储无论策略如何一律 LAST_WRITE_WINS因为打标本质上是训练期问题。真正的解析逻辑在 conflict_resolver.py 的resolve_conflicts(df, join_key_columns, feature_name_columns, timestamp_field, labeler_field, conflict_policy, labeler_prioritiesNone)对包含完整历史的 DataFrame 做“每个实体 key 一行”的裁决策略实现行为LAST_WRITE_WINS按timestamp_field降序排序后对 join keydrop_duplicates(keepfirst)即保留每个实体的最新一行。LABELER_PRIORITY依据labeler_priorities从高到低排序的标注者列表计算优先级秩按优先级秩升序、时间戳降序排序取首行同一高优先级标注者写过多行时最新时间戳获胜不在优先级列表中的标注者排最低未提供labeler_priorities时回退为 LAST_WRITE_WINS。MAJORITY_VOTE按 join key 分组后对每个标签列取出现频率最高的值平票时由最新时间戳打破平局裁决行的labeler列被标记为majority_vote时间戳取组内最大值。这一实现印证了 ADR 的关键约束conflict_policy目前只在离线读取路径强制执行在线存储始终 last-write-wins。摄入路径FeatureStore.push()标签写入复用既有FeatureStore.push()API数据被路由到PushSource名称匹配的任意 FeatureView或 LabelView默认PushMode.ONLINE同时写入在线与离线两个存储——标签立即可用于服务稍后可用于训练数据集生成。ADR 指出FeatureStore内部的_fvs_for_push_source_or_raise()被扩展为在解析 PushSource 名称时遍历list_label_views()使既有 push 基础设施无需改动即可工作。import pandas as pd from feast import FeatureStore store FeatureStore(repo_pathfeature_repo/) labels_df pd.DataFrame({ interaction_id: [int-001, int-002], reward_label: [positive, negative], safety_score: [0.95, 0.12], labeler: [nemo_guardrails, nemo_guardrails], event_timestamp: pd.to_datetime([2025-01-15, 2025-01-15]), }) # 同时写入在线与离线存储 store.push(label_push_source, labels_df)语义上每次 push向离线存储追加保留全部历史并更新在线存储中该 key 的最新值——这正是冲突解析器能在离线侧看到多标注者分歧、而在线侧只拿到最新值的原因。取回路径get_historical_features() 与 FeatureServiceLabelView 通过与普通特征视图相同的代码路径参与历史取回registry 的get_any_feature_view()会与其他视图类型一起搜索 LabelView而batch_source属性为离线存储实现提供底层批源以兼容 point-in-time join。直接按特征名引用特征与标签混排一次取回training_df store.get_historical_features( entity_dfentity_df, features[ driver_hourly_stats:conv_rate, # 来自 FeatureView interaction_labels:reward_label, # 来自 LabelView interaction_labels:safety_score, # 来自 LabelView ], ).to_df()FeatureService 组合LabelView 可与普通 FeatureView 打包进一个FeatureService训练管道在一次调用中以 point-in-time 语义取回特征加标签from feast import FeatureService training_service FeatureService( nameinteraction_training_service, features[ interaction_history, # 普通 FeatureView interaction_labels, # LabelView ], ) training_df store.get_historical_features( entity_dfentity_df, featurestraining_service, ).to_df()批量回填batch_source 与 feast materialize这是 ADR 中已解决的关键设计决策LabelView 支持经batch_source的批量回填。背景金融机构等受监管行业存在大量早于实时打标管道建立的历史标签表。例如信用风险团队有一张 Snowflake/Spark 贷款违约结果表需要作为标签载入 Feast 供训练使用这类数据动辄数百万行、跨越数年放贷历史用push()循环不现实。且标签数据往往与被标注的特征数据存放在完全不同的源/表中因此 LabelView 需要自己独立的batch_source而不是借用所链接 FeatureView 的源。此类数据的标准形态是point-in-time 标签表loan_id | origination_date | as_of_date | vintage | delinquent --------|------------------|------------|----------|------------ 1 | 2026-01-01 | 2026-01-01 | 00 days | no 1 | 2026-01-01 | 2026-02-01 | 30 days | no 1 | 2026-01-01 | 2026-03-01 | 60 days | no 1 | 2026-01-01 | 2026-04-01 | 90 days | yes 2 | 2026-01-01 | 2026-01-01 | 00 days | no 2 | 2026-01-01 | 2026-02-01 | 30 days | no ...每行都是entity_key,as_of_date在某一时刻对标签的观测——恰好是feast materialize写入离线存储的形态。行为规则batch_source非空时普通DataSource直连或PushSource内嵌batch_sourcefeast materialize/feast materialize-incremental会把该 LabelView 纳入物化运行把历史标签行写入离线存储仅有PushSource而无底层batch_source的 LabelView被排除在 materialize 之外其标签只能经FeatureStore.push()到达。这一点在 feature_store.py 中得到印证materialize路径遇到纯 push 型 LabelView 会显式抛出cannot be materialized错误而teardown()路径feature_store.py#L1952会把 LabelView 一并纳入在线表清理。FeatureStore 集成点全览ADR 列出了 LabelView 集成所涉及的每个组件及改动组件改动LabelView.proto新增LabelViewSpec、LabelViewMeta与ConflictResolutionPolicy枚举RegistryServer.protoApplyFeatureViewRequestoneof 增加label_view分支Permission.protoPermissionSpec.Type枚举增加LABEL_VIEW 11Registry.proto增加repeated LabelView label_views字段base_registry.py新增抽象方法_get_label_view、_list_label_views、delete_label_viewapply_materialization类型标注registry.pyfile实现 label view CRUD、proto 构建器、删除、apply_materialization类型标注sql.py为 LabelView 增加_infer_fv_table/_infer_fv_classes、proto()构建器、类型标注remote.py增加 LabelView 的apply_feature_view分支、get/list/delete 方法snowflake.py增加LABEL_VIEWSDDL、_infer_fv_classes、delete_feature_view映射、proto()构建器registry_server.py增加 LabelView 的ApplyFeatureView与 proto 构建分支feature_store.py扩展apply()、push()、teardown()、get_historical_features()、_make_inferences()materialize 排除逻辑repo_operations.py从 repo 模块自动收集 LabelView 对象repo_contents.pyRepoContentsNamedTuple 增加label_views字段feature_service.pyfeatures列表接受 LabelViewfeast_object.pyFeastObject联合类型增加 LabelViewpermission.py_PERMISSION_TYPES映射增加LABEL_VIEWCLI新增feast label-views list与feast label-views describe命令provider.pyupdate_infra放宽为接受BaseFeatureView管理 LabelView 在线表在 feature_store.py 中可直接看到list_label_views()/get_label_view()两个 APIapply()通过isinstance(ob, LabelView)分流 LabelViewlvs_to_update注册时与 FeatureView 一并处理。注册表支持与权限四种 registry 后端全部支持 LabelView 的 apply / get / list / delete 与 proto 序列化Registry状态文件型 registry支持SQL registry支持远程 gRPC registry支持Snowflake registry支持远程 registry 通过ApplyFeatureViewRequestoneof 中专用的label_view分支完成 gRPC 传输。LabelView 同时是受权限保护的资源LABEL_VIEW类型已加入Permission.proto值 11与 Python 侧_PERMISSION_TYPES映射可套用标准 Feast RBAC 策略例如只允许安全团队写标签而不动特征from feast import Permission from feast.permissions.action import AuthzedAction from feast.labeling.label_view import LabelView label_write_permission Permission( namelabel_writers, types[LabelView], policymy_policy, actions[AuthzedAction.UPDATE], )CLI 与完整 API 面# 列出所有 label view feast label-views list # 查看某个 label view 的详情 feast label-views describe interaction_labelsPython SDK 完整用法定义 → 注册 → 写入 → 在线读 → 历史读 → 列表/获取 → 拆除from datetime import timedelta from feast import Entity, FeatureStore, Field, PushSource from feast.labeling import ConflictPolicy, LabelView from feast.types import Float32, String # 定义 interaction_labels LabelView( nameinteraction_labels, entities[interaction], ttltimedelta(days90), schema[ Field(nameinteraction_id, dtypeString), Field(namereward_label, dtypeString), Field(namesafety_score, dtypeFloat32), Field(namelabeler, dtypeString), ], sourcelabel_source, labeler_fieldlabeler, conflict_policyConflictPolicy.LAST_WRITE_WINS, reference_feature_viewinteraction_history, ) # 注册 store.apply([interaction, label_source, interaction_labels]) # 写入标签 store.push(label_push_source, labels_df) # 在线读取 store.get_online_features( features[interaction_labels:reward_label], entity_rows[{interaction_id: int-001}], ) # 历史读取训练用 store.get_historical_features( entity_dfentity_df, features[interaction_labels:reward_label], ) # 列表 / 获取 store.list_label_views() store.get_label_view(interaction_labels) # 拆除包含 label view 在线表 store.teardown()ConflictPolicy 枚举语义汇总策略行为状态LAST_WRITE_WINS最近写入的标签获胜默认离线 在线均强制LABELER_PRIORITY高优先级标注者覆盖低优先级仅离线读取强制MAJORITY_VOTE跨标注者出现频率最高的标签值获胜仅离线读取强制版本限定引用如interaction_labelsv2:reward_label对在线与历史取回均有效versionv1版本钉选同样支持。标注画像Annotation ProfilesLabelView 支持标注画像——描述 Feast UI 应“如何创建和编辑标签”的元数据。画像通过既有tags字典中的feast.io/命名空间声明无需任何 schema 或 proto 变更。设计动因不同打标任务需要截然不同的交互形态任务交互方式示例RAG 检索评估在文档中高亮文本片段标记检索 QA 的 chunk 相关性RLHF 奖励标注按实体填结构化表单评响应质量、标记安全问题批量修正在表格中编辑单元格修正自动标注器的错误主动学习标注模型选出的高价值样本先标注不确定预测与其做一个通用大表格不如让 UI 读取 tag 中的标注元数据并动态选择对应的标注组件。Tag 规范feast.io/labeling-method → 标注方法 (table | entity-form | document-span | active-learning) feast.io/field-role:field_name → 语义角色 (label | metadata | content | content_ref | span_start | span_end) feast.io/label-values:field_name → 允许的标签值逗号分隔 feast.io/label-widget:field_name → 控件类型 (enum | binary | text | number)这些 tag 由 LabelView.annotation_config 属性解析为结构化配置profile/field_roles/label_values/label_widgets并经/annotation-config/{name}REST 端点下发给 UI动态配置 Annotate 标签页。labeling_method属性在未设置 tag 时默认返回table。画像行为矩阵画像默认方法其他可用方法主动学习document-spanDocument SpanReview Edit隐藏无实体池entity-formEntity FormReview Edit、Active Learning可用active-learningActive LearningEntity Form、Review Edit主模式table默认Review EditActive Learning、Entity Form可用字段角色语义label—— 标注者主动填写的字段配合适控件enum 下拉、binary 开关、文本输入metadata—— 展示用上下文信息不是主要标注对象content/content_ref—— 片段标注的文本内容或文档引用span_start/span_end—— 文本 span 标注的字节偏移。示例配置Entity FormRLHF / 安全评审tags{ feast.io/labeling-method: entity-form, feast.io/field-role:response_quality: label, feast.io/field-role:is_safe: label, feast.io/field-role:reviewer_notes: metadata, feast.io/label-values:response_quality: excellent,good,acceptable,poor,harmful, feast.io/label-values:is_safe: 1,0, feast.io/label-widget:response_quality: enum, feast.io/label-widget:is_safe: binary, feast.io/label-widget:reviewer_notes: text, }Document SpanRAG 检索评估tags{ feast.io/labeling-method: document-span, feast.io/field-role:source_document: content_ref, feast.io/field-role:chunk_text: content, feast.io/field-role:chunk_start: span_start, feast.io/field-role:chunk_end: span_end, feast.io/field-role:relevance: label, feast.io/field-role:ground_truth: label, feast.io/label-values:relevance: relevant,irrelevant, feast.io/label-widget:relevance: binary, feast.io/label-widget:ground_truth: text, }Table批量评审 / 修正tags{ feast.io/labeling-method: table, feast.io/field-role:is_default: label, feast.io/label-values:is_default: 1,0, feast.io/label-widget:is_default: binary, }设计权衡为什么是独立原语而非扩展 FeatureView自然的质疑是今天 LabelView 的结构schema entities PushSource与一个由PushSource驱动的FeatureView几乎相同运行时代码路径push、在线读、历史 join也完全一致labeler_field与conflict_policy能否只是FeatureView上的可选字段ADR 给出了五条选择独立原语的理由语义分离比实现相似更重要。特征与标签的生命周期语义根本不同类型区分让用户与工具仅凭类型系统即可推断数据意图而不必检查可选字段来判断某个“特征视图”是否其实是标签存储。差异在数据性质不在计算时机。既有视图层次按计算何时/如何发生批、流、按需划分LabelView 的差异在数据代表什么可变判断 vs 不可变观测——这是正交轴不应重载在面向计算的层次上。类型边界利于强制执行。离线存储冲突解析器用isinstance(view, LabelView)决定批量读取时是否应用冲突裁决未来若在线存储也强制策略同一个类型检查即可干净地分支而不必在每个存储实现中散落if feature_view.conflict_policy is not None守卫。物化语义不同。纯 push 型 LabelView 没有批源可拉取须被feast materialize排除而直连DataSource的 LabelView 则完全像普通 FeatureView 一样参与物化。类型区分让物化路径能做正确判断isinstance(view, LabelView) and view.batch_source is None → skip而非在每个视图类型上散落skip_materializationTrue标志。Registry、权限、CLI 受益于类型级分离。feast label-views list比把标签混进feast feature-views list更清晰Permission区分LABEL_VIEW与FEATURE_VIEW支撑细粒度 RBAC如安全团队可写标签但不可改特征。前向兼容性LabelView 继承BaseFeatureView、使用与FeatureView相同的运行时路径与 proto 序列化模型。若社区将来决定标签应为带可选字段的FeatureView变体迁移路径平滑——设计遵循“以后合并两个类型比拆分一个类型更容易”的原则先以独立原语起步是风险更低的方向。迁移与向后兼容零破坏性变更。LabelView 完全 opt-in不影响任何既有 Feast 工作流、特征视图或配置只有用户显式定义 LabelView 时该原语才出现。无数据迁移。复用现有在线/离线存储基础设施除 registry 元数据外不需要新的存储后端或表 schema。Proto 向后兼容。新字段使用 proto3 默认值不含 LabelView 段的旧 registry proto 可正确反序列化为空的 label view 列表。物化行为不变。LabelView 默认被排除在物化路径之外不显式按名指定 LabelView 时feast materialize行为与从前完全一致。局限与未来工作局限当前行为未来方向冲突策略强制范围仅在离线存储读取训练数据、UI、批管道强制执行在线存储使用 LAST_WRITE_WINSSQL 能力后端可选在线强制历史保留离线存储保留完整写入历史append在线存储每实体仅最新值SQL 能力后端可选在线多行保留标注者优先级配置LABELER_PRIORITY经冲突解析器的labeler_priorities列表传入尚未持久化进 proto为LabelViewSpec增加labeler_priorities字段批量物化已实现直连DataSource的 LabelView 支持feast materialize纯 push 型仍只接受 pushN/A本版本已支持跨版本标签 join历史取回中跨版本 join 标签无特殊处理版本感知的标签 join保障训练可复现标签感知训练 API没有专门的get_training_dataset(features..., labels...)理解特征/标签区分的一等训练数据集 API自动切分 X/y开放问题冲突策略是否应延伸到在线存储当前仅离线读取强制训练优先设计。SQL 能力在线存储可原生实现 MAJORITY_VOTERedis 则需要应用层解析。多数打标场景只需要离线强制。历史是否需要可配置保留窗口离线存储当前无界保留历史。max_history_entries或history_ttl配置可在保障可审计性的同时约束存储。FeatureService 是否应区分特征与标签当前 FeatureService 对 LabelView 与 FeatureView 一视同仁。未来可为“标签”投影打标供下游框架使用如训练时自动切分 X/y。参考路径内容位置本 ADR 原文docs/adr/ADR-0012-label-view.md用户概念文档docs/getting-started/concepts/label-view.mdProto 定义protos/feast/core/LabelView.protoPython 模块sdk/python/feast/labeling/label_view.py、conflict_policy.py、conflict_resolver.pyFeatureStore 集成sdk/python/feast/feature_store.pyADR 索引docs/adr/README.md单位测试位于sdk/python/tests/unit/test_label_view.pyADR References 节所列。需要说明的适用前提本文所有行为描述以当前仓库代码为准其中冲突策略仅离线强制、在线始终 last-write-wins、纯 push 型 LabelView 不可 materialize 等均为当前实现的既定约束未来版本可能放宽。【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feast创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考