Что не так с традиционными методами и инструментами разработки ПО для систем машинного обучения и как MLOps решает эти инженерные проблемы ML. Почему не стоит размещать файлы моделей Machine Learnig и датасеты в Git, а также зачем MLOps-инженеру решать вопросы архитектуры и управляться с Kubernetes.
MLOps вместо Git-репозиториев
Традиционные рабочие процессы машинного обучения хранят статические данные, например, марка, модель, конфигурация автомобиля и пр. в CSV/JSON или фичи модели в виде легковесных pickle-файлов. Напомним, Pickle представляет собой бинарный вариант Python-объекта для сериализации и десериализации его структуры, т.е. преобразования иерархии объектов Python в поток байтов и наоборот. Этот легковесный формат позволяет переносить ML-модель из среды разработки в тестовую и производственную. В Cars24 pickle-файлы сохраняются в том же репозитории, что и код. Это не лучшее решение по следующим причинам:
- форматы бинарных файлов, включая pickle, не подходят для git;
- все данные загружаются в память;
- есть зависимости от типов данных.
Также наличие pickle-файлов в репозитории кода создает ряд проблем:
- увеличивается частота сборок кода из-за изменений в pickle-файле без изменений в коде;
- растет время холодного старта при масштабировании;
- размер Docker-образа становится больше.
Кроме того, нет смысла загружать весь файл, так как во время выполнения требуется всего несколько строк в зависимости от ввода. А с учетом разнообразия данных, подходы разработки должны поддерживать быстрый поиск, возможность обслуживания и оперативного запроса. Все эти идеи реализуются в MLOps-концепции, которая применяет принципы DevOps к разработке и развертыванию решений машинного обучения. MLOps включает оркестровку экспериментов, отслеживание показателей, реестр моделей, инструменты автоматизации рутинных операций и мониторинг производительности моделей, а также обеспечивает их переносимость между разными этапами жизненного цикла, от разработки до развертывания в production.
В отличие от рабочих процессов разработки традиционного ПО, в ML-системах также есть объекты модели и файлы данных, которые требуют управления версиями и имеют другой цикл изменения, чем код. Часто версии файлов ML-модели и обучающих данных называются _1_final, _1_final_v1 и пр. При отсутствии стратегии управления версиями, все исторические неиспользуемые файлы также сохраняются в одном и том же Git-репозитории кода, запутывая пользователей и увеличивая размер Docker-образа. Кроме того, нет записей о корреляции между кодом, данными и файлами модели, что чревато большими проблемами при ротации разработчиков.
В идеале все эти файлы должны иметь свою собственную версию вне репозитория кода, т.е. размещаться в отдельных репозиториях моделей и данных, и каждая версия должна быть связана с версией кода, чтобы поддерживать корреляцию между изменениями.
Архитектурные вопросы ML-разработки
Также следует отметить проблемы масштабирования ML-системы, связанные с Python. Хотя этот язык программирования является стандартом де-факто в Data Science, позволяя быстро писать простые скрипты и использовать множество ML-библиотек, для быстрой обработки больших объемов данных он неэффективен из-за своей однопоточности. Эту проблему частично решает PySpark – API-интерфейс Python в распределенном вычислительном движке Apache Spark. В частности, PySpark позволяет отказаться от популярных библиотек анализа и визуализации данных, таких как pandas, numpy и пр., которые знает каждый начинающий Data Scientist. Но они обрабатывают большие блоки данных за одну операцию, а потому не подходят для реальных Big Data проектов.
Однако, вопросы проектирования ML-приложений не исчерпываются выбором языка и фреймворка. Важную роль играет архитектура конвейера обработки данных. Например, разделение рабочего процесса на сильносвязанные компоненты в рамках одного решения может привести к высоким вычислительным затратам. Каждое развертывание ML-приложения будет потреблять ЦП полностью, и для увеличения пропускной способности придется масштабировать эти монолитные развертывания или менять архитектуру на микросервисы. Для оркестрации таких микросервисных приложений в Docker-контейнерах сегодня используется платформа Kubernetes, которая позволяет относительно легко масштабироваться, чтобы оптимизировать затраты и производительность.
Наконец, производительность ML-модели на реальных данных часто отличается от производительности на этапе обучения. Традиционные процессы разработки ПО не имеют стандартных инструментов, которые могут отслеживать этот дрейф. Также отсутствует мониторинг использования ресурсов сервисов, что имеет решающее значение для оптимизации затрат и взаимодействия с пользователем, чаще всего время отклика API. Традиционное логирование ведется в файлах журналов, для которых требуется отдельное хранилище и частое резервное копирование для сохранения истории.
MLOps помогает устранить все эти проблемы, включая трудности управления данными, о чем мы недавно писали в этой статье. А как внедрить лучшие практики MLOps в реальные проекты для эффективной аналитики больших данных, вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
