8.0
热点
AI SCORE
技术实践2026-08-19 01:05
Jumio实时特征存储架构：亚100ms欺诈检测
AWS ML Blog#AWS#特征工程#实时系统
Editor brief · 编辑速览
基于SageMaker Feature Store+Flink+Kinesis构建实时特征工程，延迟<100ms，年省12万美元。
如果你正在管理一个实时特征存储系统，你可能正面临诸多挑战：数据冗余、特征工程、特征一致性、手动部署以及延迟问题。Jumio 是一家身份验证服务提供商，帮助企业检测欺诈并建立数字信任。为了实时提供这些服务，Jumio 的机器学习模型需要一个能够解决这些挑战的实时特征存储系统。本文以 Jumio 的案例为例，展示如何构建一个实时特征存储系统。该架构模式适用于需要亚 100 毫秒延迟的实时预测场景的 ML 用例。
本文将介绍该架构、设计权衡及其对 Jumio 工作负载的影响。你将学习如何通过 Amazon SageMaker Feature Store、Amazon Managed Service for Apache Flink 和 Amazon Kinesis Data Streams 等服务来优化你在 AWS 上的 ML 特征管理。
在构建实时特征存储系统之前，特征工程和部署往往分散且效率低下。这导致了以下问题：
由于 Jumio 的业务围绕身份验证解决方案展开，及时准确的欺诈检测至关重要。Jumio 的 ML 模型严重依赖特征来做出明智的决策。为了应对这些挑战，Jumio 需要一个集中化、可复用的实时特征存储系统。
系统的特征存储需求跨越五个相互关联的维度，共同定义了这个平台。
系统必须能够扩展以处理大量特征请求和不断增长的特征目录，并具有在不中断现有工作流程的情况下随时间演变架构的灵活性。
为了支持真实世界 ML 用例的复杂性，系统必须提供特征工程能力，包括基于事件时间的条件特征创建和选择。
低延迟是欺诈检测工作流程的关键需求，特征必须在 100 毫秒内完成服务。
模型重训练和分析需要回填历史数据。为此，离线特征存储近实时地摄取数据，用于模型重训练、调试、评估和监控。
最后，平台必须通过简化端到端特征开发和部署生命周期来支持敏捷特征开发，允许跨职能团队以最小的协调开销独立引入新特征。
Jumio 的特征存储架构采用流优先设计，为可扩展性、可靠性和性能而构建。我们在三个 AWS 区域部署了此架构：US East (N. Virginia) (us-east-1)、Europe (Frankfurt) (eu-central-1) 和 Asia Pacific (Singapore) (ap-southeast-1)。以下是数据在系统中的流动方式：
还有一条并行数据流用于离线特征存储。事件通过 Amazon Data Firehose (Firehose) 流入 Amazon S3，然后通过 Amazon EMR 运行，最终作为 Iceberg 表落地，用于模型训练。
图 1：特征存储架构，由数据管道、实时特征存储和离线特征存储组成
实时摄取通过 Amazon Kinesis Data Streams 流转，Apache Flink 应用从其中获取传入事件。Flink 在飞行中处理和丰富数据，然后直接将特征写入 Amazon SageMaker Feature Store。
批处理采用并行路径：Amazon Data Firehose 将事件传送到 Amazon S3。Amazon S3 事件通知触发 Amazon EMR，后者运行更重的转换工作负载。然后 EMR 流程将处理后的特征填充到 Amazon SageMaker Feature Store（作为冷数据）和 Apache Iceberg 表中，后者作为离线特征存储。
该架构包含实时和离线两个特征存储，各服务不同目的。
实时特征存储：Jumio 在 Amazon SageMaker Feature Store 中存储特征，针对低延迟模型服务进行优化。
离线特征存储：Flink 输出通过 Amazon Data Firehose 路由到 Amazon S3，数据以 Iceberg 格式存储。这使得特征可以通过 Amazon Athena、Amazon EMR 交互式笔记本和作业以及内部数据集准备工具访问。近实时摄取的工作方式如下：
对于实时特征存储，我们关注流应用程序的延迟和健康状况。
记录创建延迟：我们监控 Flink 应用程序内的各个阶段，包括：
Amazon Managed Service for Apache Flink：为验证 Flink 应用程序是否最佳运行，我们追踪：
Amazon SageMaker Feature Store 指标：我们监控特征存储的性能和可靠性：
离线特征存储监控
Amazon Data Firehose 指标：我们监控的关键指标包括：
在确定此架构之前，我们评估了多种方法。
Amazon SageMaker Feature Store（数据库选择）
Apache Flink（框架）
AWS 服务
延迟指标显示，第 95 百分位响应时间为 16.9 毫秒，满足了 Jumio 亚 100 毫秒响应时间的欺诈检测 SLA 要求。
下图展示了 Jumio 的读取延迟，P50（中位数）为 8.44 毫秒。
图 2：读取延迟，P50 为 8.44 毫秒
下图展示了 Jumio 的写入延迟，P50 为 18.6 毫秒。
图 3：写入延迟，P50 为 18.6 毫秒
下图展示了我们如何处理迟到事件。
图 4：迟到事件的处理方式
当前架构相比之前分散的方法有了显著改进。最初，组织中的各个团队以去中心化方式定义特征。现在的状态是集中化、可复用的特征存储。部署过程现在是自动化和统一的，取代了需要数周的手动实现。系统现在可以处理迟到的特征（如前所述）。该架构通过 Amazon SageMaker Feature Store 提供实时访问，而之前访问上游模型的能力有限。从成本角度来看，通过 Amazon SageMaker Feature Store 中的内存存储进行优化，与早期分散的特征存储相比，节省了约 120,000 美元的运营成本。
通过这个特征存储实施和来之不易的生产经验，我们提炼出以下指导。一个良好架构的特征存储建立在五个原则之上。它始于流优先设计，使特征能够实时供模型使用。集中化特征定义支持跨团队的一致性和可复用性。分层存储策略，结合内存存储和标准存储，平衡延迟与成本。特征存储健康状况和延迟的监控防止无声降级破坏模型预测。这一方法的基础是后端、ML 和数据工程团队之间的跨职能协作，使特征开发从构思到生产的过程顺畅无阻。
在本文中，你看到了 Jumio 如何在 AWS 上构建了一个实时特征存储系统，该系统能够处理大容量数据摄取、提供毫秒级延迟，并每年节省约 120,000 美元。该特征存储是 Jumio 在 AI 驱动的身份验证领域持续创新的核心组件。本案例研究中概述的架构和最佳实践为你提供了一个经过验证的方法，适用于欺诈检测、推荐系统以及其他需要低延迟预测的 ML 用例。如果你曾面临过特征存储的类似挑战，欢迎在评论区分享你的经验和问题。
要开始使用，请采取以下后续步骤：