¿Por qué estamos enseñando pandas en lugar de SQL?

Foto de Pedro González en Unsplash

Érase una vez un estudiante que estaba ansioso por aprender ciencia de datos.

Le preguntó a la gente qué debía hacer y le dijeron que aprendiera pandas. Recorrió la web en busca de cursos de datos y todos presentaban pandas. Entonces, el estudiante aprendió pandas y luego consiguió un trabajo en la academia, donde todos trabajaban con pandas.

Así que trabajó con pandas durante muchas lunas, hasta que pudo cortar marcos de datos mientras dormía. Cuando terminó, se unió a un campo de entrenamiento de datos: he aquí que estaban enseñando pandas. Cuando terminó, el campo de entrenamiento lo contrató para enseñar a los pandas.

Luego llegó el momento en que el estudiante entró en su primera empresa. Su maestro quería que procesara algunos datos.

“Usaré pandas”, dijo el estudiante.

"¡Al infierno que lo harás!" dijo el maestro. “Usamos S-Q-L aquí”, replicó, enfatizando cada letra con un golpe de su bastón.

“Pero... Pero... Verbosidad... Fealdad... Falta de funciones... Anidamiento sin fin... ¡Y las uniones, las uniones son horribles!...“

“Si no puedes ver el bosque, entonces no debes tocar los árboles”, dijo el maestro, golpeándolo en la cabeza.

El estudiante se iluminó.

O eso pensó; de hecho, el golpe del maestro lo había aturdido tanto que su juicio se vio afectado temporalmente.

Muchas lunas más tarde, después de un retiro doloroso, el estudiante entendió SQL. A partir de entonces no volvió a sentir la necesidad de usar pandas, y el maestro nunca más le asestó un golpe.

SQL >> pandas

El koan anterior es autobiográfico, aunque debo señalar que ninguno de mis supervisores me golpeó nunca (incluso cuando deberían haberlo hecho).

No ha cambiado mucho desde que empecé. La mayoría de los currículos de los bootcamps de datos presentan una gran inversión en pandas (junto con los portátiles Jupyter), mientras que SQL es, en el mejor de los casos, una idea de último momento.

Busque "ciencia de datos" en Udemy y verá los mejores cursos que mencionan Python (que inevitablemente incluye pandas) y R, a veces incluso Scala. Muy pocos de ellos mencionan SQL.

Creo que esto es malo, tanto desde el punto de vista del valor como desde el punto de vista pedagógico.

El problema del valor

Si está haciendo análisis estándar, SQL es simplemente una herramienta mejor que pandas. Es más simple, más claro, más potente y eficiente. También es más fácil de entender, compartir y reproducir. Hay una razón por la que ha sido la lengua franca del análisis de datos durante décadas.

Si se enfoca en Pandas a expensas de SQL, se está perdiendo la oportunidad de ser un profesional de datos mejor y más efectivo.

Por supuesto, hay cosas que los pandas hacen mejor y las exploro brevemente al final del artículo. Pero en general, cuando se trata de análisis puro, SQL es difícil de superar.

Las personas a menudo no se dan cuenta de que los pandas presentan una sobrecarga significativa en términos de complejidad, ineficiencia, idiosincrasia y oportunidades de confusión.

El problema de aprendizaje

Sospecho que el énfasis excesivo en los pandas perjudica a los estudiantes de datos. En mi experiencia, hay un punto en el que hacer más pandas resulta en anti-aprendizaje , es decir, la persona simplemente se vuelve más confusa con el tiempo.

Los nuevos estudiantes, en particular, experimentan problemas extraños que los confunden y que compensan con la memorización ciega.

También adquieren malos hábitos que son difíciles de abandonar más tarde, como recorrer filas cuando podrían usar operaciones de tabla; crear columnas con tipos mixtos; guardar datos en CSV; modificar datos en su lugar; obstruyendo la memoria con múltiples copias y segmentos del mismo marco de datos... Podría continuar.

Parte de esto se debe a que Python es un lenguaje extremadamente tolerante, lo que impone al usuario la carga de no hacer cosas malas (como Series pandas con tipos mixtos). Parte de esto proviene del hecho de que pandas acepta (aunque no necesariamente alienta) un enfoque imperativo.

Por ejemplo, si un estudiante quiere combinar datos de dos tablas, no hay nada que le impida usar este algoritmo:

