Errores habituales al trabajar con DataFrames grandes en Pandas (y cómo evitarlos)

Hay un momento muy concreto en la vida de casi todo análisis: el código que funcionaba de maravilla con 10.000 filas empieza a arrastrarse, o a comerse toda la RAM, cuando llegan 10 millones. Lo curioso es que la mayoría de estos problemas ya estaban ahí desde el principio; simplemente no se notaban con datos pequeños.

En esta entrada repasamos los errores más comunes al trabajar con DataFrames grandes, por qué duelen tanto al escalar y, sobre todo, cómo corregirlos. Cada uno viene con su versión “mal” y su versión “bien”.

Iterar fila a fila en lugar de vectorizar

Es, con diferencia, el error número uno. Recorrer un DataFrame con iterrows() o un bucle for convierte una operación que Pandas haría en C sobre todo el array en miles (o millones) de operaciones de Python una a una.

# Lento: una iteración de Python por fila
resultados = []
for _, fila in df.iterrows():
    resultados.append(fila['precio'] * fila['cantidad'])
df['total'] = resultados

# Rápido: operación vectorizada sobre toda la columna
df['total'] = df['precio'] * df['cantidad']

La versión vectorizada no solo es más corta: suele ser decenas o cientos de veces más rápida. Como habíamos comprobado hace tiempo, hasta 375 veces más rápido. La regla mental es sencilla: si te ves escribiendo un bucle sobre las filas, casi siempre existe una operación vectorizada que hace lo mismo.

En Analytics Lane

Los récords con asterisco, o la épica del titular sin contexto – El bestiario de los indicadores económicos absurdos (parte 8 y final)

Abusar de apply(axis=1)

apply con axis=1 parece vectorizado, pero por dentro ejecuta tu función de Python fila a fila. Es básicamente un bucle disfrazado.

# Lento: aplica una función Python a cada fila
df['total'] = df.apply(lambda f: f['precio'] * f['cantidad'], axis=1)

# Rápido: aritmética vectorizada
df['total'] = df['precio'] * df['cantidad']

Para lógica condicional, tampoco hace falta apply: usa np.where, np.select o .mask/.where:

import numpy as np

# En lugar de un apply con if/else fila a fila
df['categoria'] = np.where(df['importe'] > 1000, 'alto', 'bajo')

apply no es el demonio,es útil cuando de verdad no hay alternativa vectorizada, pero no debería ser tu primera opción en conjuntos de datos grandes.

Construir el DataFrame concatenando dentro de un bucle

Crecer un DataFrame iteración a iteración es una trampa clásica. Cada concat crea una copia completa de todo lo acumulado hasta el momento, así que el coste total es cuadrático: O(n²).

# Mal: copia todo el DataFrame en cada vuelta
df = pd.DataFrame()
for archivo in archivos:
    df = pd.concat([df, pd.read_csv(archivo)])

# Bien: acumula en una lista y concatena UNA sola vez
partes = [pd.read_csv(archivo) for archivo in archivos]
df = pd.concat(partes, ignore_index=True)

Y si todavía usas df.append() en un bucle: ese método se eliminó en Pandas 2.0, precisamente por fomentar este patrón. Acumula en una lista y haz un único concat.

No cuidar los tipos de datos (dtypes)

Por defecto, Pandas es generoso con la memoria: enteros como int64, decimales como float64 y, lo peor de todo, texto como object. En tablas grandes, elegir bien los tipos puede reducir el consumo de memoria a la mitad o más.

Dos trucos que casi siempre ayudan:

Texto repetido → category. Si una columna tiene pocos valores distintos repetidos muchas veces (país, estado, categoría de producto), category guarda cada valor una sola vez:

df['pais'] = df['pais'].astype('category')

Números → reducir precisión con downcast. Si tus enteros caben en int32 o tus decimales en float32, no pagues por int64/float64, ya que supone duplicar la memoria necesaria para almacenar el Dataframe:

df['cantidad'] = pd.to_numeric(df['cantidad'], downcast='integer')
df['precio']   = pd.to_numeric(df['precio'],   downcast='float')

