Optimizando el uso de Pandas
Cargando Datasets
Uno de los problemas más habituales que nos encontramos cuando trabajamos con datasets es el tiempo que la librería de Pandas puede llegar a tardar en cargar los datos, como ejemplo vamos a tomar un dataset con 15 millones de registros y 35 columnas. Si cargamos nuestro dataset de ejemplo de la forma habitual con la función read_csv de pandas:
Comprobamos que ha tardado 47.4 segundos en cargar el dataset completo, puede parecernos poco 47 segundos, pero si es algo que tenemos que hacer todos los días o incluso varias veces al día y no sólo una persona sino por ejemplo un equipo de 4-5 ingenieros puede llegar a ser un poco desesperante y bastante costoso (5 ingenieros si cargan el dataset de medía 2 veces diarias -> 2370 segundos a la semana, más de media hora perdida en cargar datasets).
Existen diferentes alternativas disponibles que nos permiten hacer lo mismo, pero con mayor eficiencia, por ejemplo, la librería datatable, veámosla en acción con nuestro dataset:
Como podemos comprobar ahora tarda tan sólo 26 segundos en cargar el mismo dataset, hemos ahorrado casi un 50% de tiempo.
Ahorrando memoria
Veamos un ejemplo de cómo podemos ahorrar memoria fácilmente, que es otro de los grandes problemas cuando trabajamos con datasets complejos. Los diferentes tipos de datos que tenemos en pandas son:
Pandas dtype | Python type | Uso |
object | Str o Mezcla | Texto o Mezcla de valores numéricos y no numéricos |
int64 | int | Valores Enteros |
float64 | float | Valores en coma flotante |
bool | bool | Verdadero o Falso, |
datetime64 | datetime | Fecha y Hora |
timedelta | No Existe | Diferencia entre dos Fechas |
category | No Existe | Lista finita de valores de texto |
El tipo que más consume es el dtype object, luego los de tipo float e int. Una variable instanciada con cualquiera de los tipos disponibles al final lo que consume es una parte de la memoria de la computadora que estemos usando, así que la idea es declarar cada variable que dispongamos en el tipo que consuma menos memoria. De la documentación oficial de numpy podemos ver todos los tipos de datos disponibles:
Tipo de Dato | Descripción |
bool_ | Booleano, verdadero o falso, se guarda en un byte |
int_ | Entero por defecto, normalmente int64 o int32 |
intc | Como en C |
intp | Entero usado para indexar |
int8 | Byte (-128 a 127) |
int16 | Entero (-32768 a 32767) |
int32 | Entero (-2147483648 a 2147483647) |
int64 | Entero (-9223372036854775808 a 9223372036854775807) |
uint8 | Entero positivo (0 a 255) |
uint16 | Entero positivo (0 a 65535) |
uint32 | Entero positivo (0 a 4294967295) |
unit64 | Entero positivo (0 a 18446744073709551615) |
float_ | Punto flotante |
float16 | Coma flotante, mitad de precisión, exponente con 5 bits, mantisa con 10 bits |
float32 | Coma flotante, exponente con 8 bits, mantisa con 23 bits |
float64 | Coma flotante, doble de precisión, exponente con 11 bits, mantisa con 52 bits |
complex_ | Complejos |
complex64 | Número complejo representado por dos números en coma flotante de 32 bits |
complex128 | Número complejo representado por dos números en coma flotante de 64 bits |
Normalmente nos interesa usar float16, float32 y init8, int16 o init32. Creamos una función para realizar dicha conversión, la función lo que va a hacer es por cada columna de nuestro dataframe comprobamos si es de tipo entero(int) o de coma flotante(float), extraemos el valor mínimo y el valor máximo por cada columna y vamos comprobando de menor a mayor si podría encajar en el tipo de dato que menos memoria consuma, por ejemplo si el valor mínimo de la columna es –100 y el mayor es 15.000 podemos transformarlo a int16 y así sucesivamente, veamos la ejecución de nuestra función con nuestro dataset de ejemplo:
Hemos ahorrado un 29,2% de memoria.
Comprobamos que tenemos el mismo dataset:
Como vemos tenemos las mismas filas, columnas y datos.
Últimos artículos
Acerca del autor
Juan Manuel Pruaño
Con más de 15 años de experiencia contrastada como proveedor de servicios especializado en el módulo técnico de SAP (SAP BASIS), ha trabajado en empresas consultoras y cliente final de primer nivel tanto en Europa como en EE.UU.
En los últimos 10 años ha desarrollado su actividad en entornos SAP altamente securizados, sometidos a fuertes restricciones legales y continuamente auditados.
Actualmente forma parte del equipo de OGA ejerciendo como CTO / AI Lead y aportando su experiencia técnica multidisciplinar.
- Este autor no ha escrito más artículos.