Почему люди предпочитают Pandas, а не SQL?

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

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

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

Поэтому я пытаюсь понять, почему Pandas так популярен.

На самом деле, первый вопрос заключается в том, почему люди более продуктивны с абстракциями DataFrame, чем с чистыми SQL-абстракциями.

Кратко; SQL не предназначен для процесса разработки и отладки (человеческим), DataFrames – да.

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

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

DataFrames следует рассматривать как высокоуровневый API к SQL-подпрограммам, даже если с pandas они вовсе не преобразуются в планировщик SQL.

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

Одна простая причина, почему вы можете видеть больше вопросов, связанных с манипуляцией данными в Pandas, чем в SQL, заключается в том, что использование SQL подразумевает использование базы данных, а в наши дни множество сценариев использования просто требуют небольших объемов данных для задач “сделай и забудь” (из .csv, вэб-API и т. д.). В этих случаях загрузка, хранение, манипуляция и извлечение из базы данных не представляется возможным.

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

Во-первых, основное преимущество pandas перед SQL заключается в том, что он является частью более широкой вселенной Python, что позволяет мне в один миг загрузить, очистить, манипулировать и визуализировать мои данные (я даже могу выполнять SQL через Pandas…). Другой заключается, просто, в том, что слишком многие пользователи не знают в полной мере возможностей SQL. Каждый новичок изучает “синтаксис извлечения” SQL (SELECT, FROM, WHERE и т. д.) как средство для извлечения данных из базы данных в другое место. Некоторые могут освоить более продвинутый синтаксис группировки и итерации. Но после этого существует довольно значительный разрыв в знаниях, до тех пор пока вы не станете экспертом (DBA, инженеры данных и т. д.).

кратко: частично это зависит от сценария использования, удобства или пробела в знании о возможностях SQL.

Несмотря на то, что использование этих двух вещей перекрываются, это сравнение яблок с апельсинами.

pandas — это инструмент для анализа данных, реализованный на Python, языке программирования общего назначения. SQL — это язык, специфичный для домена, предназначенный для опроса реляционных данных (обычно в системе управления реляционными базами данных, примерами которых являются SQLite, MySQL, Oracle, SQL Server, PostgreSQL и т.д.).

SQL предполагает

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

* Стоит подчеркнуть тот факт, что SQL настолько специфичен для домена, что он становится все менее актуальным для работы с все более распространенными альтернативами реляционным базам данных, такими как базы данных NoSQL. Это представляет собой фундаментальную смену в том, как данные хранятся и структурируются, и реально нет универсального общего способа доступа к ним, как это попыталась достичь стандартизация SQL.

Python, с другой стороны (pandas достаточно “питоничен”, так что это справедливо здесь), гибок и доступен для людей из различных слоев общества. Его можно использовать как “язык сценариев”, как функциональный язык и как полнофункциональный объектно-ориентированный язык. Визуализация возможности и совместимость данных встроены в pandas, но вы свободно можете интегрировать все, что Python может сделать, в свой рабочий процесс (что включает в себя большинство вещей); научная экосистема Python расширилась и включает в себя отличные инструменты, такие как Jupyter Notebook и необходимые библиотеки scipy, такие как matplotlib и numpy (на которых основан pandas). Важные элементы анализа данных в pandas вдохновлены R, и вы обычно не найдете статистиков, сомневающихся в том, использовать ли R (или, возможно, все более pandas!) вместо того, чтобы помещать все в базу данных и писать свои анализы на SQL.

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

Во-первых, pandas не так популярен. Я использую и pandas, и SQL. Сначала я пытаюсь понять задачу – если можно сделать ее в SQL, я предпочитаю SQL, потому что он более эффективен, чем pandas. Попробуйте работать с большими данными (10,000,000 x 50). Попробуйте выполнить некоторое groupby в обоих SQL и pandas. Вы поймете.

Я использую pandas, когда это удобно – например, разбиение значений колонки в массив и выполнение некоторых операций на нем (например, выбор только некоторых значений из этого массива). Теперь такой вид задачи относительно сложно кодировать в SQL, но pandas упростит вашу задачу.

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

Основное преимущество, которое я вижу в пайплайнах Pandas/dplyr/data.table, состоит в том, что операции атомарны и их можно читать сверху вниз.

