Spark: RDDs y DataFrames
Resilient Distributed Dataset
Un RDD es una colección de partículas repartida entre nodos, tolerante a fallos por linaje. Se transforma con map, filter y reduce, y si un nodo cae, Spark reconstruye la partición perdida repitiendo los pasos del linaje.
Pereza y planificación
Las transformaciones son perezosas: construyen un grafo de instrucciones. Las acciones, como count o collect, disparan el cálculo. Esa separación deja al planificador fusionar y reordenar etapas.
Del RDD al DataFrame
El RDD obliga a pensar en partículas y escribir la lógica de datos a mano. DataFrame añade esquema y una capa que optimiza la consulta, como un motor SQL, quitando al programador el trabajo pesado.
Catalyst
- Un optimizador de consultas reescribe el plan lógico antes de ejecutarlo.
- Se aprovecha el esquema para podar columnas y empujar filtros al origen.
- Programar en DataFrame suele ser más rápido que en RDD puro por esa optimización.
Persistir en memoria
Cuando un resultado intermedio se reutiliza, conviene guardarlo en memoria o disco con persist. Es la herida que curaba Spark frente a MapReduce: evita recalcular y reescribir en cada etapa.
Shuffle aún pesa
Aunque sea rápido, el shuffle sigue siendo caro en Spark. Particionar bien y evitar reagrupaciones innecesarias marca la diferencia entre un job ágil y uno que se arrastra por mover datos entre nodos.
Cuándo cuál
DataFrame para casi todo: datos tabulares, optimización y claridad. RDD cuando hace falta control fino sobre partículas o estructuras no tabulares que el optimizador no entendería.
Errores frecuentes
- Encadenar acciones por error y provocar varios cálculos completos del mismo plano.
- Programar en RDD todo lo que es tabular y perder la optimización de Catalyst.
- Reparticionar sin necesidad y pagar shuffles que el job no pedía.
Ejemplo resuelto: acelerar un job que repite el mismo volumen
Un entrenamiento lee cada vuelta los mismos cien gigabytes y tarda una hora por iteración. La corrección:
- Medir primero dónde se va el tiempo, mirando el plan y las etapas con shuffle.
- Persistir en memoria el conjunto base que todas las iteraciones reutilizan.
- Preferir DataFrame para que el optimizador pode columnas y empuje filtros al origen.
- Reparticionar solo por la clave con la que se agrega, evitando reagrupaciones extra.
- Comprobar con el historial de etapas que la segunda iteración ya no relee el disco.
¿Para qué sirve en la realidad?
Todo trabajo iterativo, del machine learning a los gráficos de recomendación, relee el mismo dato vuelta y vuelta. Entender la pereza y la persistencia decide si el experimento tarda minutos u horas.
Encadenas varias transformaciones en un DataFrame y no ves que se calcule nada hasta llamar a una acción. El comportamiento se debe a que Spark es:
Un DataFrame suele rendir mejor que un RDD equivalente porque Spark puede optimizar la consulta.
Spark
Ordena el ciclo de vida de un job Spark perezoso:
Transformar
Planificar
Optimizar
Acción
Guía de RDDs de Spark
Programación con RDDs, transformaciones perezosas y linaje.
Une cada pieza de Spark con su papel.
No se calcula hasta que se pide
# Spark ## RDD ### control fino ### linaje reconstruye ### optimización a mano ## DataFrame ### esquema visible ### Catalyst poda y empuja ## Pereza ### planos sin calcular ### la acción dispara ## Memoria ### persist evita recalcular ### shuffle sigue caro
Guía de DataFrames de Spark
Documentación oficial del API de DataFrame y del optimizador Catalyst.
Tu job iterativo reprocesa cada vuelta el mismo gran volumen. ¿Dónde aplicarías persist y por qué no basta con confiar en la pereza? Razona por reuso y memoria frente a recalculo.