¿Por qué la gente prefiere Pandas a SQL?

He estado usando SQL desde 1996, por lo que puedo estar sesgado. He usado MySQL y SQLite 3 ampliamente, pero también he usado Microsoft SQL Server y Oracle.

La gran mayoría de las operaciones que he visto con Pandas se pueden hacer más fácilmente con SQL. Esto incluye filtrar un conjunto de datos, seleccionar columnas específicas para mostrar, aplicar una función a un valor, etc.

SQL tiene la ventaja de tener un optimizador y persistencia de datos. SQL también tiene mensajes de error que son claros y comprensibles. Pandas tiene una API algo críptica, en la que a veces es apropiado usar una sola [ stuff ], otras veces que necesita [[ stuff ]], y a veces necesita una .loc. Parte de la complejidad de Pandas surge del hecho de que hay tanta sobrecarga.

Así que estoy tratando de entender por qué Pandas es tan popular.

La primera pregunta real es por qué las personas son más productivas con las abstracciones de DataFrame que las abstracciones de SQL puro.

TLDR; SQL no está orientado al desarrollo (humano) y al proceso de depuración, los DataFrames sí.

La razón principal es que las abstracciones de DataFrame le permiten construir sentencias SQL mientras evita el anidamiento detallado e ilegible. El patrón de escribir rutinas anidadas, comentarlas para verificarlas y luego descomentarlas se reemplaza por líneas simples de transformación. Naturalmente, puede ejecutar cosas línea por línea en una respuesta (incluso en Spark) y ver los resultados.

Considere el ejemplo, de agregar una nueva transformada (columna de cadena destrozada) a una tabla, luego agruparla y hacer algunas agregaciones. El SQL se pone bastante feo. Los pandas pueden resolver esto, pero le faltan algunas cosas cuando se trata de datos realmente grandes o en particiones particulares (quizás mejorado recientemente).

Los marcos de datos deben verse como una API de alto nivel para las rutinas de SQL, incluso si con los pandas no se representan en absoluto para algún planificador de SQL.

-

Probablemente pueda tener muchas discusiones técnicas sobre esto, pero estoy considerando la perspectiva del usuario a continuación.

Una razón simple por la que puede ver muchas más preguntas sobre la manipulación de datos de Pandas en lugar de SQL es que usar SQL, por definición, significa usar una base de datos, y muchos casos de uso en estos días simplemente requieren bits de datos para ' tareas 'one-and-done' (desde .csv, web api, etc.). En estos casos, cargar, almacenar, manipular y extraer de una base de datos no es viable.

Sin embargo, teniendo en cuenta los casos en los que el caso de uso puede justificar el uso de Pandas o SQL, ciertamente no está equivocado. Si desea realizar muchas tareas repetitivas de manipulación de datos y persistir en los resultados, siempre le recomendaría que primero intente usar SQL. Por lo que he visto, la razón por la cual muchos usuarios, incluso en estos casos, no utilizan SQL, es doble.

En primer lugar, la principal ventaja que tienen los pandas sobre SQL es que es parte del universo más amplio de Python, lo que significa que de una sola vez puedo cargar, limpiar, manipular y visualizar mis datos (incluso puedo ejecutar SQL a través de Pandas ...). El otro es, simplemente, que demasiados usuarios no conocen el alcance de las capacidades de SQL. Cada principiante aprende la 'sintaxis de extracción' de SQL (SELECCIONAR, DESDE, DONDE, etc.) como un medio para llevar sus datos de una base de datos al siguiente lugar. Algunos pueden recoger algunas de las sintaxis de iteración y agrupación más avanzadas. Pero después de eso, tiende a haber un abismo de conocimiento bastante significativo, hasta llegar a los expertos (DBA, ingenieros de datos, etc.).

tl; dr: a menudo depende del caso de uso, la conveniencia o una brecha en el conocimiento sobre el alcance de las capacidades de SQL.

Por mucho que haya superposición en la aplicación de estas dos cosas, esto es comparar manzanas con naranjas.

pandas es un kit de herramientas de análisis de datos implementado en Python, un lenguaje de programación de propósito general. SQL es un lenguaje específico de dominio para consultar datos relacionales (generalmente en un sistema de gestión de bases de datos relacionales que SQLite, MySQL, Oracle, SQL Server, PostgreSQL, etc. son ejemplos).

SQL implica

