Осмысление больших данных

Магазин функций как основа для машинного обучения

Искусственный интеллект и машинное обучение достигли критической точки. В 2020 году организации в различных отраслях и разного размера начали развивать свои проекты машинного обучения от экспериментальных до производства в промышленных масштабах. При этом они поняли, что тратят много времени и усилий на определение и извлечение функций.

Хранилище функций - это фундаментальный компонент стека машинного обучения и любой надежной инфраструктуры данных, поскольку он обеспечивает эффективную разработку и управление функциями. Это также позволяет легко повторно использовать функции, стандартизировать функции в рамках всей компании и обеспечить согласованность функций между автономными и онлайн-моделями. Централизованное масштабируемое хранилище функций позволяет организациям быстрее внедрять инновации и масштабировать процессы машинного обучения.

Команда Provectus создала несколько магазинов функций, и мы хотели бы поделиться своим опытом и извлеченными уроками. В этой статье мы рассмотрим, как хранилища функций могут помочь избежать доработки и обеспечить отслеживаемость данных от источника к модели в разных командах. Мы рассмотрим особенности построения масштабируемого хранилища функций и обсудим, как добиться согласованности между функциями реального времени и обучающими функциями, чтобы улучшить воспроизводимость данных при перемещении во времени.

Что такое магазин функций?

Хранилище функций - это уровень управления данными для функций машинного обучения. Функции ML - это измеримые свойства наблюдаемых явлений, такие как необработанные слова, пиксели, значения датчиков, строки данных в хранилище данных, поля в файле CSV, агрегаты (минимальное, максимальное, сумма, среднее) или производные представления (встраивание или кластер).

С точки зрения бизнеса магазины функций предлагают два основных преимущества:

  1. Повышение рентабельности инвестиций от разработки функций за счет снижения стоимости модели, что упрощает совместную работу, совместное использование и повторное использование функций.
  2. Более быстрый вывод новых моделей на рынок за счет повышения производительности инженеров по машинному обучению. Это позволяет организациям отделить реализацию хранилища и функции, обслуживающие API, от инженеров машинного обучения, освобождая их для работы над моделями, а не над проблемами задержки, для более эффективного онлайн-обслуживания.

Некоторые варианты использования не требуют централизованного масштабируемого хранилища функций. Хранилища функций работают для проектов, в которых модели нуждаются в постоянно меняющемся представлении системы с отслеживанием состояния. Примеры таких вариантов использования включают прогнозирование спроса, персонализацию и механизмы рекомендаций, динамическую оптимизацию ценообразования, оптимизацию цепочки поставок, оптимизацию логистики и транспортировки, обнаружение мошенничества и профилактическое обслуживание.

Концепции магазина функций

Стандартизованное хранилище функций имеет определенные ключевые концепции, которые вращаются вокруг него. Эти концепции:

  1. Интернет-магазин функций. Онлайн-приложения ищут вектор признаков, который отправляется в модель машинного обучения для прогнозов.

2. Метаданные, специфичные для машинного обучения. Позволяет обнаруживать и повторно использовать функции

3. API и SDK для машинного обучения. Операции высокого уровня для получения наборов обучающих функций и онлайн-доступа

4. Материализованные наборы данных с версией. Поддерживает версии наборов функций, используемых для обучения моделей машинного обучения.

Все концепции представлены на изображении выше. Аналитические данные берутся из озера данных и проталкиваются через конвейер проектирования функций, где выходные данные сохраняются в хранилище функций. Оттуда инженеры машинного обучения могут обнаруживать функции, использовать их для обучения новых моделей, а затем повторно использовать функции для обслуживания.

Эти четыре концепции поддерживаются несколькими продуктами. Лидерами рынка являются Feast, Tecton, Hopsworks и AWS SageMaker Feature Store. Мы сосредоточимся на продуктах с открытым исходным кодом: Feast и Hopsworks.

# 1 Праздник

Feast - это сервис машинного обучения, который помогает командам преодолеть разрыв между моделями данных и машинного обучения. Это позволяет командам регистрировать, принимать, обслуживать и отслеживать функции в производственной среде.

Этот сервис находится в стадии активной разработки, но уже прошел боевые испытания с GoJek, Farfetch, Postmates и Zulily. Он может быть интегрирован с Kubeflow и поддерживается сильным сообществом Kubeflow.