1. Bucle sobre la table1

2. Para cada fila de la table1 1, escanee toda la table2 para buscar

3. Actualice la fila en la table1 1 a partir de los datos de la table2

   
   

Sí, esto es obviamente muy malo. Pero los principiantes no saben nada mejor.

Por el contrario, el enfoque declarativo de SQL hace que sea más difícil hacer cosas malas.

La programación declarativa obliga al usuario a pensar en términos del resultado que quiere ver, en lugar de cómo producirlo . Esto les da el espacio que necesitan para concentrarse en la lógica detrás de su análisis, en lugar de estar constantemente atascados por problemas y errores extraños.

SQL también obliga a los estudiantes a pensar en tablas (es decir, modelo relacional) y operaciones a nivel de columna, lo cual es muy beneficioso cuando su primer instinto es recorrerlo todo.

Finalmente, aprender SQL produce un mayor retorno de la inversión debido a su universalidad y portabilidad.

Descargo de responsabilidad

No odio a los pandas. Fue mi herramienta analítica básica durante dos años y todavía la uso para mis proyectos personales. Me alegra ver que la gente lo aprende.

Pero estoy tratando de ver el panorama general. Creo que enfatizar demasiado los pandas a expensas de SQL hace más daño que bien . Especialmente cuando se trata de principiantes, que están aprendiendo sobre Pandas MultiIndex antes de poder hacer un GROUP BY adecuado.

Perspectiva

En la siguiente sección, analizo algunos de los aspectos más extraños de los pandas y los comparo directamente con SQL.

El objetivo, una vez más, no es menospreciar a los pandas, sino ampliar la perspectiva del lector sobre las herramientas a su disposición.

Profundicemos.

 SELECT * FROM opinionated_comparison WHERE sql > pandas

Comparación

Selección de columnas

En una sola declaración, SELECT de SQL le permite:

1. Elija las columnas que desee y el orden en que deben devolverse.

   
   

2. Cree nuevas columnas basadas en combinaciones y transformaciones de columnas existentes.

   
   

3. Cambiar el nombre de las columnas.

   
   

Este ejemplo selecciona todas las columnas excepto una, luego crea una nueva columna basada en una combinación lineal de otras dos columnas:

 SELECT * EXCEPT (first_name), equity_comp / total_comp * 100 AS percent_equity FROM salaries

La selección de columnas de pandas solo permite elegir y ordenar columnas. Si desea cambiar el nombre o transformar algunos, necesita varias declaraciones, y muchas personas caen en el error de transformar los datos en su lugar (consulte la inmutabilidad a continuación).

Los principiantes se confunden porque seleccionar una sola columna requiere un conjunto de corchetes ( df[”first_name”] ) mientras que seleccionar varias columnas requiere un doble conjunto de corchetes ( df[[”first_name”, "last_name"]] ).

El mayor problema que tengo con los pandas aquí es la notación de puntos: el hecho de que puedes seleccionar columnas como esta: df.first_name .

Esto es mucho más fácil que usar corchetes y comillas, por lo que la gente termina prefiriéndolo por pura pereza. Al menos eso es lo que me pasó a mí: todavía uso la notación de puntos automáticamente, aunque sé que es mala.

Los problemas aparecen cuando tiene una columna llamada count shape diff o cualquier otro de los muchos atributos estándar de un marco de datos (puede verlos todos con dir(df) ).

Cuando intente acceder a ellos con notación de puntos, obtendrá el atributo en lugar de la columna y su código se romperá.

Entonces, pandas tiene tres formas de seleccionar columnas: dos para obtener una sola columna (¡de las cuales una es mala pero más atractiva!) Y una tercera para seleccionar varias columnas.

Selección de filas

En SQL, para seleccionar filas específicas, simplemente use la declaración WHERE (consulte Filtrado a continuación).

Seleccionar filas en Pandas es... complejo. Para ver qué tan complejo, consulte la guía de inicio del usuario . O profundice en un tutorial típico de 30 minutos .

Me limitaré a un solo ejemplo. Cada DataFrame tiene un Index . El índice predeterminado es una secuencia de enteros: [0,1,2,3,4,5...] .

Naturalmente, la mayoría de la gente asume que el índice representa la cardinalidad de las filas. En realidad, ¡los números son solo etiquetas categóricas! También podrían ser letras aleatorias como ['x', 'z', 'a'] . No hay cardinalidad implícita.

