Ejecución especulativa en Spark: ¿red de seguridad o multiplicador de costo oculto?

Con la especulación activada, Spark vigila las tareas que van significativamente más lentas que la mediana en su stage y lanza un intento duplicado en otro lugar, quedándose con el que termine primero.

El caso donde funciona exactamente como debe

Una sola tarea atascada en 10 veces la duración mediana mientras el resto de las tareas del stage terminan con normalidad es el caso de manual: un nodo con problemas, un vecino ruidoso en infraestructura compartida, un hipo transitorio de disco o de red. La especulación lanza un duplicado, el duplicado termina en un nodo sano, y el job se recupera sin que nadie reciba una alerta - exactamente la red de seguridad para la que fue diseñada.

El caso donde empeora las cosas

El sesgo de datos produce el mismo síntoma superficial - una tarea mucho más lenta que el resto - por una razón completamente distinta: esa tarea simplemente tiene más datos que procesar. La especulación lanza un duplicado de una tarea que nunca iba a terminar rápido sin importar qué nodo la ejecute, así que pagas por dos intentos lentos en lugar de uno, sin ninguna mejora en el tiempo real de finalización. La tarea sesgada de todos modos termina la última.

Cómo distinguirlas antes de activar el interruptor

Revisa el tamaño de entrada de datos, no solo la duración, de la tarea lenta frente a sus pares en el mismo stage. Un tamaño de entrada aproximadamente parejo con una tarea muchísimo más lenta apunta a un problema de infraestructura con el que la especulación sí ayuda de verdad. Una tarea lenta con visiblemente más datos de entrada (de "Input Metrics" o de los bytes de shuffle read en el event log) es sesgo - el arreglo ahí es reparticionar o hacer «salting» de la clave del join, no la especulación, que solo duplica el costo de una tarea que siempre iba a ser la más larga.