1. 课程导入

在推荐、风控、搜索、广告等实时智能场景中，模型效果的上限往往不取决于算法本身，而取决于特征工程的质量与时效。一个典型的推荐系统，离线训练时使用T+1的统计特征，线上推理时却需要用户最近5分钟的点击序列；如果离线与线上特征口径不一致，模型离线AUC再高，上线后也会出现严重的效果衰减。这正是批流特征计算与Feature Store要解决的核心问题。

一、核心价值：从“特征孤岛”到“特征资产”

传统特征开发模式中，数据工程师用Hive/Spark写批处理，算法工程师用Flink/Storm写流处理，线上服务再单独维护一套Redis查询逻辑。三套代码、三套口径、三套监控，导致特征重复开发、线上线下不一致、回溯困难。Feature Store的出现，把特征从“项目附属品”升级为“可复用资产”。

其核心价值可归纳为四点：

• 一致性：同一份特征定义同时用于离线训练和线上推理，消除训练-服务偏差（Training-Serving Skew）。
• 时效性：批处理负责历史统计与回溯，流处理负责实时更新，二者在Feature Store中统一注册与读取。
• 复用性：特征一次定义、多处引用，避免每个模型重复开发用户活跃度、商品热度等通用特征。
• 可观测性：特征的血缘、版本、新鲜度、分布漂移均可监控，问题定位从“猜”变为“查”。

二、整体知识框架与实战路线图

本课程围绕“定义—计算—存储—服务—治理”五层架构展开，共30章。整体知识框架如下表所示：

实战路线图遵循“先跑通再优化”的原则：第6-11章用Spark构建离线特征管道，第12-18章用Flink构建实时特征管道，第19-23章将两者接入Feature Store并对外提供在线查询，第24-30章完成监控、治理与端到端集成。每一阶段都配有可运行的代码与配置。

三、典型场景：实时风控中的批流特征协同

以支付风控为例。离线侧，Spark每天凌晨计算用户过去30天的交易金额均值、夜间交易占比、常用设备列表，写入离线存储用于模型训练。在线侧，Flink消费Kafka中的实时交易事件，维护用户最近1分钟的交易次数、最近5分钟的设备切换次数，写入Redis供推理服务毫秒级查询。

当一笔新交易到达时，风控引擎同时读取：

# 在线特征查询示例（伪代码）
features = feature_store.get_online_features(
    entity="user_id:U10086",
    feature_refs=[
        "user_txn_amt_avg_30d",      # 离线批特征
        "user_night_txn_ratio_30d",  # 离线批特征
        "user_txn_cnt_1min",         # 实时流特征
        "user_device_switch_5min"    # 实时流特征
    ]
)
# 返回结果直接拼接为模型输入向量
model.predict(features)

这里的关键在于：user_txn_amt_avg_30d在离线训练和在线推理中必须来自同一份特征定义、同一套计算逻辑。Feature Store通过“特征视图”统一注册，批计算任务和在线查询服务引用同一个视图ID，从而保证口径一致。

四、常见误区与复盘