Para obtener una fila por su índice, usa df.loc . Pero para seleccionar por la cardinalidad de la fila, usa df.iloc . Con el índice predeterminado, estos dos métodos dan el mismo resultado.

Lo que solo aumenta la confusión, porque en cualquier momento su índice puede cambiar a algo completamente aleatorio como [7, 2, 2, 'c', True, None] . ¡Sí, todo esto está permitido! Y no hay restricciones para evitarlo (ver Restricciones a continuación).

Imagina que escribiste tu código asumiendo que el índice representaba la cardinalidad de fila. Ahora:

• df.loc[7] devolverá la primera fila
• df.loc[2] devolverá un segmento de marco de datos en lugar de una fila (porque aparece más de una vez en el índice)
• df.loc[None] devolverá una fila real.

• 
  

No estoy llorando tu estas llorando

Y sí: el mismo método puede devolver un valor escalar, una fila o un segmento de marco de datos dependiendo de cómo esté compuesto el índice. Los documentos de los pandas reconocen esta locura:

Otros métodos, como la indexación, pueden dar resultados muy sorprendentes. Por lo general, la indexación con un escalar reducirá la dimensionalidad . Cortar un DataFrame con un escalar devolverá una Series . Cortar una Series con un escalar devolverá un escalar. Pero con [índice] duplicados, este no es el caso.

Y recuerde, no hay ninguna restricción para evitar que el índice contenga duplicados. No puedo comenzar a decirles cuántos dolores de cabeza me ha causado esto.

(Además de todos los métodos para seleccionar que hemos mencionado, pandas también tiene df.at y df.iat para valores únicos. Otra cosa para recordar y evitar confusiones).

Filtración

En SQL, el filtrado es sencillo. Escriba WHERE , inserte tantas declaraciones como desee y encadenelas con operadores lógicos. Los corchetes le dan más control sobre la estructuración de expresiones.

Por ejemplo, los siguientes filtros de consulta para personas que tienen más de 30 años y cumplen al menos una de dos condiciones: más de 5 años de antigüedad o compensación de capital inferior a 50:

 SELECT * from salaries WHERE age > 30 AND (tenure > 5 OR equity_comp < 50)

¿Cómo se ve esto en Pandas?

 new_df = df[(df["age"] > 30) & ((df["tenure"] > 5) | (df["equity_comp"] < 50))]

Puaj. Diviértete explicando esto a los principiantes.

De acuerdo, probablemente no lo escribirías así porque es demasiado feo. Ejecutaría el filtrado en varias declaraciones: lo que significa más líneas de código, variables y repetición.

Los filtros de Pandas se basan en un método llamado indexación booleana . Cada operación de filtrado ocurre en dos pasos:

1. Toma una Series (que es el objeto de la columna) y ejecuta cada elemento a través de una prueba booleana. Así transformándolo en una nueva Series hecha de valores booleanos (verdadero o falso).

   
   

2. Selecciona el marco de datos con esta columna, que termina excluyendo las filas donde la Series booleana contiene un valor falso.

   
   

¿Notas la suposición oculta aquí? La Series utilizada para filtrar y el marco de datos que se filtra deben compartir el mismo índice, en el mismo orden. Esto no siempre está garantizado.

En la práctica, la indexación booleana significa que cuando filtra, siempre tiene que repetir la variable del marco de datos, por ejemplo, salaries[salaries["cash_comp"] > 20] . ¡Esto es muy molesto cuando estás escribiendo mucho código! Vea el ejemplo anterior: se hace referencia a la variable del marco de datos 4 veces.

También puedo decir por experiencia que la indexación booleana no es fácil de entender para los principiantes. Algunas personas nunca entienden el mecanismo subyacente en absoluto. Simplemente memorizan el patrón de codificación.

(El método df.query() parece proporcionar un mejor método para filtrar ).

Agrupamiento

No hay quejas importantes aquí. Pero SQL definitivamente está más cerca del inglés. Estos dos son equivalentes:

 SELECT AVG(cash_comp), SUM(tenure) FROM salaries GROUP BY department

 grouped_df = df.groupby('department').agg({"cash_comp": np.mean, "tenure": np.sum})

Uniones

