Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 1 de 5
Plan físico y métricas de stages
Aprende a distinguir skew real de una etapa simplemente costosa usando la distribución de tiempos, bytes y registros por tarea.
17 min aprox.
01Modelo mentalPlan físico y métricas de stages
Aprende a distinguir skew real de una etapa simplemente costosa usando la distribución de tiempos, bytes y registros por tarea.
+
Plan físico y métricas de stages
Aprende a distinguir skew real de una etapa simplemente costosa usando la distribución de tiempos, bytes y registros por tarea.
En Spark, una etapa termina cuando acaba su tarea más lenta. Por eso una media razonable puede ocultar una cola extrema: si la mediana dura 18 segundos y una tarea tarda 11 minutos, añadir workers no elimina la clave caliente que concentra datos. La evidencia útil está en la pestaña Stages de Spark UI: duración máxima frente a mediana, registros de entrada, shuffle read y tamaño de cada tarea.
Antes de aplicar salting, confirma la causa. Un join con una clave nula dominante, un cliente desproporcionado o una partición temporal demasiado amplia producen remedios distintos. AQE puede dividir particiones sesgadas en joins compatibles; si la distribución forma parte del negocio, conviene además aislar claves calientes o rediseñar la agregación y medir el efecto con el mismo conjunto de datos.
from pyspark.sql import functions as F
key_profile = (
orders.groupBy("customer_id")
.count()
.orderBy(F.desc("count"))
)
key_profile.show(20, truncate=False)
orders.where(F.col("customer_id").isNull()).count()La tabla de frecuencias no sustituye Spark UI, pero permite conectar una tarea extrema con una clave de negocio concreta.
Una etapa tiene 4.000 tareas; 3.995 duran menos de 25 segundos y cinco superan 12 minutos con diez veces más shuffle read. ¿Cuál es la primera hipótesis?
Profundiza
Imagina una etapa de Spark como una carrera por equipos cuyo tiempo oficial lo determina el último corredor. Cada partición produce una tarea y todas deben terminar antes de avanzar; por eso el promedio oculta el dato decisivo. El skew no significa simplemente que el conjunto sea grande, sino que el reparto de trabajo entre tareas es muy desigual. Una clave frecuente, un valor nulo dominante o un rango temporal desproporcionado concentra registros y bytes en pocas particiones. El diagnóstico correcto enlaza tres niveles: distribución del dato de negocio, particionado físico tras el exchange y cola de duraciones observada en Spark UI. Escalar compute mejora capacidad general, pero no redistribuye una clave caliente por sí solo.
Distribución en la que unas pocas claves o rangos concentran una fracción desproporcionada de registros y trabajo.
Convierte unas pocas tareas en el camino crítico aunque el clúster tenga capacidad ociosa.Frontera del plan físico que redistribuye datos entre executors, normalmente para joins, agregaciones o ventanas.
Es el punto donde la distribución lógica de claves se materializa como particiones y puede revelar skew.Tarea mucho más lenta que sus pares dentro de la misma etapa.
La etapa no finaliza hasta que termina el straggler; por ello el máximo pesa más que la media.Resumen
Puntos clave
- Compara percentiles y máximos por tarea, no sólo la duración media de la etapa.
- Relaciona la tarea lenta con sus bytes de shuffle y número de registros.
- Corrige la distribución de datos antes de aumentar capacidad de forma permanente.
Evita
- Confundir muchas tareas pequeñas con skew: en ese caso el problema puede ser sobreparticionado y overhead de planificación.
- Aplicar salting a todas las claves y encarecer el join aunque sólo una fracción mínima esté sesgada.