Большинство дата-сайентистов использовали или до сих пор используют notebooks. В чем-то это здорово, но кажется, что дата-сайентисты должны действовать как разработчики. И поэтому с notebooks надо переходить на скрипты, разрабатываемые в IDE.
Команда VK Cloud перевела статью о том, какие преимущества вам даст более активное использование IDE.
Для чего мы используем notebooks и почему это неэффективно
Почему нам, дата-сайентистам, нравятся notebooks
Чаще всего notebooks используют в самом начале проекта по обработке данных: чтобы исследовать возможные варианты, найти доказательство концепции и проверить техническую
-
скорость: чтобы запустить новый notebook, нужно несколько минут;
-
удобство вычислительных операций: notebook можно запустить на виртуальной машине или в облачной среде;
-
простота использования: для проведения тестов не нужны уверенные навыки разработки, а код можно выполнять строку за строкой;
-
готовые презентации: графики и текст с разметкой, отображаемые в документе, можно показывать нетехническим командам.
Пример ячейки notebook
Что не так с notebooks
Хотя это интересные функции, мне, как и многим другим дата-сайентистам, использование notebooks мешает внедрять современные практики разработки программного обеспечения.
Большую часть времени (если не сказать всегда) приходится заново создавать код для всего, что попадает в продакшен. Это же двойная работа! Не лучше ли сразу создать хорошую базу, чтобы потом просто вносить изменения, не переделывая весь код заново?
Еще у notebooks есть несколько недостатков:
-
нет отслеживаемости;
-
нет воспроизводимости;
-
нет инструментов для разработки кода: справки для строки документации, проверки Lineage, исправления багов, автозаполнения и многого другого;
-
акцент экспериментальной проверки на машинном обучении, а не на тестировании всех технических аспектов решения;
- устранение багов может занимать много времени, особенно при настройке ядра и среды.
Не говоря уже о том, что notebook не подходит для разработки сложных систем и системного анализа.
Поговорим про недостатки notebooks чуть подробнее.
Ненадежная основа для исследований. Работа в notebooks плохо вписывается в научный подход. Даже если команда обращается к точному методу, а такое случается нередко, notebook не облегчает внедрение этого подхода.
Нет отслеживаемости. Во-первых, в notebooks нет поддержки отслеживания хода экспериментов. Они не поддерживают контроль версий. При слиянии возникает множество конфликтов, так что часто вам ничего не остается, кроме как работать в своем notebook в одиночку. В результате команда часто теряет из виду ход эксперимента. Я встречал альтернативную систему отслеживания версий вручную, когда команды используют имена файлов как источник информации. Это не оптимальное решение.
Нет воспроизводимости. Вполне возможно, что полученные результаты не имеют ничего общего с фактическим кодом в notebook. Инженер прошелся по коду, выполнил код из ячейки здесь, что-то подправил и уже не вспомнит, какая информация используется для интерпретации результатов исследования. Какой код я использовал, чтобы получить эти результаты? А какие данные? Но дело здесь не в неточной работе инженера — никто не мыслит линейно. Проблема во фреймворке эксперимента, из-за которого его невозможно воспроизвести.
Нехватка инструментов для разработки. В notebooks не поддерживаются многие инструменты, которые можно использовать в IDE: автозаполнение, навигация по коду и его форматирование, контроль версий, рефакторинг и т. п. Следовательно, работа занимает больше времени и выполняется не в соответствии с передовыми методами, которые позволяют:
- упростить работу и доступ для участников команды;
- реализовывать однозначное поведение программного обеспечения, когда каждая функция должна работать только определенным образом;
- обеспечить модульность кода.
Акцент экспериментальной проверки только на одном аспекте задачи. Поскольку приносит пользу именно продукт, необходимо апробировать продукт в целом, а не только модель. Что, если главная трудность — это не задача обучения, а работоспособность самой модели? Что, если она работает локально, но не работает в приложении? Тестируя только задачу обучения, мы оставляем за рамками проверки UX, деплоймент, безопасность и все технические аспекты программы. Кроме того, начав с простого комплексного теста, можно сократить цикл разработки, заранее протестировать пользу продукта, сэкономить время и повысить качество дизайна. Для этого лучше всего с самого начала разрабатывать решение как программное обеспечение.
Заниматься Data Science так, будто вы разработчик, непросто, но выход есть!
Новый подход: отнеситесь к исследованию как к составной части жизненного цикла разработки ПО
Сегодня появляется все больше готовых моделей и решений под ключ. В том числе поэтому современная наука о данных сильнее сосредотачивается на проработке сценариев использования, моделировании задач и работе с данными, а не на создании самой модели.
Занимайтесь наукой о данных как разработчик
Используйте скрипты и IDE. Таким образом вы сможете выполнять полноценные эксперименты, манипулируя разными модулями и по необходимости запуская с ними сложные циклы обучения. Например, для задач обучения с подкреплением или генерирования изображений необходимо спроектировать несколько частей (среду и один или несколько агентов) или несколько моделей (генератор и дискриминатор) и привести их в действие в цикле обучения, дизайн которого имеет критически важное значение для обучения. Способность моделировать и решать особенно сложные задачи окажется еще важнее для дата-сайентистов, поскольку им больше не нужно решать простые задачи машинного обучения. Действительно, многие решения доступны и неэкспертам в математике или статистике, например:
- решения без кода (dataiku);
- машинное обучение (auto-sklearn);
- предварительно обученные модели, модели и примеры из проектов с открытым исходным кодом (например, на платформах Vertex AI, от компании Hugginface и сообщества решений с открытым исходным кодом).
Управляйте версиями кода и экспериментами как разработчики. С сильной методологией контроля версий можно:
- разобраться, чем один эксперимент отличается от других;
- сделать эксперимент действительно воспроизводимым;
- улучшить отслеживаемость и сократить риск повторения одинаковых экспериментов.
Но контроль версий кода и экспериментов — две разные вещи. С одной стороны, можно использовать Git и современные методы (например, Karma convention) и таким образом фиксировать все, что было сделано, открыв доступ к данным для всей команды. С другой стороны, для отслеживания экспериментов Data Science можно использовать инструменты вроде MlFlow tracking, который позволяет получать метрики, конфигурацию и артефакты, связанные со всеми параметрами.
В идеале хорошо бы объединить обе стороны контроля версий, чтобы можно было сопоставить код с результатами эксперимента. Для этого можно использовать git python, который позволяет делать новый коммит при выполнении кода, то есть провести новый эксперимент.
Сохраните самые интересные преимущества notebooks
Выполняйте код строка за строкой и стройте графики. При проведении экспериментов, а еще потому, что основной для дата-сайентистов Python — это интерпретируемый язык, бывает очень удобно выполнять код построчно или поблочно. Это вполне осуществимо, если к IDE привязан терминал Python. С помощью Pycharm можно выполнять выбранные строки сочетанием клавиш.
В notebooks результаты построения графиков отображаются сразу под каждой ячейкой. В IDE это реализовано не так удобно, но все-таки возможно: в Pycharm можно настроить всплывающие окна с графиком, если использовать matplotlib. Но вы можете — и я даже советую вам — сохранять графики как HTML-страницы (или в другом формате) в отдельных папках, чтобы удобно было вернуться к ним при необходимости. Для любого типа графиков это легко сделать с помощью plotly. Еще можно использовать pandas-profiling, чтобы быстро провести первый исчерпывающий эксперимент с данными.
Скриншот отчета pandas-profiling в HTML
Кроме того, есть инструменты для комплексного отслеживания экспериментов, например tensorboard или MLflow. В этом случае вам не придется строить много графиков, чтобы отслеживать ход исследования.
stackoverflow.com/questions/53529632/how-to-display-the-accuracy-graph-on-tensorboard
Выполнение кода на мощном оборудовании. Возможности локального оборудования достаточно ограничены. В отличие от notebooks, которые можно запускать удаленно на очень мощном оборудовании (экземпляры notebooks предоставляют все крупные облачные провайдеры, Google Collab и т. п.), IDE часто используется в локальной среде.
Первый вариант — запускать вычислительные задачи на удаленных машинах вроде станции DXG с GPU по SSH или через управляемые сервисы, предоставляемые облачными провайдерами. Например, пакетные задачи Azure можно запускать из Python API.
Второй вариант — использовать IDE на виртуальной машине. Такую услугу предоставляет JetBrains GetWay, в котором можно запускать IDE на собственной виртуальной машине по SSH или в Space, другом сервисе JetBrains.
Учитывая все моменты, в подавляющем большинстве случаев имеет смысл спросить себя: действительно ли вам нужна такая вычислительная мощность? Часто это пальба из пушки по воробьям, ведь есть стратегии, позволяющие избежать использования огромных вычислительных ресурсов:
- исследование выборки;
- выбор в пользу непосредственных подходов: передача обучения, готовые модели, доступные на платформах или в режиме службы, бизнес-правила.
У этих стратегий есть другое преимущество: не выполнять масштабное обучение на мощном оборудовании, а сначала попробовать метод побыстрее.
Усилие, которое стоит сделать
Конечно, заниматься Data Science как разработчик не так просто для большинства специалистов, но затраченные усилия окупятся:
- приложить усилия для входа в эту нишу нужно всего один раз;
- команда сможет извлечь пользу из того, что делают другие.
Перестроиться можно быстро. По моему опыту, если даже дата-сайентист вообще не знаком с современными методами работы, ему хватит несколько недель, чтобы освоить:
- IDE,
- контроль версий,
- тестирование,
- сервисы.
В частности, я создал трехдневную программу вводного обучения для дата-сайентистов. За это время мы, в числе прочего, обсуждаем современные подходы к разработке. Меня очень порадовало, что ученики не только быстро вникли в концепции, но и сразу же попытались применить их в работе. Через некоторое время они уже могли создать Data-Science-проект непосредственно в IDE и применяли осовремененные подходы к разработке.
Заключение
Отказаться от notebooks не так-то просто: придется менять привычки, осваивать новые инструменты и подбирать рабочие процессы, оптимальные именно для ваших обстоятельств. Но со всем этим можно быстро справиться и уже в ближайшем будущем пожинать плоды — значительную экономию времени и снижение рисков при проведении исследований.
Кроме того, это позволяет дата-сайентистам стать ближе к разработчикам, дата-инженерам и другим специалистам из проектной команды. В результате вы сможете лучше соответствовать современным стандартам и методам разработки, упростить и ускорить работу, а еще обеспечить понимание и согласованность в команде.
Отказ от notebooks — первый шаг к высокой цели — интеграции экспериментов в полный рабочий процесс MLOps.
VK Cloud развивает собственную платформу для полного цикла ML-разработки ML Cloud Platform. Сейчас она на этапе бета-теста и доступна бесплатно. Мы будем рады, если вы ее протестируете и дадите обратную связь.
Комментарии (20)
TiesP
02.12.2022 15:08-3В юпитер блокноте можно нажать "shift+tab" и увидеть все параметры данного метода и его описание. А в ide такое возможно?
ris58h
02.12.2022 16:51+2Вы имеете в виду, можно ли в IDE посмотреть документацию к методу? В любой нормальной - конечно да.
Shift+Tab - странный шорткат для документации. В большинстве редакторов это шорткат для уменьшения отступа.
gematit
02.12.2022 17:19Очень поддерживаю.
Абсолютно согласен с тем, что в data-science или любой другой science лучше переходить в обычные IDE и хранить проекты (открытые) на Github или в подобных местах.
Получается куда более структурировано, да и ссылаться удобнее.
Alexey2005
02.12.2022 17:21+5Киллер-фича этих блокнотов - возможность править код на живую и менять порядок исполнения кода прямо во время работы. То есть вы можете выполнить часть программы, увидеть результат - и исправить следующий кусочек не прерывая выполнения всего скрипта. Более того, можете перезапустить ранее выполнявшийся кусок кода, если с результатами его выполнения что-то не так. Выскочило исключение? Вам не нужно запускать выполнение всего скрипта с нуля, в большинстве случаев возможно перезапустить сбойный кусочек.
И даже стартовать скрипт может не с начала, а с указанного места и выполняться в указанном порядке.
Ни одна IDE и близко не даст вам подобного функционала, когда вы пишете и правите код непосредственно работающего скрипта без необходимости перезапуска. Это ускоряет разработку неимоверно, особенно учитывая, что ML - это зубодробильная матрично-векторная математика, где накосячить ну очень легко, а найти ошибку бывает сложно.
gematit
02.12.2022 17:41Формально, MATLAB в рамках своей IDE даёт такую возможность даже в обычных скриптах, не говоря уже о LiveScripts.
Но если мы говорим о питоне, то в нём логичнее бить код на обычные блоки (отдельные модули/классы/функции), а не писать длинную простыню. Хотя дело вкуса, конечно.
Mdm3
02.12.2022 22:46+2Вопрос в другом. Вот у меня приложение на старте загружает тяжеленную нейронку. Потом эта неронка за милисекунды обрабатывает разные данные, которые ей подсовываю для отладки визуализации. В блокноте один раз загрузил веса и работай с ними меняя код как хочешь в других ячейках.
А в IDE как избежать постоянной загрузки весов нейронки заново при перезапусках после изменений в модуле/функции?
gematit
03.12.2022 05:01Так где у вас веса: в блокноте или в приложении?
А как избежать постоянной загрузки?.. Ну запишите это всё в один файл. А оттуда уже берите.
Mdm3
03.12.2022 09:55+5Какая разница, где веса. Вопрос как избежать их загрузки при каждом перезапуске кода, потому что это занимает время. В блокноте понятно как - одна ячейка загузила веса, в другой отлаживаешь работу с весами, изменяя и перезапуская ее сколько угодно раз.
А в IDE надо ждать загрузку весов при каждом изменении/перезапуске кода и тратится куча времени.
Пример упрощенный, для наглядности.
Ales_Nim
02.12.2022 17:32А почему не упоминаются расширения для того же Юпитера, которые помогают работать с блокнотами в гите (nbdime и др)? Так же нет ни слова про DVC, которая, по сути создана для совместного использования с гитом
dolfinus
03.12.2022 13:54Кто-то реально использует DVC? Сколько видел советов его использования, но ни один знакомых мне дата саентистов им не пользуется.
Ales_Nim
03.12.2022 14:52А кто-то не использует Jupyter и интерактивные блокноты? Из всех моих знакомых дата саентистов, все используют. Надеюсь, я достаточно апеллировал к личному опыту.
DVC используют, как минимум, потому что DVC развивается и гайдов по его использованию становится все больше.
P.S. Мы у себя в команде начинаем внедрять, но у нас очень маленькая команда, поэтому не в счет
kkalmutskiy
02.12.2022 20:56+3В целом, посыл верный, но более правильный путь - это пользоваться блокнотами там, где это необходимо. В самом начале экспериментов сразу лезть в IDE и писать скрипты - это не самая лучшая идея, учитывая, что большие датасеты могут загружаться в память и подготавливаться несколько минут, и словить ошибку после загрузки из-за какой-то мелочи (что часто случается в силу особенностей питона) очень неприятно, можно потратить кучу времени впустую. Да и вообще, каждый раз полностью перезапускать пайплайн, когда он еще не доведен до ума - накладно. Плюс в ноутбуках есть такая прекрасная вещь, как Markdown блоки, которые позволяют записывать свои мысли и описывать, что вообще там происходит, что нужно еще попробовать и так далее. Ну и не забываем про удобство работы с графиками, в скриптовом подходе это делать неудобно и долго по времени, поскольку датасеты в памяти не хранятся.
gematit
03.12.2022 05:13Мне показалось, что вы мешаете тёплое с мягким. Датасет и его чтение/разбор — одна сущность. Построение графиков — другая.
В философском плане, любая работа с данными (будь то ML, статистический анализ, регрессии какие-то) — суть метод сокращения размерности этого датасета.
И мы находим закономерности, не читая/правя датасет (абсолютно техническая операция), а делая над ним (уже загруженным) некие преобразования.
kkalmutskiy
03.12.2022 09:04+2Ничего я не мешаю. Я говорю конкретный сценарий работы, в котором, например, может происходить следующее:
1) Загружаем большой датасет
2) Заполняем пропуски, чистим выбросы
3) Визуализируем, смотрим распределения
4) Создаем признаки
5) etc
В ноутбуках можно в рамках одной сессии легко вернуться в начало любого пункта и что-то переделать, можно быстро построить новые графики, попробовать разные способы чистки датасета, попробовать разные признаки, пока не получим хорошие, исправить ошибки и так далее, не тратя кучу процессорного времени на то, чтобы перезапускать все шаги с самого начала. Можно оставлять себе развернутые пометки в отдельных блоках, что проверил и почему от этого в итоге отказался.
Да, с помощью скриптов эти все проблемы можно решить, потратив на разработку дополнительное время, но зачем? Учитывая, что эти оптимизации все-равно вряд ли доедут до прода.
Ноутбуки - это классная штука, когда ты еще не знаешь, что конкретно ты хочешь сделать и что в итоге получить.
lllamnyp
04.12.2022 03:34+3Простите, осуждаю. Возникло впечатление, что разработчик познал дзен хороших практик в разработке и побежал в отдел датасатанистов, дабы открыть им истину. Творческий процесс в науке (будь это наука о данных или о чём либо ещё) немного не так работает. Зачастую, глубоко плевать на версионирование 95% итераций (а если так параметры подкрутить? А сяк? А если ещё слой нейронов добавить?) Ещё 4% наиболее интересных попыток будут сохранены, чтобы вернуться к ним и/или кому-то показать. Наконец, оставшийся 1% будет признан удачным и, вероятно, на его основе уже напишут какое-то более чистое решение для продакшена, в котором уже будут применяться подходы из разработки. Но это уже будет самая простая часть работы, после всех предыдущих мучений.
economist75
04.12.2022 23:19Автор статьи предлагает выбросить то, что стало общепризнанным стандартом исследований, РКИ, A/B-tests итп, даже не упомянув главный плюс блокнотов - по-ячейное выполнение кода-лапши и сохранение значений переменных в RAM между выполнениями.
Анализ данных, ETL/ELT, визуализации - это абсолютно всегда итеративный процесс с театральными паузами, ручным перебором параметров, заменой концепций, возвратом к пол-сырым данным (версионирование данных), которые немыслимо делать в IDE, поскольку процедура загрузки данных, расчета огромного числа промежуточных полу-чистых колонок в IDE - сделает работу невыносимой. И да, дата-сатанистам нередко хочется выполнить 5-ю строку раньше 4-й, блокнот это позволяет на уровне ячеек. Разрезать ячейку можно нажав Ctrl+Shift+- и смею заверить, такое тоже происходит ежедневно.
Часть описанных проблем у блокнотов есть, но она не является стоп-фактором и решаема. Например, версионирование - решается простым nbdime или сложным Git plugin.
То что блокноты/тетрадки часто напоминают кухню холостяка - верно, с этим надо что-то делать: выносить UDF во внешние модули, стараться сохранять структурное программирование. Ну и просто быть аккуратнее. В IDE так не забалуешь, 5-я строка кода никогда не запустится раньше 4-й, но парадокс в том что именно это в DS нужно.
Нужно не "выбрасывать", а использовать лучшее из двух систем: IDE c открытым блокнотом (VSC, Pycharm итд) - позволяет привычно исполнять его по-ячейно, а если нужно - построчно отдебажить цикл перебора значений итп сложные штуки. В JupyterLab (web IDE) сейчас это тоже возможно.
CyaN
05.12.2022 09:18Автор статьи не понимает одну простую вещь: если бы датасатанисты хотели работать как разработчики, они бы и были разработчиками. А они в массе своей, специалисты совсем в других направлениях, для которых лучшей заменой блокнота стал бы более визуальный интерфейс, а не IDE. Надо будет - поставят задачу разработчикам.
netricks
Инженер думает на бумажке.
Lorendrake
как по мне так в Ide то поприятней думать) сразу кость алгоритма накидал и протестил
netricks
Иногда надо и картинки порисовать. Но ваш тезис скорее в пользу того, что юпитер нужен, чем нет.