3、反洗钱特征工程服务化：特征计算逻辑封装、特征存储(Redis/Feature Store)、特征API设计
反洗钱模型在生产环境中的实时推理依赖稳定、低延迟的特征服务。本章聚焦如何将离线挖掘的数百个特征指标封装为可复用的服务化组件，并设计高性能存储与标准API接口。
3.1 特征计算逻辑封装
特征计算逻辑封装的核心目标是将特征定义与计算引擎解耦，使业务分析师能通过配置而非代码来管理特征逻辑。
3.1.1 封装原则
- 幂等性：同一笔交易在相同时间窗口内重复计算，结果必须一致。
- 可追溯：每个特征值必须携带版本号、计算时间戳、依赖的原始字段列表。
- 无状态：计算单元不持有业务状态，所有上下文通过入参传递。
3.1.2 封装层次
| 层次 | 职责 | 技术选型 |
|---|---|---|
| 原子特征 | 单字段直接映射，如交易金额、交易时间 | JSON Path / SQL 表达式 |
| 聚合特征 | 时间窗口内统计值，如近1小时交易笔数、近7天累计金额 | Flink CEP / Spark Streaming |
| 衍生特征 | 多特征组合运算，如金额与历史均值的偏离度 | Python UDF / 规则引擎 |
| 图谱特征 | 关联网络指标，如一度联系人数量、资金环检测 | Neo4j / JanusGraph 查询 |
实践要点：将特征计算逻辑封装为独立的微服务模块，每个模块暴露 gRPC 接口，通过统一特征注册中心管理元数据。避免将特征计算逻辑硬编码在模型推理代码中。
3.2 特征存储：Redis 与 Feature Store
特征存储需要同时满足低延迟在线查询和高吞吐离线回填两种场景。生产环境通常采用分层存储架构。
3.2.1 存储选型对比
| 维度 | Redis | Feature Store (如 Feast / Tecton) |
|---|---|---|
| 延迟 | < 5ms (纯内存) | 10-50ms (含序列化) |
| 持久化 | RDB/AOF 可选 | 强一致，基于对象存储 |
| 特征回溯 | 不支持 | 支持时间旅行查询 |
| 数据治理 | 无 | 特征血缘、版本管理、监控 |
| 适用场景 | 实时特征缓存 | 特征生产、共享、训练/推理一致性 |
3.2.2 混合存储架构
推荐采用Feature Store 作为特征权威存储，Redis 作为在线推理的热缓存层。特征数据从 Feature Store 批量或实时同步至 Redis，设置 TTL 保证数据新鲜度。
# 特征写入 Redis 示例 (Python + redis-py)
import redis
import json
r = redis.Redis(host='feature-cache.aml.svc', port=6379, decode_responses=True)
# 特征键设计：entity_type:entity_id:feature_name:timestamp
feature_key = f"account:ACC10001:txn_amt_avg_1h:20250321143000"
feature_value = {
"value": 12500.75,
"version": "v2.3.1",
"computed_at": "2025-03-21T14:30:00Z"
}
r.setex(feature_key, 3600, json.dumps(feature_value)) # TTL 1小时
性能优化：使用 Redis Pipeline 批量获取特征，减少网络往返。对于高频访问的特征，采用 Hash 结构按 entity_id 聚合，降低内存开销。
3.3 特征 API 设计
特征 API 是模型服务获取特征数据的统一入口，设计需遵循高内聚、低耦合、可观测原则。
3.3.1 API 接口规范
| 接口 | 方法 | 请求参数 | 响应 |
|---|---|---|---|
| 批量特征获取 | POST /v1/features/batch | entity_ids, feature_names, timestamp | Map<entity_id, Map<feature_name, value>> |
| 单实体全量特征 | GET /v1/features/{entity_type}/{entity_id} | 无 | JSON 特征字典 |
| 特征元数据查询 | GET /v1/features/meta/{feature_name} | 无 | 特征定义、类型、依赖、版本 |
| 特征健康检查 | GET /v1/features/health | 无 | 缓存命中率、延迟P99、存储状态 |
3.3.2 降级与熔断策略
- 本地缓存兜底：当 Redis 或 Feature Store 不可用时，返回模型实例本地缓存的最近一次特征快照。
- 默认值注入：对缺失特征使用统计默认值（中位数/众数），并记录特征缺失日志。
- 熔断阈值：当特征服务 P99 延迟超过 200ms 或错误率超过 5% 时，触发熔断，直接返回降级特征集。
注意：特征 API 必须实现全链路追踪，在响应头中注入 trace_id，便于排查特征值异常或延迟抖动问题。禁止在特征 API 中执行复杂的实时计算逻辑，所有计算应在特征生产阶段完成。
3.4 特征工程服务化架构总览
下图展示了从特征生产到在线服务的完整数据流与组件关系。
3.5 特征服务部署清单
特征服务上线前需完成以下检查项，确保生产环境稳定运行。
| 检查项 | 验收标准 | 工具/方法 |
|---|---|---|
| 特征计算正确性 | 离线与在线计算结果差异 < 0.01% | 数据比对框架 (Great Expectations) |
| 缓存命中率 | Redis 热缓存命中率 > 95% | Redis INFO / Prometheus 监控 |
| API 延迟 | P99 < 50ms, P999 < 200ms | gRPC 内置 metrics / 链路追踪 |
| 降级演练 | Redis 宕机后自动切换本地缓存，业务无感 | Chaos Engineering (Chaos Mesh) |
| 数据新鲜度 | 实时特征延迟 < 30s | Kafka Lag 监控 / 特征时间戳校验 |
上线建议：先以影子模式部署特征服务，同时向新旧两套特征系统发送请求，对比输出差异并修复后再正式切换流量。建议为每个特征设置独立的开关，支持按实体维度灰度发布。