¿Por qué la gente prefiere Pandas a SQL?


69

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.


Los comentarios no son para discusión extendida; Esta conversación se ha movido al chat .
Sean Owen

Respuestas:


51

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.


2
Creo que SQL se basa en gran medida en jugar juega un papel importante, cuando muchas personas de otras áreas técnicas están acostumbradas a manejar datos línea por línea. También tenga en cuenta que los datos son principalmente datos para pandas, pero diferentes motores SQL admiten diferentes funciones integradas que pueden volverse muy molestas rápidamente si tiene que cortar y cambiar durante su día de trabajo
Dave

3
No diría que no es viable. Si puede obtener los datos en un marco de datos de pandas, probablemente pueda insertarlos en una base de datos PostgreSQL. Pero para uno y listo, probablemente sea más esfuerzo y tiempo del que ahorraría.
jpmc26

2
Estoy de acuerdo en que algunos enfoques ETL parecen ser decisiones centradas en el programador. Es decir, prefieren manipular los datos y luego presentar esta carga útil "perfecta" a la base de datos. Sin embargo, como usted indica, si se puede hacer a través de varias consultas SQL, entonces la capa programática adicional es innecesaria. Exactamente lo que enfrenté recientemente. Como indica el OP y su respuesta, podría ser que la gente de la "vieja escuela" o centrada en DBA lo mire y diga, ¿por qué no hacerlo en SQL (incluso solo varias consultas simples!). Dicho esto, he encontrado que los pandas son muy poderosos para conjuntos de datos extremadamente diversos.
SaltySub2

1
@SaltySub Solo un punto para cambiar las cosas de la capa programática a SQL: es un punto justo y puede ser perfectamente válido, pero ir tan lejos como enterrar la lógica de la aplicación en los procedimientos SQL puede traer su propio sabor especial de dolor de cabeza.
Cabeza eléctrica

1
@ElectricHead Estoy de acuerdo en que debe haber un equilibrio correcto. Si una serie de consultas SQL puede realizar las tareas adecuadamente, definitivamente puede ser más fácil y más eficiente. Por el contrario, como usted indica, si uno tiene que colocar una gran cantidad de lógica en los procedimientos de SQL, etc., los pandas deben ser considerados. Particularmente como anteriormente si está utilizando diferentes tipos de bases de datos, las diferencias de sintaxis SQL pueden ser muy complicadas.
SaltySub2

29

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.


1
Esta es la única respuesta verdadera, debería ser la elegida. SQL y Pandas son dos cosas diferentes, no entiendo qué comparación intentan hacer las personas.
Gented

Sospecho que es una perspectiva del usuario final escribir algo similar a un código para obtener y masajear algunos datos de alguna parte y escupir algunos números. No estoy completamente sorprendido; He tenido experiencia de primera mano de cómo los analistas de datos presentados con una base de datos Oracle antigua pero poco notable ni siquiera tienen la primera idea de qué es y cómo conectarse a ella, y mucho menos sacar datos. Creo que revela una falta fundamental de comprensión de la tecnología: de hecho, he agregado un poco para enfatizar la rapidez con la que se cae el malentendido del alcance de SQL.
Cabeza eléctrica

Desafiaría tu parte sobre ser irrelevante para las situaciones NoSQL. Considere, por ejemplo, los avances que PostgreSQL ha realizado con su almacenamiento JSON.
jpmc26

Traté de elegir mis palabras con cuidado; PostgreSQL sigue siendo un RDBMS a pesar de hacer muchas cosas bien (como SQL Server lo es a pesar de los gráficos compatibles). Pero, he relajado un poco la redacción porque todavía es un buen punto: hay algunos cruces y, lo que es más importante, existen API de SQL para algunos sistemas NoSQL. Sin embargo, es cruzado, SQL no es un lenguaje universal y no todos los datos están estructurados relacionalmente.
Cabeza eléctrica

Creo que puedes hacer todo en SQL, lo cual es posible en pandas. SQL no es flexible pero está muy optimizado.
Medios

22

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.


¿Es esta ineficiencia específica de los pandas? Hice bastante manipulación de datos en memoria en C # y lo encontré bastante fácil y eficiente, siempre que se ajustara a la memoria y fuera de una sola vez (es decir, no es necesario actualizar los índices de forma incremental a medida que cambian los datos).
CodesInChaos

