2. 特征存储选型：内存KV存储 vs 嵌入式存储 vs 远端存储
特征存储是模型Serving系统的数据基座，其选型直接决定特征获取的延迟、吞吐与一致性。不同存储引擎在访问模式、数据生命周期、一致性要求上存在本质差异，本章从架构视角给出系统化的对比与选型策略。
选型核心原则： 特征存储选型不是“哪个更好”，而是“哪个更适合当前场景”。延迟敏感的特征走内存，大吞吐的离线特征走远端，需要持久化与低延迟平衡的走嵌入式引擎。
2.1 三类存储引擎的架构定位
根据数据访问距离与存储介质，特征存储可分为三个层级：
- 内存KV存储（Redis / Memcached）： 纯内存、网络访问、毫秒级延迟，适合高频实时特征。
- 嵌入式存储（RocksDB）： 本地磁盘+内存缓存、进程内调用、微秒级延迟，适合中等规模、需要持久化的特征。
- 远端存储（S3 / HDFS）： 远端对象存储、百毫秒级延迟，适合大规模离线特征与模型文件。
2.2 核心维度对比
| 对比维度 | Redis / Memcached | RocksDB | S3 / HDFS |
|---|---|---|---|
| 访问延迟 | 0.1~1ms（网络RTT） | 10~100μs（进程内） | 50~500ms（远端RPC） |
| 吞吐能力 | 10万~100万 QPS | 100万~1000万 QPS | 千~万级 QPS |
| 数据持久化 | 可选（RDB/AOF） | 强（LSM-Tree + WAL） | 强（多副本） |
| 容量上限 | GB~TB（受内存限制） | GB~TB（受磁盘限制） | PB+（弹性扩展） |
| 一致性模型 | 最终/强（取决于配置） | 强（单机） | 最终（S3） / 强（HDFS） |
| 运维复杂度 | 中（需管理集群） | 低（嵌入应用） | 高（需管理存储集群） |
| 成本模型 | 高（内存昂贵） | 中（SSD适中） | 低（对象存储便宜） |
2.3 选型策略矩阵
根据特征的生命周期与访问模式，推荐以下选型策略：
选型决策流程：
- 特征是否要求亚毫秒级延迟？ → 是 → 选内存KV存储
- 特征是否需要持久化且容量较大？ → 是 → 选嵌入式存储
- 特征是否用于离线批处理或模型训练？ → 是 → 选远端存储
- 特征是否同时需要实时与离线访问？ → 采用分层混合架构
2.4 典型场景与推荐方案
| 场景 | 特征特点 | 推荐存储 | 理由 |
|---|---|---|---|
| 实时推荐特征 | 用户实时行为、上下文 | Redis | 毫秒级延迟，支持TTL自动过期 |
| 模型Embedding查找 | 大规模、只读、持久化 | RocksDB | 进程内访问，低延迟，支持大容量 |
| 离线特征批处理 | 全量数据、周期性更新 | S3 / HDFS | 低成本、高吞吐、弹性扩展 |
| 特征缓存加速 | 热点特征、短生命周期 | Memcached | 简单高效，纯缓存场景 |
| 多级特征获取 | 实时+近线+离线混合 | Redis + RocksDB + S3 | 分层缓存，兼顾延迟与成本 |
2.5 混合架构实践：三级特征获取流水线
生产环境中，单一存储引擎往往无法满足所有特征需求。推荐采用三级流水线架构：
2.6 选型避坑指南
常见误区：
- 过度依赖Redis： 所有特征都放Redis会导致内存成本爆炸，且大Key会阻塞其他请求。
- 忽略RocksDB的写放大： 频繁写入场景下，RocksDB的Compaction会消耗大量CPU和IO。
- 远端存储当实时存储用： S3的List操作延迟高，不适合在线Serving的实时特征获取。
- 缺乏缓存失效策略： 特征更新后，内存缓存未失效会导致模型拿到过期数据。
2.7 选型决策总结
| 决策条件 | 推荐存储 | 不推荐 |
|---|---|---|
| 延迟要求 < 1ms，数据量 < 100GB | Redis | S3 / HDFS |
| 延迟要求 < 1ms，数据量 100GB~1TB | RocksDB + 本地缓存 | Redis（内存成本过高） |
| 延迟容忍 10~100ms，数据量 > 1TB | S3 + 本地缓存层 | 纯Redis / 纯RocksDB |
| 需要强一致性、持久化 | RocksDB / HDFS | Memcached（无持久化） |
| 需要TTL自动过期 | Redis | RocksDB（需手动清理） |
最佳实践： 在模型Serving系统中，推荐采用“Redis（热数据）+ RocksDB（温数据）+ S3（冷数据）”的三级存储架构。通过异步预热与缓存淘汰策略，可以在延迟、成本、容量之间取得最优平衡。