Cuando Pandas no puede más: el problema que resuelve Spark

### El día que tu script dejó de funcionar

Imagina que llevas seis meses en tu primer trabajo como ingeniero de datos. Tu pipeline funciona perfecto: cada mañana a las 6:00, un script en Python lee el CSV de ventas del día anterior, lo limpia con Pandas, calcula métricas y lo carga en la base de datos del warehouse. El CEO está contento, tu jefe te felicita. La vida es bella.

Hasta que llega el Black Friday. Y luego Cyber Monday. Y luego la campaña de Navidad. De repente, el CSV diario ya no pesa 200 MB — pesa 2 GB. Tu script, que tardaba 3 minutos, ahora tarda 45. Y un día, el fatídico lunes tras Black Friday, el archivo pesa 8 GB. Tu máquina tiene 16 GB de RAM. Pandas intenta cargar el archivo entero en memoria... y tu proceso muere con un MemoryError. El dashboard del CEO está vacío a las 9:00 AM. Tu teléfono no para de sonar.

Este escenario no es ficción. Es exactamente lo que le pasa a miles de equipos de datos cada año cuando su empresa crece. Y la pregunta que te haces es: ¿cómo proceso datos que literalmente no caben en la memoria de mi ordenador?

### El muro de la máquina individual

Pandas es una herramienta brillante. Es rápida, expresiva, con una API intuitiva. Pero tiene una limitación fundamental que no es un bug, sino una decisión de diseño: Pandas opera en una sola máquina y carga TODO en memoria RAM. Cuando tus datos superan la RAM disponible, Pandas simplemente no puede funcionar. No hay truco, no hay parámetro mágico, no hay optimización que te salve.

Hagamos números concretos. Una máquina típica de desarrollo tiene 16 GB de RAM. El sistema operativo y las aplicaciones consumen unos 4 GB. Python y sus librerías necesitan otro 1-2 GB. Te quedan unos 10 GB "libres". Pero Pandas, al cargar un CSV, necesita entre 2x y 5x el tamaño del archivo en memoria (por las conversiones de tipo, índices, copias internas). Así que un CSV de 5 GB puede necesitar 15-25 GB de RAM. Simplemente no cabe.

1import pandas as pd
2
3# Supón que tu máquina tiene 32 GB de RAM (8 GB los usa el sistema)
4ram_total_gb = 32
5ram_sistema_gb = 8
6ram_disponible_gb = ram_total_gb - ram_sistema_gb
7
8print(f"RAM total: {ram_total_gb} GB")
9print(f"RAM disponible: {ram_disponible_gb} GB")
10
11# ¿Puede Pandas con un archivo de 12 GB?
12tamano_archivo_gb = 12
13factor_pandas = 3  # Pandas necesita ~3x en RAM (índices, tipos, buffers)
14ram_necesaria_gb = tamano_archivo_gb * factor_pandas
15
16print(f"Tamaño del archivo: {tamano_archivo_gb} GB")
17print(f"RAM que necesitaría Pandas: {ram_necesaria_gb} GB")
18
19if ram_necesaria_gb > ram_disponible_gb:
20    print("💥 MemoryError: no hay suficiente RAM para cargar este archivo")
21    print("   Pandas necesita ~3x el tamaño del archivo en memoria")
22else:
23    print(f"✓ Cabe: {ram_disponible_gb} GB disponibles > {ram_necesaria_gb} GB necesarios")

### La analogía del camión y la flota

Piensa en una mudanza. Tienes un apartamento pequeño: todo cabe en un solo viaje de camión. Pero un día te mudas a un almacén industrial con 500 toneladas de mercancía. ¿Qué haces? ¿Compras un camión del tamaño de un portaaviones? No — contratas una flota de 50 camiones que trabajan en paralelo. Cada camión lleva una parte de la carga, todos van al mismo destino, y entre todos terminan en una fracción del tiempo que tardaría uno solo.

Eso es exactamente lo que hace el procesamiento distribuido. En vez de intentar meter todos los datos en una sola máquina (el camión gigante imposible), los divides entre muchas máquinas que trabajan simultáneamente. Cada máquina procesa su porción, y al final los resultados se combinan. La suma de las memorias y CPUs de todas esas máquinas es tu capacidad real de procesamiento.

### Los números que debes tener en la cabeza

Para entender cuándo necesitas procesamiento distribuido, necesitas tener claro el orden de magnitud de los datos en el mundo real. Estos números no son teóricos — son lo que ves en empresas medianas y grandes:

