Путешествие по науке о данных от ноутбуков до развернутого продукта - Часть II

ЧАСТЬ II: Развертывание и масштабирование

TL;DR

Что это?

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

Мы поговорим о некоторых лучших практиках в MLOps, таких как CI / CD, воспроизводимость, мониторинг и обслуживание. Наконец, наш выбор с точки зрения оркестровки конвейера и инструментов, которые мы выбрали в экосистеме GCP.
Цель этой статьи - поделиться мнением о том, как мы развернули модель машинного обучения в производственной среде, и дать вам несколько советов, основанных на реальных проектах, чтобы помочь вам избежать тех же ошибок, которые мы сделали, и ускорить вашу работу. развертывания.
Надеюсь, вам понравится, приятного чтения!

Для кого?

  • Специалист по данным, инженер машинного обучения или любители данных

Выводы?

  • Хорошие практики в отношении MLOps
  • Несколько советов, уловок, которые помогут вам сэкономить время и быстрее развернуть ваши модели
  • Хорошие библиотеки, инструменты, которые мы открыли во время нашего путешествия

Машинное обучение или MLOps

Некоторые определения

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

От блокнотов до скриптов на Python

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

В результате вот несколько хороших практик для ускорения этой операции:

  • Разработайте линейный блокнот, вам не нужно запускать ячейку 4 перед ячейкой 3.
  • Используйте правильное именование для ваших переменных и ваших функций с самого начала
  • Как можно скорее упакуйте свой код в функции и избегайте дублирования
  • Не стесняйтесь использовать логирование или декораторы. Обратите внимание на scikit-lego, в котором есть довольно интересные функции и декораторы.
  • Добавьте заголовки и субтитры в уценке, это сделает блокнот более читабельным
  • Импортируйте все библиотеки в начале вашего скрипта и используйте виртуальную среду
  • Избегайте жестко заданных путей, используйте вместо них библиотеки, такие как pathlib

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

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

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

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

  • Pdb помогает проверить код в определенном месте.
Import pdb; pdb.set_trace()

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

Очевидно, что у каждого будут свои предпочтения, а иногда архитектура будет зависеть от вашей компании. Но вы можете найти некоторые рекомендации или шаблоны, такие как cookie_cutter или Библиотека Kedro.

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

Воспроизводимость и версия с ML Flow

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

Есть разные способы подойти к этой задаче:

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

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

Воспроизводимость при работе с базами данных… Очень сложно добиться идеального соответствия с вашей базой данных Prod, Pre Prod и Dev. Вы можете изменить некоторую логику ETL, исправить ошибки, выполнить частичную или полную перезагрузку и т. Д. Одним из способов решения этой проблемы было создание панели мониторинга, сравнивающей наиболее важные таблицы для наших баз данных:

  • Количество рядов
  • Количество значений NULL в столбцах
  • SUM (), AVG (), MAX (), MIN () некоторых важных столбцов, таких как: выручка, Qty_sold, is_in_promo, price и т. Д.

Это определенно не идеальное решение, но лучше, чем ничего, и оно уже дает вам хорошее представление и помощь.

Наконец, как объяснялось в предыдущей статье, мы использовали ML Flow в качестве инструмента для экспериментов по отслеживанию. Заключительная проверка воспроизводимости заключалась в том, чтобы убедиться, что наши файлы .py, обученные нашей моделью (промышленная версия), дают те же результаты, что и файлы, обученные в записных книжках. Проект с открытым исходным кодом ML Flow также предоставляет инструменты для развертывания ML-моделей и центрального реестра моделей, но мы не использовали их во время этого проекта.

Почему важно иметь конвейер CI / CD

Как упоминалось ранее, вам следует как можно скорее протестировать свой код. Но давайте начнем с того, почему вам нужно тестировать свой код:

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

Если вы не знаете, с чего начать, ознакомьтесь с такими библиотеками, как pytest, и такими понятиями, как Unit Test, Magic Mock, Integration Test, Qualification Test, Patching.

Наш CI / CD был разделен на три части:

1. Непрерывная интеграция

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

Источник: lebigdata.fr

2. Непрерывная доставка

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

Источник: codehip.com

3. Непрерывное развертывание

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

Источник: dzone.com

Эти три разных шага можно автоматизировать, и ими можно управлять с помощью таких инструментов, как Jenkins или Cloud Build.

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

Вот иллюстрация нашего конвейера CI / CD:

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

Ведение журнала и мониторинг с драйвером стека и большие надежды

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

Но что и как вы должны контролировать свой продукт?

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

  • Время выполнения: все рабочие процессы, обновления баз данных, подготовка данных, обучение модели и т. Д.
  • Отметка времени окончания рабочего процесса
  • Наборы данных для обучения и проверки RMSE во время еженедельных обновлений модели
  • Ежедневный прогноз Точность наших прогнозов
  • Количество предупреждений, выданных во время рабочего процесса
  • …

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

Большинство этих показателей хранились в виде журналов, разделенных на две категории.

Первая категория журналов информирует вас о выполняемой задаче и некоторую полезную информацию, такую ​​как: подготовка данных или вывод машинного обучения. Вторые хранятся в Stack Driver, инструменте регистрации от GCP. Затем мы можем отфильтровать те, которые нам нужны, и экспортировать их в Big Query с помощью функции приемника. Отсюда мы можем легко создать информационную панель с автоматическим обновлением таблиц во время выполнения наших скриптов.

Чтобы выявлять аномалии данных, мы также добавили модуль, проверяющий согласованность наших данных во время рабочего процесса. Модуль, основанный на действительно классной библиотеке Great_expectations (вам обязательно стоит ее проверить), библиотеке, которая позволяет вам контролировать качество ваших данных и создавать автоматические отчеты: если некоторые функции имеют значения больше или меньше порогового значения или имеют отсутствующие значения и т. д. Вы можете активировать его во время рабочего процесса или даже с помощью действий github.

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

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

Конвейерная оркестровка с Kubernetes

Существует множество возможностей, подходов к развертыванию и оркестровке вашего решения, таких как AirFlow, Luigi, Cloud scheduler, Google Kubernetes Engines (GKE), простая вкладка cron на виртуальной машине и т. Д. Мы решили выбрать GKE, управляемую версию Kubernetes на GCP. Для тех, кто не знаком с Kubernetes, это система оркестровки контейнеров с открытым исходным кодом для автоматизации развертывания, масштабирования и управления приложениями. С Kubernetes мы смогли контролировать нашу вычислительную мощность с помощью автоматического масштабирования наших ресурсов в зависимости от задачи. Мы решили выбрать GKE в основном из-за политики компании, но также из-за простоты управления нашими вычислительными мощностями и, следовательно, цен.

В результате мы развернули разные образы докеров, и благодаря заданию cron в GKE мы могли запускать и запускать связанные контейнеры.

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

Отображение результатов с помощью Rest API

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

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

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

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

Ключевые выводы

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

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

Спасибо за прочтение!

Вы дошли до этого, я надеюсь, вы отлично провели время и кое-чему научились!
Чтобы узнать больше о нас, вы можете просмотреть другие наши статьи здесь или просмотреть наши проекты с открытым исходным кодом.
Если вы есть какие-либо вопросы или моменты, с которыми вы хотите обсудить / не согласиться, я хотел бы услышать от вас.