Делают ли современные библиотеки R и / или Python SQL устаревшим?

14

Я работаю в офисе, где SQL Server является основой всего, что мы делаем, от обработки данных до очистки. Мой коллега специализируется на написании сложных функций и хранимых процедур для методической обработки входящих данных, чтобы их можно было стандартизировать и использовать в проектах отчетов, визуализаций и аналитики. До начала работы у меня было очень мало опыта работы с SQL, кроме написания самых простых запросов. Подавляющее большинство моей подготовительной работы по анализу было выполнено в R. Мой начальник настаивает на том, чтобы я улучшил свои навыки работы с SQL, хотя кажется, что очень мало заданий, которые не могут быть выполнены более эффективно и с гораздо меньшим количеством строк кода с использованием R пакеты, такие как dplyr, data.table и tidyr (чтобы назвать несколько). Мой вопрос - имеет ли это смысл?

Пару недель назад я столкнулся с задачей получения списка имен столбцов для каждой строки в таблице, отвечающей определенным критериям, и объединения их в вектор строк. Был сжатый срок, и в то время я испытывал некоторую блокировку и не мог полностью обдумать проблему. Я спросил моего босса, который в свою очередь попросил моего коллегу написать скрипт TSQL для решения проблемы. Пока он работал над этим, я нашел способ сделать это в R, написав довольно простую функцию и применив ее к фрейму данных. Мой коллега вернулся со своим сценарием около двух часов спустя. Было не менее 75 строк, включающих две вложенные петли. Я попросил его сообщить уведомить, когда он закончил работать, и он сказал, что это займет несколько часов. В то же время мой R-скрипт смог зациклить ~ 45 000 записей примерно за 30 секунд.

Правильно ли я предполагаю, что R - намного лучший выбор для очистки и удаления данных? Может быть, разработчик SQL в моем офисе просто неумел? Мне любопытно, если кто-нибудь, кто работал с R и SQL (или Python и SQL в этом отношении), задумался об этом.

AffableAmbler
источник
2
Если ваша база данных достаточно мала и статична, вы можете загрузить ее в память и использовать предпочитаемый вами инструмент ETL, например dplyr. Ваш подход просто не будет работать, когда у вас большие данные в облаке. Я регулярно запускаю запросы, которые заставляют BigQuery (Google) жаловаться. Я пишу запросы непосредственно в SQL, но я мог бы использовать Spark в качестве промежуточного уровня для работы в рамках данных, если бы захотел.
Эмре
1
Так является ли SQL по своей сути более эффективным, чем R, с точки зрения способа хранения данных, или это просто то, что серверы SQL имеют тенденцию иметь больше встроенной памяти и вычислительной мощности?
AffableAmbler
1
Вы не можете сделать общий оператор - это зависит от реализации - но хорошие базы данных имеют оптимизаторы запросов, и некоторые из них (например, BigQuery) поддерживают многоядерное выполнение. Может быть, вам нужен именно фрейм данных или ORM-абстракция поверх вашей базы данных, чтобы избежать SQL. Кажется, dplyr уже делает это в некоторой степени (см. Перевод SQL ). Вы можете сравнить этот же запрос в dplyr с необработанным SQL, чтобы выяснить это. Некоторые делают, чтобы взять небольшую выборку данных для создания прототипа, а затем использовать инструменты для работы с большими данными
Эмре,
3
Вы можете просто запустить R внутри SQL Server и получить лучшее из обоих миров
Гай

Ответы:

13

R и SQL - два совершенно разных зверя. SQL - это язык, который вы можете использовать для запроса данных, которые хранятся в базах данных, как вы уже испытали. Преимущества SQL по сравнению с R заключаются главным образом в факте работы сервера базы данных (MS SQL, Oracle, PostgreSQL, MySQL и т. Д.).

Большинство, если не все, современные серверы баз данных позволяют нескольким пользователям запрашивать данные из одного и того же источника данных и вставлять, обновлять и удалять данные в одних и тех же таблицах, обеспечивая при этом целостность данных. Это важно, например, для записи банковской транзакции. Можете ли вы представить себе управление банком на R? Вот тут и вступают серверы баз данных. Они обеспечивают свойства ACID процедур, выполняемых в базе данных. ACID означает атомарность, параллелизм, изоляцию и долговечность (см. Описание ACID в Википедии ). R - это однопользовательская платформа, где все происходит в памяти. Таким образом, если ваш компьютер перестает работать на полпути в большой операции, ваши данные не будут сохранены. Вы также единственный человек, который может получить доступ к данным. Для ясности, R не считается альтернативой для серверов баз данных и / или SQL.

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

