4、特征平台与特征存储：Feast/Tecton、在线存储与实时/预计算策略
在信用评分在线推理链路中，特征平台是连接离线开发与在线服务的核心中间层。它负责管理特征定义、特征版本、特征存储以及特征服务，确保模型在推理时能够获取到一致、低延迟且高可用的特征数据。本章将深入剖析特征平台的核心概念、主流开源与商业方案（Feast / Tecton）、在线特征存储选型（Redis / DynamoDB），以及实时计算与预计算策略的权衡。
4.1 特征平台的核心职责
特征平台并非简单的特征存储，而是一套完整的特征生命周期管理体系。其核心职责包括：
- 特征注册与发现：数据科学家或工程师在平台中注册特征定义（Feature Definition），包括特征名称、类型、来源、时间戳、聚合逻辑等元数据。
- 特征版本管理：支持特征定义的版本化，确保历史模型可以回溯到对应的特征版本进行推理或回测。
- 特征存储抽象：统一管理离线存储（如 Parquet 文件、Hive 表）和在线存储（如 Redis、DynamoDB），对上层应用透明。
- 特征服务：提供低延迟的在线特征获取 API，通常支持批量获取（Multi-get）以支持批量推理。
- 特征监控与一致性：监控在线与离线特征的一致性，检测数据漂移和延迟。
关键原则：特征平台应遵循“Write Once, Serve Anywhere”的理念，即特征定义在平台中统一管理，同时服务于离线训练和在线推理，避免特征逻辑分裂。
4.2 主流特征平台方案对比：Feast vs Tecton
目前业界最受关注的特征平台方案包括开源的 Feast 和商业化的 Tecton。两者在架构理念上有相似之处，但在功能完整度、运维成本和生态集成上存在差异。
| 维度 | Feast（开源） | Tecton（商业） |
|---|---|---|
| 定位 | 开源特征存储标准，社区驱动 | 企业级特征平台，提供全托管服务 |
| 特征注册 | 基于 YAML 或 Python SDK 定义特征视图（Feature View） | 基于 Python SDK 或 Web UI，支持更丰富的特征派生逻辑 |
| 在线存储 | 支持 Redis、DynamoDB、Firestore 等，通过插件扩展 | 内置高性能在线存储，支持 DynamoDB、Redis 及自研引擎 |
| 实时计算 | 需自行集成流处理引擎（如 Kafka + Flink） | 内置流处理管道，支持实时特征计算（Stream Feature View） |
| 特征监控 | 基础监控能力，需自行扩展 | 内置特征一致性监控、数据漂移检测、延迟告警 |
| 适用场景 | 技术团队较强，希望自主掌控特征管线的团队 | 追求快速落地、减少运维负担的企业 |
选型建议：对于信用评分场景，如果团队具备较强的流处理与运维能力，Feast 结合 Redis 和 Flink 可以构建高性价比的特征平台。如果预算充足且希望快速上线，Tecton 的托管特性可以显著降低工程复杂度。
4.3 在线特征存储选型：Redis vs DynamoDB
在线特征存储是特征平台中延迟最敏感的一环。信用评分推理通常要求特征获取延迟在毫秒级（<10ms），且需要支持高并发（数千 QPS 以上）。Redis 和 DynamoDB 是两种最常用的在线存储后端。
4.3.1 Redis：内存型键值存储
- 优势：极低延迟（通常 <1ms）、丰富的数据结构（Hash、Sorted Set 等）、支持 TTL 自动过期。
- 劣势：受限于内存容量，成本较高；数据持久化需额外配置（RDB/AOF）；集群运维复杂度较高。
- 适用场景：特征维度较小（单条特征 <1KB）、对延迟极度敏感、特征总量可控的场景。
4.3.2 DynamoDB：托管 NoSQL 数据库
- 优势：全托管、自动扩缩容、按需付费、支持 TTL、与 AWS 生态深度集成。
- 劣势：延迟相对 Redis 略高（通常 1-5ms）、单次请求成本较高、对强一致性读取有性能开销。
- 适用场景：特征维度较大、需要弹性伸缩、团队希望减少运维负担的场景。
| 对比维度 | Redis | DynamoDB |
|---|---|---|
| 延迟（P99） | <1ms | 1-5ms |
| 存储模型 | 内存 + 可选持久化 | SSD 存储 + 内存缓存 |
| 成本结构 | 按内存容量 + 实例费用 | 按读写容量 + 存储量 |
| 运维复杂度 | 较高（集群、分片、持久化） | 低（全托管） |
| 数据一致性 | 最终一致性（默认） | 最终一致性 / 强一致性（可选） |
| TTL 支持 | 原生支持 | 原生支持 |
避坑提示：在信用评分场景中，特征数据通常具有时效性（如近 30 天逾期次数）。务必为在线特征设置合理的 TTL，避免过期特征影响模型效果。同时，对于 Redis 集群，建议使用一致性哈希进行分片，避免热点 key 导致延迟抖动。
4.4 特征实时计算与预计算策略
信用评分特征可以分为三类：静态特征（如年龄、性别）、批量计算特征（如近 30 天平均消费金额，每日更新一次）、实时特征（如当前设备指纹、最近一次交易金额）。针对不同类型的特征，需要采用不同的计算与存储策略。
4.4.1 预计算策略（Batch Pre-computation）
- 原理：通过离线批处理作业（如 Spark、Hive）按固定时间窗口（如每小时、每天）计算特征，并将结果写入在线存储。
- 优点：计算成本低、易于回溯和验证、适合时间窗口较长的聚合特征。
- 缺点：数据新鲜度受限于批处理周期，无法捕捉窗口内的实时变化。
- 适用特征：近 7 天/30 天逾期次数、近 3 个月平均收入、历史最大负债率等。
4.4.2 实时计算策略（Real-time Computation）
- 原理：通过流处理引擎（如 Flink、Kafka Streams）实时消费事件流，在事件到达时立即更新特征状态，并写入在线存储。
- 优点：数据新鲜度达到秒级甚至毫秒级，能够捕捉用户最新的行为变化。
- 缺点：计算成本高、状态管理复杂、需要处理乱序事件和 Exactly-Once 语义。
- 适用特征：当前设备风险评分、最近 5 分钟交易次数、实时地理位置特征。
4.4.3 混合策略（Lambda Architecture）
在实际信用评分系统中，通常采用混合策略：
- 批处理层：计算大部分历史聚合特征，每日更新一次，写入在线存储。
- 流处理层：实时计算最近时间窗口内的特征（如近 5 分钟交易次数），覆盖批处理层无法满足的新鲜度需求。
- 服务层：推理时优先读取实时特征，若实时特征缺失或过期，则回退到批处理特征。
实践建议：在信用评分场景中，建议将 80% 的特征通过预计算方式生成，仅对少数对时效性极其敏感的特征（如欺诈检测相关的实时行为特征）采用实时计算。这可以在保证模型效果的同时，有效控制计算和存储成本。
4.5 特征平台架构总览
下图展示了信用评分在线推理链路中特征平台的核心架构，包括特征注册、离线/在线存储、实时计算与预计算策略的协同关系。
4.6 特征实时计算与预计算策略对比总结
| 策略 | 计算引擎 | 数据新鲜度 | 计算成本 | 运维复杂度 | 典型特征示例 |
|---|---|---|---|---|---|
| 预计算（Batch） | Spark、Hive、Presto | 小时级 / 天级 | 低 | 低 | 近 30 天逾期次数、近 3 月平均收入 |
| 实时计算（Stream） | Flink、Kafka Streams | 秒级 / 毫秒级 | 高 | 高 | 最近 5 分钟交易次数、设备风险评分 |
| 混合策略（Lambda） | Spark + Flink | 分层满足 | 中高 | 高 | 历史聚合 + 实时行为特征 |
工程落地建议：在信用评分系统中，建议优先采用预计算策略覆盖大部分特征，仅对欺诈检测等对时效性要求极高的场景引入实时计算。同时，务必在特征平台中建立特征一致性监控，定期对比离线与在线特征的值，及时发现并修复数据偏差。