С 2020 года Feast доступен только для GCP. Он немного перегружен инфраструктурой, не имеет возможности компоновки и не поддерживает управление версиями данных. Обратите внимание, что компания планирует решить эти проблемы в своей дорожной карте на 2021 год. А с ноября 2020 года Feast доступен как версия Tecton с открытым исходным кодом.

# 2 Хмель

Hopsworks - это корпоративная платформа для разработки и эксплуатации приложений искусственного интеллекта. Это позволяет командам быстро и эффективно управлять функциями машинного обучения. Команда, стоящая за Hopsworks, - евангелисты специализированных магазинов, предлагающие множество отличных образовательных материалов.

Хранилище функций Hopsworks можно интегрировать с большинством библиотек Python для использования и обучения. Он также поддерживает офлайн-магазины с путешествиями во времени. Что наиболее важно, он готов к работе с AWS, GCP, Azure и локально.

Что затрудняет использование Hopsworks, так это его сильная зависимость от инфраструктуры HopsML. Кроме того, интернет-магазин Hopsworks может не удовлетворять всем требованиям к задержке.

Проблемы современных платформ данных

Прежде чем рассматривать особенности создания хранилищ функций, необходимо рассмотреть проблемы современных платформ данных. Хранилища функций нельзя исследовать изолированно от остальных данных и инфраструктуры машинного обучения.

Традиционно архитектура канонического озера данных выглядит так:

В этой высокоуровневой архитектуре есть компоненты для поиска, приема, обработки, сохранения, запросов и потребительский компонент. Хотя он отлично работает для большинства задач, он не идеален.

Доступ к данным и их обнаружение могут быть проблемой. Данные разбросаны по нескольким источникам данных и службам. Когда-то это помогало защищать данные, но теперь это только добавляет новый уровень сложности и создает разрозненные хранилища данных. Такая архитектура влечет за собой утомительный процесс управления ролями AWS IAM, политиками Amazon S3, шлюзами API и разрешениями базы данных. Это становится еще более сложным при настройке нескольких учетных записей. В результате инженеры не понимают, какие данные существуют и какие на самом деле доступны им, поскольку метаданные по умолчанию не обнаруживаются. Это создает среду, в которой инвестиции в данные и машинное обучение сокращаются из-за проблем с доступом к данным.

Монолитные группы данных - еще одна проблема, которую следует учитывать. Поскольку группы данных и машинного обучения чрезвычайно специализированы, им часто приходится работать вне контекста. Отсутствие владения и контекста предметной области создает разрозненность между производителями и потребителями данных, что значительно усложняет задачу группы обработки отложенных данных для удовлетворения требований бизнеса. Data и ML Engineering становятся жертвами сложных зависимостей, из-за которых не удается синхронизировать свои операции. В таких обстоятельствах невозможно провести быстрое и непрерывное экспериментирование.

Инфраструктура для экспериментов с машинным обучением - неизведанная территория. В традиционной архитектуре отсутствует экспериментальный компонент, что не только приводит к проблемам с обнаружением данных и доступом к ним, но и усложняет поддержание воспроизводимости наборов данных, конвейеров машинного обучения, сред машинного обучения и автономных экспериментов. Хотя Amazon SageMaker и Kubeflow добились здесь определенного прогресса, воспроизводимость проблематична. Рамки производственных экспериментов незрелы, и на них нельзя полностью полагаться. В результате на перевод одного сквозного эксперимента от данных к производственному машинному обучению может потребоваться от трех до шести месяцев.

Масштабирование машинного обучения в производственной среде - сложная задача, требующая много времени и усилий. Хотя машинное обучение в основном обсуждается как автономная деятельность (например, сбор данных, обработка, обучение моделей, оценка результатов и т. Д.), То, как модели используются и обслуживаются в режиме онлайн в реальном мире, действительно имеет значение. В традиционной архитектуре вы не можете получить доступ к функциям во время обслуживания модели унифицированным и согласованным способом. Вы также не можете повторно использовать функции между несколькими обучающими конвейерами и приложениями машинного обучения. Мониторинг и обслуживание приложений машинного обучения также более сложны. В результате время и затраты, необходимые для масштабирования от 1 до 100 моделей в производстве, растут в геометрической прогрессии, что ограничивает способность организаций внедрять инновации в желаемом темпе.

Новые архитектурные сдвиги

