i_shutov Sep 7 2016 at 14:55

Джентельменский набор пакетов R для автоматизации бизнес-задач

3 min

14K

Data Mining*Big Data*R*

+21

Comments 20

atikhonov Sep 7 2016 at 15:07

В раздел Shiny и веб формы, я бы добавил еще flexdashboard

i_shutov Sep 7 2016 at 15:19

Добавил. Упоминал его в предыдущих статьях, тут на этапе компоновки затерялся

galev Sep 7 2016 at 23:42

Интересно, Вы упомянули iterators, но не foreach? Мне кажется, это вообще пакет №2 для работы.

i_shutov Sep 8 2016 at 09:48

да, они шли в связке, потерялся при copy-paste при вычленении вторичных. Исправил

Alibek24 Sep 8 2016 at 11:43

спасибо! Ждем теперь какой-нибудь туториал

i_shutov Sep 8 2016 at 13:53

Вряд-ли получится дождаться. Их в интернете есть множество, нет смысла дублировать. А вот если есть конкретная задача, то можно попробовать накидать костяк и на ее примере обсудить тонкие или непонятные моменты.

ikashnitsky Sep 8 2016 at 14:24

Добавил бы к общим рекомендациям пакет rio, который оборачивает кучу разновидных функций для чтения файлов разных расширений в единую функций rio::import. С этим пакетом в большинстве случаев достаточно писать лишь import('file.extension') — а дальше магия.
Еще я очень люблю пакет pacman, который сильно упрощает установку/обновление/загрузку пакетов.
Много еще классных пакетов. Всех не перечислить. Стоит лишь столкнуться с конкретным вопросом — как правило, есть классный пакет.

i_shutov Sep 8 2016 at 14:34

pacman, как devtools начинают требоваться, когда занимаешься постоянными инсталляциями R на разных машинах\серверах.
Поэтому и не стал их упоминать с базовом списке.

К pacman я бы добавил еще и githubinstall

jzha Sep 8 2016 at 18:25

Спасибо за полезный список!

Интересно знать, Rcpp и прочие Rcpp* библиотеки не входят в ваш активный набор инструментов?

i_shutov Sep 8 2016 at 18:46

Евгений, добрый день.
В мой не входит, поскольку мне более интересно смотреть на задачи на стыке с бизнесом, чем писать низкоуровневые компоненты.
Если можете расширить список полезными для широкого круга на Ваш взгляд пакетами, допишите, пожалуйста, в комментарии, а я потом перетащу в текст.

jzha Sep 8 2016 at 23:01

Илья, пакет data.table включен в ваш список, но хочу лишний раз его порекоммендовать к использованию. Очень удобный синтаксис и превосходное быстродействие при работе с данными.
Еще, на мой взгляд, стоит упомянуть пакет googleVis для построения Google Charts диаграмм.

i_shutov Sep 9 2016 at 09:47

googleVis сам не использую, но включил

ikashnitsky Sep 9 2016 at 11:40

По-моему, уже вполне можно подводить итог: data.table начисто проиграл dplyr — и по читабельности/удобству скрипта, и по скорости расчетов, и по удобству интеграции с другими полезными пакетами (это отсылка к Hadleyverse)

i_shutov Sep 9 2016 at 11:45

Опасное заявление. Есть множество сторонников data.table и для ряда задач он действительно гораздо быстре. Люди в Яндексе, например, его любят. В целом, это хорошо, что есть альтернативные сосуществующие подходы. Но по простоте и широте подходов dplyr действительно выглядит лучше.

ikashnitsky Sep 9 2016 at 12:45

Раз уж такая пьянка… позволю себе еще одно "опасное" и совершенно субъективное мнение. Мне кажется, что data.table приходится больше по душе людям со сформированным давно математическим складом ума и тягой к емким формулировкам. Не удивительно, что гораздо более "человечный" dplyr стал значительно популярнее. Для подавляющего большинства пользователей R — это в первую очередь не язык программирования, а скриптовая замена менее гибких сред для анализа и визуализации данных (Excel, SPSS, SAS...). На протяжении долгого времени скорость работы data.table была главным аргументом против plyr. Но с появлением dplyr пал последний бастион. Так что, мне кажется, рекомендовать новичкам (а ведь на них рассчитана ваша статья, так?) data.table не правильно. При этом я абсолютно отдаю себе отчет в том, что data.table красив, быстр и прекрасно подходит для тех, что давно к нему привык.

i_shutov Sep 9 2016 at 12:51

в контексте новичков я совершенно согласен.
У меня data.table не "пошел", да и задач для его специального применения не было.
Ускорять с суток до секунд разумно, в этом случае можно искать альтернативные подходы.
Ускорять с десятков секунд до секунд — ну только, если действительно никак нельзя подождать.

Но не упомянуть было бы неправильно.
Опять же, рядом упомянут и tibble.
А списывать data.table не стоит, в репозитории 9К пакетов, наверняка у половины из них есть активные пользователи.

jzha Sep 9 2016 at 13:10

Хорошо, читабельность/удобство вещи субъективные. Приведите, пожалуйста, примеры или ссылки на тесты, в которых data.table начисто проигрывает по скорости расчетов dplyr. Я полагаю, такого быть не может. Возможно, ошибаюсь, не отслеживаю изменения в dplyr.

atikhonov Sep 9 2016 at 13:29

Согласен, во всех внешних тестах сравнений dplyr и data.table, да и на своем опыте вижу, data.table быстрее, как на базовых операциях (фильтрация, выбор) так и на сложных агрегациях, но может в каких-то вырожденных случаях dplyr и будет быстрее.

AristarXXXX Sep 14 2016 at 11:58

Хочу ещё добавить, что для получения данных из БД — не обойтись без:

RODBC для подключения к любым(ну почти) БД через ODBC коннекторы (но с настройкой с ходу разобраться не просто)
RMySQL для простого и удобного подключения к MySQL БД.

Знаю, что Илья (автор) про эти пакеты знает, но, может, кому-то информация будет полезна.

i_shutov Sep 22 2016 at 12:41

Новый термин — Tidyverse, который полезно взять на заметку.

Не далее как вчера применение parallel + hadleyverse позволило ускорить решение одной процессинговой задачки почти на порядок. Кода при этом стало существенно меньше.

Show the best of all time