Feature Store 实战：构建生产级特征生命周期管理系统

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”，结果上线后发现：训练时用的特征是 T+1 离线计算的，而线上服务调用的是实时流处理的同一指标，两者口径不一致（比如“近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_date=2024-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） 。我们强制要求注册流程包含五个不可跳过的环节：

1. 语义定义（Semantic Definition） ：必须用业务语言而非技术语言描述。错误示例：“ user_click_count_1h ：用户过去一小时点击次数”。正确示例：“ user_click_count_1h ：用户在当前会话中，从进入 APP 首页到离开 APP 的完整时间段内，所有页面元素（含广告位、商品卡片、搜索框）的点击总次数。不含后台静默心跳点击。” 这个定义直接决定了下游模型如何解释该特征。

2. 实体绑定（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) 。我们曾因允许一个特征绑定多个实体，导致在线查询时无法确定分片键，引发大量跨节点查询，延迟飙升。

3. 计算逻辑验证（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.0

CI 流水线会自动加载这些测试用例，用 Flink Local Environment 执行 SQL，比对结果。未通过测试的 PR 直接拒绝合并。

4. 数据质量规则（Data Quality Rules） ：必须定义至少一条质量规则。我们内置了四类规则：
   • null_ratio_threshold : 空值率上限（如 user_age 要求 < 0.5%）
   • distribution_drift_threshold : 与基线分布的 KL 散度阈值（如 user_total_order_amount_7d 要求 KL < 0.15）
   • value_range : 取值范围（如 user_click_count_1h 要求 [0, 1000]）
   • freshness_sla : 数据新鲜度 SLA（如 user_last_login_time 要求延迟 < 5 分钟）

这些规则会在特征计算完成后自动触发校验，并将结果写入质量仪表盘。

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 个自然日内，任意一天有至少一次登录行为的天数。自然日以 UTC+0 为准，登录行为以 login_time 字段的日期部分（YYYY-MM-DD）为准。”
• 离线实现：Spark SQL， SELECT 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 架构是三层缓存：

• L1：CPU Cache（本地内存） ：每个服务实例启动时，预热最热的 10 万个 user_id 的基础特征（如 user_gender , user_age ）。这部分数据永不淘汰，访问延迟 < 100μs。
• L2：Redis Cluster（分布式缓存） ：存储所有 user_id 的全量特征。Key 设计为 feature:{feature_name}:{entity_value} ，例如 feature:user_total_order_amount_7d:u1001 。我们用 Redis 的 HASH 结构存储一个用户的所有特征，避免多次网络往返。
• L3：TiKV（持久化存储） ：当 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 元/月以内（云资源）。

提示：不要在初期就引入 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:
  - "zhangsan@company.com"
  - "lisi@company.com"
business_stakeholders:
  - "wangwu@business.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_df=entity_df,
    features=["user_is_vip:latest"]
).to_df()

4.3 构建特征监控体系：让一切“看得见、管得住”

Feature Store 的价值不仅在于“能用”，更在于“敢用”。我们构建了三层监控：

第一层：基础设施监控（Infrastructure Monitoring）

• TiKV：Region 均衡度、Raft 延迟、磁盘 IO
• Flink：Checkpoint 成功率、背压（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 最常被质疑的问题。我们整理了一套标准化的五步排查法：

实操心得：我们把这个五步法做成了一个交互式 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 API：2ms → 正常
• Proxy 到 Redis：15ms → 异常（正常应 < 2ms）
• Redis 到 TiKV（穿透）：95ms → 异常（正常应 < 10ms）

Step 2：Redis 层分析
redis-cli --latency 显示平均延迟 15ms， redis-cli info memory 发现 mem_fragmentation_ratio = 2.8（严重内存碎片）。原因是：我们用 HASH 存储用户全量特征，但不同用户特征数量差异巨大（VIP 用户 200+ 个特征，普通用户仅 10 个），导致 Redis 内存分配不均。

解决方案 ：

• 紧急： redis-cli CONFIG SET activedefrag yes 启用主动碎片整理
• 长期：将 HASH 改为 STRING ，Key 设计为 feature:{feature_name}:{user_id} ，每个特征单独存储。虽然增加 Key 数量，但彻底解决碎片问题。改造后，Redis P99 延迟稳定在 0.8ms。

Step 3：TiKV 层分析
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 Categorization） ：

• Tier 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 Tagging） ：

• domain ： user , item , session , app
• source ： ods , dwd , dws , stream
• owner_team ： recommendation , risk_control , marketing
• quality_level ： gold （已上线模型使用）、 silver （测试中）、 bronze （仅注册，未计算）

在 Registry UI 上，用户可通过多维筛选（如 domain=user AND owner_team=recommendation AND quality_level=gold ）一键获取所有可用核心特征，避免在上千个特征中