特征服务架构概览
信用评分特征服务是连接原始数据与模型推理的核心中间层。其架构设计需要同时满足在线推理的低延迟（通常要求 P99 < 50ms）和离线批量计算的吞吐量（每日百亿级特征生成）。下图展示了特征服务的整体组件与数据流向。
核心组件详解
特征服务由四个核心组件构成，各组件职责明确，通过标准接口协同工作。
| 组件 | 核心职责 | 关键技术选型 | 关键指标 |
|---|---|---|---|
| 特征计算引擎 | 将原始数据转换为标准化特征 | Flink / Spark / Python UDF | 实时延迟 < 1s；离线吞吐 > 10TB/h |
| 特征存储 | 统一管理在线/离线特征数据 | Redis / Tair / Hive / Iceberg | 在线 P99 < 5ms；离线存储成本可控 |
| 在线 API 服务 | 提供低延迟特征获取接口 | gRPC / HTTP / 本地缓存 | P99 < 50ms；可用性 99.99% |
| 离线批处理 | 批量生成特征宽表与回溯数据 | Spark / Hive / Airflow | 日调度完成 < 4h；数据一致性 100% |
特征计算引擎
计算引擎是特征生产的核心，需要同时处理实时流和离线批两种计算模式。
- 实时特征计算：基于 Flink 消费 Kafka 事件流，执行滑动窗口聚合、时序特征、比率计算等算子。输出直接写入在线 KV 存储，保证秒级特征新鲜度。
- 离线特征计算：基于 Spark 每日批量处理全量数据，生成 T+1 特征宽表。支持复杂多表 Join、历史回溯、特征衍生等场景。
- 自定义特征：提供 Python UDF 沙箱，允许算法工程师快速验证新特征逻辑，通过后迁移至生产算子。
实践要点：实时与离线计算必须使用同一套特征逻辑代码（Lambda 架构），避免因计算口径不一致导致在线/离线特征偏差。推荐将特征算子封装为独立 JAR 包，Flink 和 Spark 共用。
特征存储
特征存储采用分层多模态设计，不同场景使用不同的存储引擎。
| 存储层 | 存储内容 | 引擎 | 访问模式 |
|---|---|---|---|
| 在线 KV 层 | 实时特征、高频特征 | Redis / Tair | Key-Value 点查，QPS > 10w |
| 离线宽表层 | 全量特征宽表 | Hive / Iceberg | 批量扫描，分区裁剪 |
| 元数据中心 | 特征定义、版本、血缘 | MySQL | 低频管理查询 |
| 特征快照层 | 每日特征快照 | HDFS / Parquet | 回溯分析、模型训练 |
设计建议：在线 KV 存储建议开启本地缓存（如 Redis 的 read-through 或 Caffeine），可降低 60% 以上的网络开销。同时设置合理的 TTL 和降级策略，防止缓存雪崩。
在线 API 服务
API 服务是特征服务的流量入口，直接面向信用评分模型推理请求。其架构设计需重点关注延迟、可用性和一致性。
避坑指南：在线 API 服务必须实现多级降级策略。当远程 KV 存储超时或不可用时，应优先返回本地缓存数据（允许一定程度的特征过期），而非直接返回错误。同时设置熔断阈值，防止雪崩效应。
离线批处理
离线批处理负责每日全量特征宽表的生成、特征回溯数据的准备以及特征一致性的校验。
- 每日宽表生成：基于 Airflow 调度 Spark 任务，读取离线数仓数据，执行与实时计算相同的特征逻辑，产出 T+1 特征宽表。
- 特征回溯：支持指定时间范围的历史特征重算，用于模型训练样本的构建和回测验证。
- 一致性校验：每日离线任务完成后，自动对比在线 KV 存储与离线宽表中同一批样本的特征值，偏差超过阈值则触发告警。
关键实践：离线批处理与在线 API 服务共享特征元数据中心。所有特征的定义、版本、数据类型、空值处理策略均从元数据中心获取，确保“一次定义，多处使用”。建议使用 Protobuf 或 Avro 作为特征序列化格式，保证跨语言、跨平台的兼容性。