# Майк дел Бальсо: «2021 год станет годом Feature Store в индустрии ML» Источник: https://www.youtube.com/watch?v=kty5JVc0b8w Канал: The TWIML AI Podcast Опубликовано: 11.11.2020 --- Майк дел Бальсо, сооснователь и генеральный директор Tecton, вернулся в подкаст TWIML AI спустя два с половиной года после своего первого визита, чтобы обсудить эволюцию MLOps. В беседе с ведущим Сэмом Чаррингтоном он объясняет, почему именно Feature Store (хранилище признаков) стало тем недостающим звеном, которое позволяет компаниям масштабировать машинное обучение и превращать экспериментальные модели в работающие бизнес-продукты. ## 🛠 От Google до Uber: рождение концепции Feature Store [[JUMP:02:43]] Майк дел Бальсо начал свой путь в Google, работая над системами машинного обучения (ML) для рекламных аукционов. По его словам, в Google эти процессы были максимально «продакшн-ориентированными» ещё до того, как термин MLOps стал общепринятым [03:08]. Перейдя в Uber в 2015 году, дел Бальсо столкнулся с иным вызовом: компания имела лишь несколько моделей в производстве и не обладала готовой инфраструктурой для их масштабирования. Вместе с командой он разработал Michelangelo — платформу, которая позволила Uber совершить качественный скачок в использовании ИИ. Оглядываясь назад, Майк отмечает: самым ценным компонентом этой платформы оказался именно Feature Store, хотя тогда команда даже не использовала этот термин [06:25]. Основные выводы из опыта в Uber: * **Скрытая работа:** Data Scientist-ы тратят 85% времени на очистку данных, но существует ещё «скрытые 85%» времени, необходимых для вывода модели в продакшн [05:18]. * **Путь к производству:** Feature Store позволил командам быстро переходить от прототипа к работающему сервису, минуя длительный этап ручного переписывания пайплайнов данных инженерами [06:10]. * **Многократное использование:** Вместо того чтобы создавать одинаковые признаки (например, среднюю стоимость поездки пользователя) с нуля, разные команды начали использовать единый канонический каталог [06:51]. ## 🤝 Проблема сотрудничества и «налог на надежность» [[JUMP:08:46]] Одной из главных сложностей внедрения Feature Store является сопротивление со стороны индивидуальных исследователей данных. Ведущий Сэм Чаррингтон отметил, что публикация признака в общее хранилище накладывает на автора обязательства по его поддержке, что может восприниматься как лишнее бремя [08:58]. Майк дел Бальсо подтверждает наличие этой «проблемы доверия», но подчеркивает, что без централизованной системы эффективность падает: 1. **Дублирование усилий:** Часто два специалиста, сидящих рядом, строят одни и те же 100 признаков, потому что не знают о работе друг друга или не имеют механизма для переиспользования [10:15]. 2. **Роль метаданных:** Современные хранилища признаков отслеживают не только сами данные, но и метаданные: кто владелец, каков уровень SLA (Tier-1 или Tier-2), является ли признак экспериментальным или промышленным [11:51]. 3. **Централизованные команды:** Дел Бальсо выделил новый тренд — появление выделенных команд внутри ML-платформ, которые берут на себя владение самыми важными и часто используемыми признаками, снимая эту нагрузку с отдельных дата-сайентистов [13:37]. ## 🏗 Пять столпов современного Feature Store [[JUMP:21:35]] Объясняя техническую суть системы, Майк выделил пять ключевых компонентов, которые превращают обычное хранилище данных в инструмент для MLOps: 1. **Transformation Layer (Слой трансформации):** Преобразует сырые данные в значения признаков [21:47]. 2. **Storage Layer (Слой хранения):** Организует хранение для быстрого извлечения данных как в реальном времени (онлайн), так и для обучения (оффлайн) [21:55]. 3. **Serving Layer (Слой выдачи):** Обеспечивает низкую задержку при получении признаков для работающей модели и консистентность данных между обучением и продакшном [22:02]. 4. **Central Registry (Центральный реестр):** Содержит определения признаков и метаданные, являясь «неизменяемой записью» о том, что использовалось в производстве [22:29]. 5. **Monitoring Layer (Слой мониторинга):** Отслеживает операционные метрики и корректность данных, предотвращая сбои в работе моделей [22:42]. Дел Бальсо подчеркивает, что Feature Store не заменяет существующую инфраструктуру (например, Snowflake или Amazon S3), а интегрируется с ней, выполняя роль координатора [24:14]. ## 📈 Рынок и будущее: 2021 год как переломный момент [[JUMP:30:52]] Согласно прогнозу Майка, 2021 год станет «годом Feature Store» [30:52]. Он отмечает, что даже те компании, которые начали с внедрения сложных систем AutoML, быстро упираются в проблему подготовки данных: «Легко перетащить CSV-файл в систему обучения, но трудно понять, откуда этот файл взялся и как обновлять его в реальном времени» [16:59]. Обсуждая конкурентную среду, Майк выделил несколько игроков: * **Open Source:** Проект Feast (созданный Go-Jek совместно с Google Cloud) — легкое и мощное решение для старта [30:24]. * **Enterprise:** Собственное решение Mike del Balso — Tecton, ориентированное на крупный бизнес с жесткими требованиями к SLA и управлению в облаке (AWS) [30:38]. Майк также затронул тему Deep Learning. По мнению гостя, даже в эру глубокого обучения, которое якобы само находит признаки, хранилища остаются актуальными. Они используются для управления эмбеддингами и доставки контекстных данных о пользователе в реальном времени, что критично для рекомендательных систем [45:02]. ## 💡 Советы для бизнеса: когда пора внедрять Feature Store? [[JUMP:42:14]] Для компаний, раздумывающих над архитектурой, дел Бальсо предлагает два простых критерия: 1. **Наличие Real-time компонента:** Если ваша модель должна реагировать на действия пользователя мгновенно, вам почти наверняка понадобится онлайн-хранилище признаков [42:53]. 2. **Проблема масштаба:** Если у вас больше «горстки» моделей и признаков, управление ими через Google-таблицы (что Майк называет распространенным паттерном) неизбежно приведет к хаосу [43:31]. Главный совет Майка — «начинать с простого» и не переусложнять стек ради самих технологий [48:53]. Он рекомендует консультироваться с теми, кто уже проходил путь внедрения ML, чтобы избежать типичной ошибки — инвестирования в сложные алгоритмы при отсутствии порядка в базовой инфраструктуре данных.