• trabajar con datos en un RDBMS * que puede o no ser apropiado para la carga de trabajo, incluso si es solo una pequeña base de datos SQLite,
• conocimiento del dominio de la base de datos (como usuario final, desarrollador y / o administrador; la sugerencia de que "SQL es más rápido" a menudo veo es una simplificación excesiva masiva), y
• superar la curva de aprendizaje no insignificante en el uso eficaz de SQL, particularmente en aplicaciones especializadas como el análisis de datos (en lugar de crear informes simples de datos simples).

* Vale la pena subrayar el hecho de que SQL es tan específico del dominio que se vuelve mucho menos relevante para trabajar con alternativas cada vez más comunes a las bases de datos relacionales, como las bases de datos NoSQL . Esto representa un cambio fundamental en la forma en que se almacenan y estructuran los datos, y en realidad no hay una forma universal de acceder a ellos, como el desarrollo de la estandarización SQL que se pretende lograr.

Python, por otro lado (los pandas son bastante "pitónicos", por lo que es cierto aquí) es flexible y accesible para personas de diversos orígenes. Se puede utilizar como un "lenguaje de secuencias de comandos", como un lenguaje funcional y un lenguaje OOP con todas las funciones. Las capacidades de visualización y la interoperabilidad de la fuente de datos están integradas en los pandas, pero puede incorporar lo que Python pueda hacer en su flujo de trabajo (que es la mayoría de las cosas); El ecosistema científico de Python se ha disparado e incluye excelentes herramientas como Jupyter Notebook y bibliotecas esenciales de scipy como matplotlib y numpy (que se construyen sobre los pandas). Elementos significativos del análisis de datos de pandas es R-inspirados y generalmente no encontrarás estadísticos que digan y digan si usan R (¡o posiblemente cada vez más pandas!) sobre poner todo en una base de datos y escribir sus análisis en SQL.

No digo que los pandas sean mejores que SQL o viceversa, pero SQL es una herramienta muy específica del dominio, mientras que los pandas son parte de un ecosistema gigante, flexible y accesible. Trabajo con sistemas de datos geoespaciales, de los cuales las bases de datos relacionales son una gran parte, y SQL es una herramienta poderosa y esencial. Sin embargo, los pandas son una parte igualmente esencial, si no más, de mi conjunto de herramientas del día a día, y SQL a menudo se relega a la obtención de datos, tal vez con algo de procesamiento previo, por lo que puedo hacer cosas con ellos en los pandas.

Primero, los pandas no son tan populares. Yo uso pandas y SQL. Primero trato de entender la tarea: si se puede hacer en SQL, prefiero SQL porque es más eficiente que los pandas. Intente trabajar en datos grandes (10,000,000 x 50). Intente hacer alguna operación groupby en SQL y pandas. Tu entenderás.

Utilizo pandas donde resulta útil, como dividir los valores de una columna en una matriz y hacer algunas cosas (como elegir solo algunos valores de esa matriz). Ahora, este tipo de tarea es relativamente difícil de codificar en SQL, pero los pandas facilitarán su tarea.

Soy una de esas personas que usaría (en mi caso) R's dplyr (el lenguaje, no necesariamente la herramienta) en todos los casos si pudiera aunque conozco mi SQL.

El principal beneficio que veo en las canalizaciones de Pandas / dplyr / data.table es que las operaciones son atómicas y se pueden leer de arriba a abajo.

En SQL, debe analizar todo el script, saltando (lo que se suma, lo que se une y cómo, ¿izquierda, interior, derecha, hay algún filtro aplicado?) Para comprender completamente lo que está sucediendo.

En Pandas et al., Cada paso de la tubería es autónomo, hace algo con los datos de entrada y devuelve datos de salida, este proceso secuencial hace que sea más fácil razonar sobre lo que está sucediendo, ya que hay un estado claramente definido para cada operación en lugar de solo Un nivel de consulta.

Y sí, puede hacer WITHdeclaraciones y tal, pero requiere mucho más código y no está tan claro qué objeto se está utilizando en comparación con las tuberías.

Soy bastante nuevo en Pandas / Python, pero tengo más de 20 años como administrador de bases de datos SQLServer, arquitecto, administrador, etc. Amo a Pandas y me estoy esforzando para que siempre intente hacer que las cosas funcionen en Pandas antes de volver a mi cómodo, acogedor mundo SQL.

