Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLecció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.
17 min aprox.
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.
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.
Una dimensión tiene 20 millones de filas pero sólo se necesitan dos columnas y los registros activos son el 1 %. ¿Qué harías antes del join?
Profundiza
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.Resumen
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.