Язык SQL имеет совершенно другой синтаксис, и я поделюсь вашим опытом, что короче писать шаги обработки данных с использованием таблицы данных или синтаксиса dplyr. Однако иногда ваши данные слишком велики для R, или вам нужно хранить результаты в базе данных как часть периодического пакетного задания, которое потребует кодирования вашей логики в SQL.

По моему опыту есть конкретные случаи использования для SQL и R / Python. SQL отлично подходит для хранения важных для бизнеса данных и позволяет нескольким людям получать доступ, изменять, вставлять и удалять данные в централизованной среде. Для любых одноразовых данных отлично подойдут R и Python. Если ваши данные должны периодически выполняться, вам нужно будет перенести сценарий R / Python на SQL.

Стерео
источник
3

Это даже не сравнимо, правда. SQL - это язык, предназначенный для доступа к данным, R - это язык, предназначенный для работы с данными.

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

Мой рабочий процесс обычно:

  1. Получить необработанные данные из запроса SQL (в R)
  2. Построить рутины
  3. Если возможно, перепишите SQL-запрос, чтобы выполнить манипуляцию, которую я выполнил в R

Также следует понимать, что не все потребители данных используют R, но многие по-прежнему связывают свою платформу с данными с использованием SQL.

HEITZ
источник
1
Это тот же процесс, которому я следую (к большой неприязни моего руководителя). Я согласен с тем, что выполнение сложных задач, таких как те, что я описал выше, кажется, гораздо более эффективно выполняется на языке, подобном R. (Примите во внимание утверждение). Но если единственная цель SQL - быть гигантским жестким диском для ваших данных, почему бы просто не иметь R-сервер? Похоже, что все функции (сопоставление, установка ключей для связывания таблиц, группирование и объединение данных) теперь могут выполняться очень эффективно в R. Является ли таблица SQL более эффективной с точки зрения использования памяти, чем фрейм данных R?
AffableAmbler
1
@ Нет, потому что не все люди используют R.
HEITZ
2

библиотека (dbplyr) имеет правильный подход: запишите все в R (используя tidyverse) и позвольте библиотеке точно в срок «скомпилировать» код R в низкоуровневый SQL.

Поскольку не все функции могут быть переведены, SQL Server использует другой подход: пусть фрагменты кода R запускаются из команд SQL «select».

Дэн Резник
источник
1

Подход 1., 2., 3., упомянутый HEITZ, по моему опыту, может быть расширен за счет альтернативы 3., где вы записываете свои данные из R (data.table) обратно в MySQL.

Так что полными шагами являются MySQL-> data.table-> MySQL

Если вы уверены, что используете синтаксис data.table, если не копируете DT, он также дружествен к ОЗУ.

Нильс Крог
источник
1

Одним словом НЕТ . SQL является мощным, лаконичным и гибким способом описания и обобщения структурированных полуструктурированных и даже неструктурированных данных, когда над ним размещается соответствующий уровень интерпретатора. Кстатиsql , считается почти обязательным для данных ученых.

SQL это краткий и эффективный способ выполнения основных операций:

  • прогнозы ( выберите ..)
  • фильтрация ( где ..)
  • группировка / фильтрация ( группировка и наличие )
  • базовые агрегаты ( количество , сумма , средняя ..)
  • присоединяется

Настоящая сила приходит при объединении результатов с использованием встроенных представлений . Когда мне нужно сделать , что я буду использовать один из sqldf, pandasql, pysparkSql/ sparkSqlили прямого подключения РСУБД. Писать то же самое в максимально сжатой форме с data.table(намного лучше чем data.frame) или datatable(лучше чем pandas) все еще более неуклюже, намного более неуклюже или почти невозможно в зависимости от сложности попыток запроса.

Для манипулирования данными : это другая история: некоторые операции легко выражаются в sql, а некоторые не так много. Однако, если вы включите UDFs, то вы получите более широкую свободу действий. Моя текущая задача включает в себя ряд задач UDF, таких как операции пересечения клиентов , пользовательские агрегации и пользовательские методы оценки .

javadba
источник