Por qué los RDBMS son mejores: La ventaja de los RDBMS son sus años de experiencia optimizando la velocidad de consulta y las operaciones de lectura de datos. Lo impresionante es que pueden hacer esto al mismo tiempo que equilibran la necesidad de optimizar la velocidad de escritura y administrar el acceso altamente concurrente. A veces, estos gastos generales adicionales inclinan la ventaja de Pandas cuando se trata de casos de uso simples para un solo usuario. Pero incluso entonces, un DBA experimentado puede ajustar una base de datos para que esté altamente optimizada para la velocidad de lectura sobre la velocidad de escritura. Los DBA pueden aprovechar cosas como la optimización del almacenamiento de datos, el tamaño de página de disco estratégico, el relleno / relleno de página, el controlador de datos y las estrategias de partición de disco, planes de E / S optimizados, fijación de datos en memoria, planes de ejecución predefinidos, indexación, compresión de datos , y muchos más. Muchos desarrolladores de Pandas me dan la impresión de que no No entiendo la profundidad que está disponible allí. Lo que creo que suele suceder es que si el desarrollador de Pandas nunca tiene datos lo suficientemente grandes como para necesitar estas optimizaciones, no aprecian cuánto tiempo pueden ahorrarle de inmediato. El mundo RDBMS tiene 30 años de experiencia optimizando esto, por lo que si se necesita velocidad bruta en grandes conjuntos de datos, los RDBMS pueden ser superados.

¿Por qué es mejor Python / Pandas? Dicho esto, la velocidad no lo es todo y en muchos casos de uso no es el factor de conducción. Depende de cómo esté utilizando los datos, si se comparten y si le importa la velocidad del procesamiento. Los RDBMS son generalmente más rígidos en sus estructuras de datos y suponen una carga para el desarrollador para que sea más determinista con las formas de datos. Pandas te permite ser más suelto aquí. Además, y esta es mi razón favorita, estás en un verdadero lenguaje de programación. Los lenguajes de programación le brindan infinitamente más flexibilidad para aplicar lógica avanzada a los datos. Por supuesto, también existe el rico ecosistema de módulos y marcos de terceros a los que SQL no puede acercarse. Es MUY conveniente poder pasar de los datos sin procesar hasta la presentación web o la visualización de datos en una base de código. También es mucho más portátil. Puede ejecutar Python en casi cualquier lugar, incluidos los cuadernos públicos que pueden ampliar el alcance de sus resultados para llegar a las personas más rápidamente. Las bases de datos no se destacan en esto.

¿Mi consejo? Si se encuentra graduándose a conjuntos de datos cada vez más grandes, debe dar el paso y aprender cómo los RDBMS pueden ayudarlo. He visto millones de filas, combinación de varias tablas, consultas agregadas sumadas ajustadas de 5 minutos a 2 segundos. Tener esta comprensión en su cinturón de herramientas simplemente lo convierte en un científico de datos más completo. Es posible que pueda hacer todo en Pandas hoy, pero algún día puede tener una tarea en la que RDBMS es la mejor opción.

Cosas que los pandas pueden hacer, que SQL no puede hacer

1. df.describe()
2. Trazado, p. Ej. df['population'].plot(kind='hist')
3. Utilice un marco de datos directamente para entrenar algoritmos de aprendizaje automático

Cosas que los pandas pueden hacer, no sabía que SQL también puede hacer

1. Exportar a CSV: df.to_csv('foobar.sv'). Esto es importante cuando desea mostrar algo al propietario de una empresa que quiere trabajar con Excel. Y lo hay df.to_exceltambién. Pero en SQL, puedes hacerlo SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM test_table;(¡gracias, vy32!)

Lo único que no está cubierto en estas respuestas que me gustaría mencionar es que también depende de cómo esté usando SQL. Tome arcpy por ejemplo. Por alguna razón, ninguna de las funciones arcpy.da tiene una función de ejecución múltiple. Esto es realmente extraño porque casi todas las demás bibliotecas de Python sql lo hacen. La instrucción Where en las funciones arcpy.da también está limitada a alrededor de 120 caracteres. Esto significa esencialmente que si tiene un número relativamente alto de cosas que está tratando de hacer con su base de datos, su única opción real es llamar a la función arcpy.da elegida varias veces, cambiando la instrucción where cada vez que lo haga. Hay algunos trucos que puede usar para acelerar este proceso, por ejemplo, puede iterar sobre fragmentos de su conjunto de datos, pero literalmente cada uno de estos trucos es mucho más lento que simplemente usar un arcpy.da. searchcursor para cargar toda su tabla en un marco de datos de pandas, y luego manipularla usando pandas, numpy y, si sus datos son realmente tan masivos, basura. Necesito enfatizar aquí que los pandas no son solo un poco más rápidos en este caso. Es asquerosamente más rápido. Es mucho más rápido que literalmente me estaba riendo de mí mismo por no hacerlo antes. El uso de pandas redujo el tiempo de ejecución de una secuencia de comandos de más de una hora (me olvido si este fue el salto de 3.5 horas o de 1.5 horas) a literalmente 12 minutos. Es mucho más rápido que literalmente me estaba riendo de mí mismo por no hacerlo antes. El uso de pandas redujo el tiempo de ejecución de una secuencia de comandos de más de una hora (me olvido si este fue el salto de 3.5 horas o de 1.5 horas) a literalmente 12 minutos. Es mucho más rápido que literalmente me estaba riendo de mí mismo por no hacerlo antes. El uso de pandas redujo el tiempo de ejecución de una secuencia de comandos de más de una hora (me olvido si este fue el salto de 3.5 horas o de 1.5 horas) a literalmente 12 minutos.

