Союз R и PostgreSQL. Анализируем работу аэропортов, рассчитываем пенсии

[kolu4iy]

Долго думал — что за неизвестный продукт космической индустрии "Союз R".

[Igor_Le]

:)

[BkmzSpb]

require("RPostgreSQL")

Обычно require рекомендуется использовать в функциях, т.к. в случае ошибки он выдает warning. Для загрузки пакета лучше использовать library один раз в начале.

Time <- res1[,c('t')]
City <- res1[,c('city')]

Несовсем понятно зачем использовать функцию c() для создания вектора длиной… 1 элемент. Достаточно написать res1[, "t"] или даже res1$t.

Ну и про оператор присваивания. Их так-то 5 штук, и на месте <- спокойно можно использовать = (дело вкуса / соглашения). = необходим при вызове функций и передачи аргументов по имени.

dev.off(), кстати, тоже выполняет определенную функцию и в целом его вызов может не требоваться. Зависит от окружения в котором вы строите графики (например, IDE). dev.off() необходим для I/O, его можно скобинировать с tryCatch({ expr;}, finally = dev.off()) чтобы не оставить ваш "девайс" в подвешенном состоянии если во время построения графика что-то отвалится.

[Igor_Le]

Спасибо! Моя цель показать, что R + PostgreSQL полезное сочетание. Я, как можно догадаться, «со стороны» PG, и такие дополнения, как ваши, очень к месту.

[evgeny_i]

Использую R в связке с PostgreSQL. RPostgreSQL уже несколько лет не обновляется. Вместо него рекомендую RPostgres. К тому же он быстрее.

[Val83]

Если бы прочитал такое пару лет назад — желание изучать R отпало бы. Примитив какой-то описан.

[Igor_Le]

У меня не было цели рекламировать R.

[BkmzSpb]

Вообще лучше бы прорекламировали. На хабре так мало статей про R, хотя для работы с данными это один из лучших инструментов. Не говоря уже о tidyverse, где можно обложиться пайпами и non-standard evaluation и переквалифицироваться в функциональщину.

[Igor_Le]

Что-то tidyverse.org недоступен.

[Ananiev_Genrih]

статья из разряда "ну совсем вводная" и конечно не про рекламу R ибо такую "бородатую" визуализацию на R нынче мало кто делает.
Больше интересно было бы про нагрузочное тестирование в этой связке, какие есть вилы/грабли при связке dbplyr+СУБД, какие есть возможности тюнинга для повышения эффективности работы этой связки.
Например недавно коллеги подбросили интересную ссылку по сравнению производительности связки одной колоночной аналитической СУБД как в классической связке (R+Server) так и СУБД развернутой внутри самой R-сессии (вообще огонь). Там к примеру есть сравнение как с (PL/R-naive) так и с (PL/R-tuned), вот про тюнинг было бы интересно почитать как описание личного опыта/эксперимента.

[StepanTomsk]

Если есть возможность то поднимайте slave read only для аналитики — снижаете риск «положить» прод. Когда это не помогает экспортируйте данные, желательно совместно с обработкой и денормализацией, например в clickhouse или в Vertica (до 1 ТБ — бесплатно).
Если у Вас обработка данных разовая то порой проще выгрузить весь набор данных за период не фильтруя в БД, seq-scan дешевле (особенно на ssd).
Join это боль, лучше делать его на самом последнем этапе, и не в БД.
Если таблица в PostgreSQL разбита на партиции то лучше выгружать и обрабатывать данные по каждой партиции отдельно. Большая боль будет если одновременно нужно сделать join по нескольким партишированным таблицам.

Основной подход — выгрузить данные и обрабатывать их за пределами реляционной БД.

[Igor_Le]

Насчет нагрузочного тестирования — отличная идея. Не на ближайшие дни, конечно. Вторая часть будет тоже «ну совсем вводная», а вот попозже можно и про нагрузочное и про тюнинг. В ближайшей, может, будет о «наоборот»: о визуализации в R статистики самой базы под нагрузкой. За ссылку и идеи спасибо!

[StepanTomsk]

Доброго всем дня.
Статью можно рассматривать как первый шаг к дальнейшему погружению в R и/или статистическую обработку данных, особенно если у Вас уже есть PostgreSQL (или иная БД с ODBC).

Существует одна ошибка начинающих аналитиков — работая с R мы продолжаем мыслить в рамках терминов баз данных, писать SQL… и, по факту, тратить свое время не на исследование данных.

В R есть великолепный инструмент dplyr, который позволяет абстрагироваться от синтаксиса SQL и перейти непосредственно к обработке данных. Но dplyr не ограничивает Вас и позволяет исполнять «рукописные» запросы.
Когда нужны «рукописные» запросы? Здесь варианты, например — сложные join, ручная оптимизация, вызов табличных функций. Да, в этих случаев иногда стоимостный оптимизатор PostgreSQL справляется не блестяще, но не забываем у нас не OLAP БД.

Рекомендую к прочтению Why SQL is not for Analysis, but dplyr is (eng).