SQL tiene un tipo de unión. Se llama JOIN . Claro, puede ser izquierda/derecha e interior/exterior, pero el uso es bastante sencillo.

Pandas tiene dos métodos: join y merge . Nunca entendí por qué necesitamos dos. se supone que join funciona en índices, se supone que merge funciona en cualquier columna.

Pero si observa los documentos [ 1 ][ 2 ], cada uno parece admitir índices y columnas. soy confusión. (Si tiene dudas, le sugiero que elija siempre merge , ya que join es más un método heredado).

SQL hace que sea realmente fácil UNIRSE en función de una cadena de condiciones lógicas, como: unirse por función, pero solo si el salario de Londres es mejor que el de Washington, o si la persona tiene una permanencia más larga.

 SELECT * FROM london_hq lhq JOIN washington_hq whq ON lhq.role = whq.role AND (lhq.salary > whq.salary OR lhq.tenure > whq.tenure)

Hasta donde yo sé, esto no es posible con pandas. Al unirse (o fusionarse) solo puede usar la condición de igualdad.

Entonces, primero tendría que ejecutar JOIN en role , realizar un seguimiento del origen de cada columna y luego filtrar el resultado.

Sin embargo, diría que esas condiciones pertenecen legítimamente a JOIN y no son menos relevantes por no usar la comparación de igualdad.

Mecanografía

Una de las principales ventajas de SQL es que cada columna tiene un tipo bien definido. Además, no se permite que las columnas tengan tipos mixtos. Esto ahorra muchos errores y dolores de cabeza a largo plazo.

Cuando carga datos en pandas, la mayoría de las columnas se escriben automáticamente como object . Esto puede significar una de tres cosas:

1. La columna contiene solo cadenas

2. La columna contiene objetos de Python que no son un tipo de datos primitivo, por ejemplo, una lista o un diccionario.

3. La columna contiene tipos mixtos.

   
   

Cuando ve el tipo de datos del object , nunca sabe cuál es el caso. Encuentro esto muy molesto.

A diferencia de SQL, puede cargar datos con tipos mixtos en pandas: simplemente se escribirán como object .

Pandas no lo obliga a especificar un esquema y atenerse a él. Esto le otorga una prima de velocidad cuando está comenzando, pero a menudo lo paga muy caro en futuros errores y confusión.

Esto es especialmente problemático para los principiantes que no están alertas a las trampas comunes. Por ejemplo, cuando estaba trabajando con Pandas, a menudo intentaba una operación de fecha y hora, solo para darme cuenta de que la columna de fecha y hora estaba hecha de cadenas (por lo tanto, clasificada como object ). Ingenuamente haría esto:

 df['Date'] = df['Date'].astype('datetime64[ns]')

Y seguir adelante, solo para descubrir mucho más tarde que el analizador de fechas de Pandas había leído mal mis cadenas y las fechas no tenían sentido.

Archivos y CSV

Seamos honestos: la mayoría de las personas almacenan sus marcos de datos como CSV. Los estudiantes de Pandas son bienvenidos, y más aún, alentados a hacer esto. ¡Esta es una mala idea!

Claro, los CSV son legibles por humanos y... sus ventajas terminan aquí. Sus desventajas son:

• Al convertir a CSV, pierde toda la información sobre el esquema y los tipos de columnas. Todo vuelve a ser texto.

  
  

• Los CSV son propensos a errores de formato, corrupción y análisis.

  
  

• Los CSV son difíciles de comprimir, lo que aumenta los costos de almacenamiento.

  
  

• El formato CSV está subespecificado , lo que significa que diferentes programas crean CSV de diferentes maneras, y el usuario tiene la responsabilidad de descubrir cómo analizarlos. Esto puede convertirse rápidamente en una experiencia infernal, como puede atestiguar cualquier profesional de datos.

  
  

La pérdida del esquema suele ser el mayor problema para las personas que trabajan en pandas. Esta es una situación común:

1. Su trabajo comienza con un CSV. Siempre que haya averiguado el formato correcto, la codificación, la especificación de caracteres de comillas y el resto de los muchos argumentos para read_csv de pandas, lo cargará en un marco de datos. Ahora debe dedicar tiempo a explorar las columnas, convertir cada columna al tipo correcto, solucionar cualquier error que aparezca en el proceso y verificar que el resultado final tenga sentido. (O podría comenzar a trabajar de inmediato y enfrentar muchos errores más adelante).

   
   

