待翻譯：How Jumio built a real-time feature store on AWS

AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。

If you’re managing a real-time feature store, you might be facing challenges such as data duplication, feature engineering, feature consistency, manual deployment, and latency. Jumio is an identity verification provider that helps businesses detect fraud and build digital trust. To provide these services in real time, Jumio’s machine learning (ML) models needed a real-time feature store that solves these challenges. We use Jumio’s case study to show you how to build a real-time feature store. This architecture pattern applies to ML use cases that require sub-100ms latency for real-time predictions. In this post, we show you the architecture, the design trade-offs, and their impact on Jumio’s workload. You learn how to optimize your ML feature management on AWS by using services such as Amazon SageMaker Feature Store, Amazon Managed Service for Apache Flink, and Amazon Kinesis Data Streams. Problem statement Before building the real-time feature store, feature engineering and deployment were often fragmented and inefficient. This led to the following issues: Data duplication: Teams maintained their own offline feature stores, resulting in redundant data and inconsistent feature definitions. Manual production deployment: Teams manually re-implemented features trained offline in production code (Java or Python), which increased the risk of mismatches and bugs. Latency challenges: Fraud detection demands immediate access to features, including upstream model outputs. Delayed event handling: Certain event types arrive with delays or in irregular patterns. They can appear shortly after initial activity or several weeks later because of extended review processes. Because Jumio’s business revolves around identity verification solutions, timely and accurate fraud detection is important. Jumio’s ML models rely heavily on features to make informed decisions. To address these challenges, Jumio needed a centralized, reusable, real-time feature store. Technical requirements The system’s feature store requirements span five interconnected dimensions that together define the platform. The system must scale to accommodate high volumes of feature requests and a growing feature catalog, with the flexibility to evolve schemas over time without disrupting existing workflows. To support the complexity of real-world ML use cases, it must offer feature engineering capabilities, including conditional feature creation and selection based on event times. Low latency is a requirement particularly for fraud detection workflows, where features must be served in under 100 milliseconds. Model retraining and analysis require backfilling of historical data. To do this, the offline feature store ingests data in near real time for model retraining, debugging, evaluation, and monitoring. Finally, the platform must support agile feature development by simplifying end-to-end feature development and deployment lifecycle, allowing cross-functional teams to independently introduce new features with minimal coordination overhead. Architecture Jumio’s feature store architecture is a streaming-first design, built for scalability, reliability, and performance. We deployed this architecture in three AWS Regions: US East (N. Virginia) (us-east-1), Europe (Frankfurt) (eu-central-1), and Asia Pacific (Singapore) (ap-southeast-1). Here’s how data flows through the system: Events enter through Kinesis. Flink processes the events to features. Amazon SageMaker Feature Store stores features in-memory. ML models retrieve features for inference. There is also a parallel data flow for the offline feature store. Events flow into Amazon Simple Storage Service (Amazon S3) through Amazon Data Firehose (Firehose), then run through Amazon EMR and land as Iceberg tables for model training. Figure 1: The feature store architecture, which consists of a data pipeline, a real-time feature store, and an offline feature store Data pipeline Real-time ingestion flows through Amazon Kinesis Data Streams, where Apache Flink applications pick up incoming events. Flink processes and enriches the data in-flight before writing features directly to Amazon SageMaker Feature Store. Batch processing takes a parallel path: Amazon Data Firehose delivers events to Amazon S3. An Amazon S3 event notification triggers Amazon EMR, which runs the heavier transformation workloads. The EMR process then populates the resulting processed features into Amazon SageMaker Feature Store (as cold data) and into an Apache Iceberg table, which serves as the offline feature store. Real-time and offline feature store The architecture comprises both real-time and offline feature stores, each serving a distinct purpose. Real-time feature store: Jumio stores features in Amazon SageMaker Feature Store, optimized for low-latency model serving. Hot data: An in-memory store, powered by Amazon ElastiCache for Valkey, serves recent, frequently accessed features and supports low-latency reads and cost-effective writes. Cold data: Less frequently accessed features are retained in the standard store for scalability and durability. Offline feature store: Flink output is routed to Amazon Data Firehose and then to Amazon S3, with data stored in Iceberg format. This makes features accessible from Amazon Athena, Amazon EMR interactive notebooks and jobs, and internal dataset preparation tools.Near real-time ingestion works as follows: A Flink Sink writes to Amazon Data Firehose. Firehose delivers to Amazon S3. An Amazon S3 event triggers AWS Lambda, which invokes Amazon EMR Serverless. Amazon EMR Serverless updates the Iceberg tables. Monitoring For the real-time feature store, we focus on the latency and health of the streaming application. Records creation latency: We monitor various stages within Flink applications, including: Input Kinesis Data Streams to Flink consumer latency (milliseconds). Flink consumer to Flink Sink latency (milliseconds). Flink Sink to Amazon SageMaker Feature Store latency (milliseconds). Latency from the input Kinesis Data Streams to Amazon SageMaker Feature Store (milliseconds). Amazon Managed Service for Apache Flink: To verify that the Flink application is operating optimally, we track: Busy time. Kinesis Processing Unit (KPU) usage. Last checkpoint duration, CPU, and memory utilization. Backpressure time. Amazon SageMaker Feature Store metrics: We monitor the performance and reliability of the feature store: GET and PUT request volumes. Read and write latency. Timeout rates. Record output size. Offline feature store monitoring Amazon Data Firehose metrics: Key metrics we monitor include: Incoming records (volume). Put Records batch latency. Records delivered to Amazon S3. Delivery to Amazon S3 freshness. Delivery to Amazon S3 success. Pros and cons of the database choice, framework, and AWS services We evaluated several approaches before settling on this architecture. Amazon SageMaker Feature Store (database choice) Pros: A managed service purpose-built for ML features reduces operational overhead, so your team can focus on model development instead of infrastructure management. It offers an in-memory store for low latency and a standard store for scalability. Cons: Cost can be a factor without storage optimization. Apache Flink (framework) Pros: Powerful stream-processing capabilities that handle high data volumes, which keeps your fraud detection fast even during traffic spikes. It is also well suited for building features that represent complex event logic. Cons: A higher learning curve compared to batch-processing frameworks, and the operational complexity of managing Flink applications. AWS services Pros: A wide range of services (Amazon Kinesis, Amazon S3, Amazon Data Firehose, AWS Lambda, Amazon EMR Serverless, AWS Glue Data Catalog, and AWS Lake Formation), high scalability and reliability, and strong security features. Cons: Integrating multiple services can be complex, and optimal configuration and cost management require deep AWS expertise. Performance metrics Latency metrics showed a 95th-percentile response time of 16.9 milliseconds, which meets Jumio’s fraud detection SLA requirement of sub-100ms response times. The following image shows Jumio’s read latency, with a P50 (50th percentile) of 8.44 ms. Figure 2: Read latency, with a P50 of 8.44 ms The following image shows Jumio’s write latency, with a P50 of 18.6 ms. Figure 3: Write latency, with a P50 of 18.6 ms Real-time feature store records overview The following diagram shows how we process late events. Figure 4: How late-arriving events are processed Current state compared to previous iterations The current architecture represents a significant improvement over previous, fragmented approaches. Initially, individual teams across the organization defined features in a decentralized way. The current state has a centralized, reusable feature store. The deployment process is now automated and unified, replacing the manual implementation that took weeks. The system can now handle late-arriving features, as described earlier. This architecture provides real-time access through Amazon SageMaker Feature Store, whereas access to upstream models was previously limited. From a cost perspective, optimizing with the in-memory store in Amazon SageMaker Feature Store has saved approximately $120,000 in operational costs compared with the earlier disparate feature stores. Implementation guidance Through this feature store implementation and hard-won production lessons, we distilled the following guidance. A well-architected feature store rests on five principles. It starts with a streaming-first design that makes features available to models in real time. Centralized feature definitions support consistency and reusability across teams. A tiered storage strategy, which pairs in-memory and standard stores, balances latency against cost. Monitoring of feature store health and latency prevents silent degradation from corrupting model predictions. Underpinning this approach is cross-functional collaboration between backend, ML, and data engineering teams, which keeps feature development moving from ideation to production without handoff friction. ROI and impact Key benefits include: Accelerated model development: This approach can help reduce the time and effort required to develop new ML models by providing centralized, readily available features. Improved model accuracy: Consistent feature definitions and data access lead to more accurate ML models. Operational cost savings: Jumio achieved approximately $120K (based on its workload) in annual savings by migrating to Amazon SageMaker Feature Store without compromising latency. Enhanced customer experience: Faster and more reliable identity verification processes contribute to a more secure customer experience. Increased agility: This flexible architecture supports iterating, deploying new features, and responding to evolving business needs. Conclusion In this post, you saw how Jumio built a real-time feature store on AWS that handles high-volume data ingestion, delivers millisecond latency, and saves approximately $120,000 annually. The feature store is a core component of Jumio’s continued innovation in AI-powered identity verification. The architecture and best practices outlined in this case study provide you a proven approach for use cases such as fraud detection, recommendations, and other ML use cases that require low-latency predictions. If you’ve faced similar challenges with feature stores, share your experiences and questions in the comments. To get started, take the following next steps: Set up your Amazon Kinesis data stream to start collecting real-time data at scale for streaming data ingestion. For more information, see Amazon Kinesis. Use Amazon Managed Service for Apache Flink to process and transform your streaming [truncated for AI cost control]