Давайте я немного поясню контекст, в котором я с этим сталкиваюсь на практике.
В DS/ML проектах зависимости обычно тяжёлые, чувствительные к версии окружения и легко могут занимать 5+ ГБ (только py пакеты). При этом код должен одинаково запускаться локально, на удалённых dev боксах и, условно, в k8s кластере. Да, разработчик может самостоятельно поставить себе venv, настроить питон, зависимости, линтеры и редактор. Но на практике это почти всегда означает часы ручной настройки, расхождения окружений и ошибки, которые сложно воспроизводить.
В этом шаблоне делается другой выбор: разработчику сразу даётся готовый dev инструмент, который поднимается одной командой docker compose run. В моём случае это слой с vim/jupyter/codex..., но это не принципиально, т.к. на его месте может быть VS Code devcontainer или любая другая IDE. Ключевая идея в том, что редактор и инструменты работают в том же окружении, где живёт код и зависимости, локально или на удалённой машине, в том числе с доступом к GPU.
При этом важно разделять dev и прод контейнеры, и в шаблоне это разделение есть. В прод образе (или заготовке под него) нет линтеров и прочих dev инструментов, там только код и runtime зависимости. Реализовать это можно разными способами, я выбрал установку через poetry с группами зависимостей для унификации подхода.
Согласен, у такого решения есть избыточность по размеру dev образов. В общем случае, CI и прод сборки почти всегда требуют отдельной оптимизации и универсального решения здесь не существует. Однако, процедура настройки рабочего окружения сводится к паре команд, а довести шаблон до конкретных прод сценариев можно в любой момент, уже под задачи проекта.
Зачем внутри контейнера нужен venv, это и так изолированная среда?
Хорший вопрос. Могу поделиться интуицией. venv здесь используется не для изоляции, а для структуры и предсказуемости. venv вместе с целевой версией питона выделяет окружение проекта в отдельный, хорошо определённый слой. Это упрощает контроль зависимостей, хорошо интегрируется с poetry и делает поведение окружения более стабильным в мультистадиных сборках. В таком подходе зависимости проекта не смешиваются с системным питоном и не протекают между стадиями сборки.
Кроме того, на практике многие инструменты, типа, линтеры, чекеры, форматтеры и автокомплитеры (black, pylint, ruff, lsp и т. д.) ожидают наличие виртуального окружения или, по крайней мере, работают с ним более предсказуемо.
Зачем копировать src до вызова установки зависимостей
poetry install в режиме установки root пакета требует наличия readme и исходного кода проекта. Поэтому на этом этапе код копируется заранее. Подумаю как разделить, но вызовов poetry install будет два...
Снятие лимитов тоже крайне сомнительная история
В целом замечание справедливое. Вопрос здесь скорее в том, какие значения задавать по умолчанию для шаблона. На практике я часто их отключаю для dev сборок, что бы не натыкаться переодически на ограничения и не пересобирать всё. Наверное, стоит добавить комментарий в документацию по этому поводу, что настройки лимитов не являются рекомендацией для прода, а лишь удобной стартовой точкой.
Если честно, то я пока ни разу не сталкивался с блокировкой хостинга archlinux.org со стороны своего провайдера (РТ). Но, конечно же, такое может случиться.
Если запрос зеркал не отработает, то в контейнере остануться зеркала по умолчанию. Сейчас это:
В качестве решения можно задать зеркала в отдельном конфиге (например, зеркало Яндекса). И на сборке заменять /etc/pacman.d/mirrorlist без динамического резолвинга зеркал по стране. В этом случае, докерфайл получится короче, но нужно следить за актуальносью зеркал.
На мой взгляд воспроизводимое. pacman -Syu больше для безопасности, по размеру это с десяток мегабайт, базовые пакеты не так часто обноаляются, но что бы установка зависимостей прошла гарантировано без сбоев лучше убедиться что всё в актуальном состоянии.
прям две субд сразу используете в проде?
Это пример установки библиотек в шаблоне. Эти библиотеки вообще можно убрать из .env если python пакеты не имеют от них зависимостей. На практике DS/ML проекты не обходятся без клиентов к БД, поэтому решил оставить для иллюстрации.
а зачем ставили?
sudo остаётся для dev сборок. Иногда по зависитям что то не работает сразу. Удобно в контейнере что то доставить, проверить и потом перенести решение в сборки за один раз.
Аспирантура это научная деятельность. Туда надо идти, если вы хотите заниматься наукой, открывать, доказывать и очень тяжело работать. В этом деле то же можно прилично зарабатывать, но для этого необходимо состоятся как учёный. Все сразу начинают сравнивать доход аспиранта с оплатой труда начинающего разработчика. Да, по началу такое сравнение не в пользу науки. Но со временем, ситуация меняется, доход растёт и (очень трудолюбивый) человек из науки может иметь сопоставимый доход, при том, что он занимается уникальными, интересными вещами, ездит по конференциям, сам решает куда ему двигаться и, возможно, окажется в одном из ведущих мировых университетов, где будет делать любимое дело до 70+ лет. Это как сравнивать людей, которые не захотели идти в университет и решили сразу зарабатывать руками. Сопоставим ли доход студента с доходом, например, профессионального сантехника? Нет. Но в перспективе всё меняется. С аспирантурой можно провести такую же аналогию.
Хороший обзор у вас получился. В этой области есть еще одна важная и фундаментальная работа. Это механизм favor+. Он позволят выпонять операции внимания в линейном пространстве и полностью совместим с оригинальной архитектурой трансформера.
Это обычный Pro, тип машины с увеличенным объёмом памяти. Есть ещё машины на TPU, там памяти больше, но и возни с этим TPU тоже не мало.
Сейчас появился план Pro+, там обещают ещё более мощные ресурсы, выполнение блокнотов в фоне, большее время работы инстансов. Правда стоит это в 5 раз дороже - почти 50 баксов в месяц.
У меня Pro, но это не помогло )) Потому что у инстанса с GPU всего 120 GiB свободно. А обучение с диска на одну эпоху это в среднем час против 30 минут с локального хранилища. И ещё при обучении с диска в течении суток могут возникнуть ошибки с доступом к файлу и процесс прервётся.
Да, конечно. Собственно, защита диссертации это и было представление реализованной системы.
Там отдельны компоненты в разное время запускались, вот статьи по ним, если вам интересно
Новая архитектура автоматизированной системы сбора, хранения и обработки сейсмологических данных, 2013, ссылка
Автоматическая система на базе EARTHWORM для расчёта параметров очагов локальных землетрясений в режиме реального времени, 2016, ссылка есть только на переводной вариант.
Ну смотрите: даже чисто интуитивно, наша цель это каталог землетрясений на какой то наблюдаемой территории. В каталоге для каждого события обычно четыре параметра: координаты эпицентра, глубина и магнитуда. Даже если отбросить тонкости расчёта магнитуды, для 3-х неизвестных нам нужно минимум три станции. И чем больше станций, тем точнее вы определяете положение очага, что очень важно. Если у вас шумные станции, но вы можете снимать с них вступления, то всё ОК. Если их много, то у вас маленькие невязки при расчёте. Ещё есть всякие вещи, связанные с измерением ускорений грунта, это, с какой силой трясло. Эти измерения то же важны, и чем их больше - тем лучше.
Подробно про методы расчёта параметров очага можно здесь посмотреть (раздел 1.5). А в главе 3 рассмотрены вопросы оценки погрешностей в расчётах.
Такая практика распространена в Японии с финансированием на государственном уровне. Скважинные датчики действительно очень "тихие". И очень дорогие )) как сами по себе так и в обслуживании. За стоимость одного скважинного датчика можно поставить 10+ raspberry shake и получить плотную сеть, что гораздо важнее.
Спасибо за отзыв ) Работа не касается предсказания землетрясений как таковых. Усилия были направлены на выявление землетрясений которые уже произошли и попали на сейсмограммы.
В соревновании не участвовал. А вообще, предсказание землетрясений - это, на текущий момент, не решенная фундаментальная проблема сейсмологии. Даже если сделать какую-то модель на реальных данных и она что-то будет предсказывать, то потребуется серьёзное обоснование того, что модель делает правильные вещи.
Калифорнийский датасэт самый большой, содержит только локальные записи и очень качественно сформирован. Мы дополнительно к нему опубликовали два своих. Ещё есть STEAD.
выкинули дни с дождями меньше 45 мм? Ok, пусть (или какую-то ещё очистку производили?).
Вообще то 54 мм. Все значения проверили, можете сами посмотреть, там всё в порядке.
"Рассчитываем важность фичей с помощью SHAP". Я думаю это может вполне подсветить "черный ящик".
SHAP отличная штука. Кроме этого, есть ещё байесовские нейронные сети - то же интересный подход в этом направлении. Лично меня эта тема очень захватывает. Но вы поймите, мы писали научную статью, рассчитанную на определённое научное сообщество геофизиков, поэтому выбор инструментов был соответсвующий. Кроме этого, положительных классов крайне мало.
Очистку данных производили. Смотрите, пожалуйста, раздел таблицы после заголовка Data user for logistic regression.
Мне кажется несколько надуманной идея использования именно логистической регрессии.
В статье подробно объясняется почему мы использовали этот инструмент - нам нужна была значимость коэффициентов и их оценка. Если вы будете использовать подход ML вы получите модель "черный ящик", где параметры абсолютно ничего не значат.
Ну, с одной стороны, вы правы. С другой стороны, есть предупреждающие меры, а есть спасательные работы. Если уже 5 дней льёт дождь, и у вас есть в распоряжении прогноз погоды, то вы можете предсказать высокую вероятность оползней в городской черте. В этом случае, у вас есть время собрать силы и средства для возможных оползней: подготовить технику, проинструктировать спасателей и так далее. Передвижение готового отряда по городу - это часы. А если не подготовится и сойдёт много оползней, то до кого то помощь может во время не дойти.
Берем конкретный день, например, вчера 15 августа 2021 года. Смотрим показания метеостанции, а именно:
DR - суточное значение осадков за 15 августа;
AR - значение предшествующих осадков. Если дождь лил непрерывно, то это будет кумулятивное значение за все дни непрерывных осадков. Если был один сухой день - 14 августа - то 0.
CP - кумулятивное значение осадков с начала года.
Теперь мы ставим все эти данные с метеостанции в формулу выше и если левая часть больше либо равна 122 то оползень будет (по модели).
Кстати! Здесь есть один очень интересный момент. Если AR и CP равны 0, то что бы сошел оползень (по модели) за день должно выпасть 122 мм осадков! Этот вывод отмечен в статье. И это ещё один аргумент в пользу статистического подхода - мы можем использовать исходные коэффициенты регрессии для таких выводов.
Давайте я немного поясню контекст, в котором я с этим сталкиваюсь на практике.
В DS/ML проектах зависимости обычно тяжёлые, чувствительные к версии окружения и легко могут занимать 5+ ГБ (только py пакеты). При этом код должен одинаково запускаться локально, на удалённых dev боксах и, условно, в k8s кластере. Да, разработчик может самостоятельно поставить себе venv, настроить питон, зависимости, линтеры и редактор. Но на практике это почти всегда означает часы ручной настройки, расхождения окружений и ошибки, которые сложно воспроизводить.
В этом шаблоне делается другой выбор: разработчику сразу даётся готовый dev инструмент, который поднимается одной командой docker compose run. В моём случае это слой с vim/jupyter/codex..., но это не принципиально, т.к. на его месте может быть VS Code devcontainer или любая другая IDE. Ключевая идея в том, что редактор и инструменты работают в том же окружении, где живёт код и зависимости, локально или на удалённой машине, в том числе с доступом к GPU.
При этом важно разделять dev и прод контейнеры, и в шаблоне это разделение есть. В прод образе (или заготовке под него) нет линтеров и прочих dev инструментов, там только код и runtime зависимости. Реализовать это можно разными способами, я выбрал установку через poetry с группами зависимостей для унификации подхода.
Согласен, у такого решения есть избыточность по размеру dev образов. В общем случае, CI и прод сборки почти всегда требуют отдельной оптимизации и универсального решения здесь не существует. Однако, процедура настройки рабочего окружения сводится к паре команд, а довести шаблон до конкретных прод сценариев можно в любой момент, уже под задачи проекта.
Хорший вопрос. Могу поделиться интуицией. venv здесь используется не для изоляции, а для структуры и предсказуемости. venv вместе с целевой версией питона выделяет окружение проекта в отдельный, хорошо определённый слой. Это упрощает контроль зависимостей, хорошо интегрируется с poetry и делает поведение окружения более стабильным в мультистадиных сборках. В таком подходе зависимости проекта не смешиваются с системным питоном и не протекают между стадиями сборки.
Кроме того, на практике многие инструменты, типа, линтеры, чекеры, форматтеры и автокомплитеры (black, pylint, ruff, lsp и т. д.) ожидают наличие виртуального окружения или, по крайней мере, работают с ним более предсказуемо.
poetry install в режиме установки root пакета требует наличия readme и исходного кода проекта. Поэтому на этом этапе код копируется заранее. Подумаю как разделить, но вызовов poetry install будет два...
В целом замечание справедливое. Вопрос здесь скорее в том, какие значения задавать по умолчанию для шаблона. На практике я часто их отключаю для dev сборок, что бы не натыкаться переодически на ограничения и не пересобирать всё. Наверное, стоит добавить комментарий в документацию по этому поводу, что настройки лимитов не являются рекомендацией для прода, а лишь удобной стартовой точкой.
Если честно, то я пока ни разу не сталкивался с блокировкой хостинга archlinux.org со стороны своего провайдера (РТ). Но, конечно же, такое может случиться.
Если запрос зеркал не отработает, то в контейнере остануться зеркала по умолчанию. Сейчас это:
Server =https://fastly.mirror.pkgbuild.com/
arch
Server =https://geo.mirror.pkgbuild.com/
archПо whois, похоже, это один и тот же провайдер.
В качестве решения можно задать зеркала в отдельном конфиге (например, зеркало Яндекса). И на сборке заменять
/etc/pacman.d/mirrorlistбез динамического резолвинга зеркал по стране. В этом случае, докерфайл получится короче, но нужно следить за актуальносью зеркал.На мой взгляд воспроизводимое. pacman -Syu больше для безопасности, по размеру это с десяток мегабайт, базовые пакеты не так часто обноаляются, но что бы установка зависимостей прошла гарантировано без сбоев лучше убедиться что всё в актуальном состоянии.
Это пример установки библиотек в шаблоне. Эти библиотеки вообще можно убрать из .env если python пакеты не имеют от них зависимостей. На практике DS/ML проекты не обходятся без клиентов к БД, поэтому решил оставить для иллюстрации.
sudo остаётся для dev сборок. Иногда по зависитям что то не работает сразу. Удобно в контейнере что то доставить, проверить и потом перенести решение в сборки за один раз.
Аспирантура это научная деятельность. Туда надо идти, если вы хотите заниматься наукой, открывать, доказывать и очень тяжело работать. В этом деле то же можно прилично зарабатывать, но для этого необходимо состоятся как учёный. Все сразу начинают сравнивать доход аспиранта с оплатой труда начинающего разработчика. Да, по началу такое сравнение не в пользу науки. Но со временем, ситуация меняется, доход растёт и (очень трудолюбивый) человек из науки может иметь сопоставимый доход, при том, что он занимается уникальными, интересными вещами, ездит по конференциям, сам решает куда ему двигаться и, возможно, окажется в одном из ведущих мировых университетов, где будет делать любимое дело до 70+ лет. Это как сравнивать людей, которые не захотели идти в университет и решили сразу зарабатывать руками. Сопоставим ли доход студента с доходом, например, профессионального сантехника? Нет. Но в перспективе всё меняется. С аспирантурой можно провести такую же аналогию.
Это работа вышла меньше года назад, но на неё уже 252 ссылки )
Хороший обзор у вас получился. В этой области есть еще одна важная и фундаментальная работа. Это механизм favor+. Он позволят выпонять операции внимания в линейном пространстве и полностью совместим с оригинальной архитектурой трансформера.
cat /proc/cpuinfo
Это обычный Pro, тип машины с увеличенным объёмом памяти. Есть ещё машины на TPU, там памяти больше, но и возни с этим TPU тоже не мало.
Сейчас появился план Pro+, там обещают ещё более мощные ресурсы, выполнение блокнотов в фоне, большее время работы инстансов. Правда стоит это в 5 раз дороже - почти 50 баксов в месяц.
У меня Pro, но это не помогло )) Потому что у инстанса с GPU всего 120 GiB свободно. А обучение с диска на одну эпоху это в среднем час против 30 минут с локального хранилища. И ещё при обучении с диска в течении суток могут возникнуть ошибки с доступом к файлу и процесс прервётся.
Да, конечно. Собственно, защита диссертации это и было представление реализованной системы.
Там отдельны компоненты в разное время запускались, вот статьи по ним, если вам интересно
Новая архитектура автоматизированной системы сбора, хранения и обработки сейсмологических данных, 2013, ссылка
Автоматическая система на базе EARTHWORM для расчёта параметров очагов локальных землетрясений в режиме реального времени, 2016, ссылка есть только на переводной вариант.
Ну смотрите: даже чисто интуитивно, наша цель это каталог землетрясений на какой то наблюдаемой территории. В каталоге для каждого события обычно четыре параметра: координаты эпицентра, глубина и магнитуда. Даже если отбросить тонкости расчёта магнитуды, для 3-х неизвестных нам нужно минимум три станции. И чем больше станций, тем точнее вы определяете положение очага, что очень важно. Если у вас шумные станции, но вы можете снимать с них вступления, то всё ОК. Если их много, то у вас маленькие невязки при расчёте. Ещё есть всякие вещи, связанные с измерением ускорений грунта, это, с какой силой трясло. Эти измерения то же важны, и чем их больше - тем лучше.
Подробно про методы расчёта параметров очага можно здесь посмотреть (раздел 1.5). А в главе 3 рассмотрены вопросы оценки погрешностей в расчётах.
Такая практика распространена в Японии с финансированием на государственном уровне. Скважинные датчики действительно очень "тихие". И очень дорогие )) как сами по себе так и в обслуживании. За стоимость одного скважинного датчика можно поставить 10+ raspberry shake и получить плотную сеть, что гораздо важнее.
Спасибо за отзыв ) Работа не касается предсказания землетрясений как таковых. Усилия были направлены на выявление землетрясений которые уже произошли и попали на сейсмограммы.
В соревновании не участвовал. А вообще, предсказание землетрясений - это, на текущий момент, не решенная фундаментальная проблема сейсмологии. Даже если сделать какую-то модель на реальных данных и она что-то будет предсказывать, то потребуется серьёзное обоснование того, что модель делает правильные вещи.
Калифорнийский датасэт самый большой, содержит только локальные записи и очень качественно сформирован. Мы дополнительно к нему опубликовали два своих. Ещё есть STEAD.
Вообще то 54 мм. Все значения проверили, можете сами посмотреть, там всё в порядке.
SHAP отличная штука. Кроме этого, есть ещё байесовские нейронные сети - то же интересный подход в этом направлении. Лично меня эта тема очень захватывает. Но вы поймите, мы писали научную статью, рассчитанную на определённое научное сообщество геофизиков, поэтому выбор инструментов был соответсвующий. Кроме этого, положительных классов крайне мало.
Очистку данных производили. Смотрите, пожалуйста, раздел таблицы после заголовка Data user for logistic regression.
В статье подробно объясняется почему мы использовали этот инструмент - нам нужна была значимость коэффициентов и их оценка. Если вы будете использовать подход ML вы получите модель "черный ящик", где параметры абсолютно ничего не значат.
Спасибо за отзыв!
Ну, с одной стороны, вы правы. С другой стороны, есть предупреждающие меры, а есть спасательные работы. Если уже 5 дней льёт дождь, и у вас есть в распоряжении прогноз погоды, то вы можете предсказать высокую вероятность оползней в городской черте. В этом случае, у вас есть время собрать силы и средства для возможных оползней: подготовить технику, проинструктировать спасателей и так далее. Передвижение готового отряда по городу - это часы. А если не подготовится и сойдёт много оползней, то до кого то помощь может во время не дойти.
Спасибо!
В статье стоят авторы и аффилиация: ДВГИ ДВО РАН. В основном работа была выполнена силами сотрудников Сахалинского филиала.
Берем конкретный день, например, вчера 15 августа 2021 года. Смотрим показания метеостанции, а именно:
DR - суточное значение осадков за 15 августа;
AR - значение предшествующих осадков. Если дождь лил непрерывно, то это будет кумулятивное значение за все дни непрерывных осадков. Если был один сухой день - 14 августа - то 0.
CP - кумулятивное значение осадков с начала года.
Теперь мы ставим все эти данные с метеостанции в формулу выше и если левая часть больше либо равна 122 то оползень будет (по модели).
Кстати! Здесь есть один очень интересный момент. Если AR и CP равны 0, то что бы сошел оползень (по модели) за день должно выпасть 122 мм осадков! Этот вывод отмечен в статье. И это ещё один аргумент в пользу статистического подхода - мы можем использовать исходные коэффициенты регрессии для таких выводов.