В SQL вам нужно разбирать весь скрипт, перемещаясь (что суммируется, что соединяется и как – слева? изнутри? справа?, есть ли наложенные фильтры?), чтобы полностью понять, что происходит.

В Pandas и др. каждый этап пайплайна автономен, он делает что-то с входными данными и возвращает выходные данные, этот последовательный процесс упрощает рассуждения о том, что происходит, поскольку есть четко определенное состояние для каждой операции, а не только на уровне запроса.

И да, вы можете использовать WITH инструкции и подобное, но это требует гораздо больше кода и не так ясно, какой объект используется по сравнению с конвейерами.

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

Почему RDBMS лучше:
Преимущество RDBMS – это их многолетний опыт оптимизации скорости запросов и операций чтения данных. Что впечатляет, так это то, что они могут делать это, одновременно балансируя необходимость оптимизации скорости записи и управляя высокой конкурентной доступностью. Иногда эти дополнительные накладные расходы наклоняют преимущество в сторону Pandas, когда речь идет о простых, однопользовательских сценариях использования. Но даже тогда опытный DBA может настроить базу данных для высокой оптимизации скорости чтения в ущерб скорости записи. DBA могут воспользоваться вещами, такими как оптимизация хранения данных, стратегическое определение размера страниц диска, заполнение/откат страниц, стратегии патирования данных и диска, оптимизированные планы ввода-вывода, закрепление данных в памяти, предварительно определенные планы выполнения, индексация, сжатие данных и многое другое. У меня складывается впечатление, что многие разработчики Pandas не понимают глубину возможностей, доступных здесь. Что, по моему мнению, обычно происходит, это если разработчик Pandas никогда не имеет данных, достаточно больших, чтобы нуждаться в этих оптимизациях, они не оценят, сколько времени они могут сэкономить из коробки. RDBMS мир имеет 30 лет опыта оптимизации этого, так что если нужна сырая скорость на больших наборах данных, RDBMS не может быть побит.

Почему Python/Pandas лучше:
Тем не менее, скорость – это не все, и в многих случаях использования это не является основным фактором. Это зависит от того, как вы используете данные, являются ли они разделяемыми и заботитесь ли вы о скорости обработки.
RDBMS обычно более жестко регулируют свои структуры данных и возлагают большую нагрузку на разработчика, чтобы быть более детерминированным с формами данных. Pandas позволяет вам быть более свободным здесь. Также, и это моя любимая причина, вы находитесь в настоящем языке программирования. Языки программирования дают вам бесконечно больше гибкости в применении сложной логики к данным. Конечно, также есть богатая экосистема модулей и сторонних фреймворков, которая не может сравниться с 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.csv'). Это важно, если вы хотите показать что-то владельцу бизнеса, который хочет работать с 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. По какой-то причине в None из функций arcpy.da нет функции execute many. Это очень странно, потому что почти каждая другая библиотека Python SQL делает. Инструкция Where в функциях arcpy.da также ограничивается примерно 120 символами. Это, по сути, означает, что если у вас есть относительно большое количество вещей, которые вы пытаетесь сделать с вашей базой данных, ваш единственный реальный выбор – вызывать выбранную вами функцию arcpy.da несколько раз, изменяя оператор where каждый раз, когда вы это делаете. Существуют несколько хитростей, которые вы можете использовать, чтобы сделать этот процесс быстрее — можно выполнять итерацию по частям вашего набора данных, например, — но буквально каждый из этих трюков гораздо медленнее, чем просто использование одного arcpy.da.searchcursor для загрузки всей вашей таблицы в pandas data frame, а затем ее манипулирования с использованием pandas, numpy и, если ваши данные действительно такие большие, dask. Я хочу подчеркнуть здесь, что pandas в данном случае не просто немного быстрее. Он невероятно быстрее. Он настолько быстрее, что я засмеялся над собой, что не сделал это раньше. Использование pandas сократило время выполнения одного скрипта со значительно превышающего часа — я забыл, если это был прыжок с 3,5 часа или с 1,5 часа, — до буквально 12 минут.

Одна вещь, которую стоит отметить, это то, что хоть я бы мог сделать это с помощью SQL, мне потребовалось бы намного больше времени, чтобы выучить. Мне бы пришлось либо выучить операции специально для SQL в Access — вот где данные для этого скрипта оказались — SQL в Access не был таким надежным, каким я нуждался, когда я на самом деле смотрел на это, — или мне бы пришлось записать все мои данные в базу данных sqlite3, манипулировать ими там, а затем поместить их в Access. Хотя это могло бы дать мне аналогичные результаты производительности, это сделало бы мой скрипт сложнее для модификации в будущем.