2. Una vez que haya terminado su trabajo, tendrá un nuevo marco de datos. ¿Que vas a hacer con eso? Por qué, guárdelo como un CSV. Ahora todo su trabajo anterior sobre la definición del esquema se ha ido, ya que el marco de datos se vuelca en texto.

   
   

3. Debe cargar el nuevo marco de datos para otro flujo de trabajo. Eso significa cargar el CSV que acabas de descargar. Espero que haya escrito funciones que puedan restaurar con éxito el esquema, o tendrá que hacer el trabajo de nuevo (siempre que recuerde lo que se suponía que debía hacer cada columna).

   
   

4. ¿Quieres compartir el CSV con un amigo o publicarlo en GitHub? Es mejor que comparta el código que puede volver a imputar el esquema y espere que estén dispuestos y puedan ejecutarlo. O se quedarán con una gota de texto y tendrán que repetir todo el trabajo de imputación del esquema desde cero.

   
   

¿Suena absurdo? He visto esto hacer innumerables veces . ¡He hecho esto yo mismo! Pero ahora me pregunto: ¿por qué le enseñamos a la gente a trabajar así? ¿Qué justifica tal locura y crueldad?

Hay dos soluciones aquí.

Si realmente necesita trabajar en pandas, exporte sus marcos de datos en Parquet.

O podría trabajar en SQL y ahorrarse todos los problemas. Después de todo, una base de datos es el mejor lugar para almacenar datos.

Pregúntese: ¿Por qué necesito una capa de archivo? Si simplemente está leyendo algunos datos, procesándolos y luego almacenando los resultados, probablemente no lo haga. Cargar desde la base de datos, trabajar en la base de datos, guardar en la base de datos. Es así de simple. ¿Necesita compartir datos externamente? Exportación en Parquet.

El mundo no necesita más CSV.

Nota: algunas personas intentan resolver el problema del esquema decapando sus marcos de datos. Esta es una idea terrible .

El encurtido es ineficiente e inseguro (¡nunca abra un encurtido en el que no confíe!). Un marco de datos en escabeche solo se puede abrir dentro de Python, y tiene que ocurrir dentro del mismo entorno de biblioteca (sobre el cual el usuario puede no saber absolutamente nada). Si los pandas que leen el pickle son una versión diferente a los pandas que lo escribieron, ¡el archivo podría ser ilegible!

nulos

SQL usa valores NULL para indicar datos faltantes. Puede filtrar fácilmente los valores nulos.

 SELECT * FROM salaries WHERE equity_comp IS NOT NULL AND cash_comp IS NOT NULL

En Pandas, los valores faltantes pueden ser cualquiera de estos:

• None nativo de Python (que Pandas muestra como None pero lo trata como nan )

• numpy.nan

• pandas.NA

• pandas.NaT (para fechas y horas)

  
  

Centrémonos en numpy.nan que es el más común:

• El tipo de este objeto es float , así que olvídate de detectarlo con controles de tipo.

• Es cierto, así que olvídate de las pruebas booleanas. bool(np.nan) es True .

• Falla la prueba de igualdad, ya que numpy.nan == numpy.nan es falso. ¡ nan no es igual a sí mismo!

• El uso de nan en una operación no arroja una excepción, solo significa que el resultado es nan .

  
  

¿No es esto divertido?

La única forma de detectar un nan es usar pandas.isna() . Eso está bien, una vez que lea los documentos y olvide todos sus instintos pitónicos. Aún así, este comportamiento es extremadamente confuso para los principiantes.

Así es como puede replicar la consulta anterior en Pandas:

 new_df = df.dropna(subset=["equity_comp", "cash_comp"])

Restricciones

Las restricciones son importantes en SQL. Le permiten especificar reglas que mantienen sus datos seguros y consistentes. Por ejemplo, la clave principal, que sirve como identificador único para cada fila, debe ser única y no nula.

Pandas no tiene nada como esto.

Lo más parecido a una clave principal en pandas es el índice. Desafortunadamente, el valor del índice puede ser tanto repetido como nulo (sí, puede tener un índice con valores None ).

