1. 项目概述 Feature Store 不是“新玩具”而是 MLOps 流水线里那台被长期忽略的数控机床你有没有遇到过这样的场景模型在实验室里 AUC 0.92一上线就掉到 0.78特征工程代码在训练脚本里写得密不透风但线上推理服务却用着另一套硬编码的逻辑数据科学家反复向工程师要“昨天用户点击率”这个字段而工程师翻遍三个数据库、两个数仓表、一个 Kafka 主题最后发现它其实藏在凌晨三点跑完的一张临时宽表里——还只保留 48 小时。这些不是偶然故障而是 MLOps 落地过程中最典型的“特征失同步”症状。Feature Store这个词最近两年高频出现在技术大会和架构图里但它绝不是又一个为融资故事准备的 buzzword。在我过去三年深度参与的 7 个中大型企业级机器学习平台建设项目中Feature Store 是唯一一个上线后能直接让模型迭代周期从“周级”压缩到“天级”、让特征复用率从不足 15% 提升至 63%、并让线上模型特征漂移告警响应时间从平均 17 小时缩短至 22 分钟的核心基础设施。它解决的不是“能不能做”的问题而是“能不能稳、能不能快、能不能准”的问题。简单说Feature Store 就是把特征当成“产品”来管理——有版本、有血缘、有测试、有发布、有下线而不是散落在 Jupyter Notebook、SQL 脚本、Python 函数和配置文件里的“一次性代码”。它面向三类人数据科学家需要可复用、可追溯的特征机器学习工程师需要低延迟、高一致性的特征服务数据平台团队需要统一治理、可观测、可审计的数据资产。如果你还在手动 copy-paste 特征逻辑、靠 Excel 维护特征字典、或用 Redis 缓存临时特征值那么这篇内容就是为你写的——它不讲概念只讲怎么在真实生产环境里把它跑起来、管住、用熟。2. 核心设计思路拆解为什么 Feature Store 不是“特征缓存”而是一套完整的特征生命周期操作系统2.1 从“缓存思维”到“产品思维”的根本转向很多团队第一次接触 Feature Store第一反应是“这不就是个带版本号的 Redis 吗”这种理解偏差会直接导致项目失败。我见过某电商公司花三个月搭了个基于 Redis 的“轻量版 Feature Store”结果上线后发现训练时用的特征是 T1 离线计算的而线上服务调用的是实时流处理的同一指标两者口径不一致比如“近7日下单金额”在离线侧按订单创建时间统计在实时侧按支付成功时间统计导致模型效果持续劣化却无法定位。问题根源在于混淆了Serving Layer服务层和Storage Layer存储层的职责。Feature Store 的核心价值不在“存得快”而在“定义得清、算得准、用得对、管得住”。真正的 Feature Store 架构必须包含四个不可分割的模块Feature Registry特征注册中心这是它的“心脏”。它不是简单的元数据表而是一个强约束的 Schema 管理系统。每个特征必须明确定义名称、数据类型、描述、所属实体如 user_id, item_id、计算逻辑SQL 或 Python UDF、依赖的原始数据源、更新频率batch/hourly/realtime、数据质量规则如空值率阈值、分布偏移检测阈值。我们曾强制要求所有特征注册时必须填写“业务负责人”和“技术负责人”字段上线后发现 40% 的特征因负责人离职或转岗而长期无人维护这套机制直接推动了跨部门 SLA 协议的签署。Feature Computation Engine特征计算引擎这是它的“肌肉”。它必须同时支持批处理Spark/Flink Batch和流处理Flink/Kafka Streams且保证同一特征在两种模式下的计算逻辑完全一致。我们采用 Flink SQL 作为统一计算语言所有特征逻辑都写成标准 SQL 视图并通过 CI/CD 流水线自动部署到离线和实时两个执行环境。关键技巧是在 SQL 中显式声明-- feature: user_total_order_amount_7d这样的注释让注册中心能自动解析依赖关系。Online Store在线存储这是它的“神经末梢”。它必须满足毫秒级 P99 延迟通常 10ms、高并发 10K QPS、强一致性读写不脏。我们淘汰了早期用 Cassandra 的方案最终选择 TiKV 自研 Proxy 的组合TiKV 提供分布式事务和强一致性Proxy 层实现特征键的智能路由如 user_id 哈希分片、批量聚合一次请求拉取 user_id item_id 的联合特征、以及熔断降级当 TiKV 延迟升高时自动 fallback 到本地 LRU Cache 并返回 stale 数据比报错更友好。Offline Store离线存储这是它的“记忆中枢”。它不追求速度而追求容量、成本和分析能力。我们用 Iceberg 表格式构建湖仓一体的离线存储所有特征以 Parquet 文件形式按feature_name/partition_date2024-06-01的路径组织。Iceberg 的 Snapshot 机制天然支持特征版本回溯——比如你想复现 3 月 15 日上线的模型所用的全部特征只需指定对应时间点的 Snapshot ID就能精确读取当时所有特征的值无需人工拼凑历史表。提示不要试图用一个数据库同时承担 Online Store 和 Offline Store 的角色。我们曾用 PostgreSQL 兼顾两者结果发现当离线任务大量写入时线上查询延迟飙升而当线上流量高峰时离线任务又频繁超时。物理隔离是稳定性的底线。2.2 “特征即代码”Feature-as-Code让特征开发像写微服务一样规范Feature Store 的最大文化冲击是把特征开发从“数据探索”转变为“软件工程”。在传统模式下一个特征可能诞生于数据科学家的 Jupyter Notebook经过几轮修改后变成一段 SQL再被复制进 Airflow DAG最后由工程师封装成 API。整个过程没有版本控制、没有单元测试、没有接口契约。Feature Store 强制推行Feature-as-Code实践所有特征定义包括 SQL 逻辑、Python UDF、Schema 描述都存放在 Git 仓库中与业务代码同库同分支。每次 PR 都触发自动化流水线先进行 SQL 语法检查用 sqlfluff、再在沙箱环境执行单元测试验证计算逻辑是否符合预期例如user_total_order_amount_7d在用户无订单时应返回 0 而非 NULL、最后进行集成测试模拟特征注册、计算、写入 Online Store、读取验证。我们设计了一套最小化的 Feature Definition YAML 模板# features/user_features.yaml name: user_total_order_amount_7d description: 用户近7日总下单金额人民币元含取消订单 entity: user_id dtype: double online_store: true offline_store: true batch_computation: engine: flink_sql query: | SELECT user_id, COALESCE(SUM(order_amount), 0) AS user_total_order_amount_7d FROM ods_orders WHERE order_create_time DATE_SUB(CURRENT_DATE, 7) GROUP BY user_id stream_computation: engine: flink_sql query: | SELECT user_id, SUM(order_amount) OVER (PARTITION BY user_id ORDER BY proc_time ROWS BETWEEN 6 DAYS PRECEDING AND CURRENT ROW) AS user_total_order_amount_7d FROM ods_orders_stream这个 YAML 文件就是特征的“唯一真相源”。注册中心读取它计算引擎执行它监控系统校验它。当业务方质疑“为什么这个特征值是 0”你不需要翻日志、查代码直接打开 Git 历史就能看到这个特征从 2023 年 11 月 3 日首次提交到 2024 年 2 月 17 日修复了空值 bug 的完整演进。2.3 为什么必须放弃“单体式”Feature Store拥抱分层架构市面上有开源方案Feast、Hopsworks、云厂商托管服务AWS SageMaker Feature Store、GCP Vertex AI Feature Store、以及自研方案。我们做过详细对比结论很明确没有银弹只有适配。某金融客户曾采购某云厂商的全托管 Feature Store结果发现其 Online Store 仅支持 key-value 查询无法满足他们“根据用户画像标签圈选人群”的复杂 OLAP 需求最终不得不在上面再叠一层 Presto。这违背了 Feature Store 降低复杂度的初衷。我们的推荐架构是“分层解耦按需组合”Registry 层必须自研或深度定制。因为它是治理核心需要与公司内部的权限系统如 LDAP/OAuth2、数据目录如 Atlas、监控告警如 Prometheus深度集成。我们基于 Spring Boot 开发了一个轻量 Registry 服务API 完全兼容 Feast 的 OpenAPI 规范确保上层工具链无缝迁移。Computation 层优先复用现有大数据引擎。如果公司已大规模使用 Flink就不要为了 Feature Store 引入 Spark如果已有成熟的 Spark SQL 平台就用 Delta Lake Spark 3.3 的 AQE 优化器。关键是保证计算逻辑的“一次编写多处运行”。Store 层Online Store 选型看延迟和一致性要求Offline Store 选型看成本和生态兼容性。我们给不同业务线提供“菜单式”选项电商核心交易特征用 TiKV风控实时特征用 Redis Cluster牺牲部分一致性换取极致性能用户行为宽表用 Iceberg on S3。这种分层架构让我们在 6 个月内完成了从零到支撑日均 2.3B 次特征查询的落地而总投入人力仅为 3 名工程师1 后端、1 大数据、1 SRE。3. 核心细节解析与实操要点从注册一个特征到服务一个模型的完整闭环3.1 特征注册不是填表而是签订一份数据契约在 Feature Store 中“注册一个特征”远比在 Excel 里新增一行记录严肃得多。它本质上是在数据团队、算法团队、业务方之间签订一份数据契约Data Contract。我们强制要求注册流程包含五个不可跳过的环节语义定义Semantic Definition必须用业务语言而非技术语言描述。错误示例“user_click_count_1h用户过去一小时点击次数”。正确示例“user_click_count_1h用户在当前会话中从进入 APP 首页到离开 APP 的完整时间段内所有页面元素含广告位、商品卡片、搜索框的点击总次数。不含后台静默心跳点击。” 这个定义直接决定了下游模型如何解释该特征。实体绑定Entity Binding明确该特征属于哪个业务实体。常见实体有user_id,item_id,order_id,session_id。关键规则是一个特征只能绑定一个主实体。例如user_avg_order_amount_30d的主实体是user_id不能同时绑定item_id。如果需要“用户对某商品的偏好分”应该定义为user_item_preference_score主实体是复合键(user_id, item_id)。我们曾因允许一个特征绑定多个实体导致在线查询时无法确定分片键引发大量跨节点查询延迟飙升。计算逻辑验证Computation Logic Validation注册前必须提供可执行的验证用例。我们要求每个特征 YAML 必须附带test_cases字段test_cases: - input: ods_orders: - {user_id: u1001, order_amount: 150.0, order_create_time: 2024-06-01 10:00:00} - {user_id: u1001, order_amount: 80.0, order_create_time: 2024-06-01 14:00:00} expected: u1001: 230.0CI 流水线会自动加载这些测试用例用 Flink Local Environment 执行 SQL比对结果。未通过测试的 PR 直接拒绝合并。数据质量规则Data Quality Rules必须定义至少一条质量规则。我们内置了四类规则null_ratio_threshold: 空值率上限如user_age要求 0.5%distribution_drift_threshold: 与基线分布的 KL 散度阈值如user_total_order_amount_7d要求 KL 0.15value_range: 取值范围如user_click_count_1h要求 [0, 1000]freshness_sla: 数据新鲜度 SLA如user_last_login_time要求延迟 5 分钟这些规则会在特征计算完成后自动触发校验并将结果写入质量仪表盘。权限与生命周期Permissions Lifecycle注册时必须指定owners: 至少 2 名技术负责人避免单点故障business_stakeholders: 业务方联系人用于变更通知retention_days: 数据保留天数默认 90 天敏感特征可设为 30 天deprecation_date: 计划下线日期如业务下线、指标废弃注意我们禁止“永久有效”的特征。所有特征必须有明确的deprecation_date到期前 30 天自动邮件提醒负责人。上线半年后我们清理了 237 个无人认领的“僵尸特征”释放了 1.2TB 存储空间。3.2 特征计算批流一体的陷阱与避坑指南批流一体Lambda Architecture是 Feature Store 的理想状态但落地时充满陷阱。我们踩过最深的坑是“语义一致性”。案例还原特征user_active_days_30d定义为“用户过去 30 天内有登录行为的天数”。离线计算Spark每天凌晨 2 点跑一次扫描ods_user_login_log表中login_time 2024-05-02的所有记录去重date(login_time)后计数。实时计算Flink用TUMBLING WINDOW (30 DAYS)窗口内对user_id去重计数。表面看逻辑一致但上线后发现离线值普遍比实时值高 1-2 天。根因是Flink 的TUMBLING WINDOW是基于事件时间event time的而login_time字段在 Kafka 中存在最多 3 分钟的乱序。Flink 为处理乱序设置了 5 分钟的allowedLateness导致某些本该属于昨天的登录事件被计入了今天的窗口。而 Spark 扫描的是已落库的、时间戳已修正的ods_user_login_log表不存在乱序问题。解决方案我们彻底放弃了“用同一套 SQL 逻辑跑批流”的天真想法改为“逻辑统一实现分离”定义一个Canonical Logic规范逻辑用自然语言和伪代码描述例如“统计用户在过去 30 个自然日内任意一天有至少一次登录行为的天数。自然日以 UTC0 为准登录行为以login_time字段的日期部分YYYY-MM-DD为准。”离线实现Spark SQLSELECT COUNT(DISTINCT TO_DATE(login_time)) ... WHERE login_time DATE_SUB(CURRENT_DATE, 30)实时实现Flink SQL先用WATERMARK FOR login_time AS login_time - INTERVAL 5 MINUTES处理乱序再用TUMBLING WINDOW (30 DAYS)但窗口内不直接计数而是先生成user_id, login_date的明细流再用GROUP BY user_id, login_date去重最后COUNT(DISTINCT login_date)。这个方案增加了实时侧的计算复杂度但换来了绝对的语义一致性。我们在监控大盘上并列展示离线值、实时值、两者的差值任何超过 0.5% 的偏差都会触发告警。3.3 在线服务如何让特征查询快如闪电稳如磐石Online Store 是用户感知 Feature Store 价值的第一触点。我们设定的硬性 SLA 是P99 延迟 ≤ 8ms可用性 ≥ 99.99%。达成这一目标的关键不在“堆硬件”而在“分层缓存 智能降级 精准限流”。我们的 Online Store 架构是三层缓存L1CPU Cache本地内存每个服务实例启动时预热最热的 10 万个user_id的基础特征如user_gender,user_age。这部分数据永不淘汰访问延迟 100μs。L2Redis Cluster分布式缓存存储所有user_id的全量特征。Key 设计为feature:{feature_name}:{entity_value}例如feature:user_total_order_amount_7d:u1001。我们用 Redis 的HASH结构存储一个用户的所有特征避免多次网络往返。L3TiKV持久化存储当 Redis 缓存未命中时穿透查询 TiKV。TiKV 的 Region 分片基于entity_value的哈希值确保查询能精准路由到目标节点。智能降级策略这才是稳定性的灵魂当 TiKV P99 延迟 50ms 时自动开启stale-read模式从 Redis 读取可能过期最多 5 分钟但确定存在的数据同时异步刷新 TiKV。当 Redis 整体命中率 80% 时触发bulk-load从 TiKV 批量拉取热点user_id的特征预热到 Redis。当单个user_id的查询连续失败 3 次自动标记为blacklisted后续请求直接返回预设的默认值如user_total_order_amount_7d 0并告警。精准限流 我们不用全局 QPS 限流而是基于“实体维度”限流。例如对user_id限流单个user_id每秒最多 100 次查询防爬虫。对feature_name限流user_total_order_amount_7d这个特征每秒最多 5000 次查询防突发流量打垮 TiKV。对client_ip限流单个 IP 每分钟最多 1000 次查询防恶意探测。这套策略让我们在一次 TiKV 集群网络分区事故中将服务降级影响控制在 0.3% 的请求上且未产生任何业务投诉。4. 实操过程与核心环节实现手把手搭建一个生产级 Feature Store以电商场景为例4.1 环境准备与工具链选型我们选择“最小可行架构”启动避免过度设计。整个搭建过程可在 3 天内完成成本控制在 5000 元/月以内云资源。组件选型理由配置示例Registry自研 Spring Boot 服务需要深度集成公司权限系统开源方案扩展性不足2C4G × 2 实例Nginx 负载均衡ComputationApache Flink 1.17 (Standalone)批流一体成熟SQL 支持好运维成本低于 Spark StreamingJobManager: 2C4G × 1, TaskManager: 4C16G × 3Online StoreTiKV 6.5 自研 Proxy强一致性 高性能 可观测性比 Cassandra 更易运维TiKV: 4C16G × 3, PD: 2C4G × 3, Proxy: 4C8G × 2Offline StoreAWS S3 Apache Iceberg 1.3成本最低无限扩展与 Athena 无缝集成S3 存储桶Iceberg 表格式Glue Data Catalog提示不要在初期就引入 Kubernetes。Flink Standalone 和 TiKV 的静态部署足够稳定且调试更直观。我们直到 Feature Store 支撑日均 500M 查询后才迁移到 K8s。4.2 注册第一个特征user_is_vip这是最简单的特征却是验证整个流程的“Hello World”。步骤 1编写 Feature Definition YAML# features/user_is_vip.yaml name: user_is_vip description: 用户是否为 VIP 会员1是0否 entity: user_id dtype: int online_store: true offline_store: true batch_computation: engine: flink_sql query: | SELECT user_id, CASE WHEN vip_expire_time CURRENT_DATE THEN 1 ELSE 0 END AS user_is_vip FROM ods_user_profile stream_computation: engine: flink_sql query: | SELECT user_id, CASE WHEN vip_expire_time CURRENT_DATE THEN 1 ELSE 0 END AS user_is_vip FROM ods_user_profile_stream test_cases: - input: ods_user_profile: - {user_id: u1001, vip_expire_time: 2024-12-31} - {user_id: u1002, vip_expire_time: 2023-06-01} expected: u1001: 1 u1002: 0 data_quality_rules: - type: null_ratio_threshold threshold: 0.01 - type: value_range min: 0 max: 1 owners: - zhangsancompany.com - lisicompany.com business_stakeholders: - wangwubusiness.com retention_days: 90 deprecation_date: 2025-06-01步骤 2提交 PR 并触发 CI将 YAML 文件提交到feature-store-registry仓库的main分支。CI 流水线自动执行sqlfluff检查 SQL 语法启动 Flink Local Environment加载测试用例执行 SQL比对结果生成 OpenAPI 文档更新 Swagger UI步骤 3手动触发首次计算通过 Registry 的 Web UI 或 CLI 工具手动触发user_is_vip的首次批计算# 使用我们自研的 feast-cli 工具 feast-cli apply --feature user_is_vip --mode batch --start-date 2024-01-01 --end-date 2024-06-01该命令会在 Flink JobManager 上提交一个批处理作业作业读取ods_user_profile表Parquet 格式位于 S3计算结果写入 Iceberg 表feature_store.offline.user_is_vip同时将最新快照写入 TiKV 的feature:user_is_vip:*Key 空间步骤 4验证在线查询用 curl 测试在线服务curl -X POST http://feature-proxy.company.com/get-features \ -H Content-Type: application/json \ -d { features: [user_is_vip], entities: [{user_id: u1001}] } # 返回: {user_id:u1001,user_is_vip:1}步骤 5接入模型训练在 PyTorch 训练脚本中用 Feast SDK 替换原来的 Pandas 读取# 旧方式硬编码路径 # df pd.read_parquet(s3://bucket/features/user_is_vip.parquet) # 新方式Feature Store from feast import FeatureStore store FeatureStore(repo_path/path/to/feature-repo) entity_df pd.DataFrame({user_id: [u1001, u1002]}) training_df store.get_historical_features( entity_dfentity_df, features[user_is_vip:latest] ).to_df()4.3 构建特征监控体系让一切“看得见、管得住”Feature Store 的价值不仅在于“能用”更在于“敢用”。我们构建了三层监控第一层基础设施监控Infrastructure MonitoringTiKVRegion 均衡度、Raft 延迟、磁盘 IOFlinkCheckpoint 成功率、背压Back Pressure状态、TaskManager 内存使用率Redis命中率、内存碎片率、连接数工具Prometheus Grafana所有指标接入公司统一告警平台。第二层特征管道监控Pipeline Monitoring每个特征的计算延迟从上游数据就绪到写入 Store 的耗时每个特征的 SLA 达成率如user_is_vip要求每日 2 点前完成计算达成率 99.5% 告警每个特征的血缘图谱谁在用上游依赖哪些表下游影响哪些模型工具自研 Pipeline Dashboard数据来自 Flink Metrics 和 Registry API。第三层特征数据质量监控Data Quality Monitoring每个特征的空值率、分布偏移KL 散度、值域越界次数、新鲜度延迟关键特征的“健康分”Health Score综合以上指标0-100 分 60 分标红工具PySpark Great Expectations结果写入 Iceberg 表Dashboard 实时渲染。我们设置了一个“特征健康日报”机器人每天上午 9 点自动发送 Slack 消息列出健康分 60 的特征 Top 5昨日新增的异常告警如user_is_vip空值率突增至 5%即将到期的deprecation_date特征列表这个日报让数据科学家和工程师养成了每天晨会快速对齐特征状态的习惯问题平均发现时间从 12 小时缩短至 15 分钟。5. 常见问题与排查技巧实录那些文档里不会写的实战经验5.1 “特征值对不上”训练与线上不一致的终极排查手册这是 Feature Store 最常被质疑的问题。我们整理了一套标准化的五步排查法步骤操作工具/命令预期结果常见原因1. 确认时间点查看训练时使用的特征快照 ID 和线上查询的时间戳feast-cli get-historical-features --snapshot-id xxxcurl -v http://proxy/...两者时间点应一致如都是 2024-06-01 10:00:00训练用了旧快照线上用了新数据2. 确认实体值检查训练时entity_df中的user_id和线上请求的user_id是否完全一致注意大小写、前后空格、编码echo u1001hexdump -CbrSELECT LENGTH(user_id) FROM ... WHERE user_id u1001二进制完全相同3. 确认计算逻辑获取训练和线上各自执行的 SQL 逻辑feast-cli get-feature-definition --name user_is_vipkubectl logs flink-jobmanagergrep user_is_vip两条 SQL 应完全一致4. 确认数据源检查训练和线上各自读取的原始数据表是否为同一份DESCRIBE FORMATTED ods_user_profileDESCRIBE FORMATTED ods_user_profile_streamLocation字段应指向同一 S3 路径或 Kafka Topic离线表和实时表是两个独立数据源未做对齐5. 确认存储状态检查 Online Store 中该user_id的特征值是否与 Offline Store 中对应快照的值一致redis-cli GET feature:user_is_vip:u1001spark-sql -e SELECT * FROM feature_store.offline.user_is_vip WHERE user_idu1001 AND snapshot_idxxx两者值应相等TiKV 写入失败、Redis 同步延迟、Proxy 缓存污染实操心得我们把这个五步法做成了一个交互式 CLI 工具feast-debug。工程师只需输入user_id和feature_name工具自动执行全部五步并生成 HTML 报告。上线后此类问题的平均解决时间从 4.2 小时降至 18 分钟。5.2 “查询慢”从 100ms 到 5ms 的性能调优实战某次大促期间user_total_order_amount_7d的 P99 延迟从 8ms 飙升至 120ms。排查过程堪称教科书级Step 1定位瓶颈层用curl -w curl-format.txt测试各层耗时Registry API2ms → 正常Proxy 到 Redis15ms → 异常正常应 2msRedis 到 TiKV穿透95ms → 异常正常应 10msStep 2Redis 层分析redis-cli --latency显示平均延迟 15msredis-cli info memory发现mem_fragmentation_ratio 2.8严重内存碎片。原因是我们用HASH存储用户全量特征但不同用户特征数量差异巨大VIP 用户 200 个特征普通用户仅 10 个导致 Redis 内存分配不均。解决方案紧急redis-cli CONFIG SET activedefrag yes启用主动碎片整理长期将HASH改为STRINGKey 设计为feature:{feature_name}:{user_id}每个特征单独存储。虽然增加 Key 数量但彻底解决碎片问题。改造后Redis P99 延迟稳定在 0.8ms。Step 3TiKV 层分析tikv-ctl查看 Region 状态发现user_total_order_amount_7d的数据集中在少数几个 Region热点明显。原因是user_id的哈希分片未考虑业务分布头部用户如 u1001的订单量是长尾用户的 1000 倍导致其特征更新频次极高Region 负载不均。解决方案紧急tikv-ctl compact-cluster强制合并小 Region长期改用user_id random_suffix作为分片键例如u1001_abc123将单个用户的高热度分散到多个 Region。改造后TiKV P99 延迟从 95ms 降至 4.2ms。5.3 “特征爆炸”如何管理上千个特征而不失控随着 Feature Store 推广特征数量从最初的 23 个激增至 1247 个。我们面临“找不到、不敢删、不敢动”的困境。解决方案是“三级分类 四维标签”三级分类Tiered CategorizationTier 1核心特征直接影响核心业务指标GMV、DAU、风控通过率的特征如user_gmv_30d,user_risk_score。必须有专人维护SLA 最高。Tier 2实验特征算法团队用于 A/B 测试的新特征如user_click_embedding_v2。生命周期短默认 30 天到期自动归档。Tier 3废弃特征已下线业务对应的特征如user_pdd_coupon_used_count拼多多优惠券已下线。只读不计算3 个月后自动删除。四维标签4D Taggingdomainuser,item,session,appsourceods,dwd,dws,streamowner_teamrecommendation,risk_control,marketingquality_levelgold已上线模型使用、silver测试中、bronze仅注册未计算在 Registry UI 上用户可通过多维筛选如domainuser AND owner_teamrecommendation AND quality_levelgold一键获取所有可用核心特征避免在上千个特征中