Lo ideal es fijar los tipos al leer el fichero, no después, como se explica en el punto siguiente.

Cargar todo el fichero cuando solo necesitas una parte

Hacer pd.read_csv('enorme.csv') y luego quedarte con tres columnas significa que cargaste a memoria todo lo demás para nada. read_csv tiene parámetros para no malgastar recursos:

df = pd.read_csv(
    'enorme.csv',
    usecols=['fecha', 'importe', 'cliente'],   # solo las columnas que usas
    dtype={'cliente': 'category'},             # tipos correctos desde el inicio
    parse_dates=['fecha'],                     # fechas como datetime, no como texto
)

Y si el fichero no cabe en memoria, procésalo por trozos con chunksize, agregando sobre la marcha:

total = 0
for trozo in pd.read_csv('enorme.csv', chunksize=100_000):
    total += trozo['importe'].sum()

Así nunca tienes el conjunto de datos completo en RAM, solo un trozo cada vez.

Indexación encadenada y el temido SettingWithCopyWarning

Este error es doble: no solo es lento, sino que puede no hacer lo que crees. La indexación encadenada (df[...][...] = ...) puede operar sobre una copia temporal en lugar del DataFrame original, de modo que la asignación se pierde silenciosamente.

# Mal: indexación encadenada → SettingWithCopyWarning, asignación poco fiable
df[df['edad'] > 65]['descuento'] = 0.1

# Bien: una sola operación con .loc
df.loc[df['edad'] > 65, 'descuento'] = 0.1

La regla: si vas a asignar sobre un subconjunto filtrado, usa siempre .loc[filas, columnas] en una única instrucción. Si solo quieres leer una porción y trabajar con ella aparte, pide explícitamente una copia con .copy().

No medir la memoria que realmente consumes

Es difícil optimizar lo que no mides. Y df.info() a secas miente con las columnas de texto, porque no cuenta lo que ocupan las cadenas en sí. Para una cifra real, usa deep:

df.info(memory_usage='deep')          # resumen con memoria real
df.memory_usage(deep=True)            # desglose columna a columna

Mirar el desglose por columnas suele ser revelador: muchas veces una o dos columnas object se llevan el 80 % de la memoria, y convertirlas a category lo arregla casi todo.

Bonus: saber cuándo Pandas se queda corto

A veces el problema no es tu código, sino que el conjunto de datos ya no es del tamaño para el que Pandas funciona correctamente. Antes de pelear con la RAM, conoce las alternativas:

• Backend de PyArrow (Pandas 2.0+): tipos más compactos y rápidos, sobre todo para texto y nulos, sin cambiar tu API:

  df = pd.read_csv('datos.csv', dtype_backend='pyarrow')

• Polars: una librería de DataFrames distinta, muy rápida y con menor consumo de memoria, pensada para datos grandes y operaciones perezosas (lazy).
• Dask: ejecuta una API parecida a la de Pandas en paralelo y sobre datos que no caben en memoria.

No hace falta migrar todo: a veces basta con usar PyArrow para una etapa concreta del pipeline.

Conclusiones

La buena noticia es que casi todos estos errores se corrigen con una o dos líneas. Y como muchos no se notan hasta que los datos crecen, interiorizarlos pronto te ahorra reescribir el análisis entero el día que el CSV pase de megas a gigas.

A modo de resumen, nos podemos quedar con los siguientes puntos:

• Vectoriza. Si escribes un bucle sobre las filas (iterrows, apply(axis=1)), casi siempre hay una versión vectorizada mucho más rápida.
• No hagas crecer el DataFrame en un bucle. Acumula en una lista y haz un único concat.
• Cuida los dtypes: category para texto repetido, downcast para números, y fíjalos al leer.
• Lee solo lo que necesitas: usecols, dtype, parse_dates y, si no cabe, chunksize.
• Asigna con .loc, nunca con indexación encadenada.
• Mide con memory_usage(deep=True) antes de optimizar a ciegas.
• Si Pandas se queda pequeño, valora el backend de PyArrow, Polars o Dask.

Image de Gerd Altmann en Pixabay