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
Toca una tarjeta para ver la respuesta.
Ordena el ciclo de vida de un job Spark perezoso:
Arrastra cada ficha a su categoría (o tócala y luego toca la categoría). También puedes usar el teclado.
Guía de RDDs de SparkProgramació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
- control fino
- linaje reconstruye
- RDD
- optimización a mano
- esquema visible
- planos sin calcular
- persist evita recalcular
Guía de DataFrames de SparkDocumentació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.
Tu texto se guarda sólo en este dispositivo.
Comentarios
Inicia sesión para comentar.
Todavía no hay comentarios. Sé la primera persona en opinar.