Los usuarios suelen trabajar con la suposición implícita de que el índice es una clave principal, una idea reforzada por el hecho de que el índice predeterminado está formado por números enteros: [0,1,2,3,4...] . Por lo tanto, la gente tiende a usar el índice para hacer referencia a filas específicas, por ejemplo, df.loc[2] .

Es un tonto acto de fe. Esto se hace evidente al concatenar o fusionar diferentes tramas de datos. A menudo sucede que se mezclan índices similares y obtienes un índice que se ve así: [0,1,2,2,2,3...] .

Pandas no lanza ninguna advertencia sobre esto, por lo que no te das cuenta al principio. Pero la próxima vez que use df.loc[2] su código se romperá porque en lugar de una sola fila, ahora devolverá un marco de datos con tres filas.

Muchas lágrimas fluirán antes de darse cuenta de que necesita ejecutar reset_index() en el marco de datos fusionado para que cada fila obtenga un valor único nuevamente.

Además, las restricciones de SQL le permiten ejecutar comprobaciones en el momento de la escritura. Si intenta insertar un valor nulo en una columna que lleva la restricción NOT NULL , obtiene una excepción y la mala escritura no ocurre. Pandas solo permite ejecutar comprobaciones en lectura. Es decir, si te acuerdas de hacerlo.

Operaciones vectorizadas

Esto es principalmente un punto pedagógico. Pandas, como es bien sabido, permite e incluso fomenta las operaciones vectorizadas (donde se accede en paralelo a todos los elementos de una serie).

Pero muchas personas que trabajan en Python no piensan así automáticamente. Comenzaron aprendiendo bucles y ahora, por Guido , quieren usar esos bucles.

Cuando comienzan con pandas, pronto descubren los métodos iterrows e itertuples , que les permiten recorrer el marco de datos por filas.

Casi inevitablemente, vuelven a caer en patrones circulares, porque nada los obliga a pensar en vectores. Esto hace que escriban un código terrible que se ejecuta muy lento.

Empecé a centrarme en SQL después de una larga experiencia con pandas. Cada vez que me enfrentaba a un problema de SQL, mi instinto era encontrar una solución en bucle. Frustrantemente, SQL no me permitió hacer eso.

Su sintaxis declarativa me obligó a pensar en términos de operaciones de columna, JOIN y funciones de ventana. Gradualmente, construí un nuevo conjunto de modelos mentales que me hicieron un mejor analista.

Creo que los alumnos deberían generar confianza al manipular datos en SQL antes de comenzar con pandas. Estarán mejor equipados para comprender cuándo el bucle por fila es inevitable, lo cual es raro.

Inmutabilidad

Cargas un marco de datos en la memoria. Necesita modificar ese marco de datos. ¿Lo cambias en su lugar o creas una copia? ¿Debería actualizar las columnas existentes o crear otras nuevas?

¿Qué sucede si necesita crear varios segmentos de marcos de datos y luego trabajar en cada segmento? ¿Debe almacenar cada segmento en una variable separada o usar la misma variable para contener diferentes segmentos a su vez?

Cuando las personas trabajan en pandas, tienden a hacer todas estas cosas al mismo tiempo. Pronto se vuelve difícil realizar un seguimiento de todas las variables que contienen tramas de datos, porciones de tramas de datos y porciones de porciones, y saber cómo se agregaron o modificaron los datos.

(No siempre escribo pandas, pero cuando lo hago, obtengo la configuración con advertencia de copia ).

Y dado que la mayoría de la gente usa pandas con portátiles, estos problemas se combinan con las trampas típicas de los portátiles y terminan causando enormes dolores de cabeza.

Esta es una de las razones por las que creo que pandas no es la mejor opción para el análisis de datos.

Al procesar datos en SQL, no cambia los datos originales. La instrucción UPDATE no se usa en análisis. En su lugar, crea canalizaciones de tablas y vistas que representan diferentes selecciones.

Cuando necesite guardar sus resultados, cree nuevas tablas (o agregue filas a las tablas de destino existentes, pero sin modificar ni eliminar las filas anteriores). Esto respeta el principio de inmutabilidad : nunca modifique ni elimine los datos de origen. Hace que su proceso sea seguro, transparente y fácil de replicar.

Sí, puedes respetar la inmutabilidad en pandas, pero no es obvio que debas hacerlo, y muchas personas nunca aprenden a hacerlo. Lo que normalmente ve es la inmutabilidad a nivel de archivos : las personas generalmente cargan un CSV y generan un nuevo CSV. ¿Pero por el trabajo que sucede en el medio? Todo vale.

