Mastering Modern Pandas

Hola, soy Alex de DEV STORIES DOT EU. Dominando pandas moderno, episodio 1 de 8. Te traes dos columnas de datos financieros, las sumas, y el resultado final no tiene sentido. Las filas se han desplazado, y simplemente le has sumado el precio de cierre de ayer al volumen de hoy. Eso pasa cuando tratas los datos como una cuadrícula tonta en lugar de confiar en la abstracción fundamental: los DataFrames y la alineación de labels. La gente suele mirar pandas y pensar que es solo una hoja de cálculo programática o un array de NumPy bidimensional estándar. No lo es. Un array de NumPy normal depende de un indexing posicional estricto. Si sumas dos arrays, el elemento en la posición cero se suma al elemento en la posición cero. Si a tus datos les falta una fila, todo se desplaza y tus cálculos se corrompen en silencio. Pandas resuelve exactamente este problema desacoplando los datos de su posición física en memoria. Utiliza una alineación de datos intrínseca, lo que significa que alinea los datos por labels, nunca por posición. Para entender esto, fíjate en la base de la librería: las Series. Una Series es un array unidimensional que puede contener cualquier tipo de dato. A diferencia de una lista estándar, cada elemento de una Series está firmemente unido a un label. Estos labels en conjunto forman lo que pandas llama el index. Puedes usar números enteros como labels, pero lo más normal es usar strings o timestamps. Un DataFrame es simplemente una colección de estos objetos Series actuando como columnas, todos compartiendo el mismo index, situados uno al lado del otro. Aquí está la clave. Cuando haces una operación en pandas, el index dicta el comportamiento. Digamos que tienes dos Series de rendimientos diarios de acciones. La Series A tiene datos para el lunes, martes, miércoles y jueves. La Series B tiene datos para el miércoles, jueves y viernes. Si le dices a pandas que sume estas dos Series, ignora su orden físico. Se fija en los labels de fecha. Encuentra el miércoles en la Series A y lo suma al miércoles en la Series B, aunque el miércoles sea el tercer elemento en el primer dataset y el primer elemento en el segundo dataset. Esto saca a relucir el problema de los días que no se solapan. El lunes existe en la primera Series, pero no en la segunda. El viernes existe en la segunda, pero no en la primera. Pandas no hace crash, y desde luego no se inventa un valor. En su lugar, crea un nuevo index que es la unión de todos los labels de ambos inputs. Para cualquier label que no exista en ambos sitios, pandas inserta un NaN, que significa Not a Number. La operación se completa con éxito, y puedes ver inmediatamente dónde están incompletos tus datos. Nunca tienes que escribir un loop para comprobar si las fechas coinciden. La alineación es automática, integrada directamente en la propia estructura de datos. Esta misma lógica escala directamente a los DataFrames. Un DataFrame se alinea en ambas dimensiones simultáneamente. Cuando operas con dos DataFrames, pandas empareja label de fila con label de fila, y nombre de columna con nombre de columna. Alinea toda la estructura a la perfección antes de ejecutar una sola operación matemática. Cualquier cosa que no se solape tanto en las filas como en las columnas se marca como missing data. El verdadero poder de pandas no son las matemáticas que realiza, sino el hecho de que el label siempre viaja con los datos, haciendo que los desajustes posicionales sean estructuralmente imposibles. Si quieres apoyar el programa, puedes encontrarnos buscando DevStoriesEU en Patreon. Gracias por escuchar, ¡y happy coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. Dominando Pandas Moderno, episodio 2 de 8. Extraes un slice de tus datos, actualizas un solo valor y, de repente, tu dataset original se corrompe. O peor aún, recibes un warning impredecible y no tienes ni idea de si tu actualización se aplicó realmente al slice o al origen. La versión 3.0 finalmente resuelve este caos haciendo que Copy-on-Write sea el comportamiento por defecto. Copy-on-Write redefine por completo la forma en que pandas gestiona la memoria. En versiones anteriores, pandas hacía copias defensivas con frecuencia para evitar que modificaras accidentalmente el dataset original. Si filtrabas un dataset, pandas lo copiaba. Si hacías drop de una columna, pandas copiaba el resto. Esto desperdiciaba cantidades enormes de memoria y ciclos de CPU. Cuando no copiaba, devolvía una view, lo que significaba que modificar el nuevo objeto alteraba silenciosamente al padre. Con Copy-on-Write, cualquier DataFrame o Series derivado de otro comparte exactamente la misma memoria subyacente. Esto significa que sacar un subset, hacer drop de una columna o hacer un reset del index es prácticamente instantáneo. No se duplica ningún dato de antemano. Aquí está la clave. No confundas una view tradicional con una lazy copy de Copy-on-Write. En una view tradicional, tanto el padre como el hijo apuntan a la misma memoria, y un cambio en uno cambia al otro. Copy-on-Write es diferente. La memoria compartida es temporal y está estrictamente protegida. El uso compartido solo dura hasta que intentas cambiar algo. Considera un escenario concreto. Tienes un DataFrame que contiene perfiles de usuario. Seleccionas la columna age y la asignas a una nueva variable llamada age subset. En este preciso instante, age subset ocupa cero memoria extra. Apunta directamente al DataFrame original de perfiles de usuario. A continuación, actualizas el primer valor en tu age subset a noventa y nueve. Aquí es donde entra la parte write de Copy-on-Write. Pandas detecta la modificación. Antes de ejecutar tu actualización, comprueba si algún otro objeto está compartiendo este bloque de datos específico. Dado que el DataFrame padre aún lo está utilizando, pandas asigna instantáneamente nueva memoria, copia los datos y luego escribe el valor noventa y nueve en la nueva ubicación. Tu DataFrame padre permanece intacto y seguro. Mutar un subset nunca muta al padre. Este mecanismo funciona a la perfección en operaciones encadenadas. Cuando encadenas operaciones como hacer drop de filas vacías, reemplazar valores y renombrar columnas, las versiones más antiguas de pandas creaban una copia física en cada uno de los pasos. Con Copy-on-Write, esos pasos intermedios simplemente comparten memoria. Una copia física solo se activa cuando un paso muta realmente los arrays de datos subyacentes. Si una operación solo reorganiza referencias, no se produce ninguna copia. Esto elimina por completo la corrupción accidental de datos. Ya no tienes que adivinar si una operación devolvió una view o una copy, y nunca más volverás a ver el warning de Setting With Copy. La regla es absoluta: un objeto padre y un objeto hijo nunca se modificarán entre sí. Al posponer las copias hasta el milisegundo exacto en que ocurre una modificación, pandas te da el rendimiento rápido y el bajo consumo de memoria de las views, combinado con la estricta seguridad de las deep copies. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. Dominando Pandas Moderno, episodio 3 de 8. Cargas un dataset con varios millones de filas y, de repente, el uso de memoria se dispara por las nubes. Los números están bien, pero las columnas de texto y los missing values están destrozando tu RAM silenciosamente. La solución es un cambio fundamental en cómo pandas almacena los datos, y de eso trata exactamente este episodio: The PyArrow Engine Room. Si has oído hablar de Apache Arrow, puede que pienses que es estrictamente para grandes sistemas distribuidos como Spark o Hadoop. Pues no lo es. Arrow es ahora un formato de memoria nativo de primera clase y un execution engine integrado directamente en pandas. Durante años, pandas ha dependido completamente de NumPy. NumPy es increíblemente rápido para cálculos numéricos densos, pero tiene un enorme punto ciego en lo que respecta a los missing data. NumPy no tiene un concepto nativo de un integer missing o un boolean missing. Si tienes una columna de integers y falta un solo valor, históricamente pandas se ha visto obligado a convertir toda la columna a números de coma flotante solo para poder usar el marcador Not a Number. Esto cambia tus data types, arruina las coincidencias exactas y consume más memoria. PyArrow resuelve esto usando un validity bitmap. En lugar de cambiar el data type para acomodar un missing value, Arrow mantiene tus integers como integers. Añade un array oculto y altamente comprimido de unos y ceros junto a tus datos. Un uno significa que el valor es válido. Un cero significa que es missing. Tu data type se mantiene intacto, y rastrear los missing values cuesta casi cero memoria. Aquí está la clave. El ahorro de memoria es aún más extremo cuando se trata de texto. Tradicionalmente, pandas almacena los strings usando el data type object de NumPy. Esto significa que la columna no contiene realmente tu texto. Contiene punteros de memoria. Cada fila apunta a un objeto string estándar de Python disperso en algún otro lugar de la memoria de tu ordenador. Si tienes diez millones de filas de texto, tienes diez millones de punteros y diez millones de objetos string separados. El overhead de memoria es asombroso, e iterar sobre ellos es terriblemente lento. PyArrow cambia la arquitectura por completo. Cuando configuras tus columnas de pandas para usar un data type string de PyArrow, el texto se almacena en un único bloque de memoria contiguo. La columna simplemente hace un seguimiento de los byte offsets. Registra exactamente dónde empieza y termina cada palabra en ese gran bloque continuo. Imagínate un dataset de alta cardinalidad. Tienes una columna de strings de user agent o IDs de transacción únicos. Muchas de las filas están vacías. Si lees esto en pandas de la forma tradicional, por defecto se convierte en un array object de NumPy. Ahora, dile a pandas que use el engine de PyArrow en su lugar, asignando explícitamente un data type string basado en PyArrow durante tu paso de lectura. Al instante, el memory footprint cae, a menudo en un cincuenta por ciento o más. La mejora va más allá de los límites de la RAM. Como los datos ahora están empaquetados de forma compacta en una estructura construida para analítica, las operaciones de string matching se aceleran. Si ejecutas una búsqueda con expresiones regulares en esa columna, el engine de Arrow procesa los raw bytes directamente a nivel de sistema. Evita por completo el lento overhead de los objetos de Python. Obtienes columnas de integers que realmente se mantienen como integers cuando hay missing data, y operaciones de strings que no ahogan tu hardware. Si procesas texto o datos desordenados, depender del array object de NumPy está obsoleto. Usar data types basados en PyArrow es la forma más rápida de hacer que un pipeline pesado de pandas sea más ligero al instante. ¡Gracias por escuchar, happy coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. Dominando Pandas Moderno, episodio 4 de 8. Tienes un archivo Parquet de varios gigabytes con cien columnas. Solo necesitas cuatro de ellas para ejecutar tus métricas. Si lo primero que haces es cargar todo el archivo en un dataframe y luego filtrar las columnas, estás desperdiciando una enorme cantidad de RAM y ciclos de CPU antes incluso de que comience tu análisis. La solución reside en dominar la ingesta de datos moderna. El principal cuello de botella en la ingesta de datos es el input y output de disco. Las funciones read de Pandas, como read underscore csv y read underscore parquet, escanean los datos del disco a la memoria. Para minimizar esta transferencia, usas un argumento llamado usecols. Pasas una lista con los nombres exactos de las columnas que quieres. El parser lee solo esas columnas específicas del archivo. La mejora de rendimiento que ves depende en gran medida del formato de tu archivo. Los archivos CSV almacenan los datos fila por fila. Cuando usas usecols con un CSV, el parser aún tiene que escanear todo el archivo de texto fila por fila, pero descarta inmediatamente las columnas innecesarias antes de reservar memoria para el dataframe. Los archivos Parquet, en cambio, almacenan los datos columna por columna. Para un archivo Parquet de cien columnas donde solo necesitas cuatro columnas de métricas, pasar usecols significa que el parser ignora por completo los bloques de archivo que contienen las otras noventa y seis columnas. Lee solo los bytes que absolutamente necesita del disco. Esto reduce drásticamente tanto tu tiempo de lectura como tu memory footprint. Restringir las columnas es solo el primer paso. La siguiente optimización ocurre en cómo Pandas almacena esas columnas en memoria. Históricamente, Pandas dependía completamente de los arrays de NumPy. NumPy es excelente para cálculos numéricos densos, pero tiene dificultades con los datos de texto y los missing values. Almacena los strings como objetos de Python dispersos en la memoria, y obliga a las columnas de integers a convertirse en floats solo para representar los datos faltantes. Para solucionar esto, Pandas introdujo el argumento dtype backend. Cuando configuras este argumento al string pyarrow, Pandas usa Apache Arrow para respaldar tus datos en su lugar. Arrow almacena los strings en bloques de memoria contiguos y de alta eficiencia, y usa un bitmask independiente para rastrear los missing values, manteniendo tus integers intactos. Aquí está la clave. Podrías pensar que Pandas lee primero los datos en arrays de NumPy y luego los convierte a Arrow. Eso no es lo que pasa. Cuando especificas el backend PyArrow durante la función read, Pandas omite NumPy por completo durante la fase de parse. Los datos fluyen directamente desde el archivo en disco a los arrays de PyArrow en memoria. Esto evita la severa penalización de rendimiento de las memory allocations intermedias. Veamos el pipeline completo. Llamas a read underscore parquet. Primero, pasas la ruta de tu archivo. Segundo, pasas usecols con una lista de tus cuatro columnas de métricas. Tercero, configuras el argumento dtype backend a pyarrow. El parser salta directamente a las cuatro columnas en disco, las extrae y las envía por stream directamente a la memoria respaldada por Arrow. Terminas con un dataframe ligero y ultrarrápido que contiene exactamente lo que necesitas, respaldado por tipos de datos modernos. Filtrar las columnas en la capa de IO en lugar de en la capa de aplicación es la forma más efectiva de evitar crashes de out-of-memory en Pandas. Eso es todo por este episodio. Gracias por escuchar, y ¡sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. Dominando Pandas Moderno, episodio 5 de 8. Tienes una lista de diez millones de transacciones, y cada una solo tiene un customer ID. Necesitas los nombres reales de los clientes asociados a esas transacciones. Si escribes un loop en Python o usas un mapping de diccionario para relacionar esos IDs con los nombres, estás desperdiciando ciclos de CPU y memoria. Pandas tiene un motor optimizado diseñado específicamente para operaciones estilo SQL en una sola línea. Hoy hablamos de álgebra relacional: Merge y Join. Antes de seguir, aclaremos una confusión común. La gente suele confundir hacer merge con concatenar. La concatenación es simplemente apilar físicamente arrays uno encima del otro o uno al lado del otro. El merge es completamente diferente. El merge es para hacer joins de bases de datos relacionales. Alinea las rows de dos tablas diferentes basándose en los valores de las keys compartidas. La función principal para esto es pandas punto merge. Recibe dos DataFrames, que llamamos la tabla izquierda y la tabla derecha. Piensa de nuevo en nuestro escenario de transacciones. Tu DataFrame izquierdo es una fact table enorme que contiene millones de compras. Tu DataFrame derecho es una dimension table más pequeña que contiene detalles de los clientes, como nombres y direcciones de email. Ambas tablas comparten una columna llamada customer ID. Esta configuración específica se llama un join many-to-one. Tienes muchas transacciones que pertenecen a un solo cliente. Cuando haces el merge usando la key customer ID, pandas coge el registro único del cliente de la tabla derecha y hace un broadcast a todas las transacciones que hacen match en la tabla izquierda. Aquí está el punto clave. El parámetro más crítico que controlas es el argumento how. Este dicta qué keys sobreviven al merge y llegan al resultado final. Por defecto, pandas usa un inner join. Si no especificas el argumento how, el resultado solo mantiene las rows donde el customer ID existe en ambas tablas. Si un cliente hizo una transacción pero su registro se borró de la base de datos de clientes, esa transacción desaparece por completo de tu resultado del merge. Para evitar perder datos de tu tabla principal, usas un left join. Al pasarle left al argumento how, pandas mantiene cada una de las rows de tu tabla izquierda, que es tu lista masiva de transacciones. Si una transacción tiene un customer ID que no existe en la tabla derecha, pandas sigue manteniendo la row de la transacción, pero rellena los detalles del cliente que faltan con valores Not a Number. Esta es exactamente la lógica que quieres cuando adjuntas detalles de la dimension table a una fact table principal. Exactamente lo opuesto es un right join. Pasarle right mantiene todas las rows de la dimension table de clientes, independientemente de si tienen alguna transacción que haga match en la tabla izquierda. Terminas con una lista de todos los clientes, y aquellos que no han comprado nada simplemente muestran missing values para los datos de la transacción. Finalmente, está el outer join. Pásale outer al argumento how, y pandas lo mantiene todo. Hace la unión de las keys de ambos frames. Cada transacción y cada cliente llega al dataset final, con missing values rellenando los huecos donde no se encuentra un match perfecto. El inner join por defecto descarta silenciosamente los datos que no hacen match, así que, a menos que quieras filtrar rows explícitamente, siempre deberías especificar un left join cuando adjuntes lookup tables a tu dataset principal. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. Dominando Pandas moderno, episodio 6 de 8. Probablemente pienses que agrupar datos consiste simplemente en consolidar números para obtener un total o una media. Pero, ¿qué pasa si necesitas evaluar una sola fila basándote en el comportamiento del grupo al que pertenece, sin perder la forma original de tu dataset? Esto requiere ir más allá de los simples resúmenes y usar el patrón Split-Apply-Combine. Cuando llamas a un método groupby en pandas, desencadenas un proceso secuencial de tres pasos. El primero es el split. Pandas toma todo tu dataset y lo divide en grupos independientes basándose en una key que tú le proporcionas. El siguiente es el paso apply, donde se ejecuta una función sobre cada grupo de forma totalmente independiente de los demás. Por último, el paso combine toma los resultados de cada grupo y los vuelve a unir en una única estructura de datos. Muchos desarrolladores creen que el paso apply sirve estrictamente para hacer agregaciones. La agregación toma un grupo de valores y devuelve un solo número, como la suma o la media. Si agrupas un dataset de atención al cliente por agente y pides el tiempo medio de resolución, obtienes un nuevo dataset con una fila por agente. Eso es útil, pero es solo un tercio de la historia. Aquí está la clave. El paso apply se utiliza con la misma frecuencia para la transformación y el filtrado. Una transformación realiza un cálculo sobre el grupo, pero devuelve un objeto indexado exactamente igual que los datos originales. No reduce el número de filas. Volvamos a nuestro dataset de atención al cliente. Quieres saber si un ticket específico tardó un tiempo inusual en resolverse. Pero un tiempo inusual para un agente junior podría ser un tiempo normal para un agente senior que gestiona problemas muy complejos. Necesitas el z-score del tiempo de resolución, relativo únicamente a la media histórica de ese agente en específico. Divides los datos por agente y aplicas una función de transformación que calcula el z-score. Pandas calcula la media y la desviación estándar para el agente A, estandariza los tickets del agente A, hace exactamente lo mismo para el agente B, y luego los combina. Recuperas tu dataset original, fila por fila, pero ahora cada ticket tiene un score estandarizado basado estrictamente en su contexto de grupo específico. La tercera aplicación principal es el filtrado. Esto te permite descartar grupos completos basándote en una propiedad colectiva, en lugar de evaluar filas individuales. Supongamos que quieres analizar los z-scores de esos tickets, pero algunos agentes de tu dataset solo procesaron dos o tres tickets. Sus medias carecen de significado estadístico. Puedes usar una función filter en tu objeto agrupado para comprobar el tamaño de cada grupo. Si un grupo tiene menos de diez tickets, la lógica del filter devuelve false, y pandas descarta todas y cada una de las filas pertenecientes a ese agente. El paso combine devuelve entonces un dataset que contiene solo los tickets de los agentes con un tamaño de muestra válido. Divides los datos por una key, aplicas una regla lógica que evalúa el grupo, y combinas los supervivientes. La agregación reduce los datos. La transformación estandariza los datos dentro de su contexto local. El filtrado descarta datos según las reglas de grupo. El verdadero poder del patrón Split-Apply-Combine es que te permite manipular filas individuales utilizando el contexto a nivel de grupo, sin tener que escribir nunca un loop manual. Si estos análisis a fondo te resultan útiles y quieres apoyar el programa, puedes buscar DevStoriesEU en Patreon. Me gustaría tomarme un momento para darte las gracias por escucharnos; nos ayuda muchísimo. ¡Que tengas un gran día!

