Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 4 de 5
Shuffle partitions y file sizing
Selecciona broadcast, sort-merge u otra estrategia según tamaño, tipo de join, estadísticas y riesgo para el driver y los executors.
- Duración
- 17 min aprox.
- Objetivo
- Selecciona broadcast, sort-merge u otra estrategia según tamaño, tipo de join, estadísticas y riesgo para el driver y los executors.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Tuning avanzado de Spark
Optimiza con evidencia del plan y las métricas, no con recetas globales ni más cómputo por defecto.
- Diagnosticar skew y spill
- Ajustar joins y particiones
- Evaluar UDF, Pandas UDF y funciones nativas
04DiagnósticoShuffle partitions y file sizing
Selecciona broadcast, sort-merge u otra estrategia según tamaño, tipo de join, estadísticas y riesgo para el driver y los executors.
+
Shuffle partitions y file sizing
Selecciona broadcast, sort-merge u otra estrategia según tamaño, tipo de join, estadísticas y riesgo para el driver y los executors.
Un broadcast hash join replica la relación pequeña y evita repartir la grande por la clave. Es excelente para una dimensión realmente pequeña, pero peligroso si las estadísticas están obsoletas o si el lado difundido crece: la transferencia y la tabla hash consumen memoria en cada executor. Los hints expresan una preferencia al optimizador, no corrigen una semántica de join incompatible.
Para joins grandes, el sort-merge distribuye ambos lados y paga shuffle y ordenación. Reduce primero las filas y columnas, conserva estadísticas y observa si hay claves calientes. En SQL y DataFrames, el criterio no es 'broadcast siempre es más rápido', sino coste total, compatibilidad del tipo de join y evidencia estable en ejecuciones representativas.
Modelo mental
Una estrategia de join decide dónde se encuentran las filas, cuánto dato viaja y qué memoria se replica. Broadcast lleva una relación pequeña a cada executor y evita redistribuir la grande; sort-merge redistribuye ambos lados por clave y los ordena; shuffle hash también reparte y construye mapas por partición. No existe una estrategia universalmente rápida. La elección depende del tamaño después de filtros y proyecciones, el tipo de join, la distribución de claves, la calidad de estadísticas y los límites de memoria. El modelo mental correcto compara coste total y riesgo: red, ordenación, memoria repetida, posible skew y estabilidad cuando el lado supuestamente pequeño crece.
Lado del join usado para construir la estructura hash, local o difundida.
Determina memoria, compatibilidad con outer joins y qué conjunto debe permanecer acotado.Operación que recopila y distribuye una relación a los executors que ejecutan el join.
Evita un shuffle grande, pero replica bytes y puede fallar si la relación crece.Estrategia que reparte ambos lados por clave, los ordena y fusiona secuencialmente.
Escala a relaciones grandes a cambio de red, ordenación, memoria temporal y posible spill.from pyspark.sql import functions as F
active_products = (
spark.table("prod.ref.products")
.where("is_active = true")
.select("product_id", "category")
)
enriched = orders.join(F.broadcast(active_products), "product_id", "left")
enriched.explain("formatted")Documenta el tamaño máximo esperado de `active_products`; un snapshot pequeño hoy no garantiza que siga siendo difundible.
Puntos clave
- Difunde sólo relaciones acotadas cuyo tamaño conoces en producción.
- Un hint no cambia qué lado puede difundirse en cada tipo de join.
- Actualiza estadísticas y compara el plan físico, no sólo el código fuente.
Evita
- Forzar broadcast a partir de un `count()` de muestra que no representa el máximo diario.
- Difundir una tabla ancha cuando bastaba proyectar dos columnas de la dimensión.
Recuerdo activo