Чи сучасні бібліотеки R та / або Python роблять SQL застарілим?


14

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

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

Чи правильно я вважаю, що R - це набагато кращий вибір для очищення та розміщення даних? Можливо, розробник SQL в моєму кабінеті просто невмілий? Мені цікаво, якщо хтось, хто працював як з R, так і з SQL (або Python і SQL з цього питання), має якісь думки з цього приводу.


2
Якщо ваша база даних невелика і статична, ви можете завантажити її в пам'ять і використовувати вподобаний інструмент ETL, наприклад, dplyr. Ваш підхід просто не працюватиме, коли у вас є великі дані в хмарі. Я регулярно запускаю запити, на які BigQuery (Google) скаржиться. Я пишу запити безпосередньо в SQL, але я міг би використовувати Spark як середній шар для роботи в кадрах даних, якщо хотів.
Емре

1
Тож, SQL по суті є більш ефективним, ніж R, з точки зору способу зберігання даних, чи це просто те, що сервери SQL мають більшу вбудовану пам'ять і потужність обробки?
AffableAmbler

1
Ви не можете зробити конвертну заяву - це залежить від реалізації - але в хороших базах даних є оптимізатори запитів, а деякі з них (як BigQuery) підтримують багатоядерне виконання. Можливо, те, що ви хочете, - це кадр даних або абстракція ORM поверх вашої бази даних, щоб уникнути SQL. Здається, dplyr вже певною мірою робить це (пор. SQL-переклад ). Ви можете порівняти той самий запит у dplyr проти сирої SQL, щоб дізнатися. Що потрібно зробити - це взяти невеликий зразок даних для складання прототипів, а потім витягнути великі інструменти для виробництва даних
Емре

3
Ви можете просто запустити R всередині SQL Server і мати найкраще з обох світів
Gaius

Відповіді:


13

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

Більшість, якщо не всі, сучасні сервери баз даних дозволяють багатьом користувачам запитувати дані з одного і того ж джерела даних та вставляти, оновлювати та видаляти дані в одних і тих же таблицях, забезпечуючи при цьому збереження даних. Це дуже важливо для запису банківської транзакції. Ви можете собі уявити, як працює банк на R? Ось де заходять сервери баз даних. Вони забезпечують властивості ACID процедур, що працюють у базі даних. ACID означає атомність, сумісність, ізоляцію та довговічність (див. Опис ACID на wikipedia ). 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-запит, щоб здійснити обробку I, виконану в R

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


1
Це той самий процес, за яким я слідую (що дуже не подобається моєму керівникові). Я погоджуюсь, що виконання складних завдань з роздумів, таких як те, що я описав вище, здається набагато ефективнішим у такій мові, як Р. (Вдячний за твердження). Але якщо єдиною метою SQL є гігантський жорсткий диск для ваших даних, чому б просто не мати R-сервер? Схоже, що всі функції (картографування, налаштування ключів для зв’язування таблиць, групування та об'єднання даних) тепер у Р. все можна зробити дуже ефективно. Чи є таблиця SQL ефективнішою з точки зору використання пам'яті, ніж кадр R?
AffableAmbler

1
@Noah, тому що не всі користуються 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, він також є зручним для RAM


1

Словом НІ . SQL є потужним стислим та гнучким способом опису та узагальнення структурованих напівструктурованих та навіть неструктурованих даних - коли над ним розміщується відповідний рівень інтерпретатора. До речі, sqlвчені вважаються майже обов'язковим для даних.

SQL це стислий і потужний спосіб виконання основних операцій з:

  • проекції ( виберіть ..)
  • фільтрація ( де ..)
  • групування / фільтрування ( групування та наявність )
  • основні агрегації ( підрахунок , сума , сер .)
  • приєднується

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

Для обміну даними : це вже інша історія: деякі операції легко виражаються в sql, а деякі не так багато. Якщо ви все-таки включаєте UDF, існує ширша широта того, чого можна досягти. Моє поточне завдання включає в себе ряд UDFs - робити такі дії, як операції перетину клієнтів , спеціальні агрегації та спеціальні методи оцінювання .

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.