-
Notifications
You must be signed in to change notification settings - Fork 28.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SPARK-49846][SS] Add numUpdatedStateRows and numRemovedStateRows metrics for use with transformWithState operator #48317
base: master
Are you sure you want to change the base?
Conversation
… for use with transformWithState operator
cc - @neilramaswamy @HeartSaVioR - PTAL, thx ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably also want a suite for TTL (making sure we count the removal due to TTL in metrics), but the other comments are probably more important.
} | ||
} | ||
|
||
/** Remove this state. */ | ||
override def clear(): Unit = { | ||
store.remove(stateTypesEncoder.encodeGroupingKey(), stateName) | ||
TWSMetricsUtils.incrementMetric(metrics, "numRemovedStateRows") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, every time we append a value we add one to the numUpdatedStateRows
metric, even though we're not actually adding a row to RocksDB, we're merging something into an existing row.
But over here, we're counting removing an entire row (which may have multiple values all merged together) as one removal. So then if you do k
calls to appendValue
and then a clear()
, numUpdatedRows != numRemovedStateRows
.
I don't have a good solution for you (without iterating through everything in clear()
), but this does seem trickier than it might have initially seemed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@neilramaswamy - yes thats correct. we have that inherent limitation here since we either need to iterate on all the values on clear just to get the count or if we want to count only once - we need to do a get
explicitly each time we call appendValue
. Also, we don't really expect users to tally these numbers across batches since these are cumulative across all state operations on all variables. If you still think its too confusing for the users, I think its prob better to just mark this as TODO
for listState and we will circle back to this issue
@@ -301,6 +301,8 @@ class TransformWithListStateSuite extends StreamTest | |||
CheckNewAnswer(("k5", "v5"), ("k5", "v6")), | |||
Execute { q => | |||
assert(q.lastProgress.stateOperators(0).customMetrics.get("numListStateVars") > 0) | |||
assert(q.lastProgress.stateOperators(0).numRowsUpdated === 6) | |||
assert(q.lastProgress.stateOperators(0).numRowsRemoved === 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, seems like my earlier comment is getting at exactly this. It's 1 here, even though it should probably be 6? To the user, the fact that we use merge for lists is an implementation detail.
What changes were proposed in this pull request?
Add numUpdatedStateRows and numRemovedStateRows metrics for use with transformWithState operator
Why are the changes needed?
Without this change, metrics around these operations are not available in the query progress metrics
Does this PR introduce any user-facing change?
No
Metrics updated as part of the streaming query progress
How was this patch tested?
Added unit tests
Was this patch authored or co-authored using generative AI tooling?
No