← 返回信息流

精选AWS AI Blog新闻

Jumio 如何在 AWS 上构建实时特征存储

aws.amazon.com作者：Amit Peshwani行业AI评分：70/100

本文以 Jumio 的身份验证业务为例，介绍了在 AWS 上构建实时特征存储的架构。该架构使用 Amazon SageMaker Feature Store、Apache Flink 和 Kinesis Data Streams，实现了亚 100 毫秒的特征服务延迟，并每年节省约 12 万美元。文章详细阐述了数据管道、实时与离线特征存储的设计、监控指标以及技术选型的优缺点，适用于需要低延迟预测的机器学习场景。

如果你正在管理一个实时特征存储（real-time feature store），你可能会面临数据重复、特征工程、特征一致性、手动部署和延迟等挑战。Jumio 是一家身份验证服务提供商，帮助企业检测欺诈并建立数字信任。为了实时提供这些服务，Jumio 的机器学习（ML）模型需要一个能够解决这些挑战的实时特征存储。我们以 Jumio 的案例研究为例，向你展示如何构建实时特征存储。该架构模式适用于需要亚 100 毫秒延迟进行实时预测的机器学习用例。

在本文中，我们展示了该架构、设计权衡及其对 Jumio 工作负载的影响。你将学习如何利用 Amazon SageMaker Feature Store、Amazon Managed Service for Apache Flink 和 Amazon Kinesis Data Streams 等服务，在 AWS 上优化你的机器学习特征管理。

问题陈述

在构建实时特征存储之前，特征工程和部署往往是分散且低效的。这导致了以下问题：

  • 数据重复：各团队维护自己的离线特征存储，导致数据冗余和特征定义不一致。
  • 手动生产部署：团队在生产代码（Java 或 Python）中手动重新实现离线训练的特征，这增加了不匹配和错误的风险。
  • 延迟挑战：欺诈检测要求即时访问特征，包括上游模型的输出。
  • 事件处理延迟：某些事件类型会延迟到达或以不规则模式出现。它们可能在初始活动后不久出现，也可能因延长审核流程而在数周后出现。

由于 Jumio 的业务围绕身份验证解决方案展开，及时且准确的欺诈检测至关重要。Jumio 的机器学习模型高度依赖特征来做出明智的决策。为了应对这些挑战，Jumio 需要一个集中式、可复用、实时的特征存储。

技术要求

系统的特征存储需求涵盖五个相互关联的维度，它们共同定义了该平台。

  1. 系统必须能够扩展，以容纳高吞吐量的特征请求和不断增长的特征目录，并具备随时间演进 schema 的灵活性，同时不干扰现有工作流。
  2. 为支持真实世界机器学习用例的复杂性，系统必须提供特征工程能力，包括基于事件时间的条件特征创建和选择。
  3. 低延迟是硬性要求，尤其是在欺诈检测工作流中，特征必须在 100 毫秒内提供。
  4. 模型重训练和分析需要回填历史数据。为此，离线特征存储以近实时方式摄取数据，用于模型重训练、调试、评估和监控。
  5. 最后，平台必须通过简化端到端的特征开发和部署生命周期来支持敏捷特征开发，允许跨职能团队以最小的协调开销独立引入新特征。

架构

Jumio 的特征存储架构采用流优先（streaming-first）设计，专为可扩展性、可靠性和性能而构建。我们将该架构部署在三个 AWS 区域：美国东部（弗吉尼亚北部）（us-east-1）、欧洲（法兰克福）（eu-central-1）和亚太地区（新加坡）（ap-southeast-1）。以下是数据在系统中的流转方式：

  1. 事件通过 Kinesis 进入。
  2. Flink 将事件处理为特征。
  3. Amazon SageMaker Feature Store 将特征存储在内存中。
  4. 机器学习模型检索特征进行推理。

此外，还有一条并行的数据流用于离线特征存储。事件通过 Amazon Data Firehose（Firehose）流入 Amazon Simple Storage Service（Amazon S3），然后经过 Amazon EMR 处理，最终以 Iceberg 表的形式落地，用于模型训练。

Architecture diagram showing three components: a data pipeline, a real-time feature store, and an offline feature store
Architecture diagram showing three components: a data pipeline, a real-time feature store, and an offline feature store

数据管道

实时摄取通过 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 中，并针对低延迟模型服务进行了优化。热数据：由 Amazon ElastiCache for Valkey 提供支持的内存存储，用于服务近期频繁访问的特征，支持低延迟读取和低成本写入。冷数据：访问频率较低的特征保留在标准存储中，以确保可扩展性和持久性。

离线特征存储：Flink 输出被路由到 Amazon Data Firehose，然后传输到 Amazon S3，数据以 Iceberg 格式存储。这使得特征可以通过 Amazon Athena、Amazon EMR 交互式笔记本和作业以及内部数据集准备工具进行访问。近实时摄取的工作流程如下：Flink Sink 写入 Amazon Data Firehose，Firehose 将数据投递到 Amazon S3，Amazon S3 事件触发 AWS Lambda，AWS Lambda 调用 Amazon EMR Serverless，Amazon EMR Serverless 更新 Iceberg 表。

监控

对于实时特征存储，我们重点关注流式应用程序的延迟和健康状况。

  • 输入 Kinesis Data Streams 到 Flink 消费端的延迟（毫秒）。
  • Flink 消费端到 Flink Sink 的延迟（毫秒）。
  • Flink Sink 到 Amazon SageMaker Feature Store 的延迟（毫秒）。
  • 从输入 Kinesis Data Streams 到 Amazon SageMaker Feature Store 的总延迟（毫秒）。
  • 繁忙时间。
  • Kinesis Processing Unit（KPU）使用率。
  • 最近一次检查点持续时间、CPU 和内存利用率。
  • 背压时间。
  • GET 和 PUT 请求量。
  • 读写延迟。
  • 超时率。
  • 记录输出大小。

