2. 核心概念与术语：特征工程、特征存储、在线特征服务、离线批处理、实时流处理、延迟与吞吐量
在搭建低延迟贷后预警特征服务之前，必须统一团队对核心概念的认知。本章将逐一拆解特征工程、特征存储、在线特征服务、离线批处理、实时流处理以及延迟与吞吐量这七个关键术语，并阐明它们在贷后预警场景中的具体含义与相互关系。
2.1 特征工程
特征工程是将原始数据（如还款记录、催收通话、多头借贷查询）转化为模型可用的数值化特征的过程。在贷后预警中，特征工程的质量直接决定预警模型的准确率与时效性。
| 特征类型 | 贷后示例 | 处理方式 |
|---|---|---|
| 数值型 | 逾期天数、剩余本金 | 标准化、对数变换 |
| 类别型 | 产品类型、渠道来源 | One-Hot / Embedding |
| 时序型 | 近30天还款次数趋势 | 滑动窗口、差分 |
| 聚合型 | 历史最大逾期天数 | GroupBy + 聚合函数 |
实践要点：贷后预警特征工程应优先保证特征的可回溯性（Point-in-Time Correctness），避免未来信息泄露导致模型过拟合。
2.2 特征存储
特征存储（Feature Store）是统一管理特征定义、计算逻辑与在线/离线数据的中间层。它解决了特征重复开发、训练与推理不一致的问题。
- 离线存储：基于 Hive / Iceberg 存储历史全量特征，用于模型训练与回测。
- 在线存储：基于 Redis / HBase 存储最新特征快照，用于实时推理。
- 特征注册：通过元数据管理特征名称、类型、时间戳与血缘关系。
2.3 在线特征服务
在线特征服务是面向实时推理请求的低延迟特征获取层。在贷后预警场景中，当用户还款行为触发或风控系统发起查询时，在线特征服务需要在毫秒级返回当前借款人的最新特征向量。
关键指标：在线特征服务 P99 延迟需控制在 20ms 以内，否则会阻塞风控决策链路，导致用户等待超时或降级。
- API 网关：统一接收特征查询请求，进行鉴权与限流。
- 特征缓存：使用 Redis Cluster 缓存热点特征，减少后端存储压力。
- 预计算引擎：对复杂聚合特征提前计算并写入在线存储。
2.4 离线批处理
离线批处理用于处理历史全量数据，生成训练特征与周期性报表。在贷后预警中，每日凌晨通过 Spark / Hive 计算所有存量借款人的最新特征，并写入离线特征存储。
| 维度 | 离线批处理 | 贷后场景 |
|---|---|---|
| 数据范围 | 全量历史数据 | 所有借款人的还款、催收记录 |
| 计算频率 | 天级 / 小时级 | 每日凌晨 T+1 计算 |
| 延迟要求 | 分钟级 ~ 小时级 | 不影响次日模型训练即可 |
| 典型引擎 | Spark / Hive / Flink Batch | Spark SQL 聚合 + 窗口函数 |
2.5 实时流处理
实时流处理用于处理持续到达的事件流，在秒级或毫秒级生成最新特征。贷后预警场景中，借款人还款、逾期、催收状态变更等事件通过 Kafka 接入，由 Flink / Spark Streaming 实时计算并更新在线特征。
2.6 延迟与吞吐量
延迟与吞吐量是衡量特征服务性能的核心指标，两者在贷后预警场景中需要权衡。
- 延迟（Latency）：从请求发出到收到响应的时间间隔。在线特征服务关注 P50、P99 延迟。
- 吞吐量（Throughput）：单位时间内系统能处理的请求数或事件数。通常用 QPS（每秒查询数）或 TPS（每秒事务数）衡量。
| 指标 | 定义 | 贷后预警目标 | 常见瓶颈 |
|---|---|---|---|
| P50 延迟 | 50% 请求的响应时间 | < 10ms | 网络开销、序列化 |
| P99 延迟 | 99% 请求的响应时间 | < 50ms | 缓存穿透、GC 停顿 |
| QPS | 每秒查询数 | > 10,000 | 连接池、线程模型 |
| TPS | 每秒事务数 | > 5,000 | 数据库写入、锁竞争 |
避坑提示：不要盲目追求极低延迟而牺牲吞吐量。在贷后预警中，批量查询场景（如每日全量评分）更关注吞吐量，而单笔实时查询更关注延迟。架构设计时应根据业务场景做差异化隔离。
2.7 概念关系总结
上述六个概念在贷后预警特征服务中形成完整闭环：
- 离线批处理 生成历史特征，存入 特征存储 的离线部分，用于模型训练。
- 实时流处理 消费事件流，实时更新 特征存储 的在线部分。
- 在线特征服务 从在线存储中读取最新特征，响应风控决策引擎的实时查询。
- 特征工程 贯穿离线与实时两条链路，保证特征定义与计算逻辑一致。
- 延迟与吞吐量 作为性能标尺，指导架构选型与资源规划。