1、实时特征存储概述

大家好，我是这次课程的主讲。今天咱们聊聊实时特征存储——这个在推荐、风控、搜索场景里绕不开的基础设施。

先问个问题：你做过特征工程吧？那你一定遇到过这种情况——模型训练时效果不错，上线后却越跑越差。为什么？
说白了，离线训练和在线推理用的特征，根本就不是同一套数据。

实时特征存储，就是来解决这个问题的。

什么是实时特征

实时特征，指的是从数据产生到特征可用，延迟在秒级甚至毫秒级的一类特征。
它跟离线特征最大的区别在于：时效性。

维度	离线特征	实时特征
计算窗口	T+1 或小时级	秒级/毫秒级
数据源	Hive/数仓	Kafka/消息队列
存储介质	HDFS/对象存储	Redis/内存KV
典型场景	用户画像、历史统计	点击序列、实时行为

举个例子。你在淘宝点了一个商品，下一秒推荐系统就要根据这个点击行为调整排序。
这个「点击」就是一个实时特征。它必须被快速写入、快速读取、快速过期。

特征存储的演进历史

我入行那会儿，特征存储还没这个概念。大家怎么做的？
训练时从 Hive 里跑 SQL 拉特征，上线时把特征逻辑硬编码到 Java 代码里。
嗯，现在听起来很原始，但当时确实这么干。

后来大家发现，离线特征和在线特征对不上。模型在离线 AUC 0.85，上线直接掉到 0.72。
查了半天，原来是离线用的特征 A 和在线用的特征 A，计算逻辑差了一个字段。

于是有了第一代特征存储——特征工程平台。把特征定义统一管理，离线在线共用一套配置。
但问题来了：实时特征怎么存？

我记得 2018 年帮一家金融公司做风控系统。他们的实时特征存在 Redis 里，key 是用户 ID，value 是 JSON 串。
每次读取都要反序列化整个 JSON，延迟高不说，还容易丢字段。
后来我们改成了结构化存储，每个特征一个 field，延迟从 15ms 降到了 2ms。

这就是第二代——实时特征存储。专门为实时特征设计的存储系统，支持高并发读写、TTL 自动过期、增量更新。

现在到了第三代，也就是我们这门课要重点讲的——实时特征状态存储。
它不光存特征值，还存特征的状态。比如一个用户的点击序列，不是存一个聚合值，而是存整个序列的状态。
这样模型可以拿到更丰富的上下文信息。

核心应用场景

实时特征存储不是银弹，但它确实在三个场景里表现突出。

推荐系统

推荐系统是实时特征存储最大的用户。
用户每一次点击、停留、加购，都是实时特征。这些特征要喂给排序模型，在几百毫秒内算出新的推荐列表。

我曾经遇到一个案例：某短视频平台的推荐系统，实时特征存储的 QPS 峰值到了 200 万。
他们用 Redis Cluster 做存储，但热点 key 问题很严重——头部用户的特征被频繁读写。
后来我们加了本地缓存 + 异步写回，才把 P99 延迟控制在 5ms 以内。

风控系统

风控对实时性的要求比推荐更苛刻。
一笔交易从发生到判定是否欺诈，通常只有 100ms 的时间窗口。
实时特征存储要在这 100ms 内完成：读取用户历史行为、计算当前行为特征、比对规则模型。

这里有个坑，我踩过。
风控场景的特征往往有很强的时效性——比如「最近 5 分钟登录次数」。
如果 TTL 设置不当，特征过期后还在被使用，就会产生误判。
我曾经因为 TTL 设成了 6 分钟而不是 5 分钟，导致一批欺诈交易被放过。
嗯，从那以后我再也不敢凭感觉设 TTL 了。

搜索系统

搜索场景的实时特征，更多体现在 query 理解和个性化排序上。
比如用户搜索「iPhone」，实时特征要能反映出他刚才浏览过「手机壳」——这就是上下文特征。

搜索的实时特征存储，对一致性要求很高。
推荐场景可以接受最终一致性，但搜索不行——用户搜完一次，下次搜同样的词，结果应该一样。
所以搜索场景的实时特征存储，通常要支持强一致性读。

本章知识体系

下面这张图，帮你快速建立本章的知识框架。

这张图把本章的核心内容串起来了。
从实时特征存储这个中心节点出发，三个应用场景各有侧重，底部是演进路线。
你想想看，是不是每个场景对实时特征的要求都不一样？

好了，第一章就到这里。我们先把概念理清楚，后面几章会深入每个技术细节。
记住一句话：实时特征存储，本质上是为时效性而生的状态管理方案。