Чтобы решить эти проблемы, появилось несколько архитектурных изменений:

  1. От озер данных до озер Худи / Дельта. Озеро данных - это не просто папка в Amazon S3. Это многофункциональный, полностью управляемый уровень для приема данных, дополнительной обработки и обслуживания с транзакциями ACID и запросами на определенный момент времени.
  2. От озер данных к сетке данных. Владение доменами данных, конвейерами данных, метаданными и API переходит от централизованных команд к группам разработчиков. Еще одно важное преимущество - это обращение с данными и владение ими как с законченным продуктом, а не как побочный эффект, который никого не волнует.
  3. От озер данных к инфраструктуре данных как платформе. Если владение данными децентрализовано, компоненты платформы должны быть унифицированы и упакованы в платформу данных многократного использования.
  4. От защиты конечных точек к глобальному управлению данными. В рамках перехода к централизованным платформам данных организации переходят от Endpoint Protection к GLobal Data Governance, который представляет собой план контроля более высокого уровня для управления политиками безопасности и доступа к данным из доступных источников данных.
  5. Из хранилища метаданных в глобальный каталог данных. Хранилища метаданных, такие как хранилище метаданных Hive, не могут агрегировать множество источников данных. Отрасли нужен глобальный каталог данных для поддержки взаимодействия с пользователем при обнаружении, происхождении и управлении версиями данных.
  6. Магазин функций. Хранилище функций - это новый развивающийся компонент стека машинного обучения, который позволяет масштабировать эксперименты и операции машинного обучения путем добавления отдельного уровня управления данными для функций машинного обучения.

Все эти преобразования происходят параллельно, и их следует рассматривать как единое целое. Вы не можете начать проектирование хранилища функций и в конечном итоге получить отдельные каталоги данных для функций и других приложений данных. При создании хранилища функций вы должны полагаться на функции управления версиями данных, которые легко могут быть частью других параллельных проектов.

Прежде чем двигаться дальше, несколько слов о четырех основных компонентах, которые управляют вышеупомянутыми преобразованиями от разрозненных заданий ML к MLOps, чтобы обеспечить более широкий контекст для важности хранилищ функций.

# 1 Дельта / Худи Лейкс

Озера данных ACID обеспечивают управляемую загрузку, эффективное управление версиями наборов данных для обучения машинному обучению, дешевые «удаления», чтобы сделать их совместимыми с GDPR / CCPA, и «upserts» для приема данных. Они также предлагают журнал аудита для отслеживания изменений набора данных и транзакций ACID, обеспечивая при этом качество данных с помощью схем. Озера Дельта и Худи обеспечивают потоковую обработку больших данных, предоставляя свежие данные намного эффективнее, чем традиционная пакетная обработка.

# 2 Глобальное управление данными

Поскольку управление ролями AWS IAM, политиками Amazon S3, шлюзами API и разрешениями базы данных на уровне пользователя больше не является стандартом, структура управления данными в масштабах компании должна использоваться для:

  1. Ускорьте операции по обеспечению конфиденциальности с помощью уже имеющихся данных. Автоматизируйте бизнес-процессы, сопоставление данных, а также обнаружение и классификацию PI для рабочих процессов конфиденциальности.
  2. Централизованно применяйте политики. Управляйте политиками конфиденциальности, чтобы обеспечить эффективное управление политиками в масштабах всего предприятия. Определяйте и документируйте рабочие процессы, представления прослеживаемости и реестры бизнес-процессов.
  3. Масштабирование соответствия между несколькими нормативными актами. Используйте платформу, разработанную и созданную с учетом конфиденциальности, которую можно легко расширить для поддержки новых нормативных требований.

# 3 Глобальный каталог данных

Хотя здесь нет единого лидера рынка, стоит упомянуть Marquez, Amundsen, Apache Atlas, Collibra, Alation и Data Hub.

Глобальный каталог данных чрезвычайно полезен для ответа на такие вопросы, как: существуют ли эти данные? Где это находится? Каков источник достоверности этих данных? У меня есть доступ? Кто владелец? Кто использует эти данные? Могу ли я повторно использовать существующие активы? Могу ли я доверять этим данным? По сути, он действует как своего рода хранилище метаданных.

# 4 воспроизводимые конвейеры ML

Последний компонент - воспроизводимые конвейеры машинного обучения для экспериментов.

На приведенной выше диаграмме представлена ​​архитектура MLOps и воспроизводимых конвейеров экспериментов. Он начинается с четырех входов: кода модели ML, кода конвейера ML, инфраструктуры как кода и набора данных с поддержкой версий. Версионный набор данных - входные данные для вашего конвейера машинного обучения - должен быть получен из хранилища функций.

Современная инфраструктура данных

Теперь давайте посмотрим на современную инфраструктуру данных.

