Fundamentos de la Interoperabilidad: El fin del "Memory Waste"¶

En el ecosistema de datos moderno, el movimiento de información entre diferentes herramientas (por ejemplo, de un motor de base de datos a un framework de análisis) suele ser el punto más débil del pipeline. Históricamente, este proceso implicaba una serialización costosa: convertir los datos de un formato interno a otro, consumiendo tiempo de CPU y duplicando el uso de memoria.

El objetivo de este módulo es entender cómo hemos pasado de un modelo basado en objetos (Pandas) a un modelo columnar estandarizado (Apache Arrow) que permite el intercambio de datos mediante Zero-copy.

El Cuello de Botella: "Memory Waste"¶

Para comprender la ventaja de las herramientas modernas, debemos analizar cómo gestionan la memoria.

El modelo de Pandas (Object-based)¶

Pandas fue diseñado originalmente para analizar datos tabulares pequeños y medianos. Internamente, gran parte de su estructura se basa en bloques de memoria que, en muchos casos, actúan como contenedores de objetos Python.

El problema: Cuando trabajamos con strings o tipos mixtos, Pandas almacena punteros a objetos dispersos en la memoria. Esto provoca:
- Fragmentación: Los datos no están contiguos, lo que impide que la CPU use el caché de forma eficiente.
- Sobrecarga (Overhead): Cada objeto Python tiene un coste de memoria adicional.
- Carga CPU: Para realizar una operación simple, Python debe "desempaquetar" cada objeto.

El modelo Columnar (Polars y DuckDB)¶

A diferencia de Pandas, herramientas como Polars y DuckDB utilizan un formato columnar. En lugar de almacenar filas de objetos, almacenan cada columna como un array contiguo de tipos primitivos.

La solución:
- Eficiencia de Caché: La CPU puede leer bloques enteros de una columna rápidamente.
- SIMD (Single Instruction, Multiple Data): Permite procesar múltiples valores de una columna con una sola instrucción de CPU.
- Menos Memoria: Se elimina la necesidad de almacenar punteros a objetos individuales.

Enfoque en Apache Arrow: El Estándar de Interoperabilidad¶

¿Cómo es posible que Polars y DuckDB compartan datos casi instantáneamente sin "convertirlos"? La respuesta es Apache Arrow.

¿Qué es Apache Arrow?¶

Apache Arrow no es una base de datos ni un lenguaje, sino una especificación de formato de memoria. Define exactamente cómo deben representarse los datos columnares en la RAM.

¿Por qué es un "Estándar"?¶

Antes de Arrow, cada herramienta tenía su propio formato interno. Pasar datos de DuckDB a Polars requería:
Formato DuckDB \(\rightarrow\) Serialización (CSV/JSON/Parquet) \(\rightarrow\) Deserialización \(\rightarrow\) Formato Polars.

Con Arrow, ambas herramientas hablan el mismo "idioma" en la memoria.

El concepto de Zero-copy¶

Gracias a que Arrow estandariza la disposición de los bytes en la RAM, es posible implementar el Zero-copy. Esto significa que una herramienta puede pasarle a otra la dirección de memoria donde residen los datos. La segunda herramienta lee esos bytes directamente, sin copiarlos ni transformarlos.

Resultado: El tiempo de transferencia es prácticamente cero, independientemente del tamaño del dataset.

Comparativa Práctica: Pandas 👉 Polars 👉 DuckDB¶

A continuación, veremos cómo estas tres herramientas gestionan la misma tarea, moviéndose desde el modelo tradicional hacia el modelo interoperable.

pip install polars duckdb pandas

import pandas as pd
import polars as pl
import duckdb

1. Carga de datos (CSVs)¶

Pandas (El enfoque tradicional)¶

Pandas lee el CSV y crea un DataFrame basado en bloques de memoria propios.

df_pd = pd.read_csv("EuropeSales.csv")
df_pd.head(3)

Polars (El enfoque Arrow-native)¶

Polars lee el CSV directamente en un formato compatible con Arrow.

df_pl = pl.read_csv("EuropeSales.csv")
df_pl.head(3)

DuckDB (El motor analítico)¶

DuckDB procesa el CSV y puede exportarlo a un DataFrame de Pandas o Polars aprovechando la interoperabilidad.

con = duckdb.connect()
df_duck = con.execute("SELECT * FROM 'EuropeSales.csv'").df()
df_duck.head(3)

2. Filtrado de Datos¶

Pandas¶

El filtrado en Pandas implica crear máscaras booleanas que se aplican sobre los objetos.

fpd = df_pd[df_pd.Country == "Ukraine"]
fpd.head(10)

Polars¶

Polars utiliza expresiones que pueden ser optimizadas antes de ejecutarse (Lazy Evaluation).

fpd = df_pl.filter(pl.col("Country") == "Ukraine")
fpd.head(10)

DuckDB¶

DuckDB puede realizar el filtrado directamente en el motor SQL antes de convertir el resultado a un DataFrame, optimizando la cantidad de datos que viajan a la RAM de Python.

df_duck = con.execute("SELECT * FROM 'EuropeSales.csv' WHERE Country LIKE 'Ukraine'").df()
df_duck.head(10)

3. Agregación de Datos¶

Pandas¶

El agrupamiento en Pandas es potente pero consume mucha memoria al crear objetos intermedios.

agg_pd = df_pd.groupby("Country")["Total Revenue"].sum().reset_index()
agg_pd.head(10)

Polars¶

Polars utiliza un motor de ejecución multihilo y optimizaciones de Arrow para realizar agregaciones masivas en paralelo.

agg_pl = df_pl.group_by("Country").agg([pl.sum("Total Revenue").alias("country_revenue")])
agg_pl.head(15)

DuckDB¶

DuckDB utiliza un motor vectorial (Vectorized Execution Engine), procesando datos en bloques (chunks) que encajan perfectamente en la caché de la CPU.

agg_duck = con.execute("""
    SELECT Country, sum("Total Revenue") AS country_revenue
    FROM 'EuropeSales.csv'
    GROUP BY country
    ORDER BY country
""").df()
agg_duck.head(10)