Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[SQL] State-store instance metrics are shipped in every task result

Cerrado
  • ¿Algo no está bien?
#58,394 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

@Diveyam-Mishra ya está trabajando en esto.

Desde el 2/9/2026.

  • #58476 de @Diveyam-Mishra — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
scala, sql
Área
data-engineering, distributed-systems

Línea de trabajo

Empieza con StateStoreWriter.stateStoreInstanceMetricsWithIds y setStoreInstanceMetrics, y luego sigue el manejo de los acumuladores a través de AccumulatorV2.readObject, Task.collectAccumulatorUpdates, Executor y TaskSetManager.canFetchMoreResults. Reproduce la carga de trabajo de ResultStage descrita, con un número elevado de particiones, e inspecciona los tamaños de los resultados de las tareas. La implementación terminada debería evitar que las métricas irrelevantes de instancias del state store inflen los resultados finales de las tareas, preservando al mismo tiempo las métricas de progreso requeridas del operador de estado.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

Stateful operators currently create one state-store instance metric accumulator for every combination of:

state partition
x supported provider metric
x state-store name

Every task then receives and registers all of those accumulators, even though it processes only one state partition. On task completion, all external accumulators are included in the task result.

For a job with 20,000 shuffle partitions, RocksDB state, and one default store, this can result in approximately 20,000 state-instance metric updates per task.

Reproduction

A representative workload is:

spark.sql.shuffle.partitions = 20000
stateful operator using RocksDB state
checkpoint or write the stateful result

Observed behavior:

per-task result size: approximately 3 MiB
number of tasks: approximately 20,000
terminal stage: ResultStage

The cumulative task-result data can therefore be approximately 60 GiB. The job may fail with spark.driver.maxResultSize even though the actual rows are written or checkpointed by executors.

The same issue can occur with direct file writes because the final write stage is submitted through SparkContext.runJob and uses ResultTasks. Each task returns a commit result plus accumulator updates.

Root cause

Relevant code paths on master include:

  • StateStoreWriter.stateStoreInstanceMetricsWithIds creates metrics for all state partitions, supported metrics, and store names.
  • StateStoreWriter.setStoreInstanceMetrics updates the corresponding per-instance SQLMetric.
  • AccumulatorV2.readObject registers all deserialized accumulators with the task.
  • Task.collectAccumulatorUpdates sends all external accumulators on successful task completion.
  • Executor serializes those accumulator updates into DirectTaskResult.
  • TaskSetManager.canFetchMoreResults applies spark.driver.maxResultSize to ResultStages.

ignoreIfUnchanged and numStateStoreInstanceMetricsToReport are applied while generating state-operator progress after the driver has received and merged the updates. They do not reduce the task-result payload.

Why checkpointing and direct writes are affected

RDD checkpoint materialization calls SparkContext.runJob, making the checkpointing stage a ResultStage.

Direct file writes also use runJob and return per-task write results or commit messages to the driver. Those task results contain the write result plus accumulator updates, so state-store metrics can contribute to the cumulative result size.

The spark.driver.maxResultSize check is not enforced for upstream ShuffleMapStages, but it is enforced for these terminal ResultStages.

Impact

This behavior causes:

  • inflated task-result serialization and network traffic;
  • increased executor and driver deserialization work;
  • large CompletionEvent payloads on the driver;
  • driver heap pressure if result processing falls behind task completion;
  • possible spark.driver.maxResultSize failures;
  • increased per-task metric metadata retained by scheduler or UI structures.

Scope

This is not specific to TransformWithState. It can affect any stateful operator using StateStoreWriter and a provider that exposes state-store instance metrics.

Multiple state stores, such as those used by streaming joins, multiply the number of metrics included in each task result.

Lenguaje dominante
Scala
Estrellas
44.3k
Forks
29.5k
Merge medio
8 h 43 min
PR fusionados (30 d)
1

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/spark

Todos los issues de apache/spark

Issues similares

Más issues de Scala

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.