2. 特征工程与特征存储:离线特征与在线特征的区别、特征存储选型

特征工程是特征平台的核心环节,而特征存储则是连接离线与在线世界的桥梁。本章将深入剖析离线特征与在线特征的本质差异,并对比主流特征存储引擎的选型策略。

2.1 离线特征与在线特征:核心差异

离线特征与在线特征在计算模式、时效性、数据量级和访问模式上存在根本性区别。理解这些差异是设计特征存储架构的前提。

对比维度 离线特征 在线特征
计算模式 批量(Batch)计算,通常基于 Spark、Hive 等引擎,按天/小时调度 实时(Real-time)计算,基于 Flink、Kafka Streams 等流处理引擎,毫秒级延迟
时效性 T+1 或小时级,适用于模型训练和离线评估 秒级/毫秒级,适用于在线推理和实时决策
数据量级 PB 级,全量历史数据,用于特征回溯和样本生成 GB ~ TB 级,仅存储当前活跃特征,支持高并发点查
访问模式 全表扫描、大范围聚合、JOIN 操作 Key-Value 点查、批量 Multi-Get、高 QPS 低延迟
存储介质 HDFS、对象存储(S3/OSS)、Hive 表、Parquet/ORC 文件 内存型 KV 存储(Redis)、LSM-Tree 存储(HBase)、托管 KV 服务(DynamoDB)
一致性要求 最终一致性,允许数据延迟 强一致性或读己之写,避免特征穿越
实践要点:离线特征与在线特征之间需要建立明确的“特征映射表”,确保同一特征在离线训练和在线推理时使用相同的计算逻辑和编码方式,避免训练/推理不一致(Training-Serving Skew)。

2.2 离线特征存储:数据湖与特征回溯

离线特征通常存储在数据湖(Data Lake)中,以 Parquet/ORC 列式格式组织。特征回溯(Point-in-Time Join)是离线特征存储的核心能力,它允许模型训练时获取“特征被计算时刻”的真实值,避免未来信息泄露。

-- 特征回溯 SQL 示例:在训练样本生成时,确保特征时间戳早于标签时间戳
SELECT
    e.event_id,
    e.label,
    f.feature_value
FROM events e
LEFT JOIN feature_table f
    ON e.user_id = f.user_id
    AND f.feature_timestamp <= e.event_timestamp
    AND f.feature_timestamp >= e.event_timestamp - INTERVAL 7 DAY

2.3 在线特征存储选型:三大主流方案对比

在线特征存储需要支撑高并发、低延迟的 Key-Value 读取。Redis、HBase、DynamoDB 是三种最主流的选型,它们在架构、性能、运维成本和生态集成上各有优劣。

特性 Redis HBase DynamoDB
存储模型 内存 + 可选持久化(RDB/AOF) LSM-Tree,磁盘为主,内存缓存 托管分布式 KV + SSD 存储
读写延迟 < 1ms(纯内存) 1-10ms(依赖缓存命中率) 1-10ms(SSD 本地 + 缓存)
QPS 能力 单节点 10万+,集群可扩展 单 Region 数千,集群百万级 按 WCU/RCU 预置,可自动扩缩
数据容量 受内存限制(GB ~ 百 GB) PB 级(自动 Split) TB ~ PB 级(自动分区)
TTL 支持 原生支持,精确到秒 原生支持(列族级别) 原生支持(按表设置)
事务支持 Lua 脚本 / Redis Transactions 行级 ACID(CP 模式) 事务 API(乐观锁)
运维复杂度 低(主从/哨兵/Cluster) 高(依赖 HDFS/ZooKeeper) 无服务器(全托管)
云原生集成 自建或云托管(ElastiCache) 自建或云托管(EMR/HBase) AWS 原生,与 Lambda/SageMaker 深度集成
典型场景 实时特征缓存、用户画像、排行榜 大规模时序特征、用户行为序列 高并发在线推荐、广告 CTR 预估
选型避坑:不要将所有特征一股脑塞进 Redis。Redis 适合存储“热特征”(高频访问、小体积),对于“温特征”(低频访问、大体积)应使用 HBase 或 DynamoDB。混合存储架构(Hot/Warm Tiering)是特征平台的最佳实践。

2.4 特征存储架构图:离线与在线协同

下图展示了特征平台中离线存储与在线存储的协同关系,以及特征数据从批量计算到实时服务的流转路径。

特征平台离线与在线存储协同架构 特征平台离线与在线存储协同架构 离线批量计算 数据湖 (HDFS/S3) 特征回溯 (Point-in-Time) 实时流计算 在线特征存储 在线推理服务 特征同步管道 离线 → 在线特征映射 模型训练 模型推理 架构要点说明: 1. 离线特征通过特征同步管道(如 Canal、Kafka Connect)实时同步到在线存储 2. 在线特征存储支持 TTL 自动过期,避免冷数据堆积 3. 特征回溯确保训练样本的时间正确性,是模型质量的生命线 4. 在线推理服务通过 Multi-Get 批量获取特征,减少网络开销

2.5 特征存储选型决策树

在实际项目中,特征存储的选型需要综合考虑数据规模、延迟要求、运维能力和云环境。以下决策树可以帮助快速定位合适的存储方案。

特征存储选型决策树 特征存储选型决策树 特征存储选型 延迟 < 5ms 延迟可接受 5-20ms 内存型 KV 存储 数据量 < 100GB 数据量 > 100GB Redis Cluster Redis + 持久化 磁盘型 KV 存储 自建/私有云 公有云/AWS HBase DynamoDB 选型建议: • 高并发、低延迟场景优先选择 Redis,但需控制单 Key 大小 < 10KB • 大规模、低成本场景选择 HBase 或 DynamoDB,配合缓存层提升性能

2.6 特征存储最佳实践清单

  • 特征分层存储:将特征按访问频率分为 Hot(Redis)、Warm(HBase/DynamoDB)、Cold(数据湖)三层,降低存储成本。
  • TTL 策略:为在线特征设置合理的 TTL(如 7-30 天),避免过期特征占用存储空间和影响推理准确性。
  • 批量获取:在线推理时使用 Multi-Get 或 Batch Get 接口,减少网络往返次数,提升吞吐量。
  • 特征版本管理:在特征 Key 中嵌入版本号(如 user:click_count:v2),支持平滑迁移和回滚。
  • 监控与告警:对特征存储的延迟、QPS、缓存命中率、存储水位进行实时监控,设置告警阈值。
关键结论:离线特征存储解决的是“历史全量 + 时间回溯”问题,在线特征存储解决的是“当前活跃 + 低延迟点查”问题。两者通过特征同步管道保持一致性,共同构成特征平台的数据基座。选型时务必结合业务场景、数据规模和运维能力综合评估,避免一刀切。