Comments 8
Пробовал dvc года полтора назад, идея хранения и версионирования датасетов понравилась и в теории и на практике в связке с s3 (пытался пользоваться с ssh для персонального проекта, получилось мучительно долго).
Отказался в пользу mlflow с ручным отслеживанием хешей датасетов по трем причинам:
- полтора года назад dvc не мог работать с несколькими метриками сразу, особенно когда их количество растет. Судя по https://github.com/iterative/dvc/issues/2973 и другим issues в гитхабе у авторов, зрелого решения у проблемы еще нет.
- очень сложно внедрять dvc в команде, которая пробовала другие инструменты (mlflow, W&B etc) из-за разной философии тулов. DVC — это про воспроизводимые эксперименты, интегрировать репозиторий на dvc в production код не нужно, а в перспективе и больно. В итоге приходится либо дублировать код и конфигурацию из репозитория dvc эксперимента в инженерный репозиторий, либо делать отдельный репозиторий с библиотекой, которую уже после использовать в dvc-репозитории и в production репозитории.
- Использовать dvc с pipenv было неприятно, как минимум раньше. Какие-то версии catboost конфликтовали с dvc при pipenv lock'е, потом вроде прошло. Зависимость от boto3 тоже чревата капризами. Но это общая беда тулинга на питоне.
По итогу, дизайн и идея — прекрасны, в практическом использовании нужно быть готовым к сюрпризам и долгим разговорам с коллегами.
А как у вас сохраняются датасеты с mlflow? Как артефакты?
Раньше пробовали сохранять датасеты как артефакты, но api у MLflow для их извлечения показался слишком неудобным, поэтому стали просто вливать в версионируемый Minio-bucket (в s3 нас legal не пускает, но суть та же), постепенно пришли к обёртке над таким доступом.
Теперь у нас в команде есть внутренняя библиотека по мотивам tensorflow datasets. Она помогает отслеживать имена и версии датасетов, мы их в MLflow в виде параметров и пишем. К ней дописали небольшой кусок, чтобы можно было быстро и безболезненно вливать и использовать свои датасеты без публикации новой версии библиотеки (в итоге нам не нужен аналог tfds-nightly, если знаешь название и версию временного датасета).
А пайплайны dvc мы просто переложили на luigi, с этим стало проще потом модели в prod запускать.
У нас подобный подход на этапах препроцессинга: каждый шаг идет как luigi.Task и заодно main каждого шага как MLflow run. То есть одновременно можно собирать в коде цепочку задач подготовки датасета и хранить артефакты и гиперпараметры с MLflow.
Поясню. Предположим мы обучаем бустинг, и он учиться 1 мин. Тогда работа выглядит так: 1 — создаем git-ветку под гипотезу, 2 — пушим туда изменения, 3 — затем обучаем модель, 4 — пушим результаты в dvc. Используем, например, mlflow для визуализации всех экспериментов. Красота!
Но это нереально если мы учим модель неделю. Т.к. мы не можем сменить ветку и делать новый эксперимент на шаге 3, т.к. надо дождаться результатов эксперимента. С облаком будет чуть по другому, т.к. там будет репо в котором нет разработки. Но либо у нас в облаке будет несколько копий датасета, либо разработчики будут шарить общую папку для обучения модели. И то и то неудобно.
Поэтому использую dvc только для версионирования датасетов. Периодичекси мерджим в develop эти изменения и тем саммым они доступны всей команде.
Судя по фразе:
Обо всех обновлениях и изменениях нужно сообщать команде где-то еще, skleg вы используете dvc не так как мы в команде. Можно рассказать об этом?
Ну как-то так выглядеть должна работа: 1 — создаёте git-ветку под гипотезу, 2 — пушите туда изменения, 3 — запускаете обучение модели на сервере или в облаке, 4 — по окончании обучения обученная модель пушится в dvc и в git.
Но либо у нас в облаке будет несколько копий датасета
Этого трудно избежать, поскольку сама идея того, что датасеты для разных веток могут отличаться это подразумевает.
вы используете dvc не так как мы в команде. Можно рассказать об этом?
Рассказываю: в целом эта проблема уже не очень актуальна, но когда начинали работу с DVC, была проблема разбираться в версиях датасетов, когда кто-то подключается, например, к разработке модели. К этому моменту другой ds мог наделать разных версий датасетов с разными шагами подготовки (кропы, удаление дубликатов и пр.). В целом эти изменения описаны в confluence, но детально с версиями все равно нужно было идти и узнавать какая актуальная для обучения будет.
Сейчас я стараюсь отмечать в коммитах ссылку на тикет задачи в JIRA и более понятный комментарий о сути изменений, чтоб можно было откатить или найти нужную версию. Но зачастую нужен просто master или набор веток, где лежат самые последние протестированные версии датасетов, моделей.
Но это нереально если мы учим модель неделю. Т.к. мы не можем сменить ветку и делать новый эксперимент на шаге 3, т.к. надо дождаться результатов эксперимента
А почему нельзя прервать эксперимент, если понятно, что есть логика/модель получше текущей?
DVC — Git для данных на примере ML-проекта