Инжиниринг в R. Часть 2: обработка данных с помощью DPLYR

Недавно мы начали серию статей о том, как организовать работу в R Notebook. Сегодня продолжим наше погружение в язык R и рассмотрим инструмент DPLYR, позволяющий производить обработку данных.

Огромное количество данных хранится в базах данных, и кто-то должен их оттуда доставать. Хорошо, если у вас большая компания и есть data-инженеры, способные закрыть эту задачу. Но часто это не так, и аналитику приходится обращаться к базам данных самому. При этом одни данные хранятся в одних базах, другие — в других. Что с этим делать?

Решить эту задачу легко с помощью пакета dplyr, который входит в tidyverse. Посмотрим на сниппет кода:

С помощью этого кода мы устанавливаем соединение с базой данных, запрашиваем из нее определенную таблицу и просим присоединить другие таблицы. После даем указания сделать ряд преобразований: зафильтровать по набору дат, по другим колонкам и сделать агрегацию. Мы пишем это на dplyr, под «капотом» которого есть dbplyr, и поэтому нам не надо транслировать это на SQL.

RStudio сделали инструмент, который умеет работать с данными, находящимися как в памяти, так и на внешних источниках (backends). Dplyr понимает, что, если вы обращаетесь к данным, которые есть в памяти, он будет обрабатывать их. Если же вы подключились к backend не из оперативной памяти, код для вас никак не поменяется. Вы работаете с тем же dplyr, и при этом трансляция с учетом поддерживаемого стандарта (MySQL/ BigQuery/ Postgres/ RedShift) произойдет за вас. Это огромная экономия и средств, и времени: можно быстро переключаться с одной базы на другую.

Выглядит это следующим образом:

Как трансляция происходит на практике? Мы запускаем код и подключаемся к базе данных, в которой около 1,3 млрд записей. Несмотря на огромное количество записей, загрузка происходит очень быстро. Почему? Ответ — lazy loading. Чтобы посмотреть, как это получилось, можно сделать преобразования и сохранить их в переменной visits. Таким образом начнет вызываться реальный SQL-запрос. В итоге мы получим 1,54 Гб данных, а также lazy query с неизвестным количеством строк и тремя колонками:

Дело в том, что dplyr старается максимально долго не обращаться к источнику данных. Пока вам действительно не понадобятся эти данные, он будет собирать все преобразования и хранить их, а когда эти данные будут нужны, он сгенерирует SQL-запрос, отдаст его в базу данных и получит результат. В приведенном случае он выдал нам небольшой объем данных, потому что мы не вызвали команду, требующую посчитать все, что есть.

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

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