(La mayoría de los métodos de pandas son teóricamente "puros" porque devuelven un nuevo marco de datos en lugar de modificar el anterior. Pero todos brindan la opción inplace que cambia un marco de datos en su lugar. Y la gente lo usa con entusiasmo).

Cuando los pandas no son suficientes

Si haces un trabajo serio con pandas, eventualmente chocarás con un muro de rendimiento. Los datos que está analizando son demasiado grandes o sus necesidades de procesamiento son demasiado altas.

Vi esto a menudo cuando estaba investigando con pandas. Cuando sucedió, mis colegas y yo buscábamos en Google "hacer que los pandas sean más rápidos" y encontramos innumerables artículos sobre este tema candente, que a su vez propusieron innumerables hacks, optimizaciones y bibliotecas PyPI que prometían hacer el truco.

Si te encuentras en esta situación, consulta los recursos disponibles. Especialmente aquellos que explican cómousar mejor los pandas . Pero no te hagas ilusiones demasiado altas. Hay límites estrictos para lo que pueden hacer los pandas. Está bien: no fue diseñado para ser el final del análisis de datos.

Las dos mejores alternativas cuando necesita escalar sus cargas de trabajo de datos son:

• PySpark . Spark es un motor para análisis a gran escala y procesamiento de datos en paralelo. PySpark le permite aprovecharlo con Python y utiliza una sintaxis que recuerda a pandas. Incluso tiene API de pandas.

  
  

• Almacén de datos . Un sistema para almacenar y analizar datos a gran escala (piense en terabytes y petabytes). Los almacenes de datos modernos se ejecutan en la nube para que pueda aprovechar el poder de los sistemas distribuidos sin administrar ningún servidor. BigQuery, la solución de almacenamiento de datos de Google Cloud, puede procesar 100 mil millones de filas o 7 terabytes de datos en 30 segundos . Los almacenes de datos suelen trabajar con SQL. (Si quieres probar BigQuery gratis, escribí sobre eso aquí).

¿Cuándo es mejor Pandas?

No quiero que evites a los pandas. Es una herramienta increíble que definitivamente vale la pena aprender.

Hay casos en los que pandas es una mejor opción que SQL. No entraré en detalles aquí, pero aquí hay una lista rápida:

• Cuando se integra con otros flujos de trabajo de Python, por ejemplo, está haciendo aprendizaje automático o desea usar una biblioteca de visualización de Python.

  
  

• Cuando necesite algunas estadísticas rápidas. El método describe() es muy útil.

  
  

• Cuando necesite realizar un análisis rápido, sin preocuparse por la escala o la reproducibilidad. Aunque Excel o Google Sheets podrían funcionar igual de bien.

  
  

• Si está creando aplicaciones de Python. Los pandas pueden ser la forma más rápida de pasar de una estructura de datos arbitraria a una tabla y viceversa.

  
  

• Cuando realmente necesita flujos de trabajo y bucles imperativos. Por ejemplo, construir simulaciones de Markov.

  
  

• Cuando necesite escribir o reutilizar funciones inusuales. Pandas es excelente para aplicar funciones arbitrarias de Python.

  
  

• Si tienes un flujo de trabajo muy dinámico y parametrizado.

Conclusión

Espero que este artículo lo haya estimulado a pensar más profundamente sobre SQL y pandas y sus fortalezas y debilidades relativas.

Creo que la tendencia actual en los datos se ha inclinado demasiado a favor de los pandas, y que ignora SQL bajo su propio riesgo.

Aquí está mi consejo:

• Si es un aprendiz : estudie SQL y aprenda a usarlo para sus análisis. No te arrepentirás.

  
  

• Si es un diseñador de planes de estudios : ahogue a sus alumnos en SQL hasta que sueñen en tablas y hablen en mayúsculas. Es un amor duro y te odiarán por ello, pero cuando llegue el día lo entenderán. (Sin embargo, no los golpees en la cabeza).

  
  

• Si es un mentor : trate de alejar gradualmente a sus alumnos de Pandas y anímelos a intentar problemas en SQL.

  
  

Me encantaría iniciar una conversación. Siéntase libre de dejar un comentario, escribirme un correo electrónico o agregarme en LinkedIn .