• ▹Startup con 10.000 usuarios: logs diarios de 500 MB - 2 GB. Pandas puede.
• ▹E-commerce mediano (100.000 pedidos/día): datos diarios de 5-10 GB. Pandas empieza a sufrir.
• ▹Fintech con millones de transacciones: datos diarios de 50-200 GB. Pandas no puede. Necesitas Spark.
• ▹Red social o telco: datos diarios de 1-10 TB. Necesitas un cluster Spark potente.
• ▹Netflix, Google, Meta: datos diarios de petabytes. Clusters de miles de nodos.

La regla empírica es simple: si tus datos caben cómodamente en la RAM de tu máquina (digamos, menos de 1/3 de tu RAM), Pandas es perfecto y más rápido para prototipar. Si tus datos superan la RAM disponible — o si el procesamiento tarda más de lo aceptable en una sola máquina — es hora de Spark.

### ¿Por qué no simplemente comprar más RAM?

Es una pregunta legítima. Si mi máquina tiene 16 GB y necesito 64 GB, ¿por qué no alquilo una máquina con 256 GB de RAM en la nube? La respuesta es triple:

1. 01.Coste: una máquina con 256 GB de RAM cuesta mucho más que 16 máquinas de 16 GB. El escalado vertical (más potencia en una máquina) es exponencialmente más caro que el horizontal (más máquinas baratas).
2. 02.Límite físico: las máquinas más grandes del mercado tienen 12-24 TB de RAM. Suena como mucho, pero un dataset de 50 TB no cabe en ninguna máquina del planeta.
3. 03.Tiempo: aunque la RAM sea suficiente, un solo procesador necesita mucho más tiempo que 100 procesadores trabajando en paralelo. 1 hora con 1 CPU vs 1 minuto con 60 CPUs.

### Qué es Apache Spark (en 30 segundos)

Apache Spark es un motor de procesamiento distribuido que divide tus datos entre múltiples máquinas, ejecuta operaciones en paralelo en cada una, y combina los resultados. Es el sucesor natural de Hadoop MapReduce (que veremos en la siguiente lección) y hoy es el estándar de facto para procesar grandes volúmenes de datos en la industria.

PySpark es la interfaz Python de Spark. Escribes código que parece Python (y de hecho ES Python), pero por debajo Spark lo distribuye entre todas las máquinas de tu cluster. La API es muy similar a Pandas: tienes DataFrames, columnas, filtros, agrupaciones, joins. Pero con la diferencia crucial de que funciona con datos de cualquier tamaño.

1# Pandas: todo en una máquina
2import pandas as pd
3df = pd.read_csv("ventas_50gb.csv")  # 💥 MemoryError
4
5# PySpark: distribuido entre máquinas
6from pyspark.sql import SparkSession
7spark = SparkSession.builder.appName("ventas").getOrCreate()
8df = spark.read.csv("ventas_50gb.csv", header=True, inferSchema=True)  # ✓ Funciona
9# Spark NO carga todo en memoria de golpe.
10# Divide el archivo en particiones y las reparte entre los nodos.

### El concepto clave: particionar los datos

La idea central del procesamiento distribuido es la partición. En vez de tener UN archivo gigante de 50 GB, lo divides en 500 particiones de 100 MB cada una. Cada nodo del cluster recibe unas cuantas particiones, las procesa en paralelo, y devuelve su resultado parcial. Es como repartir exámenes entre 50 profesores: cada uno corrige 6 exámenes en vez de que uno solo corrija 300.

Spark hace este particionamiento automáticamente. Cuando le dices "lee este archivo", Spark decide cuántas particiones crear (basándose en el tamaño del archivo y la configuración del cluster) y las reparte entre los nodos disponibles. Tú no tienes que pensar en esto al principio — pero entenderlo es crucial para optimizar más adelante.

### Cuándo usar Spark vs Pandas: la regla de oro

• ▹Datos < 1-2 GB y procesamiento simple: Pandas. Más rápido, más fácil de debuggear, sin overhead de distribución.
• ▹Datos de 2-10 GB: zona gris. Pandas puede funcionar en máquinas con mucha RAM, pero empieza a ser lento. Evalúa caso por caso.
• ▹Datos > 10 GB: Spark. No hay alternativa práctica en una sola máquina.
• ▹Datos de cualquier tamaño pero procesamiento muy complejo (muchos joins, muchas iteraciones): Spark, porque paraleliza el cómputo aunque los datos quepan en RAM.
• ▹Prototipado rápido y exploración: siempre Pandas primero con una muestra pequeña. Luego escala a Spark.

En la siguiente lección vamos a entender cómo llegamos hasta aquí: la historia de Hadoop MapReduce, por qué era doloroso de usar, y cómo Spark lo reemplazó siendo 100 veces más rápido y mucho más sencillo de programar. Pero primero, vamos a practicar identificando cuándo Pandas no basta.