viirya commented on a change in pull request #30789:
URL: https://github.com/apache/spark/pull/30789#discussion_r544501647



##########
File path: docs/structured-streaming-programming-guide.md
##########
@@ -1689,6 +1689,23 @@ hence the number is not same as the number of original 
input rows. You'd like to
 There's a known workaround: split your streaming query into multiple queries 
per stateful operator, and ensure
 end-to-end exactly once per query. Ensuring end-to-end exactly once for the 
last query is optional.
 
+### State Store and task locality
+
+The stateful operations store states for events in state stores of executors. 
State stores occupy resources such as memory and disk space to store the states.
+So it is more efficient to keep a state store provider running in the same 
executor across different streaming batches.
+Changing the location of a state store provider requires to load from 
checkpointed states from HDFS in the new executor.
+
+The stateful operations in Structured Streaming queries rely on the preferred 
location feature of Spark's RDD to run the state store provider on the same 
executor.
+However, generally the preferred location is not a hard requirement and it is 
still possible that Spark schedules tasks to the executors other than the 
preferred ones.
+
+In this case, Spark will load state store providers from checkpointed states 
on HDFS to new executors. The state store providers ran in the previous batch 
will not be unloaded immediately.
+If in the next batch the corresponding state store provider is scheduled on 
this executor again, it could reuse the previous states and save the time of 
loading checkpointed states.
+Spark runs a maintenance task which checks and unloads the state store 
providers which are inactive on the executors.
+
+For some use cases such as processing very large state data, loading new state 
store providers from checkpointed states can be very time-consuming and 
inefficient.
+By changing the Spark configurations related to task scheduling, for example 
`spark.locality.wait`, users can configure Spark how long to wait to launch a 
data-local task.
+For stateful operations in Structured Streaming, it can be used to let state 
store providers running on the same executors across batches.

Review comment:
       Good point. I added few specific info.




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to