Недостающее звено инфраструктур машинного обучения. Часть 3/3
Это третья часть серии статей: Магазины функций машинного обучения: случайный тур; Часть 1; Часть 2;
В части 1 этого тура мы рассмотрели плюсы и минусы наличия магазина функций машинного обучения в вашей организации машинного обучения. Во второй части мы рассмотрели компоненты и цели четырех магазинов функций: Hopsworks Feature Store, Go-Jek Feast, Uber Michelangelo, и Библиотеки функций Twitter / Store.
В части 3 этого тура мы рассмотрим другие примеры публично описанных хранилищ функций:
- Магазин функций Airbnb Zipline / среда разработки функций.
- Магазин фактов и возможностей Netflix
- Управление функциями Linkedin
Меры предосторожности. Магазины функций - это быстро меняющиеся компоненты инфраструктуры. В этой публикации сообщается об общедоступной информации, доступной по состоянию на 1 квартал 2020 года. Пожалуйста, проверьте соответствующие источники, чтобы получить последнюю информацию об эволюции этих систем.
Давай сделаем это.
Магазин функций Airbnb Zipline
Мотивация
Airbnb имеет множество основных приложений машинного обучения, которые постоянно улучшаются. Этот постоянный отток сопровождается обычными проблемами, с которыми сталкиваются исследователи машинного обучения. Один из них - это уровень управления объектами. Команда инфраструктуры машинного обучения в Airbnb разработала сквозную систему машинного обучения под названием Big Head, которая обеспечивает большинство инструментов и требований к инфраструктуре, которые потребуются для продукта машинного обучения в Airbnb. Компонент, который нас интересует в этой публикации, - это уровень управления функциями.
Сосредоточение на запросах на определенный момент времени для устранения перекоса при обучении / обслуживании
Особое внимание уделяется получению своевременных запросов прямо в презентациях, доступных по теме. Этот фокус PIT описан на следующей диаграмме. Запросы Zipline на момент времени генерируют данные, которые ближе к данным, которые модели видят в производственной среде. В этом случае у нас есть традиционная дневная граница DW для ежедневных заданий. Модель предполагает, что во время прогнозирования P1 функция 1 записывала значение 5, в то время как при обслуживании она фактически видела значение 7. В этом примере строгий характер разделения хранилища данных эффективно привел к неявному обучению / обслуживают перекос данных. Этот перекос данных приводит к не такой уж необычной реакции исследователей машинного обучения: «Он отлично работает в автономном режиме, но производительность в Интернете не так хороша. Интересно, что случилось ?! ».
Когда это сильно помогает
Авторы системы Zipline осознавали, что сложность такого рода мелкозернистого хранилища функций может не подходить для всех вариантов использования. На следующей диаграмме они показывают, как прогнозы на основе событий получают наибольшую выгоду от этого сложного хранилища функций. Преимущество становится еще более очевидным, когда в продукте для прогнозирования присутствует компонент, работающий почти в реальном времени. Другие продукты для прогнозирования, в которых время не имеет такого значения, например, классификация документов / изображений или категоризация статических структурированных объектов (которые имеют свой собственный набор проблем во время обучения), не получают такой пользы от системы такого типа.
Компоненты магазина функций
Инженерная структура функций Zipline является важным компонентом автономного обучения и компонентов онлайн-обслуживания. Что касается подающей стороны, оценка модели и подача обоих подаются из системы Zipline.
Такой способ управления функциями обеспечивает традиционный набор преимуществ, например, делает функции доступными для поиска и понятными. Преобразования идентифицируются с помощью определения функции, а основные выбросы могут быть обнаружены с помощью вычисления статистики функции. Это дает пользователям возможность пользоваться корзиной покупок с помощью пользовательского интерфейса.
Определение функций и API обучающего набора
Zipline позволяет пользователям определять функции, используя источники и определения функций. В приведенном выше примере пользователь ML предоставляет запрос, который определяет источник данных с помощью первичного ключа и отметки времени. Затем функция определяется путем выбора имени столбца, операции и временных окон, необходимых для каждой функции.
Поддерживаемые преобразования функций и требования к функциям
Для поддержки возможности запросов о путешествиях во времени, которые предоставляет Zipline, авторы ограничили тип поддерживаемых преобразований функций. Это сумма, количество, минимум, максимум, последние N, статистические моменты, приблизительные уникальные подсчеты, процентили, а также фильтры цветения. Кроме того, с упором на временные метки, эти преобразования поддерживаются с полной функциональностью временного окна. Преобразования поддерживаются из-за их масштабируемости. Операции должны обладать коммутативными, ассоциативными и, возможно, обратимыми свойствами. Эти свойства приводят к постоянным требованиям к вычислению времени и пространства для функций, которые соответствуют этим ограничениям.
API обучающего набора
На стороне пользователя Zipline предоставляет API обучающего набора, который определяет функции для извлечения и запрос, определяющий временной диапазон, для которого требуются функции. Выходные данные состоят из начальных функций разработчика, таких как пользователь и листинг, в дополнение к предоставленным Zipline столбцам, таким как bookings_sum_7d и booking_sum_14d, которые были объявлены на этапе определения функции.
Во время оценки это хранилище функций используется для обогащения запроса оценки и возврата функций, необходимых для службы прогнозирования, чтобы возвращать полезные прогнозные значения.
Мысли
Zipline предоставляет сложную инфраструктуру для обработки данных на уровне событий с компонентами онлайн-обслуживания. Эта система ориентирована на эффективные запросы на определенный момент времени. Эта система позволяет пользователям определять функции из ограниченного набора функций, экономящих время и пространство. Пользователю предоставляется полностью декларативный API, который можно использовать во время обучения и подсчета очков. Как описывают авторы, сложность, которую вносит такая система, уравновешивает потребности в прогнозировании в реальном времени на основе событий. Однако некоторые варианты использования, которые не сильно зависят от прогнозов на основе времени, не получат выгоды от такой системы. Характеристики этой системы могут слишком сильно ограничивать пространство функций для других приложений. В целом, если вам интересно узнать о том, как работают запросы на определенный момент времени, эта презентация более подробно описывает, как выполняются различные предварительные вычисления и как онлайн и офлайн данные используются для создания функций. .
Магазин фактов и функций Netflix
Netflix находится в авангарде рекомендательных систем с момента их создания. У них есть продукт мирового класса, который делает ставку на индивидуальный опыт каждого зрителя. С этой целью командам машинного обучения в Netflix необходимо постоянно улучшать пользовательский интерфейс. Основная цель движков Netflix recsys заключается в том, что как только пользователь садится и открывает приложение, система должна порекомендовать фильм, который пользователь сразу же посмотрит. Достичь такого уровня чтения мыслей настолько сложно, и становится только хуже, когда вы имеете дело с 150-миллионными пользователями по всему миру.
Чтобы решить эти бизнес-проблемы, команда инфраструктуры машинного обучения прошла несколько итераций, связанных с управлением функциями. Из публичных презентаций и сообщений в блогах я смог найти следующую прогрессию:
- Создание функции из данных событий из хранилища данных. Это привело к необходимости повторной реализации этапов разработки функций в онлайн-обслуживании.
- Регистрируйте особенности онлайн, когда модель тренируется. Это означает, что каждую идею новой функции необходимо внедрять в продукте, и пользователю нужно долго ждать, чтобы получить достаточно данных для этой новой функции.
- Генерация функций напрямую вызывает онлайн-сервисы и выбирает данные по временному диапазону. Это привело к перегрузке служб, и некоторые службы не ведут журнал исторических событий.
Это привело к тому, что команда Netflix разработала «машину времени», чтобы иметь возможность предоставлять спроектированные функции в определенный момент времени. Система, которую они обнародовали, называется Delorean, что означает возврат к будущей франшизе. Эта система работает на этапе создания автономных функций.
Чтобы выполнить создание функции в автономном режиме, пользователь взаимодействует с этой системой следующим образом:
Пользователь предоставляет модель функций в формате JSON с ключами необходимых функций. Тогда система DeLorean знает, как запрашивать помеченные / обучающие данные вместе с данными фактов из повторяющихся снимков. Затем он использует кодеры общих функций для преобразования этих обучающих данных в наборы данных с характеристиками. Эти наборы данных затем передаются на обучение модели.
Чтобы унифицировать конвейеры обслуживания и обучения, инфраструктура позволяет совместно использовать «кодировщики функций» и файлы моделей. Используя этот метод, онлайн-конвейер точно отражает конвейер обучения.
Сама машина времени находится на столах Hive, поддерживаемых S3, и претерпела ряд эволюций. Первоначально он был основан на опрашивающей платформе, которая создавала моментальные снимки любых данных, определенных для создания моментальных снимков. Эта архитектура была основана на ежедневных снимках на уровне фактов путем опроса микросервисов фактов. К недостаткам этого метода, о которых сообщали, были нагрузка на микросервисы, отсутствие временной точности из-за несоответствия времени обработки события и времени обработки, а также отсутствие конкретных фактов, связанных с экспериментом, поскольку процессу захвата необязательно учитываются новые факты, которые необходимо учитывать. снимок.
Вторая итерация хранилища фактов Netflix изменила направление конвейера на противоположное, переместив перемещение данных в модель на основе push. В этом методе каждая участвующая служба включает регистратор фактов, который сама служба использует для отправки фактов в очередь обмена сообщениями. Затем эти факты преобразуются и сохраняются в хранилище фактов. Со стороны читателя, из-за дополнительных знаний, которые должны существовать между преобразователем фактов и устройством чтения, была введена библиотека сборщика фактов для стандартизации и развития шаблона доступа.
Архитектура push требует, чтобы клиенты отправляли данные с их собственной скоростью и с их собственным управлением версиями. На диаграмме ниже показаны некоторые из использованных стратегий.
Управление версиями данных было смягчено за счет использования сообщений Protobuf, которые обеспечивают определенный уровень согласованности схемы между производителями и потребителями этих фактов. Проблемы с производительностью из-за переменной скорости публикации были смягчены за счет включения дополнительной логики в библиотеку регистратора фактов, которая находится внутри служб. Регистратор фактов включает сильное сжатие, а также возможность взаимодействия со службой дедупликации. Эта служба дедупликации сокращает объем принимаемых данных. Он просматривает факты, которые отправляются службами, и проверяет, есть ли какие-либо изменения в значениях. Если никаких изменений не обнаружено, сохраняются только указатели наборов данных, что сокращает объем данных, хранящихся в хранилище фактов.
Мысли
Хранилище фактов Netflix - еще одна попытка преодолеть разрыв между традиционными задачами ELT и вариантами использования DS / ML. В этом сценарии метод развертывания модели основан на совместном использовании библиотеки преобразования функций и предварительно обученных моделей. Библиотеку трансформации можно использовать как во время обучения / исследования, так и во время производства. Требования SLA и QPS для рекомендательных систем Netflix достаточно низки, чтобы позволить приложениям гидратировать запрос прогноза с данными функций онлайн, но я подозреваю, что многие рекомендации для пользователей создаются в автономном режиме, что позволяет использовать более мягкие SLA. Эта система является огромным преимуществом для такого рода приложений машинного обучения, поскольку она может извлекать гораздо более богатые данные о функциях и тем самым обслуживать более сложные системы рекомендаций.
Системы управления функциями LinkedIn
Мотивация
LinkedIn - ведущая платформа для объединения людей для реализации их миссии. Некоторые из наиболее ярких примеров использования включают людей, которых вы можете знать, рекомендации по фидам, поиск рекрутера, поиск работы, рекомендации по обучению и продажи. Эти варианты использования по своей сути загружены компонентами машинного обучения для достижения бизнес-целей организации. LinkedIn также очень активен во многих исследовательских и прикладных областях, и они открыто говорят о своих внутренних проблемах с продвижением идей в производство. Это отражено во многих выступлениях, статьях и презентациях, где публике предлагается заглянуть внутрь своей инфраструктуры машинного обучения.
1. Первые дни - Modoop
О первоначальной версии публично описанного управления функциями в Linkedin было сообщено в начале 2015 года здесь. В этой презентации авторы описали систему Modoop, которая управляет жизненным циклом машинного обучения. Особое внимание уделяется управлению функциями в хранилище данных (DM2), а также разработке функций, которые применяются к достоверным данным для тестирования.
Система Modoop управляет созданием и потреблением функций. И DM2 (витрина данных для интеллектуального анализа данных), и оценки моделей наземной истины ориентированы на Hadoop / Spark для обработки обширных наборов данных, генерируемых платформой Linkedin.
2. Масштабное производство
Следующая итерация платформы машинного обучения, которую использует LinkedIn, называется Pro-ML. В этом посте и в этой презентации мы можем заглянуть внутрь представленного рынка, который является одним из столпов инфраструктуры pro-ml.
Торговая площадка функций
В презентациях Pro-ML рынок функций описан на снимке экрана пользовательского интерфейса. Там мы можем увидеть, как организованы функции. Эта структура включает в себя категории источников функций, а также их типы данных, тип функции, статус в белом списке, окно агрегирования. Каждая функция получает имя, тип данных / функции, описание для документации и длину агрегирования. Вероятно, есть намного больше столбцов, представляющих каждую функцию.
Абстракция кадра
Торговая площадка функций взаимодействует с вычислительной инфраструктурой и инфраструктурой хранения через абстракцию фреймов. Как показано на схеме ниже, общие библиотеки фреймов предоставляют унифицированный интерфейс между заданиями соединения автономных функций, автономным хранилищем, онлайн-клиентом фреймов и онлайн-базами данных. Система управления функциями фрейма настраивается с помощью конфигурируемых функций фрейма, что взаимодействует с репозиторием моделей машинного обучения, который связывает модели с функциями, которые они используют. Эта абстракция фреймов дополнена инструментами для отладки функций и мониторинга функций, чтобы включить поиск функций на основе текущего использования и характеристик функций.
Последние события 2020 года
Одно из недавних изменений в управлении функциями для фида домашней страницы было недавно публично описано здесь. В этом посте авторы упоминают проблемы масштабируемости, связанные с сотнями онлайн-экспериментов в месяц над дюжиной новых функций, выборкой, обработкой и передачей более 100 существующих функций и рендерингом основного фида для тысяч членов в секунду .
В сообщении выше сообщается о проблемах, связанных с компромиссом между гибкостью, более сильными типами и эффективностью, из-за которых экосистема машинного обучения LinkedIn не синхронизировалась. Что касается гибкости, то в заданиях Spark и механизмах вывода использовались строки для хранения категориальных элементов и одного типа значений с плавающей запятой, что приводило к проблемам с эффективностью. Точно так же задания моментального снимка HDFS были специфичными для функций. Кроме того, оптимизация хранилища не была стандартизирована для онлайн-систем из-за разнесения жизненных циклов разработки.
Несинхронизированная комбинация схем и гибких типов данных означала, что обновление всех соответствующих API / баз данных занимало много времени. Это мешало гибкости, необходимой для экспериментов. На диаграмме ниже авторы сообщают как минимум о трех различных проблемах форматирования и преобразования.
Чтобы решить эту проблему с форматом данных, авторы сообщают о новом формате, основанном на тензоре и использующем централизованную библиотеку метаданных в сочетании с хранилищем метаданных функций. Владельцам функций предоставляется единый метод определения и регистрации своих функций в централизованном хранилище метаданных функций. Каждой функции присваивается URN. Потребители могут извлекать схему, формат, категории, временные окна и другие метаданные о каждой функции. Сообщаемое преимущество заключается в том, что потребителям не нужно реализовывать преобразования формата данных с использованием логики, заложенной в производителях данных функций. На диаграмме ниже показан пример конфигурации определения функции.
Авторы приводят сравнение с одной из предыдущих пользовательских схем кодирования. Они отмечают, что с этой настраиваемой кодировкой «понятность сочетается с форматами сериализации». В приведенном ниже примере они показывают, как вместо кодирования важной информации в строковых форматах новый формат позволяет использовать более упорядоченный тензорный формат.
Далее авторы осознают, что после унификации формата посредством общей схемы возникает проблема, как совместно использовать эту информацию схемы. Авторы противопоставляют функции с самоописанием и методы совместного использования схем на основе Avro со специальной библиотекой разрешения метаданных. Создавая версии этой библиотеки разрешения метаданных, потребители могут получить всю необходимую информацию о схемах функций перед использованием модели. Наконец, чтобы иметь дело с новыми категориальными функциями, которые проходят через систему LinkedIn, авторы сообщают об унифицированном механизме категориального хеширования для генерации стандартизированных значений сопоставления для новых строк и новых категорий. Ниже приведен пример потока данных, который обновляет сопоставления категорий.
Используя эту систему, авторы сообщают об упрощенном процессе развертывания онлайн-функций. Сообщается, что эта система также снижает когнитивную нагрузку, необходимую для управления «сотнями строк онлайн-кода переформатирования, процессами анализа схем в нескольких группах, настраиваемыми автономными соединениями плюс форматы» и трансформирует ее для использования «конфигураций и фиксированных схем».
Мысли
Большой проект по унификации, подобный тем, что описан в этой работе, является свидетельством приверженности продукта компонентам машинного обучения в LinkedIn. Попытка унифицировать и предоставить стандартную платформу функций для нескольких команд, работающих над параллельными продуктами, требует значительных инвестиций для достижения успеха. Эволюция систем управления функциями LinkedIn показывает стандартный путь, который адаптируется к потребностям бизнеса. Это включает в себя ранние этапы, которые сосредоточены на небольшом кусочке продукта. По мере роста популярности продукта и увеличения числа инженерных групп, ответственных за разработку продукта, важность интерфейсов между системами становится первостепенной. Усилия LinkedIn привели к определению удобного для машинного обучения формата данных, управления схемами и пути миграции.
Постоянный поток централизации и децентрализации, выталкивания и выталкивания, самодокументирования и общей схемы, декларативного и процедурного, унифицированного и настраиваемого, горизонтального или вертикального масштабирования, структурированной и неструктурированной абстракции - это давние компромиссы, которые были применены к компьютерным системам с первых дней вычислений. Тот факт, что мы видим исследование этих компромиссов во многих продуктах, ориентированных на машинное обучение, - это свежий взгляд на старую классику.
Что ж, было очень весело :). На этом этот случайный тур по магазинам функций машинного обучения заканчивается. Я надеюсь, что этот трехэтапный тур, в котором мы рассмотрели семь различных магазинов функций, дал вам достаточно материала, чтобы заняться вашим следующим производственным конвейером машинного обучения.
Вот несколько ссылок, чтобы глубже изучить системы, которые мы описали в этом посте (и другие, которые мы не рассматривали в этом туре, но которые одинаково интересны):
Полезная ссылка с видео бесед по теме: http://featurestore.org/
Airbnb https://www.thestrangeloop.com/2019/zipline---a-declarative-feature-engineering-library.html
Airbnb: https://databricks.com/session/zipline-airbnbs-machine-learning-data-management-platform
Netflix: https://vimeo.com/274954151
Netflix: https://www.youtube.com/watch?v=VWWdwEAlgyU
Netflix: https://www.slideshare.net/sfbiganalytics/distributed-time-travel-for-feature-generation-at-netflix
LinkedIn: https://engineering.linkedin.com/blog/2020/feed-typed-ai-features
LinkedIn: https://www.youtube.com/watch?v=3V34X8Lci80
Епископ, Кристофер (2006). Распознавание образов и машинное обучение. Берлин: Springer.
Фотография к заголовку: https://unsplash.com/photos/NMF5sEaHUmo
Заявление об ограничении ответственности: Мнения, выраженные в этом посте, принадлежат мне и не обязательно отражают взгляды моих нынешних или прошлых работодателей.
