Контекст

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

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

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

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

Общая архитектура ведения журнала

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

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

Производители, используемые в службах ML, — это оболочка, которую мы разработали, чтобы абстрагировать логику построения и подключения к внешнему ресурсу (в данном случае Kafka) и гарантировать стандарт полезной нагрузки.

Полезные нагрузки отправляются в тему Apache Kafka. Известно, что Kafka подходит для обработки очень больших объемов данных с надежностью и приличной отказоустойчивостью. В этом разделе используется равномерное распределение сообщений (полезных данных), чтобы избежать асимметрии и последующего использования Spark, используя свой параллелизм. Для «n» ML-сервисов у нас есть одна тема с «k» разделами. Наконец, после того как мы прочитаем и обработаем все доступные данные в пакете, мы сохраним их в нашем хранилище данных, доступном нашему специалисту по обработке и анализу данных, а также средствам визуализации и платформы данных.

Инженерные настройки

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

  1. Чтение данных в виде пакетов вместо прямой трансляции. Использование потоковой передачи в качестве потребителя является убедительным, поскольку нам нужно читать из Кафки. Однако, поскольку данные, которые мы читаем, не являются критически важными, мы можем считывать данные периодическими пакетами. Чтобы сохранить запись смещения Kafka, мы используем API потока записи Spark с параметром триггера 'доступно сейчас. Это обеспечивает однократное чтение при обновлении смещения, что делает нашего потребителя гибридом потоковой передачи и пакетной обработки. Считывая данные пакетами, а не поддерживая круглосуточную потоковую передачу, мы экономим около 50 % на затратах на инфраструктуру.
  2. Адаптируйте размер записи файла и количество разделов в Kafka. По мере увеличения объема данных мы заметили, что запись в один файл становится ограничением. В нашем хранилище BLOB-объектов datalake есть ограничения на размер файлов, поэтому мы применили ограничение на количество записей в нашем модуле записи потока, чтобы разбить результат на несколько файлов контролируемого размера. Мы также заметили, что можем улучшить возможности параллельного чтения Spark, настроив количество разделов для темы. Мы обнаружили, что для этой цели и текущего объема данных достаточно 20 разделов.
  3. Добавить расширенный слой для агрегирования данных. Когда команды специалистов по обработке и анализу данных начали использовать отслеживаемые данные для изучения и проведения подробного анализа, мы заметили, что можем улучшить нашу систему, используя третий (золотой) уровень нашего хранилища данных для обработки агрегатов, чтобы упростить запросы. и время обработки для наших ученых и аналитиков данных.

Примечания

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

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

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