Так что да, иногда Pandas просто строго лучше, чем те SQL-опции, которые у вас есть в распоряжении. Все, что мне бы потребовалось сделать в SQL, было выполнено с помощью функции в pandas. Вы также можете использовать SQL синтаксис с pandas, если хотите. Нет особых причин не использовать pandas и SQL вместе.

Еще одна вещь, которую я должен упомянуть о Pandas и numpy, заключается в том, что обе эти библиотеки по своей природе подходят для набора данных. Вы можете пройтись по фреймам данных и сериям, строящимся этими библиотеками, но изменение данных в этих структурах таким образом действительно сложно, поэтому вы будете писать более эффективный код — на основе наборов — с обеими этими библиотеками просто потому, что это намного легче делать. “Ведение” или даже “вынужденное использование” подходов на основе наборов нечто, что я не испытывал с SQL.

Еще одна большая вещь, о которой я забыл упомянуть с Pandas. Деньги. Pandas — это инструмент, который многие рабочие места в области науки о данных хотят, чтобы вы знали, как использовать. Почти каждая работа в области науки о данных, которую я рассматривал, оплачивалась больше, чем работа в управлении базами данных. Единственное исключение из этого, которое я заметил, это в Data Engineering, но я видел гораздо меньше таких вакансий. Pandas выглядит, как будто он делает вас больше деньги с первого взгляда.

Я постараюсь ответить на этот вопрос, основываясь на собственном опыте. В отличие от других ответов, я предпочитаю Sql для глубокого изучения и вещей, связанных с большими данными. На это есть много причин. Как видно здесь,

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

SQL-движки обычно сохраняют ключи или специальные столбцы в структурах данных, таких как $B ^+$ дерево, для облегчения операций СУБД. Эта структура данных хранит состояние всех данных в базе данных. Это не может сделать pandas, потому что он не может получить доступ ко всем данным одновременно. С другой стороны, он не может выполнять некоторые операции даже с его параметром chunk, используемым в read_csv. Например, вы не можете выполнять прямые пакетные операции для больших наборов данных, которые ваша память не может вместить. Любые другие задачи, зависящие от всего вашего набора данных, требуют дополнительного кодирования. Все это может быть выполнено в SQL без дополнительного кодирования, просто с помощью простого запроса. Простые SQL операции просто используются без всякой заботы о памяти.

Еще одно отличие в том, что операции CRUD в SQL можно применять распределенно с различными политиками авторизации, чего нет в pandas.

Это не значит, что одно лучше другого, все зависит от вашей задачи. Для вычислений в большом масштабе я предпочитаю SQL, а для маленьких — pandas.

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

Я думаю, что самый короткий ответ может быть представлен этим слайдом из доклада Джейка Вандерпласа на PyCon 2017 (и это отличный доклад, который может стать более длинным ответом):

Таким образом, большинство людей предпочитает не саму Pandas, они предпочитают быстро растущий стек данных Python и экосистему Python, включающую его. Ученые могут придерживаться высокоуровневых доменных пакетов, инженеры данных — пакетов машинного обучения, а когда одна из двух групп имеет что-то, над чем можно действовать на своих интерактивных сессиях JupyterLab, программисты могут использовать другие пакеты, чтобы добавить HTTP API и описать развертывание для перемещения его в производство. И все это с одним и тем же языком и экосистемой! SQL (даже со всем, что желают продать вам коммерческие поставщики СУБД) нигде вблизи этой возможности.

Pandas поддерживает некоторые из этих случаев использования, и в свою очередь полагается на более низкие уровни стека (например, NumPy). Может ли Python DBAPI и SQL заменить это, что сохранило бы остальное неизменным? Эквивалент, в таком виде, хорошо охвачен в сравнение Pandas с SQL.

SELECT total_bill, tip, smoker, time FROM tips LIMIT 5

                    -- vs --

df[["total_bill", "tip", "smoker", "time"]].head(5)

или

SELECT day, AVG(tip), COUNT(*) FROM tips GROUP BY day

                    -- vs --

df.groupby("day").agg({"tip": np.mean, "day": np.size})

То же намерение выражено по-разному (декларативный DSL против API в высокоуровневом общем языке императивного программирования, который имитирует DSL). С точки зрения знакомства с различными ролями (SQL существует почти 50 лет и не теряет своей актуальности, и известен за пределами программирования) и выразительности, я бы сказал, что SQL побеждает.

Но если смотреть с более широкой перспективы обслуживания и эксплуатации приложений, у SQL есть ряд проблем, которые он приносит вместе с собой:

• новая поверхность атаки
• различия в диалекте SQL RDBMS
• еще одна система программного обеспечения, которую нужно управлять в случае клиент-серверных RDBMS
• реальный мир (аналитический) SQL поддерживается как строки (например, композиция, возможность повторного использования, понятность)
• ORM как решение для вышеуказанного, но приносит своей пакет проблем

По моему мнению, не втягивание этих проблем в основную составляющую стека — это умное прагматическое решение. Вместо этого у вас есть быстрая таблица в памяти с идиоматическим (т. е. в основном антиинтуитивным) высокоуровневым императивным API, который охватывает большинство случаев использования. И что интересно, существует Blaze, который работает поверх SQL (через SQLAlchemy) и предоставляет интерфейс, похожий на Pandas, что, вероятно, означает, что последний становится стандартным API для манипуляции табличными данными для анализа данных.

Это не значит, что нет нишевых случаев использования в анализе данных, которые можно решить только с помощью SQL. Один пример, который я могу привести, это исследовательская визуализация данных в таких инструментах, как sqliteviz (SQLite в браузере с полным набором научной визуализации от Ploty) и sqlitebrowser (обычный SQLite с простыми возможностями визуализации). Это лёгкая настройка вывода (например, фильтрация, конвертация типа, добавление вычисляемых столбцов и т.д.) для визуализации в SQL (не собираясь упоминать, насколько легче делать визуализации средней сложности в GUI, по сравнению с гораздо более идиоматическим API Matplotlib).

Обновление

1. Существует очень интересный проект от нидерландского CWI, под названием DuckDB. Это открытый исходный аналитический (колоночный, векторизированный, MVCC) встроенный база данных, которая пытается решить несовпадение SQL с самым типичным рабочим потоком в области науки данных. В основном истребить необходимость создавать (аналогические) базы данных программистами науки данных, устраняя все трения для повторного использования полезных частей, которые собрало поле баз данных за более чем 50 лет. Например, вы можете его полностью установить с pip install duckdb (и у него есть колеса, так что вы, вероятно, не нуждаетесь в компиляторе), вы можете сохранять/загружать данные Pandas непосредственно в базу данных, выполнять SQL с ним на фреймах данных Pandas (т. е. ноль-копии, по крайней мере, для числовых типов), у него есть собственные механизмы композиции запросов и многое другое. Первые 15 минут этого доклада, DuckDB – The SQLite for Analytics, один из авторов, Марк Расвелд, объясняет как DuckDB адресует проблему.
2. Практический SQL для анализа данных — Что вы можете сделать без Pandas предоставляет множество продвинутых примеров PostgreSQL о том, как выполнять анализ данных в SQL, начиная от очистки, выборки и разбиения наборов данных и заканчивая категоризацией, пивотированием и вычислением линейной регрессии.

Я подумал, что добавлю, что я делаю много анализа данных на основе временных рядов, и методы pandas resample и reindex незаменимы для этого. Да, вы можете делать подобные вещи в SQL (я обычно создаю таблицу DateDimension для помощи с запросами, связанными с датами), но я просто считаю методы pandas намного более удобными.

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

Panda более популярен, так как Python в виде Jupyter блокнотов – это самый популярный набор инструментов, используемый данными учеными в области нейронных сетей. Python становится “языком”. Также возможно использовать SQL бэкэнд, но с Pandas вы не привязаны только к SQL.

Эта ветка довольно старая, но несколько моментов

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

Я думаю, что популярность Pandas обусловлена тем, что он построен на Python, доступен через блокноты и имеет легкий API, который можно быстро освоить.

Во многих организациях сервер SQL имеет слишком много корпоративных смотрителей и слишком много обручей (входы, разрешения, uat/prod окр., и т.д.), через которые гражданин- разработчик не хочет прыгать.