У нас есть пакетная обработка необработанных данных и потоковая обработка данных о событиях. Мы храним обработанные артефакты в холодном хранилище для бизнес-отчетов и в инкрементно обновляемом горячем индексе нашего API почти в реальном времени. Одни и те же данные могут использоваться в обоих сценариях, и, чтобы сделать их согласованными, мы используем разные системы публикации / подписки.

Это традиционная архитектура для платформ данных. Его цель - обеспечить согласованность между холодным и горячим хранилищами, а также обеспечить возможность обнаружения из каталога данных, качества данных и глобальной безопасности с точным контролем поверх этого.

Если мы посмотрим на дизайн магазина функций, мы увидим функции и компоненты инфраструктуры, почти идентичные тем, что есть в платформе данных. В этом случае хранилище функций не является отдельным хранилищем, в котором есть еще одна система приема, хранилище, каталог и ворота качества. Он служит легким API между нашей платформой данных и инструментами машинного обучения. Его можно хорошо интегрировать со всем, что уже было сделано в вашей инфраструктуре данных. Он должен быть составным, легким и без резкого дизайна.

Когда вы начнете проектировать и создавать свою инфраструктуру данных, примите во внимание следующие «извлеченные уроки»:

  1. Прежде чем вкладывать средства в магазин функций, начните с разработки согласованного озера данных ACID.
  2. Ценность существующих продуктов с открытым исходным кодом не оправдывает инвестиций в интеграцию и зависимости, которые они приносят.
  3. Хранилище функций - это не новая инфраструктура и решение для хранения данных, а упрощенный API и SDK, интегрированный в существующую инфраструктуру данных.
  4. Компоненты каталога данных, управления данными и качества данных являются горизонтальными для всей инфраструктуры данных, включая хранилище функций.
  5. Не существует зрелых решений с открытым исходным кодом или облачных решений для глобального каталога данных и мониторинга качества данных.

Эталонная архитектура

На этой диаграмме показана эталонная архитектура, которую мы использовали для наших клиентов. В нем представлены услуги, которые мы решили использовать, но вы не должны ограничиваться нашим выбором. Идея здесь в том, что вам нужно выбрать холодное и горячее хранилище в зависимости от рабочих нагрузок данных и потребностей вашего бизнеса.

Для горячего хранения вы можете выбрать DynamoDB, Cassandra, Hbase или традиционные СУБД, такие как Mysql, PostgreSQL или даже Redis. Важно, чтобы ваше горячее хранилище было компонуемым, подключаемым и соответствовало вашей стратегии инфраструктуры данных.

Наши фавориты - это Apache Hudi и Delta lake. Они предлагают такие функции, как «Путешествие во времени», «Инкрементальный захват» и «Материализованные представления».

На диаграмме есть пустые места, которые мы надеемся вскоре заполнить. Например, для каталога данных пока нет лидера-лидера. Инструменты качества данных также находятся на начальной стадии. На данный момент вы можете выбрать Great Expectations или Apache Deequ, которые являются отличными инструментами, но они не обеспечивают полного решения.

На изображении выше вопросительные знаки занимают места, где вы можете выбирать из решений, созданных сообществами с открытым исходным кодом, создавать собственные решения или сотрудничать с поставщиками облачных услуг (например, последнее дополнение AWS - Магазин функций Amazon SageMaker для машинного обучения »).

Движение вперед с магазином функций

Хотя магазины функций еще находятся на ранней стадии разработки, организации, которые не просто экспериментируют, но и активно переносят проекты машинного обучения в производственную среду, уже осознали необходимость иметь централизованный репозиторий для хранения, обновления, извлечения и совместного использования функций.

В этой статье мы показали, как спроектировать и построить такой репозиторий. Хотя некоторые из представленных здесь моментов спорны и открыты для отзывов сообщества, ясно, что:

  1. Для достижения желаемого результата ваша существующая инфраструктура данных должна покрывать не менее 90% требований к хранилищу функций, включая прием потоковой передачи, согласованность, каталог данных и управление версиями.
  2. Имеет смысл создать облегченный API магазина функций для интеграции с существующими решениями хранения внутри компании.
  3. Вам следует сотрудничать с сообществом и поставщиками облачных услуг, чтобы поддерживать совместимость со стандартами и современными экосистемами.
  4. Вы должны быть готовы перейти на управляемую службу или альтернативу с открытым исходным кодом по мере развития рынка.

Не стесняйтесь делиться своим видением магазинов функций. Мы открыты для обсуждения.