共计 1919 个字符，预计需要花费 5 分钟才能阅读完成。

背景痛点

1. 冷启动问题：新用户或新技能缺乏历史交互数据，导致推荐结果随机性强。传统解决方案依赖内容相似度计算，但准确率受限于特征稀疏性。

   

2. 特征更新延迟：批处理模式下特征更新周期通常为 T +1，用户实时行为无法及时反馈到推荐结果中，尤其在技能热度波动大的场景下效果衰减显著。

架构对比

1. 批处理架构
2. 优点：计算资源利用率高，适合全量特征重建

3. 缺点：数据时效性差，存储开销大（需保留多历史版本）

4. 流式架构

5. 优点：特征延迟可控制在分钟级，支持实时反馈循环

6. 缺点：需要维护状态存储，Exactly-Once 语义实现成本高

7. 混合架构选型：OpenClaw 采用 Lambda 架构，批处理层保证数据一致性，速度层通过 Kafka+Spark Streaming 实现近实时特征更新。

核心实现

近线特征管道示例

from pyspark.sql import functions as F
from pyspark.sql.window import Window

# 定义滑动窗口（15 分钟聚合，5 分钟滑动）user_skill_window = Window \
    .partitionBy('user_id') \
    .orderBy(F.col('event_time').cast('timestamp')) \
    .rangeBetween(-900, 0)  # 秒为单位

df_click_stream = spark \
    .readStream \
    .format('kafka') \
    .option('kafka.bootstrap.servers', 'kafka:9092') \
    .load()

# 窗口聚合计算 CTR 特征
df_features = df_click_stream \
    .groupBy(F.window('event_time', '15 minutes', '5 minutes'),
        'user_id',
        'skill_id'
    ) \
    .agg(F.count(F.when(F.col('is_click') == 1, True)).alias('click_count'),
        F.count('*').alias('impression_count'),
        (F.count(F.when(F.col('is_click') == 1, True)) / F.count('*')).alias('ctr')
    )

特征存储方案

1. Redis 结构设计
2. Key: user:{user_id}:skill_features
3. Value: Protobuf 序列化的 FeatureMessage 对象

4. TTL: 根据业务需求设置 24-72 小时

5. Protobuf 定义示例

   message SkillFeature {
     required string skill_id = 1;
     optional float ctr = 2;
     optional int32 impression_count = 3;
     optional int32 last_click_delta = 4;  // 上次点击时间差(秒)
   }

性能考量

1. 窗口大小实验数据
   | 窗口长度 | 特征更新延迟 | CPU 占用 | 离线 AUC 差异 |
   |———-|————–|———|————-|
   | 5min | 45s | 38% | +0.002 |
   | 15min | 2.1min | 22% | -0.001 |
   | 30min | 4.8min | 15% | -0.005 |

2. 数据倾斜处理

3. 热点用户识别：df.stat.approxQuantile('user_count', [0.99], 0.01)
4. 解决方案：
   • 拆分大用户到独立分区
   • 采用 LocalJoin 替代 ShuffleJoin

避坑指南

1. 特征版本化
2. 存储路径规范：/features/v{version}/dt={date}

3. 元数据记录：

   {
     "feature_set": "user_skill_ctr",
     "schema_version": 1.2,
     "compatibility": "backward"
   }

4. AB 测试分层

5. 流量分桶：user_id.hashCode() % 1000
6. 分层策略：
   • 10% 流量用于算法快速迭代
   • 30% 流量验证长期效果
   • 60% 流量运行稳定版本

延伸思考

1. 场景迁移建议
2. 电商推荐：将 skill_id 替换为item_id，增加价格敏感度特征
3. 新闻推荐：引入 NLP 特征实时更新（如 BERT 向量）

4. 需要调整的重点：

   • 特征窗口大小（新闻推荐可能需要更短窗口）
   • 冷启动策略（电商可结合用户画像）

5. 优化方向

6. 尝试 Flink 替代 Spark Streaming 获得更低延迟
7. 评估 FeatureStore 方案（如 Feast）的统一管理能力

本文方案已在 OpenClaw 生产环境稳定运行 6 个月，线上 CTR 提升 12.7%，冷启动场景转化率提高 23%。建议读者根据自身业务特点调整窗口参数和特征组合策略。