Polars: ETLs de Alto Rendimiento

¿Por qué cambiar algo que funciona?

Si vienes de DA-201, pandas ya es tu navaja suiza: cargas un CSV, limpias columnas, agrupas, unes tablas y exportas un resultado. Para muchos análisis de unos pocos miles de filas, pandas es perfecto y no hay razón para tocarlo.

El problema aparece cuando los datos crecen. Llega el día en que un groupby tarda minutos, un merge agota la memoria del portátil, o un pipeline que corría en segundos sobre 100.000 filas se arrastra durante media hora sobre 50 millones. Ahí es donde el diseño interno de pandas empieza a pasar factura.

Polars no es "pandas pero más rápido por arte de magia": es una arquitectura distinta que ataca, una por una, las limitaciones estructurales de pandas. Esta lección es conceptual a propósito: antes de escribir una sola expresión de Polars, conviene entender por qué es más rápido. Así sabrás cuándo te dará una ventaja real y cuándo no merece la pena migrar.

Las cuatro limitaciones de fondo de pandas

Las razones por las que pandas se queda corto no son bugs ni mala programación: son consecuencias directas de decisiones de diseño tomadas hace más de quince años, cuando los conjuntos de datos eran pequeños y los procesadores tenían un solo núcleo rápido.

1. Ejecución eager, paso a paso, sin visión global

pandas es eager: cada operación se ejecuta en el instante en que la escribes. Cuando encadenas varias transformaciones, pandas no ve la consulta completa; ejecuta cada línea de forma aislada y materializa un resultado intermedio en memoria tras cada paso.

# pandas ejecuta esto en 3 pasos independientes,
# creando 2 DataFrames intermedios que se descartan
df2 = df[df["pais"] == "ES"]      # 1) filtra TODAS las columnas
df3 = df2.assign(iva=df2["precio"] * 0.21)  # 2) crea columna
resultado = df3[["pedido_id", "iva"]]        # 3) y al final tira casi todo

Nadie le dice a pandas que al final solo necesitas dos columnas. Por eso filtra y copia las 40 columnas del DataFrame, aunque 38 acaben en la basura. No hay un optimizador que reordene el trabajo para hacer menos.

2. Un solo núcleo (single-thread)

La mayoría de las operaciones de pandas corren en un único hilo. Tu portátil tiene 8 o 16 núcleos, pero durante un groupby pesado 15 de ellos están de brazos cruzados mientras uno solo suda. pandas fue diseñado en una época en la que esto no importaba; hoy es desperdiciar la mayor parte de la máquina.

3. Modelo basado en NumPy + índice: memoria y rigidez

Un DataFrame de pandas es, en esencia, una colección de arrays de NumPy más un índice (el famoso Index). Ese diseño tiene tres costes:

• Memoria. NumPy no maneja bien los valores faltantes ni los textos. Para permitir NaN, las columnas de enteros se promueven a float64; las cadenas de texto se guardan como object, es decir, un array de punteros a objetos Python dispersos por la memoria — lento de recorrer y pesado.
• El índice. Es una estructura extra que hay que mantener, alinear y, muy a menudo, fuente de bugs sutiles (reset_index, alineaciones inesperadas, SettingWithCopyWarning).
• Copias. Muchas operaciones copian datos enteros en lugar de reaprovecharlos.

4. Sin optimizador de consultas

Una base de datos SQL, antes de ejecutar tu consulta, la planifica: empuja los filtros lo más pronto posible, descarta columnas que no se usan, reordena los joins. pandas no hace nada de esto. Ejecuta literalmente lo que escribiste, en el orden en que lo escribiste, aunque haya un camino mucho más barato para el mismo resultado.

La propuesta de Polars

Polars reconstruye el DataFrame desde cero con tecnología moderna, atacando exactamente esos cuatro puntos:

• Motor escrito en Rust. El núcleo no es Python: es un motor compilado en Rust, un lenguaje de sistemas tan rápido como C pero con seguridad de memoria. Python solo es la fina capa con la que tú hablas; el trabajo pesado ocurre en código nativo.
• Paralelismo multinúcleo por defecto. Polars reparte el trabajo entre todos los núcleos de tu CPU automáticamente. No tienes que configurar nada: un group_by usa toda la máquina.
• Backend Apache Arrow, columnar. Los datos se guardan en formato Apache Arrow: columnas contiguas en memoria, con un tipo claro y soporte nativo de nulos (sin promover enteros a float). Recorrer una columna contigua es ideal para la caché de la CPU y para procesar muchos valores de golpe (vectorización SIMD). Y no hay índice: una columna es una columna, sin estructura paralela que mantener.
• Modo lazy con optimizador de consultas. Además del modo eager (inmediato, como pandas), Polars ofrece un modo lazy: describes todo el pipeline y Polars construye un plan de consulta, lo optimiza (empuja filtros, poda columnas que no usas, reordena operaciones) y después lo ejecuta. Igual que una base de datos.

Ese último punto convierte el ejemplo anterior en algo radicalmente más eficiente: si Polars ve que al final solo quieres pedido_id e iva, leerá y procesará únicamente esas columnas desde el principio. Es la diferencia entre cargar un camión entero para entregar dos cajas, o cargar solo las dos cajas. Lo veremos a fondo en el Módulo 3.

Las dos arquitecturas, lado a lado

El siguiente diagrama resume la diferencia de fondo. A la izquierda, pandas: arrays de NumPy pegados a un índice, ejecutados de inmediato en un solo hilo. A la derecha, Polars: columnas Arrow que pasan por un motor de consultas en Rust capaz de optimizar y paralelizar.

Tabla resumen: pandas vs Polars

Fíjate en la última fila: pandas no desaparece. Su ecosistema (integraciones, tutoriales, librerías que lo esperan como entrada) sigue siendo el más amplio. La cuestión nunca es "pandas está roto", sino "para este trabajo, ¿qué arquitectura encaja mejor?". Esa decisión la afinaremos en el Módulo 5.

¿Cuánta diferencia hace en la práctica?

Las cifras dependen del hardware y de la operación, pero el patrón es consistente: en cargas con agregaciones y joins sobre millones de filas, Polars suele ser varias veces más rápido que pandas y consumir bastante menos memoria, gracias al paralelismo, al formato columnar y (en lazy) al optimizador. La siguiente gráfica es ilustrativa del orden de magnitud de la ventaja en un group_by pesado — en el Módulo 5 lo mediremos tú y yo con timeit sobre datos reales, sin creernos los números de nadie.

Ideas clave para llevarte

• pandas se queda corto por cuatro razones de diseño: ejecución eager sin visión global, un solo núcleo, modelo NumPy+índice costoso en memoria, y ausencia de optimizador.
• Polars responde con motor en Rust, paralelismo multinúcleo, backend columnar Apache Arrow (sin índice) y un modo lazy con optimizador que planifica la consulta antes de ejecutarla.
• El formato columnar de Arrow no es un detalle: hace que recorrer y agregar columnas sea drásticamente más eficiente, y maneja texto y nulos sin inflar la memoria.
• Polars no jubila a pandas: lo complementa. La ventaja crece con el tamaño de los datos y la complejidad del pipeline; en datasets pequeños la diferencia es irrelevante.
• En las próximas lecciones pasamos de la teoría a las manos: tu primer DataFrame de Polars, la API de expresiones y, más adelante, las mediciones de rendimiento reales.

Comprueba lo que aprendiste

Antes de seguir, verifica que identificas correctamente qué limitación de pandas explica cada escenario: