Илья, спасибо за статью. Уже поставил в список на изучение. А мог бы ты подробнее расказать вот по этому поводу? после завершения вычислений вызывайте plan(sequential). Это закроет все процессы и освободит занимаемую ими память.
Спасибо за статью.
Я бы добавил ещё блок по работе с БД через dplyr. Можно подробно почитать вот тут.
Там вся соль в том, что не нужно писать SQL запросы, а можно манипулировать с данными привычными R функциями. При этом, при желании, можно посмотреть, какой SQL запрос будет отправлен для выполнения определённых команд. Работает отлично.
Пишите в процессе. Буду рад помочь, если что.
Только учтите пожалуйста, что в коде учитывается вариант, что по какой-то СХД не будет ошибок, но не учитывается вариант, когда вообще нигде не будет ошибок (у нас такого не бывает, так что я поленился). Если у вас такое может быть, то это надо учесть. :)
Спасибо за внимательность :)
Согласен, что в этом плане сравнение скорости выполнение не очень честное.
Оно скорее, как рекламный слоган со звёздочкой.
Дело в том, что в изначальном коде с помощью getdisk ещё собираются серийные номера дисков, а на момент переписывания кода на R стало понятно, что эти данные не нужны.
Помечу в тексте данную оговорку, чтобы было честно.
Спасибо на добром слове.
Это EMC VNX 5300.
Ну и, на самом деле, если бы был мониторинг по SNMP — это бы не помогло, потому что интересующие нас сообщения не являются аварийными. Может, по ним snmp trap и не получилось бы генерить. А если бы получилось забирать весь лог через snmp poll, то всё равно всё свелось бы к тому, что результат надо чем-то парсить и т.д. По факту в тот же код можно пару строчек поменять и будет опрос через snmp :)
Именно R, по простой причине, что я его более-менее знаю и уже использовал в подобных задачах. Думаю, что на Python можно сделать всё плюс-минус то же самое. Вопрос того кому что удобнее.
А что по ML делали на R? Поделитесь.
Спасибо за мнение. К священной войне не готов, но R это точно не тупик ) По поводу того, что шайни "такое..." я бы тоже поспорил. К его бесплатной версии сейчас уже и балансировку научились прикручивать и авторизацию. По поводу использования в Enterprise советую почитать публикацию, что тут недавно была. https://m.habr.com/ru/post/448946/
А это вообще извечный вопрос. Что лучше R или Python? Я начал изучать R несколько лет назад и ни разу не пожалел. Python тоже смотрел базовые обучалки. Как начинающему мне показалось, что они очень похожи, поэтому не увидел смысла переучиваться. Еще я активно использую среду Shiny, которая позволяет публиковать веб приложения, написанные на R, что для меня лишний повод "не смотреть в другую сторону".
Спаибо на добром слове. Уверен, что в python можно сделать примерно то же самое. Один из скриптов на PowerShell уже был написан, да и сама vmware рекомендует именно powershell для работы с ней. Ну и, если до конца честно, что знали, на том и написали )
Первый! :)
Отличная статья! Было бы круто, если бы на основе данного решения (или какого-то другого) были более частные и технические заметки с описанием подводных камней и способов их решения применительно к используемым средствам и инструментам. Ну т.е. нормализация форматов времени, русификация, кодировка. Это обычно то, с чем сталкиваются начинающие гугло-кодеры. Информации о каких-то базовых решениях на том же R масса, но она на 99% на английском языке и у них, соответственно, вопрос локализации не стоит. А в реальной жизни с этим сталкиваться приходится постоянно и времени на это уходит целая тьма. Ну и не только на это.
Спасибо за статью!
При всех плюсах системы (а она, действительно очень крута) лично мне будет психологически сложно переходить на платную версию Shiny + R + Всё-остальное. Бесплатной версии можно простить некие огрехи (они есть), а вот к платному enterprise решению совсем другие требования. Если руководство недальновидное — будет тяжело обосновать экономическую эффективность, особенно когда подавляющее большинство коллег апогеем аналитики считает функцию ВПР (вертикальный просмотр) в Excel. :)
А так — да. Пара-тройка толковых программистов-аналитиков-датамайнеров-дизайнеров и в компании вопрос какой-либо отчётности закрыт навсегда с этой системой :)
Статья очень интересная и содержит важные тонкости, с которыми пока не столкнёшься — не оценишь. Лично я себе сохранил. И всем прочитавшим советую )
Илья, как всегда спасибо, что просвещаешь и продвигаешь интересное решение.
Спасибо, бро. Такая же задача была. Смотрел в сторону этого сервиса, но не решился идти по этому пути. Теперь, думаю, попробую.
Спасибо за статью. Работал в подобных местах. Не знал, что у всего этого есть официальное название. Интересно было почитать.
Спасибо за статью. Сохранил.
Илья, спасибо за статью. Уже поставил в список на изучение. А мог бы ты подробнее расказать вот по этому поводу?
после завершения вычислений вызывайте plan(sequential). Это закроет все процессы и освободит занимаемую ими память.
Спасибо за статью.
Я бы добавил ещё блок по работе с БД через dplyr. Можно подробно почитать вот тут.
Там вся соль в том, что не нужно писать SQL запросы, а можно манипулировать с данными привычными R функциями. При этом, при желании, можно посмотреть, какой SQL запрос будет отправлен для выполнения определённых команд. Работает отлично.
Применил рекомендации.
Так что большое спасибо за рекомендации.
Итоговый результат.
Спасибо за советы. Завтра попробую — покажу, что получилось на примере имеющихся данных.
Пишите в процессе. Буду рад помочь, если что.
Только учтите пожалуйста, что в коде учитывается вариант, что по какой-то СХД не будет ошибок, но не учитывается вариант, когда вообще нигде не будет ошибок (у нас такого не бывает, так что я поленился). Если у вас такое может быть, то это надо учесть. :)
Спасибо за внимательность :)
Согласен, что в этом плане сравнение скорости выполнение не очень честное.
Оно скорее, как рекламный слоган со звёздочкой.
Дело в том, что в изначальном коде с помощью getdisk ещё собираются серийные номера дисков, а на момент переписывания кода на R стало понятно, что эти данные не нужны.
Помечу в тексте данную оговорку, чтобы было честно.
Спасибо на добром слове.
Это EMC VNX 5300.
Ну и, на самом деле, если бы был мониторинг по SNMP — это бы не помогло, потому что интересующие нас сообщения не являются аварийными. Может, по ним snmp trap и не получилось бы генерить. А если бы получилось забирать весь лог через snmp poll, то всё равно всё свелось бы к тому, что результат надо чем-то парсить и т.д. По факту в тот же код можно пару строчек поменять и будет опрос через snmp :)
Именно R, по простой причине, что я его более-менее знаю и уже использовал в подобных задачах. Думаю, что на Python можно сделать всё плюс-минус то же самое. Вопрос того кому что удобнее.
А что по ML делали на R? Поделитесь.
DoFuture почитаю. Спасибо. Единый лог файл, да. Согласен, что не помешал бы. Попробую добавить.
Классная подборка. Спасибо. Отложил. Потом внимательно почитаю.
Спасибо за интересные примеры с пояснением причинно-следственных связей и за воспроизводимость кода.
Особенностей, да, у R тоже много. К многому не привык. А по поводу crud в R как раз есть подходы и средства. Не очень простые, но я использовал. Вполне работает. Если интересно — советую почитать про rhandsontable https://jrowen.github.io/rhandsontable/, либо dtedit https://github.com/jbryer/DTedit (это отдельные библиотеки), либо есть очень интересная статья о том, как штатными средствами crud приложение на shiny делают. Я пробовал повторить для одного проекта — вполне работает https://www.google.com/amp/s/www.r-bloggers.com/shiny-crud-app/amp/
Спасибо за мнение. К священной войне не готов, но R это точно не тупик ) По поводу того, что шайни "такое..." я бы тоже поспорил. К его бесплатной версии сейчас уже и балансировку научились прикручивать и авторизацию. По поводу использования в Enterprise советую почитать публикацию, что тут недавно была. https://m.habr.com/ru/post/448946/
А это вообще извечный вопрос. Что лучше R или Python? Я начал изучать R несколько лет назад и ни разу не пожалел. Python тоже смотрел базовые обучалки. Как начинающему мне показалось, что они очень похожи, поэтому не увидел смысла переучиваться. Еще я активно использую среду Shiny, которая позволяет публиковать веб приложения, написанные на R, что для меня лишний повод "не смотреть в другую сторону".
Спаибо на добром слове. Уверен, что в python можно сделать примерно то же самое. Один из скриптов на PowerShell уже был написан, да и сама vmware рекомендует именно powershell для работы с ней. Ну и, если до конца честно, что знали, на том и написали )
Первый! :)
Отличная статья! Было бы круто, если бы на основе данного решения (или какого-то другого) были более частные и технические заметки с описанием подводных камней и способов их решения применительно к используемым средствам и инструментам. Ну т.е. нормализация форматов времени, русификация, кодировка. Это обычно то, с чем сталкиваются начинающие гугло-кодеры. Информации о каких-то базовых решениях на том же R масса, но она на 99% на английском языке и у них, соответственно, вопрос локализации не стоит. А в реальной жизни с этим сталкиваться приходится постоянно и времени на это уходит целая тьма. Ну и не только на это.
Спасибо за статью!
При всех плюсах системы (а она, действительно очень крута) лично мне будет психологически сложно переходить на платную версию Shiny + R + Всё-остальное. Бесплатной версии можно простить некие огрехи (они есть), а вот к платному enterprise решению совсем другие требования. Если руководство недальновидное — будет тяжело обосновать экономическую эффективность, особенно когда подавляющее большинство коллег апогеем аналитики считает функцию ВПР (вертикальный просмотр) в Excel. :)
А так — да. Пара-тройка толковых программистов-аналитиков-датамайнеров-дизайнеров и в компании вопрос какой-либо отчётности закрыт навсегда с этой системой :)
Статья очень интересная и содержит важные тонкости, с которыми пока не столкнёшься — не оценишь. Лично я себе сохранил. И всем прочитавшим советую )
Илья, как всегда спасибо, что просвещаешь и продвигаешь интересное решение.