Una cosa a tener en cuenta es que, si bien podría haber hecho esto con sql, me habría llevado mucho más tiempo aprenderlo. Hubiera tenido que aprender operaciones específicamente para sql en Access, ahí es donde terminaron los datos de este script, - sql en Access no era tan robusto como lo necesitaba cuando estaba buscando hacerlo, o Hubiera tenido que escribir todos mis datos en una base de datos sqlite3, manipularlos allí y luego ponerlos en Access. Si bien esto podría haberme dado resultados de rendimiento similares, habría hecho que mi script fuera más difícil de modificar en el futuro.

Entonces, sí, a veces Pandas y es estrictamente mejor que usar las opciones sql que tiene a su disposición . Todo lo que habría necesitado hacer en sql se hizo con una función en pandas. También puede usar la sintaxis sql con pandas si lo desea. Hay pocas razones para no usar pandas y sql en conjunto.

Una cosa más que quiero mencionar sobre Pandas y numpy es que ambas bibliotecas son por naturaleza enfoques basados ​​en conjuntos. Puede recorrer los marcos de datos y la construcción de series con estas bibliotecas, pero es realmente difícil modificar los datos en estas estructuras de esa manera, por lo que terminará escribiendo código más eficiente, basado en conjuntos, con ambas bibliotecas simplemente porque es mucho más fácil hacer. Ser "guiado" si no se usa para utilizar enfoques basados ​​en conjuntos no es algo que haya experimentado con SQL.

Otra cosa masiva que olvidé mencionar con Pandas. Dinero . Pandas es una herramienta que muchos trabajos de Data Science quieren que sepa cómo usar. Casi todos los trabajos de Data Science que he visto han pagado más que los trabajos de gestión de bases de datos. La única excepción a esto que he notado es en Ingeniería de Datos, pero he visto mucho menos de esos anuncios de trabajo. Parece que Pandas te hace ganar más dinero de un vistazo.

Pensé que agregaría que hago muchos análisis de datos basados ​​en series temporales, y que los pandas resampley los reindexmétodos son invaluables para hacer esto. Sí, puede hacer cosas similares en SQL (tiendo a crear una DateDimensiontabla para ayudar con las consultas relacionadas con la fecha), pero creo que los métodos de pandas son mucho más fáciles de usar.

Además, como han dicho otros, el resto de mi modelado está en Python, y a menudo tengo llamadas web o archivos CSV.

Intentaré responder a esta pregunta basándome en mi propia experiencia. En contraste con las otras respuestas, prefiero Sqlel aprendizaje profundo y las cosas relacionadas con big data. Hay numerosas razones para eso. Como se puede ver aquí ,

Pandas proporciona una experiencia de análisis de datos intuitiva, potente y rápida en datos tabulares. Sin embargo, debido a que Pandas usa solo un hilo de ejecución y requiere que todos los datos estén en la memoria a la vez, no escala bien a conjuntos de datos mucho más allá de la escala de gigabytes.

$B ^+$

Otra diferencia es que las operaciones CRUD en SQL pueden aplicarse distribuidas con diferentes políticas de autorización que no son posibles en pandas.

No pretende decir cuál es mejor, todo depende de su tarea. Para el cómputo a gran escala, prefiero SQL y para los pequeños, prefiero pandas.

Hay otras cosas que no están en los pandas que son realmente importantes para una experiencia rápida para la extracción de datos a las que me referiré más adelante. Por ahora, solo eche un vistazo aquí .

Panda es más popular ya que Python en forma de cuadernos jupyter es la caja de herramientas más popular utilizada por el científico de datos en el área de redes neuronales. Python se está convirtiendo en "el" idioma. Incluso es posible usar SQL back-end, pero no está vinculado a SQL solo con panda.

No es exactamente la respuesta a la pregunta, pero como yo mismo vine aquí para buscar diferencias en la aplicación práctica:

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