Jumio, компания, специализирующаяся на верификации личности и борьбе с мошенничеством, столкнулась с типичными для ML-инфраструктуры проблемами: дублирование данных, ручное развертывание фич и высокая латентность. Для решения этих задач инженеры Jumio совместно с AWS разработали архитектуру real-time feature store, которая обеспечивает подачу признаков моделям менее чем за 100 миллисекунд. Это критично для fraud detection, где решения принимаются в реальном времени.
Feature store — это централизованное хранилище признаков (features), используемых для обучения и инференса ML-моделей. В случае Jumio, модели зависят от большого количества фич, которые должны быть доступны мгновенно. До внедрения feature store команды поддерживали собственные офлайн-хранилища, что приводило к дублированию и несогласованности определений. Ручная реализация фич в продакшене увеличивала риск ошибок, а задержки в обработке событий, которые могут приходить с опозданием до нескольких недель, усложняли своевременное обнаружение мошенничества.
Архитектура, описанная в блоге AWS, построена по принципу streaming-first. Данные поступают через Amazon Kinesis Data Streams, где Apache Flink обрабатывает их в потоке, обогащает и записывает в Amazon SageMaker Feature Store. Для офлайн-обработки используется параллельный путь: события попадают в Amazon S3 через Data Firehose, затем Amazon EMR выполняет тяжелые трансформации и загружает результаты в Iceberg-таблицы для обучения моделей. Такое разделение позволяет поддерживать как real-time инференс, так и периодическое переобучение.
Архитектура включает потоковую обработку через Kinesis и Flink, а также офлайн-хранилище на Iceberg.
Ключевые компоненты включают Amazon ElastiCache for Valkey для хранения горячих данных в памяти, что обеспечивает низкую латентность чтения и эффективную запись. Холодные данные хранятся в SageMaker Feature Store и Iceberg. Система развернута в трех регионах AWS: us-east-1, eu-central-1 и ap-southeast-1, что обеспечивает глобальную доступность и отказоустойчивость.
Проект решает пять ключевых требований: масштабируемость, поддержка сложной инженерии фич (включая условное создание на основе времени событий), низкая латентность, возможность backfill исторических данных и гибкость в разработке фич. Последнее особенно важно: команды могут независимо добавлять новые фичи без лишней координации, что ускоряет цикл разработки.
Для специалистов, которые только знакомятся с темой, стоит пояснить: feature store — это слой между источниками данных и ML-моделями, который стандартизирует и ускоряет доступ к признакам. Подход Jumio может быть полезен компаниям, работающим с real-time предсказаниями, например в финансовом секторе или e-commerce. Однако архитектура требует значительных инвестиций в инфраструктуру и экспертизу в потоковой обработке.
В целом, кейс Jumio демонстрирует, как правильно спроектированный feature store может решить проблемы дублирования, задержек и ручного деплоя, что в итоге повышает точность и скорость ML-систем.
