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

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

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

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

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

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

TLDR; DataFrames не ориентированы на (человеческий) процесс разработки и отладки SQL.

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

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

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

-

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

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

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

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

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

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

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

SQL подразумевает

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

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

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

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

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

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

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

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

В SQL вам нужно проанализировать весь сценарий, прыгая (что суммируется, что объединяется и как - слева? Внутреннее? Право ?, применяются ли какие-либо фильтры?), Чтобы полностью понять, что происходит.

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

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

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

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

Почему Python / Pandas лучше: Тем не менее, скорость это не все, и во многих случаях не является движущим фактором. Это зависит от того, как вы используете данные, разделяют ли они, и заботитесь ли вы о скорости обработки. СУБД, как правило, более жесткие в своих структурах данных и возлагают на разработчика бремя быть более детерминированным с формами данных. Панды позволяют вам быть более свободным здесь. Кроме того, и это моя любимая причина, вы на настоящем языке программирования. Языки программирования дают вам бесконечно большую гибкость в применении передовой логики к данным. Конечно, существует также богатая экосистема модулей и сторонних сред, к которым SQL не может приблизиться. Возможность перехода от необработанных данных к веб-презентации или визуализации данных в одной кодовой базе ОЧЕНЬ удобна. Это также намного более портативно. Вы можете запускать Python практически где угодно, включая общедоступные записные книжки, которые могут расширить область ваших результатов, чтобы быстрее добраться до людей. Базы данных не преуспевают в этом.

Мой совет? Если вы обнаруживаете, что переходите на все большие и большие наборы данных, вы обязаны сделать решающий шаг и узнать, как СУРБД могут помочь. Я видел миллион строк, объединение в несколько таблиц, суммарные запросы, настроенные с 5 минут до 2 секунд. Имея это понимание в своем поясе инструментов, вы становитесь специалистом по обработке данных. Вы можете быть в состоянии сделать все в Pandas сегодня, но однажды у вас может быть задание, где RDBMS является лучшим выбором.

Что может сделать Pandas, чего не может сделать SQL

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

Вещи, которые может сделать Панда, я не знал, что 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, например. По какой-то причине ни одна из функций arcpy.da не имеет функции execute много. Это действительно странно, потому что почти все остальные библиотеки Python sql делают. Оператор Where в функциях arcpy.da также ограничен примерно 120 символами. По сути, это означает, что, если у вас есть относительно большое количество вещей, которые вы пытаетесь сделать с вашей базой данных, ваш единственный реальный выбор - вызывать выбранную вами функцию arcpy.da несколько раз, меняя оператор where каждый раз, когда вы делаете это. Есть несколько приемов, которые вы можете использовать, чтобы ускорить этот процесс - например, вы можете перебирать фрагменты вашего набора данных - но буквально каждый из этих приемов намного медленнее, чем просто использование одного arcpy.da. searchcursor для загрузки всей вашей таблицы во фрейм данных pandas, а затем манипулирования ею с использованием pandas, numpy, и, если ваши данные действительно такие большие, dask. Здесь я должен подчеркнуть, что в этом случае панды не просто немного быстрее. Это отвратительно быстрее. Это так быстро, что я буквально смеялся над собой за то, что не сделал этого раньше. Использование панд сократило время выполнения одного скрипта с более чем часа - я забыл, если это был скачок с 3,5 часов или с 1,5 часов - до буквально 12 минут. Это было так быстро, что я буквально смеялся над собой, потому что не сделал этого раньше. Использование панд сократило время выполнения одного скрипта с более чем часа - я забыл, если это был скачок с 3,5 часов или с 1,5 часов - до буквально 12 минут. Это было так быстро, что я буквально смеялся над собой, потому что не сделал этого раньше. Использование панд сократило время выполнения одного скрипта с более чем часа - я забыл, если это был скачок с 3,5 часов или с 1,5 часов - до буквально 12 минут.

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

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

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

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

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

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

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

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

$B ^+$

Другое отличие состоит в том, что операции CRUD в Sql могут применяться с распределенными политиками авторизации, которые в пандах невозможны.

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

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

Panda более популярен, так как python в виде ноутбуков jupyter является наиболее популярным набором инструментов, который используется исследователем в области нейронных сетей. Python становится "языком". Можно даже использовать бэкэнд SQL, но вы не привязаны к SQL только с помощью panda.

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

https://pandas.pydata.org/pandas-docs/stable/getting_started/comparison/comparison_with_sql.html