Бизнес-показатели зависят не только от решений Data Scientist’а, но и от того, как команда разработчиков реализует данную модель, а администраторы и инженеры развернут ее в кластерном окружении. Важно качество входных данных (Data Quality), периодичность их поступления, источники и каналы передачи информации, что является задачей дата-инженера. Организационные и технические препятствия при взаимодействии разнопрофильных специалистов приводят к увеличению сроков создания продукта и снижению его ценности для бизнеса. Для устранения таких барьеров и придумана концепция MLOps, которая, подобно DevOps и DataOps, стремится увеличить автоматизацию и улучшить качество промышленных ML-решений, ориентируясь на нормативные требованиям и выгоду для бизнеса. Применять подходы MLOps необходимо на всех этапах создания ML решений.
В статье мы поговорим об использовании принципов и практик MLOps на стадии разработки моделей, и расскажем как самим развернуть сервис самообслуживания по созданию сред разработки для дата-саентистов.
Инструменты и практики
Совместная работа над кодом проекта
Каждому специалисту в ходе создания аналитического приложения приходится работать с множеством документов: это могут быть модули python, интерактивные блокноты jupyter, конфигурационные файлы, файлы с данными, артефакты выполнения кода, файлы с заметками, комментариями, графиками и метриками.
Существуют как минимум две основные причины навести здесь порядок.
Если договориться о структуре расположения и названиях файлов, то становится понятно, что-где находится, к чему относится, и помогает эффективнее работать даже над небольшими проектами. Если проект крупный, и в работе принимают участие большое количество специалистов, выяснить, где прячется определенный модуль и входные данные становится проблемой. Решение есть — следование определенным правилам. Ведь отсутствие структуры и соглашений о нейминге может привести (и часто приводит) к полной остановке работы над задачей — “до выяснения обстоятельств”.
Вторая причина организации проектов — возможность автоматизации. Если файлы называются и располагаются по определенным правилам — значит, с таким проектом готова работать машина. Сборка приложения или docker-контейнера на базе исходных данных, запуск тестов, корректная работа скриптов переобучения моделей, отображение результатов экспериментов в единой системе — это лишь некоторые задачи, которые можно выполнять без участия человека, избегая рутинной работы и ошибок.
Чтобы упростить процесс создания структуры проекта применяются специализированные утилиты, например, Coockie Cutter.
Но даже если вы просто договоритесь с коллегами о типовом расположении, составе и названиях документов, опишете правила и начнете ими пользоваться — процесс совместной работы существенным образом улучшится.
Проект, построенный на базе Python, обычно включает в себя:
- файл с описанием (например — “readme.md”)
- файл, содержащий список используемых библиотек/модулей (например — “requirements.txt”)
- файл, содержащий информацию о версии интерпретатора (например — “.python-version”)
- набор модулей, из которых, как правило, один — является основным (основной файл включает в себя либо цепочку вызовов функций из различных модулей, либо содержит код инференса, то есть получения результатов работы модели)
- файлы, содержащие различного рода тесты
- ссылки на данные и бинарные артефакты модели
На практике, структура и состав проекта также могут зависеть от тех инструментов совместной работы и автоматизации, которые используются, например, MLFlow, Kubflow, GitLab и т.д.
Git и плюшки в инструментах датасаентиста
Совместная работа над аналитическим приложением в современном мире невозможна без использования системы управления кодом. OpenSource стандартом в этой области является Git.
Но что делать, если вы пришли в мир Data Science без опыта разработки программного обеспечения и никогда не пользовались системой Git?
Ответ первый — изучать технологии и инструменты DevOps. Модели, которые остаются в песочнице аналитиков, никому не нужны. Бизнес хочет не просто услышать красивые слова, но и получить результаты в сжатые сроки. Следовательно, от датасаентистов начинают требовать знаний и навыков работы с инструментами, позволяющими выполнять работу эффективнее и доводить результат до коммерческого применения.
Ответ второй — применять плагины и надстройки для тех инструментов, которые уже хорошо знакомы. Примером здесь может стать расширение Git для JupyterLab. С его помощью можно управлять локальными и удаленными git-репозиториями, не прибегая к помощи командной строки.
Разработка. Кратко о воспроизводимости результатов.
Кто-то скажет: “Ну, хорошо, совместно работать с кодом мы научились, договорились о структуре файлов и папок. Можно мы пойдем делать модели?” — Конечно! Но и здесь для эффективного достижения результатов нужен системный подход.
Как правило, разработка модели включает в себя несколько этапов, таких как:
- Загрузка и предварительная обработка / проверка данных;
- Формирование и проверка признаков;
- Обучение модели;
- Валидация модели.
Эти этапы могут иметь собственные зависимости. Данные на каждом из них могут преобразовываться и использоваться по-разному.
Упомянутые выше задачи можно выделить в отдельные элементы (например, в рамках разных модулей python), и решать независимо от остальных. Такой модульный подход позволяет более гибко распределять усилия команд датасаентистов и датаинженеров, упростить проверку результатов и минимизировать возможные ошибки.
Обеспечить связь между задачами, гарантировать воспроизводимость результатов поможет Data Pipelines и соответствующие инструменты, которые позволяют ими управлять.
Согласно одному из возможных определений: Data Pipelines — это множество элементов обработки данных, объединенных в одну последовательность. При этом, выход одного элемента является входом для последующего.
Существует множество инструментов для создания и управления Data Pipelines:
- DVC Pipelines
- Kubeflow Pipelines
- Airflow
Еще одним элементом воспроизводимости является возможность сохранения, передачи и воссоздания окружения / среды (со всеми зависимостями), в рамках которого проводилась разработка. Здесь помогут контейнеры, которые обеспечат решение многих задач.
Использование контейнеризированной среды. Зачем это нужно?
Техническим специалистам контейнеры полюбились за возможность упаковать приложение вместе с его средой запуска, решая проблему зависимостей в разных окружениях. Например, различие версий языковых библиотек на ноутбуке разработчика, и в последующих окружениях, приведёт к сбоям, и нужно будет, как минимум, потратить время на их анализ, а как максимум — решать проблему проникших в продакшен багов. Использование контейнеров устраняет проблему «А на моей машине все работало!”
Также, контейнеры позволяют сократить время разработки приложения и упрощают управление им в продакшене благодаря легкости настройки и изменения конфигурации, возможности версионировать её вместе с кодом приложения. Плюсом является наличие удобных инструментов оркестрирования, позволяющих быстро масштабировать инфраструктуру.
Кроме того, фактическое отсутствие привязки контейнеров к хостинговой платформе даёт огромную гибкость при выборе или смене провайдера — вы можете запускать их без принципиальных отличий на личном компьютере, bare metal серверах и в облачных сервисах.
Что делать, если необходимо запустить выполнение кода для проведения процессной аналитики или другой задачи, но не хватает памяти и мощностей компьютера, или компьютер с необходимым софтом вообще не доступен?
Разворачиваем свой сервис: Self-Service IDE
Ответить на обозначенные выше вопросы применительно к созданию сред и запуску инструментов разработки позволяют решения на базе контейнеризации. Сейчас на рынке уже представлено несколько подобного рода систем: это и Kubeflow — платформа с открытым исходным кодом, развитие которой поддерживает Google, и разного рода платформы от компаний Cloudera (Data Science Workbench), IBM и так далее. Сегодня мы рассмотрим относительно простой вариант решения на базе контейнеров и JupyterHub.
JupyterHub
Платформа Jupyter отлично справляется со снижением порога входа в Питон для начинающих программистов, data scientist’ов. И вот команда растёт, в ней теперь не только программисты, но и менеджеры, аналитики, исследователи. Внезапно отсутствие совместного рабочего окружения и сложность настройки начинают тормозить работу. JupyterHub решает именно эту задачу: это многопользовательский сервер / хаб, предоставляющий возможность запускать Jupyter «одной кнопкой». Сервер отлично подходит для аналитиков и data scientist’ов, потому что пользователю нужен лишь браузер: никаких проблем с установкой ПО на ноутбук, совместимостью, пакетами.
Но, достаточно “лирики” и архитектурных отступлений. Давайте разберемся более подробно, что нужно сделать, чтобы развернуть собственный сервис самообслуживания для команды Data Science.
Разворачиваем решение на Swarm
Прежде всего, необходимо создать виртуальную машину, на образе CentOS 7. (Сама установка будет работать на bare-metal сервере). Также установим последнюю версию Docker ce 20.10.3., и настроим сеть так, чтобы порты 80 и 443 были доступны для HTTP и HTTPS. Свяжем Public IP-адрес с этим инстансом, для доступа в Интернет.
Добавьте своего пользователя в группу docker, чтобы вам не требовалось sudo для выполнения docker-команд. Убедитесь, что работает команда docker info.
Сервер, на котором будет выполнена команда по инициации docker swarm кластера, будет являться Manager node:
Как это ни удивительно, у Swarm нет встроенного механизма — permanent storage, который автоматически перемещает данные с одного узла на другой в случае повторного создания пользовательского контейнера на другом сервере. Зато есть несколько volume plugins, но их настройка и конфигурация заставит вас попотеть, что заставит задуматься: “Не лучше переключиться на Kubernetes?”. Чтобы добиться более простой настройки, которая позволяет обрабатывать несколько десятков пользователей, можно использовать NFS сервер. Мы просто создаем volume на NFS директорию. Пользователи не будут иметь доступ к файлам своих коллег, потому что в их контейнер монтируется только их собственная папка, созданная под пользователя в NFS.
И запустить на менеджер узле Swarm следующую команду:
Заключение
Эта статья часть цикла, посвященного MLOps. В следующий публикациях мы расскажем подробнее о внедрении ML моделей, рассмотрим вопросы мониторинга, работы с данными, автоматическом создании моделей и многом другом.
Про ModelOps/MLOps и другие вопросы вокруг применения ML и продвинутой аналитики в реальных бизнес-задачах мы регулярно общаемся в нашем сообществе NoML: