Чому люди віддають перевагу Pandas перед SQL?

Я використовую SQL з 1996 року, тому я можу бути упередженим. Я широко використовував MySQL та SQLite 3, але також використовував Microsoft SQL Server та Oracle.

Переважна більшість операцій, які я бачив з Pandas, можна простіше виконати за допомогою SQL. Це включає фільтрацію набору даних, вибір конкретних стовпців для відображення, застосування функції до значень тощо.

Перевага SQL має оптимізатор та збереження даних. У SQL також є повідомлення про помилки, які є зрозумілими і зрозумілими. У Pandas є дещо криптований API, в якому іноді доречно використовувати один [ stuff ], інший раз, коли потрібно [[ stuff ]], а іноді потрібно .loc. Частина складності Панд виникає через те, що відбувається стільки перевантажень.

Тому я намагаюся зрозуміти, чому Pandas так популярний.

Справжнє перше питання - чому люди більш продуктивні з абстракціями DataFrame, ніж чисті абстракції SQL.

TLDR; SQL не орієнтований на процес розробки та налагодження (людини), DataFrames.

Основна причина полягає в тому, що абстракції DataFrame дозволяють створювати оператори SQL, уникаючи багатослівного і нерозбірливого вкладення. Шаблон написання вкладених процедур, коментування їх для перевірки, а потім їх коментування замінюється одинарними рядками перетворення. Ви, природно, можете вести речі за рядком у відбитті (навіть у Spark) та переглядати результати.

Розглянемо приклад додавання нового перетвореного (стовпчастого стовпчика) до таблиці, а потім групування за ним та проведення деяких агрегацій. SQL стає дуже некрасивим. Панди можуть вирішити це, але не вистачає деяких речей, коли мова йде про справді великі дані або окремі розділи (можливо, останнім часом покращені).

DataFrames слід розглядати як API високого рівня для підпрограм SQL, навіть якщо з пандами вони зовсім не надаються якомусь планувальнику SQL.

-

Можливо, ви можете мати багато технічних дискусій навколо цього, але я розглядаю перспективу користувача нижче.

Однією з простих причин, чому ви можете бачити набагато більше питань щодо маніпулювання даними Pandas на відміну від SQL, полягає в тому, що використовувати SQL, за визначенням, означає використовувати базу даних, і багато випадків використання в ці дні просто вимагають бітів даних для ' однофамільні завдання (від .csv, веб-api тощо). У цих випадках завантаження, зберігання, маніпулювання та вилучення з бази даних не є життєздатним.

Однак, розглядаючи випадки, коли випадок використання може виправдати використання Pandas або SQL, ви, звичайно, не помиляєтесь. Якщо ви хочете виконати багато, багаторазові завдання маніпулювання даними та зберегти результати, я завжди рекомендую спробувати перейти через SQL. З того, що я бачив, чому багато користувачів, навіть у цих випадках, не переходять через SQL, є дворазовим.

По-перше, головна перевага панд у порівнянні з SQL полягає в тому, що це частина ширшого всесвіту Python, а це означає, що я можу одним завантаженням, очищенням, маніпулюванням та візуалізацією даних (я можу навіть виконувати SQL через Pandas ...). Інший - просто, що надто багато користувачів не знають ступеня можливостей SQL. Кожен початківець вивчає синтаксис вилучення SQL (SELECT, FROM, WHERE тощо) як спосіб перенести ваші дані з БД на наступне місце. Деякі можуть підібрати деякі з більш синтаксичного синтаксису групування та ітерації. Але після цього, як правило, існує досить значна прірва знань, поки ви не потрапите до експертів (DBA, Data Engineers тощо).

tl; dr: Часто це залежить від використання, зручності чи розриву в знаннях щодо обсягу можливостей SQL.

Стільки, скільки перекриття в застосуванні цих двох речей, це порівняння яблук з апельсинами.

pandas - це інструментарій аналізу даних, реалізований на Python, загальній мові програмування. SQL - це доменна мова для запиту реляційних даних (як правило, в системі управління реляційною базою даних, приклади якої є SQLite, MySQL, Oracle, SQL Server, PostgreSQL тощо).

SQL має на увазі

• робота з даними в RDBMS *, які можуть бути або не підходять для навантаження, навіть якщо це лише невелика база даних SQLite,
• знання домену бази даних (як кінцевий користувач, розробник та / або адміністратор; припущення про те, що "SQL швидше", я часто бачу, є масовим надмірним спрощенням), і
• подолання несуттєвої кривої навчання в ефективному використанні SQL, особливо в спеціальних додатках, таких як аналіз даних (на відміну від створення простих звітів простих даних).

* Варто підкреслити той факт, що SQL настільки специфічний для домену, що він стає набагато менш актуальним для роботи зі все більш поширеними альтернативами реляційних баз даних, таких як бази даних NoSQL . Це є принциповим зрушенням у тому, як зберігаються та структуруються дані, і насправді немає загальноприйнятого способу доступу до нього, як розробка стандартизації SQL, спрямованої на досягнення.

З іншого боку, Python (панди досить «пітонічні», тому це справедливо) тут є гнучким та доступним для людей з різних груп. Його можна використовувати як "мову сценаріїв", як функціональну мову та повнофункціональну мову OOP. Можливості візуалізації та інтероперабельність джерела даних вбудовані в панди, але ви можете включити все, що може зробити Python, у свій робочий процес (що більшість речей); наукова екосистема Python розширилася і включає в себе чудові інструменти, такі як Jupyter Notebook та основні бібліотеки scipy, такі як matplotlib і numpy (на яких базуються панди). Важливими елементами аналізу даних панд є R-натхненно, і ви, як правило, не знайдете статистиків, які придумують та хизуються щодо того, чи використовують вони R (або, можливо, все частіше панди!) над тим, щоб все вмістити в базі даних і написати свої аналітики в SQL.

Я не кажу, що панди краще, ніж SQL, або навпаки, але SQL - це дуже специфічний для домену інструмент, тоді як панди є частиною гігантської, гнучкої та доступної екосистеми. Я працюю з геопросторовими системами даних, серед яких величезна частина є реляційними базами даних, а SQL є потужним і важливим інструментом. Однак панди є не менш важливою частиною мого повсякденного набору інструментів, і SQL часто відводиться для отримання даних - можливо, з попередньою обробкою - тому я можу робити з ним речі в пандах.

По-перше, панди не настільки популярні. Я використовую і панди, і SQL. Спочатку я намагаюся зрозуміти завдання - якщо це можна зробити в SQL, я віддаю перевагу SQL, оскільки він більш ефективний, ніж панди. Спробуйте працювати над великими даними (1000000 x 50). Спробуйте зробити деяку групову операцію як у SQL, так і в пандах. Ви зрозумієте.

Я використовую панди, коли це зручно, як розділити значення стовпця на масив і виконувати на ньому деякі речі (наприклад, вибираючи з цього масиву лише деякі значення). Зараз цей вид задач порівняно важко кодувати в SQL, але панди полегшать ваше завдання.

Я з тих людей, хто використовував (у моєму випадку) d-drr R (мова, не обов'язково інструмент) у кожному випадку, якби міг, хоч і знаю свій SQL.

Основна вигода, яку я бачу в трубопроводах Pandas / dplyr / data.table, полягає в тому, що операції є атомними і їх можна читати зверху вниз.

У SQL вам потрібно проаналізувати весь сценарій, стрибаючи навколо (що зводиться, що з’єднується і як - зліва? Внутрішній? Праворуч? Чи застосовуються фільтри?), Щоб повністю зрозуміти, що відбувається.

У Pandas et al кожен крок трубопроводу є автономним, він робить щось із вхідними даними та повертає вихідні дані, цей послідовний процес полегшує міркування про те, що відбувається, оскільки існує чітко визначений стан для кожної операції, а не тільки для рівень запиту.

Так, ви можете робити WITHзаяви та ін., Але для цього потрібно набагато більше коду та не так зрозуміло, який об’єкт використовується порівняно з трубопроводом.

Я досить новачок у Pandas / Python, але в мене більше 20 років як DQL SQLServer, архітектор, адміністратор тощо. Я люблю Pandas, і я наполягаю на тому, щоб завжди намагатися зробити так, щоб все працювало в Pandas, перш ніж повертатися до зручності, затишний світ SQL.

Чому RDBMS краще: Перевагою RDBMS є їх багаторічний досвід оптимізації швидкості запитів та операцій з читання даних. Вражає те, що вони можуть це робити, одночасно врівноважуючи необхідність оптимізувати швидкість запису та керувати сильно одночасним доступом. Іноді ці додаткові накладні витрати надають перевагу Pandas, коли мова йде про прості випадки використання для одного користувача. Але навіть тоді досвідчений DBA може налаштувати базу даних, щоб бути оптимізованою для швидкості читання над швидкістю запису. DBA можуть скористатися такими речами, як оптимізація зберігання даних, стратегічний розмір сторінок диска, заповнення / доповнення сторінок, контролер даних та стратегії розподілу диска, оптимізовані плани вводу / виводу, закріплення даних в пам'яті, попередньо визначені плани виконання, індексація, стиснення даних , та багато іншого. У мене склалося враження від багатьох розробників Pandas, які вони не роблять ' t розуміти глибину, яка там доступна. Я думаю, що зазвичай трапляється так, що якщо розробник Pandas ніколи не має даних, які є достатньо великими для необхідності цих оптимізацій, вони не оцінюють, скільки часу вони можуть врятувати вас поза коробкою. Світ RDBMS має 30-річний досвід оптимізації цього, тому, якщо потрібна швидка швидкість на великих наборах даних, RDBMS можна обіграти.

Чому Python / Pandas краще: Однак, швидкість - це не все, і в багатьох випадках використання не є рушійним фактором. Це залежить від того, як ви використовуєте дані, чи є ними спільні дані, і чи дбаєте ви про швидкість обробки. RDBMS, як правило, більш жорсткі в своїх структурах даних і тягають на розробника більш детерміновані форми даних. Панди дозволяють вам бути тут більш вільним. Крім того, і це моя найулюбленіша причина - ви справжньою мовою програмування. Мови програмування дають вам нескінченно більшу гнучкість у застосуванні розробленої логіки до даних. Звичайно, є також багата екосистема модулів та сторонні рамки, до яких SQL не може наблизитися. ДУЖЕ зручно мати можливість переходити від необроблених даних аж до веб-презентації чи візуалізації даних в одній базі коду. Це також набагато портативніше. Ви можете запускати Python майже в будь-якому місці, включаючи загальнодоступні ноутбуки, що дозволяють швидше дістатись до людей. Бази даних в цьому не переважають.

Моя порада? Якщо ви виявите, що закінчуєте все більші та більші набори даних, ви зобов'язані зайнятись і дізнатися, як RDBMS може допомогти. Я бачив мільйони приєднань до кількох таблиць, підсумовував сукупні запити, налаштовані від 5 хвилин до 2 секунд. Маючи це розуміння у своєму інструментальному поясі, це просто робить вас більш чітким вченим. Ви можете зробити все в Pandas сьогодні, але одного дня у вас можуть бути завдання, де RDBMS - найкращий вибір.

Те, що Pandas може зробити, те, що SQL не може зробити

1. df.describe()
2. Плоттування, наприклад df['population'].plot(kind='hist')
3. Використовуйте фрейм даних безпосередньо для алгоритмів навчання машинного навчання

Те, що Pandas може зробити, я не знав, що SQL може також зробити

1. Експорт в CSV: df.to_csv('foobar.sv'). Це важливо, коли ви хочете щось показати власнику бізнесу, який хоче працювати з Excel. І є df.to_excelтакож. Але в SQL ви можете це зробити SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM test_table;(спасибі, vy32!)

Єдине, що не було висвітлено в цих відповідях, які я хотів би зазначити, це те, що це також залежить від того, як ви використовуєте SQL. Візьмемо для прикладу архпі. Чомусь жодна з функцій arcpy.da не має багато функцій виконання. Це дійсно дивно, тому що майже всі інші бібліотеки python sql роблять. Оператор Where у функціях arcpy.da також обмежений приблизно 120 символами. Це по суті означає, що якщо у вас є відносно велика кількість речей, які ви намагаєтеся зробити зі своєю базою даних, ваш єдиний реальний вибір - викликати вибрану функцію arcpy.da кілька разів, змінюючи оператор де щоразу, коли ви робите. Ви можете скористатися кількома хитрощами, щоб прискорити цей процес - ви можете, наприклад, повторити шматки вашого набору даних, - але буквально кожен цей трюк набагато повільніше, ніж просто один arcpy.da. searchcursor, щоб завантажити всю вашу таблицю у кадр даних панди, а потім маніпулювати нею за допомогою панд, numpy, і, якщо ваші дані справді такі масивні, dask. Мені тут потрібно наголосити, що панди в цьому випадку не просто трохи швидші. Це огидно швидше. Це настільки швидше, що я буквально сміявся над собою за те, що раніше цього не робив. Використання панд знизило час виконання одного сценарію з більш ніж години - я забуваю, якщо це був стрибок з 3,5 годин або з 1,5 години - до буквально 12 хвилин. s настільки швидше, що я буквально сміявся над собою за те, що не роблю цього раніше. Використання панд знизило час виконання одного сценарію з більш ніж години - я забуваю, якщо це був стрибок з 3,5 годин або з 1,5 години - до буквально 12 хвилин. s настільки швидше, що я буквально сміявся над собою за те, що не роблю цього раніше. Використання панд знизило час виконання одного сценарію з більш ніж години - я забуваю, якщо це був стрибок з 3,5 годин або з 1,5 години - до буквально 12 хвилин.

Варто зазначити, що, хоча я міг би зробити це з sql, це знадобило б мені набагато більше часу, щоб навчитися. Я б або повинен був вивчити операції спеціально для sql в Access - ось, де закінчилися дані для цього сценарію - - sql в Access був не настільки надійним, як мені потрібно було, коли я насправді займався цим - або Мені довелося б записати всі свої дані в базу даних sqlite3, маніпулювати ними там, а потім поставити їх у Access. Хоча це могло б дати мені подібні результати продуктивності, це зробило б мій сценарій важче модифікувати в майбутньому.

Так що так, іноді Pandas і просто суворо краще, ніж використання опцій sql, які у вас є у вашому розпорядженні . Все, що мені потрібно було б зробити в sql, робилося з функцією в пандах. Ви також можете використовувати синтаксис sql з пандами, якщо хочете. Існує мало причин не використовувати панде і sql в тандемі.

Ще одне, що я хочу зазначити про Pandas і numpy, це те, що обидві ці бібліотеки за своєю природою встановлені на основі підходів. За допомогою цих бібліотек ви можете переглядати кадри даних та збирати серії, але змінити дані в такі структури насправді важко, так що ви в кінцевому підсумку записуєте більш ефективний код, встановлений на основі - з обома цими бібліотеками, тому що це набагато простіше робити. Бути "керованим", якщо не залізничним шляхом, використовуючи задані підходи, - це не те, що я відчував із SQL.

Ще одна масивна річ, яку я забув згадати з Пандами. Гроші . Pandas - це інструмент, який багато завдань Data Science хочуть, щоб ви вміли користуватися. Практично кожна робота, яку я подивилася, заплатила більше, ніж завдання типу управління базами даних. Єдиний виняток із цього, що я помітив, - це Data Engineering, але я бачив набагато менше цих оголошень. Панди виглядають так, що вони з першого погляду заробляють більше грошей.

Я подумав, що хочу додати, що я роблю багато аналізу даних на основі часових рядів, і панди resampleта reindexметоди є безцінними для цього. Так, ви можете робити подібні речі в SQL (я прагну створити DateDimensionтаблицю для допомоги у запитах, пов’язаних з датою), але я просто знаходжу методи панд набагато простішими у використанні.

Крім того, як говорили інші, решта мого моделювання знаходиться в Python, і я часто маю веб-дзвінки або файли CSV.

Я спробую відповісти на це питання на основі власного досвіду. На відміну від інших відповідей, я віддаю перевагу Sqlглибокому навчанню та речей, пов’язаних із великими даними. Для цього є численні причини. Як видно тут ,

Pandas забезпечує інтуїтивний, потужний та швидкий досвід аналізу даних на табличних даних. Однак, оскільки Pandas використовує лише один потік виконання і вимагає, щоб усі дані були одночасно в пам'яті, він не забезпечує масштабування наборів даних, що значно перевищує масштаб гігабайт.

$B ^+$

Інша відмінність полягає в тому, що операції CRUD у Sql можна застосовувати розподіленими за допомогою різних політик авторизації, які неможливі в пандах.

Це не означає сказати, що краще, все залежить від вашого завдання. Для широкомасштабних обчислень я віддаю перевагу Sql, а для малих я віддаю перевагу пандам.

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

Панда користується більшою популярністю, оскільки пітон у формі зошитів з юпітером - найпопулярніший набір інструментів, який використовується вченим із даних в області нейронної мережі. Python стає "мовою". Можна навіть використовувати сервер SQL, але ви не пов'язані з SQL лише за допомогою панди.

Не зовсім відповідь на питання, але оскільки я сам прийшов сюди шукати відмінності в практичному застосуванні:

https://pandas.pydata.org/pandas-docs/stable/getting_started/comppare/comppare_with_sql.html