离线特征存储监控

  • 传入记录（数量）。
  • Put Records 批量延迟。
  • 投递到 Amazon S3 的记录。
  • 投递到 Amazon S3 的新鲜度。
  • 投递到 Amazon S3 的成功率。

数据库选型、框架和 AWS 服务的优缺点

在确定此架构之前，我们评估了多种方案。

Amazon SageMaker Feature Store（数据库选型）

  • 优点：作为专为机器学习特征构建的托管服务，可降低运维开销，让团队专注于模型开发而非基础设施管理。它提供用于低延迟的内存存储和用于可扩展性的标准存储。
  • 缺点：如果没有存储优化，成本可能成为一个因素。

Apache Flink（框架）

  • 优点：强大的流处理能力可处理高数据量，即使在流量高峰期间也能保持欺诈检测的高速运行。它也非常适合构建表示复杂事件逻辑的特征。
  • 缺点：与批处理框架相比学习曲线较陡，且管理 Flink 应用程序的运维复杂度较高。

AWS 服务

  • 优点：服务范围广泛（Amazon Kinesis、Amazon S3、Amazon Data Firehose、AWS Lambda、Amazon EMR Serverless、AWS Glue Data Catalog 和 AWS Lake Formation），具有高可扩展性、高可靠性和强大的安全功能。
  • 缺点：集成多个服务可能较为复杂，且优化配置和成本管理需要深厚的 AWS 专业知识。

性能指标

延迟指标显示，95 百分位响应时间为 16.9 毫秒，满足 Jumio 欺诈检测 SLA 要求的亚 100 毫秒响应时间。

Graph showing Jumio’s read latency with a P50 of 8.44 ms
Graph showing Jumio’s read latency with a P50 of 8.44 ms

下图展示了 Jumio 的读取延迟，P50（第 50 百分位）为 8.44 毫秒。

图 2：读取延迟，P50 为 8.44 毫秒

Graph showing Jumio’s write latency with a P50 of 18.6 ms
Graph showing Jumio’s write latency with a P50 of 18.6 ms

下图展示了 Jumio 的写入延迟，P50 为 18.6 毫秒。

图 3：写入延迟，P50 为 18.6 毫秒

实时特征存储记录概览

Diagram showing how late-arriving events are processed and reconciled into the feature store records
Diagram showing how late-arriving events are processed and reconciled into the feature store records

下图展示了我们如何处理延迟到达的事件。

当前状态与先前迭代的对比

当前架构相比之前分散的方法有了显著改进。最初，组织内各个团队以去中心化的方式定义特征。当前状态则拥有集中化、可复用的特征存储。部署流程现已实现自动化和统一化，取代了此前需要数周时间的手动实施。系统现在可以处理延迟到达的特征，如前文所述。该架构通过 Amazon SageMaker Feature Store 提供实时访问，而此前上游模型的访问受到限制。从成本角度来看，与之前分散的特征存储相比，通过优化使用 Amazon SageMaker Feature Store 中的内存存储，已节省约 12 万美元的运营成本。

实施指南

通过这次特征存储的实施和在生产环境中积累的宝贵经验，我们总结出以下指导原则。一个架构良好的特征存储建立在五个原则之上。首先是流式优先的设计，使特征能够实时提供给模型使用。集中化的特征定义支持跨团队的一致性和可复用性。分层存储策略将内存存储与标准存储相结合，在延迟与成本之间取得平衡。对特征存储健康状况和延迟的监控可防止静默退化破坏模型预测。支撑这一方法的是后端、机器学习和数据工程团队之间的跨职能协作，这使得特征开发能够从构思顺利推进到生产，而不会因交接产生摩擦。

投资回报与影响

主要收益包括：

  • 加速模型开发：通过提供集中化、现成可用的特征，该方法有助于减少开发新机器学习模型所需的时间和精力。
  • 提升模型准确性：一致的特征定义和数据访问方式可带来更准确的机器学习模型。
  • 降低运营成本：Jumio 通过迁移到 Amazon SageMaker Feature Store，在不影响延迟的前提下，实现了每年约 12 万美元（基于其工作负载）的成本节省。
  • 改善客户体验：更快、更可靠的身份验证流程有助于提升客户体验的安全性。
  • 增强敏捷性：这种灵活的架构支持迭代、部署新特征，并能快速响应不断变化的业务需求。

结论

在本文中，您了解了 Jumio 如何在 AWS 上构建实时特征存储，该存储可处理高吞吐量的数据接入、实现毫秒级延迟，并每年节省约 12 万美元的成本。该特征存储是 Jumio 在 AI 驱动的身份验证领域持续创新的核心组成部分。本案例研究中概述的架构和最佳实践，为欺诈检测、推荐系统以及其他需要低延迟预测的机器学习用例提供了经过验证的方案。如果您在特征存储方面遇到过类似挑战，欢迎在评论区分享您的经验和问题。

  • 设置您的 Amazon Kinesis 数据流，开始大规模收集实时数据以进行流式数据接入。更多信息，请参阅 Amazon Kinesis。
  • 使用 Amazon Managed Service for Apache Flink，以极低的运维开销处理和转换您的流式数据。更多信息，请参阅 Amazon Managed Service for Apache Flink。
  • 配置您的特征仓库，为实时推理提供毫秒级延迟，同时保留离线存储用于模型训练。更多信息，请参阅 Amazon SageMaker Feature Store 及其最新更新。

刚接触 AWS？您可以通过 AWS 免费套餐探索这些服务。

关于作者

阅读原文