欺诈检测依赖的不只是模型本身，还取决于模型能否在交易发生的瞬间拿到新鲜、可靠的特征。Jumio 在 AWS 上构建了一套集中式实时特征库，将 Amazon SageMaker Feature Store、Amazon Managed Service for Apache Flink 和 Amazon Kinesis Data Streams 组合起来，为欺诈检测提供低于 100 毫秒的特征服务延迟，并据摘要估算每年节省约 120,000 美元。
为什么实时特征比离线特征更重要
欺诈行为往往在几秒甚至几毫秒内变化。例如，某个账户刚刚修改了收货地址，随后又在短时间内发起多笔高风险交易。如果模型读取的是延迟数小时的批处理特征，就可能错过关键变化。
实时特征库通常需要同时满足三项要求：
- 数据新鲜：事件发生后，特征应尽快更新。
- 读取稳定：在线推理需要可预测的低延迟访问。
- 训练与推理一致：离线训练使用的特征定义，应尽量和线上服务保持一致。
这也是集中式特征库的价值所在：数据生产、特征计算、特征存储和模型读取不再由多个团队分别实现，特征可以围绕统一的数据契约管理。
AWS 架构中的职责划分
从摘要提供的组件看，这套方案可以拆成一条清晰的数据路径：
- Amazon Kinesis Data Streams 接收交易、账户活动或设备行为等实时事件。
- Amazon Managed Service for Apache Flink 消费事件流，计算时间窗口、计数、频率和聚合类特征。
- Amazon SageMaker Feature Store 保存特征，并为在线推理提供统一的特征访问入口。
- 欺诈检测服务 在请求到达时读取最新特征，将特征提交给模型并返回风险判断。
其中，Flink 适合处理有状态的流式计算。例如，可以在滚动窗口内统计某个设备的交易次数，或计算账户最近一次活动距离当前时间的间隔。Kinesis 负责持续传输事件，Feature Store 则负责让这些特征能够被下游模型稳定消费。
这种分工还带来一个工程上的好处：实时计算逻辑和模型服务逻辑可以独立演进。模型服务不需要知道特征是如何从原始事件计算出来的，只需要按照约定的实体标识读取特征。
一个可改造的实时特征管道示例
下面的配置示例展示了一个简化的数据流。它不是 Jumio 的内部配置，而是可以据此改造的部署草案。运行前需要替换 AWS 账户、区域、IAM 角色和实际的 Flink 应用配置。
# realtime-feature-pipeline.yaml
region: us-east-1
kinesis:
streamName: fraud-events
shardCount: 2
partitionKey: customer_id
flink:
applicationName: fraud-feature-enrichment
inputStream: fraud-events
outputStream: enriched-fraud-features
checkpointIntervalMs: 60000
parallelism: 2
features:
- name: transactions_5m
aggregation: count
window: 5m
key: customer_id
- name: device_transactions_1h
aggregation: count
window: 1h
key: device_id
sagemakerFeatureStore:
onlineStoreEnabled: true
featureGroupName: fraud-realtime-features
recordIdentifier: customer_id
eventTimeField: event_time
事件可以采用类似下面的 JSON 格式，通过 Kinesis 发布：
aws kinesis put-record \
--stream-name fraud-events \
--partition-key customer-123 \
--data "$(printf '%s' '{"customer_id":"customer-123","device_id":"device-9","amount":249.90,"event_type":"payment","event_time":"2025-01-15T12:00:00Z"}' | base64)" \
--region us-east-1
实际项目中还需要处理事件乱序、重复投递、迟到数据和时间窗口边界。Flink 作业应使用事件时间和 watermark，而不是简单依赖消息到达时间。对于重复事件，应通过事件 ID 或幂等写入策略避免重复累加。
延迟目标不能只看特征库
“低于 100 毫秒”是端到端用户体验目标，不能只用某一个组件的延迟来衡量。一次欺诈检测请求可能包括：
- API 网关或负载均衡带来的网络耗时；
- 从 Feature Store 读取多个特征的耗时；
- 特征缺失处理和数据转换耗时；
- 模型推理耗时；
- 超时、重试和日志记录耗时。
因此，落地时应分别记录事件摄取延迟、特征计算延迟、特征写入延迟、在线读取延迟和模型推理延迟。监控指标最好同时观察 p50、p95 和 p99，避免平均值掩盖尾延迟问题。
读取路径也需要保持简单。欺诈检测服务可以在请求内批量获取同一实体的多个特征，减少多次网络往返；对非关键特征可以设置合理的默认值，但不能静默掩盖核心特征缺失。若实时特征不可用，系统应明确选择降级模型、缓存值或人工审核，而不是让失败行为随机发生。
成本与治理方面的收益
集中式架构的收益不只体现在速度上。Jumio 的案例摘要指出，该方案每年可节省约 120,000 美元。具体节省来源需要结合企业原有架构核算，但通常可以从以下方面建立成本模型：
- 减少多个团队重复维护特征计算和存储系统；
- 降低批处理与实时处理之间的数据复制成本；
- 通过统一特征定义减少线上线下不一致造成的排查成本；
- 根据 Kinesis 分片、Flink 并行度和在线存储访问量进行容量规划。
治理同样重要。每个特征至少应记录名称、业务含义、实体键、事件时间、更新频率、数据来源、缺失策略和负责人。对于欺诈检测，还应保留特征版本和模型版本之间的关系，方便回溯某次决策使用了哪些数据。
采用前的检查清单
可以按以下顺序评估类似方案：
- 明确哪些特征必须实时更新，哪些特征可以批量生成；
- 为事件定义稳定的实体键、事件时间和唯一事件 ID；
- 估算峰值事件量、特征写入量和在线读取量；
- 为 Flink 作业设计状态恢复、迟到数据和重复事件处理；
- 以 p95 和 p99 延迟验证亚百毫秒目标；
- 建立特征质量、数据新鲜度和缺失率告警；
- 记录特征版本，验证训练和线上推理使用的定义一致；
- 通过压测确认成本随流量增长的曲线。
实时特征库适合对新鲜度和响应速度都有要求的场景，但它也会引入流式状态管理、数据治理和成本控制问题。更稳妥的路径是先选择一组能直接影响欺诈判断的核心特征，建立端到端延迟和质量指标，再逐步扩展特征范围。