pandas está destinado a ser conveniente sobre rápido, pero eso no quiere decir que no puede ser rápido si lo usa correctamente. Al final, ejecutar una consulta SQL sobre datos en una base de datos no es mágico: requiere recursos como cualquier cosa, es solo eso (¡si lo hace bien!) Esperamos que esté utilizando recursos en servidores de bases de datos robustos y cuidadosamente configurados . Lograr que su canalización sea correcta en pandas o similar (por ejemplo, transmitir datos en lugar de cargarlos todos en la memoria) determinará el éxito de algunos esfuerzos.
Cabeza eléctrica

@CodesInChaos Hay esta respuesta de pandas vs SQl - qr.ae/TUIpzE . Allí se describen las ventajas y desventajas de usar pandas.
Ankit Seth

12

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.


6

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.


5

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!)

1
Agradable. Aunque la mayoría de estas parecen funciones que podrían implementarse en SQL. (SQL tiene una exportación CSV directa).
vy32

¿Podría enviarme una consulta que se exporta a CSV? (Solo conozco herramientas que hacen esto para algunas bases de datos basadas en SQL, pero nunca he visto una consulta ... así que dudo que esto sea parte de la especificación SQL)
Martin Thoma

1
SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM test_table; Ver dev.mysql.com/doc/refman/8.0/en/select-into.html
vy32

Muchas gracias, vy! Creo que ajustaré mi respuesta cuando esté en casa :-)
Martin Thoma

Cosa segura. Recuerde, el archivo termina en el servidor SQL, no en el cliente.
vy32

3

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.


55
Quizás sea triste que cuando se trata de trabajos modernos se trata de tener las palabras de moda correctas en su currículum en lugar de los enfoques que toma para resolver un problema (suponiendo que pueda aprender dicha palabra de moda relativamente rápido). Es como si la palabra de moda es más importante que la resolución de problemas. Cuando la resolución de problemas para X debe implicar aprender y usar la tecnología A, B, C, no al revés. Me pregunto si la mayoría de los equipos de desarrollo ahora rompen las cosas debido a la palabra de moda y la tendencia, y luego piensan en la resolución de problemas como una cosa secundaria o de la "vieja escuela" porque no sabían / ​​usaban dicha palabra de moda.
SaltySub2

1
@ElectricHead, en mi experiencia, si está escribiendo su propia función que involucra sql en python, es más fácil usar mal el cursor y escribir malas consultas que con pandas / numpy. Debo recordar que no todos los módulos / bibliotecas sql están hechos de la misma manera. En mi caso, con arcpy.da.SearchCursors y similares, realmente no hay una buena manera de hacer algo a un montón de registros de manera eficiente debido a limitaciones extrañas. Si uso pandas / numpy, se convierte en una buena manera de hacer las cosas, y eso es lo que quiero cuando uso Python.

1
Ahhh, ok ¿Te refieres a una tubería SQL casera a través de una implementación de python dbapi en lugar de usar numpy / pandas? En cuyo caso, sí, te tengo, no hay discusión de mí allí; cuidado requerido! Me leyó como vs SQL simple con el que obviamente necesitas entender las operaciones de conjunto, pero lo descubrirá bastante rápido cuando ejecutes consultas tontas desde un cliente de base de datos.
Cabeza eléctrica

1
@ Steve Sí, no detendrá a las personas que intentan modificar dinámicamente cosas en bucles en pandas o similares :) Creo que comprender SQL ayuda a trabajar en pandas de manera efectiva (aunque no es que oculten la similitud en algunos conceptos).
Cabeza eléctrica

1
@Steve De hecho, los pandas también son poderosos ... Supongo que una de mis frustraciones es que los desarrolladores y la administración, incluido yo mismo, no pasamos el tiempo adecuado evaluando soluciones y persiguiendo tendencias (donde el dinero está involucrado para promover la auto-empresa). Pero incluso en los prototipos / mvp lean uno tendría que sentar las bases adecuadas para escalar. SQL, noSQL y Pandas ... todos tienen sus propósitos para las tareas y proyectos apropiados en diferentes etapas. Durante el año pasado más, noSQL para un prototipo / mvp lean ciertamente me ayudó en más de un sentido. SQL habría sido excesivo para eso.
SaltySub2

3

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.


2

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í .


1

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.


Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.