3、特征存储技术：特征存储选型、数据模型设计与TTL策略

特征存储是风控特征服务的核心基础设施，它决定了特征的读写性能、数据一致性以及运维成本。本章从存储选型、数据模型设计和生命周期管理三个维度，系统讲解风控场景下特征存储的技术要点。

3.1 特征存储选型：Redis vs HBase vs MySQL

不同存储引擎在读写性能、存储容量、数据模型和一致性方面存在显著差异。下表从风控特征服务的核心需求出发，对比三种主流存储方案：

3.2 特征数据模型设计

特征数据模型的设计直接影响查询效率和存储成本。风控场景下，特征数据通常以实体-时间-特征三维模型组织：

• 实体键（Entity Key）：用户ID、设备ID、订单ID等，作为特征查询的唯一标识。
• 时间戳（Timestamp）：特征计算或采集的时间，用于回溯和时序分析。
• 特征名（Feature Name）：特征的具体名称，如“近30天逾期次数”。
• 特征值（Feature Value）：数值、字符串、JSON等类型。

以下是一个典型的Redis Hash结构特征存储模型：

# 特征存储Key设计：{实体类型}:{实体ID}:{特征分组}
# 示例：用户ID 10086 的信用类特征
Key: "user:10086:credit"
Hash Field: "overdue_count_30d"    → Value: "3"
Hash Field: "max_delay_days_90d"   → Value: "15"
Hash Field: "credit_score"         → Value: "682"

# 设置TTL：特征7天后自动过期
EXPIRE "user:10086:credit" 604800

对于HBase，特征数据模型利用列族（Column Family）进行特征分组，时间戳由HBase自动管理：

# HBase RowKey设计：{实体类型}_{实体ID}_{时间戳倒序}
# 列族：cf（特征分组）
RowKey: "user_10086_20250315"
Column: "cf:overdue_count_30d"    → Value: "3"
Column: "cf:max_delay_days_90d"   → Value: "15"
Column: "cf:credit_score"         → Value: "682"

# 列族级TTL：保留30天
# hbase shell: alter 'feature_store', {NAME => 'cf', TTL => 2592000}

3.3 特征TTL与过期策略

特征数据具有强时效性，过期的特征不仅占用存储资源，还可能引入模型预测偏差。TTL（Time-To-Live）策略是特征存储的核心管理手段。

3.3.1 TTL策略分类

3.3.2 过期策略实现对比

• Redis被动+主动过期：访问时检查TTL（被动），后台每秒扫描20个随机Key（主动）。适合高并发场景，但大量过期Key可能短暂占用内存。
• HBase列族TTL：基于时间戳的Major Compaction时清理过期数据。适合大容量存储，但清理有延迟（默认1小时）。
• MySQL应用层过期：通过定时任务（如Cron）扫描特征表，删除或标记过期记录。适合小规模特征，但维护成本高。

3.4 特征存储架构总览

下图展示了风控特征服务中存储层的整体架构，包括数据写入、存储分层和查询路由的完整链路：

3.5 特征存储最佳实践

• 读写分离：特征写入走异步队列（如Kafka），避免写入影响查询性能；查询走缓存+DB两级架构。
• 批量获取：风控决策通常需要一次获取数十个特征，使用Redis的HMGET或HBase的MultiGet减少网络开销。
• 特征预热：在模型上线前，将高频特征预加载到Redis，避免冷启动时的缓存穿透。
• 监控告警：监控特征存储的QPS、延迟、命中率和TTL过期比例，设置阈值告警。