Комментарии 23
Инженер думает на бумажке.
Очень поддерживаю.
Абсолютно согласен с тем, что в data-science или любой другой science лучше переходить в обычные IDE и хранить проекты (открытые) на Github или в подобных местах.
Получается куда более структурировано, да и ссылаться удобнее.
Киллер-фича этих блокнотов - возможность править код на живую и менять порядок исполнения кода прямо во время работы. То есть вы можете выполнить часть программы, увидеть результат - и исправить следующий кусочек не прерывая выполнения всего скрипта. Более того, можете перезапустить ранее выполнявшийся кусок кода, если с результатами его выполнения что-то не так. Выскочило исключение? Вам не нужно запускать выполнение всего скрипта с нуля, в большинстве случаев возможно перезапустить сбойный кусочек.
И даже стартовать скрипт может не с начала, а с указанного места и выполняться в указанном порядке.
Ни одна IDE и близко не даст вам подобного функционала, когда вы пишете и правите код непосредственно работающего скрипта без необходимости перезапуска. Это ускоряет разработку неимоверно, особенно учитывая, что ML - это зубодробильная матрично-векторная математика, где накосячить ну очень легко, а найти ошибку бывает сложно.
Формально, MATLAB в рамках своей IDE даёт такую возможность даже в обычных скриптах, не говоря уже о LiveScripts.
Но если мы говорим о питоне, то в нём логичнее бить код на обычные блоки (отдельные модули/классы/функции), а не писать длинную простыню. Хотя дело вкуса, конечно.
Вопрос в другом. Вот у меня приложение на старте загружает тяжеленную нейронку. Потом эта неронка за милисекунды обрабатывает разные данные, которые ей подсовываю для отладки визуализации. В блокноте один раз загрузил веса и работай с ними меняя код как хочешь в других ячейках.
А в IDE как избежать постоянной загрузки весов нейронки заново при перезапусках после изменений в модуле/функции?
Так где у вас веса: в блокноте или в приложении?
А как избежать постоянной загрузки?.. Ну запишите это всё в один файл. А оттуда уже берите.
Какая разница, где веса. Вопрос как избежать их загрузки при каждом перезапуске кода, потому что это занимает время. В блокноте понятно как - одна ячейка загузила веса, в другой отлаживаешь работу с весами, изменяя и перезапуская ее сколько угодно раз.
А в IDE надо ждать загрузку весов при каждом изменении/перезапуске кода и тратится куча времени.
Пример упрощенный, для наглядности.
А почему не упоминаются расширения для того же Юпитера, которые помогают работать с блокнотами в гите (nbdime и др)? Так же нет ни слова про DVC, которая, по сути создана для совместного использования с гитом
Кто-то реально использует DVC? Сколько видел советов его использования, но ни один знакомых мне дата саентистов им не пользуется.
А кто-то не использует Jupyter и интерактивные блокноты? Из всех моих знакомых дата саентистов, все используют. Надеюсь, я достаточно апеллировал к личному опыту.
DVC используют, как минимум, потому что DVC развивается и гайдов по его использованию становится все больше.
P.S. Мы у себя в команде начинаем внедрять, но у нас очень маленькая команда, поэтому не в счет
В целом, посыл верный, но более правильный путь - это пользоваться блокнотами там, где это необходимо. В самом начале экспериментов сразу лезть в IDE и писать скрипты - это не самая лучшая идея, учитывая, что большие датасеты могут загружаться в память и подготавливаться несколько минут, и словить ошибку после загрузки из-за какой-то мелочи (что часто случается в силу особенностей питона) очень неприятно, можно потратить кучу времени впустую. Да и вообще, каждый раз полностью перезапускать пайплайн, когда он еще не доведен до ума - накладно. Плюс в ноутбуках есть такая прекрасная вещь, как Markdown блоки, которые позволяют записывать свои мысли и описывать, что вообще там происходит, что нужно еще попробовать и так далее. Ну и не забываем про удобство работы с графиками, в скриптовом подходе это делать неудобно и долго по времени, поскольку датасеты в памяти не хранятся.
Мне показалось, что вы мешаете тёплое с мягким. Датасет и его чтение/разбор — одна сущность. Построение графиков — другая.
В философском плане, любая работа с данными (будь то ML, статистический анализ, регрессии какие-то) — суть метод сокращения размерности этого датасета.
И мы находим закономерности, не читая/правя датасет (абсолютно техническая операция), а делая над ним (уже загруженным) некие преобразования.
Ничего я не мешаю. Я говорю конкретный сценарий работы, в котором, например, может происходить следующее:
1) Загружаем большой датасет
2) Заполняем пропуски, чистим выбросы
3) Визуализируем, смотрим распределения
4) Создаем признаки
5) etc
В ноутбуках можно в рамках одной сессии легко вернуться в начало любого пункта и что-то переделать, можно быстро построить новые графики, попробовать разные способы чистки датасета, попробовать разные признаки, пока не получим хорошие, исправить ошибки и так далее, не тратя кучу процессорного времени на то, чтобы перезапускать все шаги с самого начала. Можно оставлять себе развернутые пометки в отдельных блоках, что проверил и почему от этого в итоге отказался.
Да, с помощью скриптов эти все проблемы можно решить, потратив на разработку дополнительное время, но зачем? Учитывая, что эти оптимизации все-равно вряд ли доедут до прода.
Ноутбуки - это классная штука, когда ты еще не знаешь, что конкретно ты хочешь сделать и что в итоге получить.
Простите, осуждаю. Возникло впечатление, что разработчик познал дзен хороших практик в разработке и побежал в отдел датасатанистов, дабы открыть им истину. Творческий процесс в науке (будь это наука о данных или о чём либо ещё) немного не так работает. Зачастую, глубоко плевать на версионирование 95% итераций (а если так параметры подкрутить? А сяк? А если ещё слой нейронов добавить?) Ещё 4% наиболее интересных попыток будут сохранены, чтобы вернуться к ним и/или кому-то показать. Наконец, оставшийся 1% будет признан удачным и, вероятно, на его основе уже напишут какое-то более чистое решение для продакшена, в котором уже будут применяться подходы из разработки. Но это уже будет самая простая часть работы, после всех предыдущих мучений.
Автор статьи предлагает выбросить то, что стало общепризнанным стандартом исследований, РКИ, 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) сейчас это тоже возможно.
Автор статьи не понимает одну простую вещь: если бы датасатанисты хотели работать как разработчики, они бы и были разработчиками. А они в массе своей, специалисты совсем в других направлениях, для которых лучшей заменой блокнота стал бы более визуальный интерфейс, а не IDE. Надо будет - поставят задачу разработчикам.
Чет я не понял, всё что нужно есть ноутах (в том же вскоде), да и удобства космические
Мы используем ноутбуки и git, у нас есть итерации бранят и continuous delivery. Такой вариант всех устраивает.
Databricks + Azure DevOps.
Big Data Tools негодует...
Выбросьте блокноты, или почему заниматься Data Science нужно так, будто вы разработчик