Hola, soy Alex de DEV STORIES DOT EU. Dominando Pandas Moderno, episodio 7 de 8. Programar a mano tus propias agregaciones de tiempo es una pesadilla de intervalos perdidos, años bisiestos y lógica de días laborables. Si te ves escribiendo código personalizado para redondear raw timestamps en buckets regulares, te estás complicando demasiado la vida. La solución es dominar las time series usando las estructuras temporales nativas de pandas. La base de la funcionalidad de time series en pandas es el DatetimeIndex. En lugar de los clásicos números de fila enteros, el index de tu dataframe se convierte en una secuencia estricta de timestamps precisos. Actualizar tu index a un DatetimeIndex cambia por completo cómo se comporta el dataframe, haciendo que toda la estructura sea consciente del tiempo. Esto permite hacer slicing nativo basado en el tiempo. Si solo necesitas datos de octubre de 2023, le pasas el simple string "2023-10" al row locator. Pandas calcula automáticamente los límites exactos al microsegundo para ese mes y devuelve el subset correcto. Puedes pasar strings de fecha parciales hasta la hora o el minuto, y el index resuelve las matemáticas del timestamp subyacente. Una vez que tus datos son conscientes del tiempo, normalmente necesitas agregarlos. Muchos desarrolladores confunden el resampling basado en el tiempo con el grouping básico. Intentan aplicar operaciones group-by estándar a una columna de fecha. Ese enfoque falla cuando te enfrentas a time series del mundo real, que suelen ser caóticas. El grouping estándar solo se fija en las filas explícitas que están presentes en tu dataframe. Si un servidor se cae durante una hora, una operación group-by estándar simplemente se salta esa hora por completo. El timeline de salida tendrá un hueco oculto, arruinando cualquier cálculo posterior basado en el tiempo. Aquí está la clave. El método punto resample es fundamentalmente diferente porque entiende la lógica del calendario de forma nativa. Proyecta un grid de tiempo rígido y continuo sobre tus datos. Si haces un resample en intervalos de diez minutos, y no llegan datos durante una ventana específica de diez minutos, pandas genera ese bucket igualmente. Deja los valores vacíos, preservando la estricta integridad matemática de tu timeline. El resampling entiende por naturaleza los intervalos vacíos, la duración irregular de los meses y los calendarios de días laborables que excluyen fines de semana y festivos. Imagina el caso de un analista cuantitativo procesando datos de trading. Estás recibiendo datos de tick de alta frecuencia de un exchange. Los trades individuales llegan a intervalos completamente irregulares: a veces tres por microsegundo, a veces ninguno durante veinte segundos. Tu modelo de precios no puede consumir este caos. Necesita barras de cinco minutos perfectamente alineadas. Como los precios de tus trades están mapeados a un DatetimeIndex, llamas al método punto resample en tu dataframe y le pasas el string de frecuencia "5min". Esto mapea cada tick errático a un grid estricto de cinco minutos. Para alimentar un modelo financiero, necesitas específicamente los precios Open, High, Low y Close para cada bucket. En lugar de escribir funciones a medida para extraer el primer, máximo, mínimo y último trade de cada ventana, encadenas el método punto ohlc directamente a tu llamada de resample. Pandas calcula las cuatro métricas a la vez, devolviendo un dataset limpiamente estructurado de barras de cinco minutos. Esos intervalos vacíos que mencionamos antes permanecen intactos en este output. Luego, puedes encadenar otro método para hacer un forward-fill de los precios de cierre anteriores en los huecos vacíos, asegurando que tu modelo siempre tenga datos válidos. El resampling transforma registros erráticos basados en eventos en un timeline predecible y matemáticamente sólido, sin que tengas que escribir ni una sola línea de lógica de calendario. Gracias por escuchar. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Dominando Pandas Moderno, episodio 8 de 8. Antes de solicitar una instancia masiva en la nube o recurrir a un clúster de computación distribuida, te sorprenderá saber que puedes procesar terabytes de datos directamente en tu portátil. La mayoría de los errores de out-of-memory no requieren un nuevo framework, solo un cambio en la forma de leer los archivos. Hoy hablaremos sobre cómo escalar a datasets out-of-core. El procesamiento out-of-core simplemente significa trabajar con datasets que son mayores que la memoria del sistema disponible. Una reacción común ante un crash por out-of-memory es asumir que pandas ha alcanzado su límite máximo. A menudo, la gente pasa directamente a reescribir sus pipelines en PySpark o Dask. Pero pandas puede manejar datos masivos de forma nativa si dejas de intentar cargar todo el dataset en la RAM de una sola vez. Unos simples patrones de generator resuelven la gran mayoría de estos problemas de escalado. El mecanismo principal para el procesamiento out-of-core es el chunking. Si trabajas con un único archivo de texto de gran tamaño, la función read estándar acepta un argumento chunk size. Al proporcionar este argumento, pandas deja de devolver un DataFrame. En su lugar, devuelve un iterator. Cada vez que tu código avanza el iterator, pandas lee solo el número de filas especificado del disco y las devuelve como un DataFrame normal. Aplicas tu lógica a ese chunk, extraes el resultado y descartas el chunk. Como los datos antiguos se borran de la memoria antes de leer el siguiente batch, tu uso de memoria se mantiene completamente plano independientemente de lo grande que sea el archivo subyacente. Aquí es donde la cosa se pone interesante. La infraestructura de datos moderna rara vez depende de archivos de texto gigantes. Normalmente, los datasets grandes se almacenan en directorios que contienen cientos de archivos más pequeños y particionados, generalmente en un formato binario como Parquet. Los archivos Parquet están altamente comprimidos y se cargan muy rápido, pero aun así no puedes cargar cincuenta gigabytes de archivos Parquet en dieciséis gigabytes de RAM. Para manejar esto, aplicas el concepto de chunking manualmente a través de los archivos. Imagina que tienes un directorio con archivos Parquet anuales y quieres calcular la frecuencia total de las categorías en todo el dataset histórico. Construyes un bucle iterativo sencillo. Primero, inicializa una Series de pandas vacía. Esta actuará como tu acumulador para los totales globales. A continuación, itera por tu directorio archivo por archivo. Dentro del bucle, lee el archivo actual en un DataFrame. Ahora, ejecuta la función value counts en la columna específica que estás analizando. Esto te da una Series con las frecuencias solo para ese año específico. El paso crucial es combinar este resultado local con tu acumulador global. Lo haces llamando al método add en tu Series global y pasándole la Series local. Como algunas categorías pueden existir en un archivo pero no en otro, debes establecer el argumento fill value a cero. Esto garantiza que pandas alinee correctamente los índices y sume los recuentos sin introducir missing values. Una vez que el bucle termina de procesar ese archivo, pasa al siguiente. Python hace un garbage collect automático del DataFrame antiguo. Básicamente, estás haciendo streaming de un dataset masivo a través de la memoria un archivo a la vez, creando una agregación global continua. El procesamiento out-of-core no consiste en meterle más hardware a un problema. Se trata de mantener tu estado activo reducido y llevar las agregaciones matemáticas al nivel de cada chunk individual. Dado que este es el final de la serie, te animo encarecidamente a que explores la documentación oficial de pandas sobre escalado y pruebes estos patrones de forma práctica con tus propios datos. Si tienes temas que quieres que cubramos en futuras series, visita devstories dot eu y háznoslo saber. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.